Data Extraction, Transformation and Integration Guided by an Ontology - Data Warehousing Design and Advanced Engineering Applications - page 26

located (x,z) ∧ Address (z) ∧ hasContact (x,t) ∧
Contact (t)…
Furthermore, we take into account classes that
have specializations in O . When specializations
correspond to central concepts, we build one view
per specialization. For example, Museum is a
specialization of CulturalPlace which is a central
concept. We build a new view for Museum : S 12
(x,y,z,t) → Museum (x) ∧ name (x,y) ∧ located (x,z)
∧ Address (z) ∧ hasContact (x,t) ∧ Contact (t)…
When subordinated concepts have specializa-
tions in O , our treatment depends on the cardi-
nality of the relation establishing a link with the
subordinated concept. If the cardinality is multiple
(non functional property) as the cardinality of the
relation hasContact in the example just before,
we will introduce all the classes that are special-
izations in the same view. That way, the source
S 1 providing instances of Museum as it is shown
in Figure 4 will be described by a unique view
grouping the class Museum , its properties and the
classes Address , Contact , Tel , Fax linked by the
relations located and hasContact : S 12 (x,y,z,t, t 1 ,
t 2 ) → Museum (x) ∧ name (x,y) ∧ located (x,z)∧
Address (z) ∧ hasContact (x,t) ∧ Contact (t) ∧
hasContact (x,t 1 ) ∧ Tel (t 1 ) ∧ hasContact (x, t 2 ) ∧
Fax (t 2 ).
On the opposite, if the relation is a functional
property, we build one view per specialization,
as it is done for central concepts with specializa-
tions.

wrappers follows the construction process of
views. We build one query per view. Queries are
built in an incremental way, performing at first
the concept, followed by its properties. For each
central concept named conceptC in O , we look
for the instances of its corresponding element (or
attribute) mapC in D ( FOR part). For each instance
we generate a unique identifier ( generate-Id ). The
name of the concept in O is used as a tag in the
Return part. Thus the initial form of the query is
the following:

for $x in doc(“source.xml”)//mapC
let $idcpt:= gi:generate-Id($x1)
return
<p3:conceptC rdf:nodeID=”{$idcpt}”>

$x is associated to mapC and contains all the
elements belonging to the tree rooted in mapC
in the XML source. The objective of the query
that we want to generate is to extract from $x
all the elements which are properties in O . For
this, we need mappings of these elements. The
extraction of attributes in XQuery is made by
indicating the path defined in the mapping and by
using the primitive Text() to obtain the element
without tags. The extraction of the relations needs
a new identifier for the subordinated concept. A
new XML fragment will be added to describe
the subordinated concept and its properties. If
the considered mappings are conditional, we
introduce a Where part in the query in order to
specify the condition.An example of a query lead-
ing to extract data from S 1 according to the view
S 12 (x,y,z,t) described above is given in Figure 5
(left side) and the extracted data in Figure 5 (right
side). S 12 (x,y,z,t) → Museum (x) ∧ name (x,y) ∧
located (x,z)∧ Address (z) ∧ Town (z,t).

Data Extraction and Transformation

For each view, we then generate a wrapper
which will query the XML source in regard to
its language and its vocabulary and transform
returned instances into RDF facts conformed to
the RDFS+ ontology. Wrappers are associated to
queries expressed in XQuery (Boag et al., 2007).
The FLWO part of a XQuery statement performs
the extraction task while the R part performs the
transformation task from XML to RDF using
the terms of the ontology. The construction of

Data Integration

Let S 1 and S 2 be two data sources which conform
to the same RDFS+ schema. Let I 1 and I 2 be the
two reference sets that correspond respectively