The INSPIRE Directive establishes a pan-European "Spatial Data Infrastructure" (SDI) to make available multiple thematic datasets from the EU member states through stable Geo Web-Services. Parallel to this ongoing procedure, the Semantic Web has technologically fostered the Linked Data initiative which builds up huge repositories of freely collected data for public access. Querying both data categories within distributed searches looks promising. To tackle the associated prerequisites, this paper presents rstly a general approach to translate sophisticated INSPIRE GML data models into Semantic Web OWL ontologies. This is done according to Linked Data principles while preserving selective INSPIRE structural information as annotations. Secondly, a feasible conversion of the Semantic Web query language SPARQL to its Geo Web counterpart "OGC Filter Encoding" is proposed. The language mapping is required for a semantic wrapper over remote INSPIRE Download Services acting as a SPARQL-endpoint and bridging the gap between both worlds.
The INSPIRE Directive (2007/2/EC)3 obliges national authorities of the EUmember states to contribute their spatial data according to over 30 harmonized themes (e.g. Hydrography, Protected Sites or Elevation), make them accessible and described via standardized Geo Web-Services. These datasets are considered to be up-to-date, quite reliably, EU-wide and mostly free available forming a very impressive data source for multi-thematic information retrieval.
Because of its free data usage and distributed service-architecture INSPIRE does have a lot in common with the Linked Open Data initiative (LOD). Combining both data worlds while starting federated searches over INSPIRE and LOD-datasets looks attractive as repositories di er in thematic coverage and
data capture conditions. As a scenario let us consider a teacher planning a school trip which should be lled with leisure activities as well as some kind of nature exploration. He nd accomodation and leisure facilities through Geo Linked Data4 and spatially overlay them with INSPIRE themes Land Use or Protected Sites. Finally the teacher may prepare himself with reliable background information referenced by INSPIRE data and disseminated by public authorities enriching the world of free data. The same governmental controlled Protected Sites data could be combined with the LOD project GeoSpecies5 to intersect INSPIRE protection goals with species populations from GeoSpecies at the same time.
To leverage such scenarios, the existing technological discrepancies between INSPIRE and LOD have to be overcome which are mainly due to di erent knowledge representation and web service interfaces. The goal is a feasible embedding of INSPIRE data in the Semantic Web. INSPIRE itself is based on the Geo Web technologies - which are ISO and OGC6 standardizations for Geo Web-services and -transfer formats. So INSPIRE applies the ISO/OGCapproach of modeling physical things, so-called "features", in the Geography Markup Language (GML)7. GML is a XML-derivative and GML data models are written in XML-Schema Language (XSD). Conventional GML data models de ne simple and at XML-documents having features with only few attributes and thus could be easily queried and transformed to Semantic Web RDF/OWLtriples. With regard to INSPIRE we are faced with advanced GML data models which disclose features with many dependant complex elements and a heavily nested, verbose XML-tree structure. That's why transforming GML to OWL is not straight-forward and target OWL-models in which to transform INSPIRE data must be well-thought-of for not generating triples without proper content.
Former work [
This paper presents a feasible way to perform SPARQL queries on INSPIRE which contains two main achievements. At rst we propose a general approach for deriving INSPIRE ontologies from the INSPIRE UML/GML data models in order to de ne the target models for SPARQL querying. We also suggest common modeling aspects and re nements for Semantic Web-representations 4 http://linkedgeodata.org/About 5 http://about.geospecies.org/ 6 Open Geospatial Consortium, see http://www.opengeospatial.org/ 7 http://www.opengeospatial.org/standards/gml 8 http://www.opengeospatial.org/standards/wfs due to Linked Data principles. Secondly we outline a SPARQL-endpoint - which is con gured with these INSPIRE ontologies and acting as a proxy over WFSservices which are the main realizations for INSPIRE Download Services. Therefore we specify a viable translation from SPARQL to the WFS-query language "OGC Filter Encoding (FE)"9 and tackle the prerequisite of references between the INSPIRE ontology concepts and the INSPIRE GML data structure. 2
Towards INSPIRE Linked Data - Basic Architecture To ful ll the overall goal for federated queries on INSPIRE and Linked Data, the INSPIRE data must be transformed into a Semantic Web representation as Semantic Web-formats are appropriate for integration tasks and SPARQL used to query di erent repositories in particular. Two key tasks are identied: 1. we need to create common target ontologies for INSPIRE themes and 2. provide query capabilities using SPARQL. INSPIRE UML- and derived GMLdata models are regarded as community harmonizations and thus have the same characteristics as Semantic Web domain ontologies. Hence each INSPIRE theme is syntactically transferred to one domain ontology (here called "INSPIRE theme ontology") while preserving INSPIRE element names. Common concepts from di erent themes, e.g. ISO metadata elements and spatial representations, are outsourced into core ontologies and imported into the theme ontologies if needed.
The reasons for explicit INSPIRE ontologies are: { they serve as target models for a proper GML!OWL conversion set-up { they store GML structural information as annotations needed for querying { they facilitate references to INSPIRE background information { they prepare the basis for alignment with Semantic Web upper ontologies
Querying capabilities help to perform requests and lter the desired instances from the requested repository. A smart way to support SPARQL queries over INSPIRE data can be accomplished with a proxy application, wrapping remote or local INSPIRE Download Services and acting as a SPARQL-endpoint; see Fig. 1. The architecture has multiple advantages. For instance, no data replication and additional storage facilities are needed, hence queries always access up-to-date datasets. Furthermore, INSPIRE data authorities are not bothered with extra con guration e orts required for semantic WFS-pro les.
SemanticWeb
Client
SPARQL
Query RDF/OWL
Semantic Proxy (SPARQL-endpoint)
Opposed to alternative solutions which comprise one single GML!OWLtransfer into a static INSPIRE triple-store building query facilities on top, the proxy solution has to cope with a virtual repository. That means that all resulting information is temporary and has to be combined with all side e ects. The biggest challenge is the query mapping from SPARQL as a powerful general query language to the less powerful language OGC Filter Encoding. The latter is supported by WFS-services and focuses on domain-optimized lters.
We rst introduce our proposed query strategy and more details will follow in Sec. 4. Fig. 2 shows the overall query procedure. A SPARQL query is received (1) and converted to SPARQL algebraic expression10 (2). The algebraic expression is assessed for INSPIRE concepts (3) for which XPath-expressions are concatenated to address the GML-element paths needed within Filter Encoding-query operators. Thereafter the translation SPARQL !Filter Encoding takes place (4) and the WFS GetFeature-request is send to all the WFS-services which serve the requested feature types (5). On return the GML-results are transformed to OWL-instances composing the virtual repository (6). This virtual repository is then queried with the former SPARQL-query from the second step (7) and nally SPARQL-results are returned to the user (8).
1. receive SPARQLrequest 2. convert SPARQLquery to -algebra 3. detect INSPIREconcepts 4. map SPARQL to OGC-Filter Encoding 8. return SPARQLresults 7. query virtual repository (SPARQL-query) 6. transform results (GML to OWL)
5. request WFS (GetFeature-operation)
The resulting INSPIRE ontologies are designed to allow custom queries, for instance to lter Protected Sites and GeoSpecies data. Therefore we outline signi cant query types which are regarded during ontology modeling (see Sec. 3.2) in order to keep ontological structures simple and adequate for querying: { distinguish instancies by its classi cation attributes, e.g. "which protected sites are classi ed with designation = 'UNESCO World Heritage' ?" { do spatial reasoning, e.g. "which species habitats crosses protected site x?" { lter temporally, e.g. "which sites originates from era x, between dates y/z?" { assess measures, e.g. "which sites suit a hike, sites greater than x km2?"
This paper continues in Sec. 3 with a description of engineering and modeling aspects of the proposed INSPIRE ontologies. Sec. 4 is about the concept of a semantic query layer and a prototype mentioned in Sec. 5. Then, Sec. 6 outlines related work and Sec. 7 closes with conclusions and possible advancements. 10 http://www.w3.org/TR/rdf-sparql-query/; see Sec. 12.4 "SPARQL Algebra"
Conversion rules: INSPIRE GML to RDF/OWL
Before examining ontological details, we have to consider the basic conversion
rules from the original GML INSPIRE data models (written in XSD) to the
targeted INSPIRE OWL ontologies. For generic XSD!OWL transformations
several approaches [
Given these modeling hints, we can list our few main rules which imply that derived OWL-concepts are named after corresponding INSPIRE element types: { every INSPIRE UML-class except stereotype union is converted to an owl:Class. Subtypes of stereotype union are modeled each as one owl:Class { every value of codelist or enumeration is converted to an owl:Individual typed with the corresponding enumeration/codelist owl:Class { every UML-attribute corresponding to a GML-property is converted to an owl:ObjectProperty or owl:DatatypeProperty. If multiple, equally-named GML-properties lead to both OWL property types we name the owl:DatatypeProperty with su x _dataValue to be conform to OWL-DL { every UML-association is converted to an owl:ObjectProperty
Modeling aspects of frequent elements Besides these general rules there have to be ontological re nements for frequently used element types which may leverage usual query types listed in the Sec. 2. This section will examine these aspects in more detail. Furthermore we present our considerations about OWL-instance identi cation and infrastructural opportunities with INSPIRE reference data.
Classi cations with codelist- and enumeration-types In INSPIRE data models every sixth element is of such a type which are best suited to di er and lter instances. We model every codelist-type as one owl:Class and every codelist-value as one owl:Individual. Enumeration-types are equally modeled. However there is a constraint owl:oneOf to their enumeration values.
Modeling this way allows us to investigate every codelist-value of a certain codelist, e.g. ont_ps:ProtectionClassificationValue with SPARQL triple: ?x rdf:type ont_ps:ProtectionClassificationValue and opens the possibility to annotate codelist-values with standard-annotations, e.g. rdfs:label. Codelist-value individuals are simply named after their codelist: e.g. the codelist <http://inspire.ex.org/ProtectionClassificationValue> has a value <http://inspire.ex.org/ProtectionClassificationValue/ archaeological>. Hence no naming con icts arise if two di erent codelists might have the same value names.
Geometries Concerning geometry handling, there is a current speci cation
development called GeoSPARQL [
Temporal values The conversion of INSPIRE temporal values to RDF/OWL is simple, since GML makes use of XSD-datatypes xsd:date or xsd:dateTime, too. Mostly resulting RDF typed literals are appropriate. Only in such cases where temporal values are coherent (e.g. start/end-times of a duration) complex RDF-resources have to be derived to retain the coherence and enwrap two or more typed literals for the actual temporal information (e.g. start/end-times). Measure values Measure values, e.g. the GML-types Area, Length or Velocity, consist of numeric values and corresponding units of measurement (UOM). The encoding in RDF could be a rdf:PlainLiteral, e.g. "200 km2", or a typed literal, such as "200"^^http://www.ex.org/units/km2. The rst option merges the two pieces of information within one textual representation, so that both would have to be discerned during analysis. The drawback of the typed literal would be the de nition of additional RDF-datatypes for maybe tens of UOM which should be avoided for interoperability reasons. Our design choice is therefore based on the "Measure Units Ontology"11 and shown in Fig. 3 (we use namespaces 'ont_ps' for the theme ontology "ProtectedSites" and 'base' for INSPIRE basic types). The two pieces of information are bundled by a separate base:Measure instance. For numeric values we can simply adopt the XSD-types used in GML (xsd:integer, xsd:decimal etc.) and treat the UOM as an individual RDF-resource. Thus, we are able to lter measure values due to their UOM not only in SPARQL lters but even within SPARQL basic graph pattern. ont_ps:ProtectedSite
base:Measure rdf:type
rdf:type ex:ProtectedSite1 ont_ps:officialsiteArea skos:inScheme http://inspire.ex.org/
CrsUomRegister base:unitOfMeasure http://inspire.ex.org/CrsUomRegister/
uom/area/hectare base:numericalValue
"22.8"^^xsd:decimal Registries for reference data Like UOM, other kind of reference data exist, e.g. coordinate reference systems (CRS), languages-codes, country-codes or the INSPIRE codelists/ enumerations. Language-codes are trivial and equally treated in both worlds, INSPIRE and Semantic Web, by using either ISO 639-1/2 or RFC 3066. Other reference data should be explained and collected somewhere online, accessible via resolvable URIs. It makes sense to manage them centrally and in a unique fashion. The OGC has started to make SKOS-concepts12 of speci cation elements and some CRS descriptions accessible online13. The main technical INSPIRE supporter, the JRC14 provides SKOS-concepts with the terms of the European GEMET-thesauri and the INSPIRE feature concept dictionary.15 Such infrastructural measurements will de nitely facilitate a Semantic Web-enablement of INSPIRE but also could have positive side-e ects for other domains, providing harmonized lists reused e.g. in folksonomies.
Identi cation As an important Linked Data principle, identi ers for RDFresources should be kept unique and resolvable via HTTP-URIs. All INSPIRE features are identi ed with unique INSPIRE-IDs which are used here for individual URIs of OWL-instancies. An INSPIRE-ID consists of 1.) a namespace 11 http://forge.morfeo-project.org/wiki_en/index.php/Units_of_measurement_ ontology 12 SKOS: Simple Knowledge Organization System; used for semantically modeling taxonomies; http://www.w3.org/TR/skos-primer/ 13 http://www.opengis.net/def/ 14 EU Joint Research Centre, http://www.jrc.ec.europa.eu/ 15 https://semanticlab.jrc.ec.europa.eu/ including details about the data-authority or -product, 2.) a localId which is an object identi er unique in the scope of the namespace and 3.) a versionId for an optional object versioning. These identifying attributes are proposed to be included in an HTTP-URI with additional format information for Linked Data content negotiation, distinguishing the return-format as e.g. page or data. So the proposed URI-template looks like: http://inspire.ex.org/fformatg/fnamespaceg/flocalIdg[=fversionIdg] and an example would be: http://inspire.ex.org/page/NL.KAD.AU.GEM/4507/V1.0 4
Semantic query layer for INSPIRE Download Services In this section we show at rst how to translate from SPARQL to the WFS-query language "OGC Filter Encoding" and then tackle the prerequisite of references between the INSPIRE ontology concepts and the INSPIRE GML data structure. 4.1
SPARQL conversion to OGC Filter Encoding We map from a given SPARQL algebraic expression into the target language of the OGC Filter Encoding. More precisely the target language is actually a combination of a) WFS-Query addressing the feature-type to be returned and b) OGC-Filter Encoding (FE) providing spatial, comparison and logical lter operators. From now on, we only mention OGC-Filter Encoding in lieu of both.
SPARQL as well as the XML-encoded FE are declarative languages but they operate on di erent information units: SPARQL combines triples while FE lters complex GML-features as WFS-records. Given the proposed INSPIRE ontologies one GML-feature and its dependant GML-elements are usually transformed to more than one triple, so FE actually lters at a coarser level than SPARQL does. Besides, there are SPARQL-functions which have no real FE-correspondents, e.g. isBlank(a), langMatches(a,b) or regex(a,b) (FE only supports a comparator with wildcards, not regular expressions). Furthermore SPARQL-solution modi ers could not be translated, either. With this in mind we conclude that SPARQL is more powerful (even though FE provides more domain-speci c lters, e.g. spatial ones). A translation to FE may loose lter information and may be too restrictive at the same time. A viable solution is a two-step query process. In the rst step, an overly coarse query is forwarded to INSPIRE Download Services returning a superset of intended query results. In the second step, the precise SPARQL query is re-executed on the returned result set in order to yield the intended SPARQL results.
Some SPARQL lter-functions and value-comparing graphpattern are mapped to FE comparison or spatial operators (e.g. SPARQL-function sameTerm(A,B) to FE-operator <PropertyIsEqualTo>). In cases where SPARQL applies pathcomparing pattern (e.g. ?feature ont_ps:siteName ?siteName), we propose the mapping to a combination of the two FE-operators <Not><PropertyIsNull> to assure that the resulting GML contains only features with these subelements (here the info siteName) for further SPARQL-analysis afterwards. The table 1 shows the mapping of the main SPARQL-operators to their FE-pendants.
like BGP-handling using both graph pattern P1 and P2 like BGP-handling, but only for mandatory branch P1, optional branch P2 and Filter F are ignored like BGP-handling using both lter F and graph pattern P translate every comparisons under pattern P1 into appropriate
This simple conversion example transforms SPARQL-path comparisons and one temporal lter: PREFIX xsd : <http : / /www. w3 . org /2001/XMLSchema#> PREFIX o n t p s : <http : / / i n s p i r e . ex . org / P r o t e c t e d S i t e s/> S e l e c t ? f e a t u r e ?name ? b e g i n L i f e s p a n Wheref ? f e a t u r e a o n t p s : P r o t e c t e d S i t e . ? f e a t u r e o n t p s : siteName ?name . ? f e a t u r e o n t p s : b e g i n L i f e s p a n V e r s i o n ? b e g i n L i f e s p a n .
FILTER( ? b e g i n L i f e s p a n > "2009 01 01T12 : 0 0 : 0 0 "^ ^ xsd : dateTime ) g to its corresponding WFS-GetFeature request (abbreviated): 4.2
Annotations for GML-element references In order to provide a SPARQL-endpoint which acts as a wrapper around WFSservices the SPARQL-endpoint must map INSPIRE ontologies to GML data models. When the SPARQL-endpoint receives a query, INSPIRE OWL-concepts have to be detected by their URIs (see Fig. 2, third step) and resolved to corresponding GML-element paths in order to compose a WFS-requests with OGC Filter Encoding lters (fourth step). For mapping OWL-concepts to GMLelements we annotate INSPIRE OWL-concepts with relative XPath-expressions for indicating their corresponding GML-element paths. We restrict the usage of XPath-version 1.0 to unique element references which means we avoid wild-cards for node-tests ('*') or predicate- ltering ('@*').
To this end we introduce instances of owl:AnnotationProperty: { Annotation property cf:xmlnamespace is used at ontology-level to indicate which GML XML-namespaces are used in the particular INSPIRE ontology, e.g. <http://inspire.ex.org/ProtectedSites> cf:xmlnamespace "xmlns:ps=\"urn:x-inspire:specification:gmlas: ProtectedSites:3.0\"". Given these annotations, abbreviations of GML XML-namespaces with XML-pre xes are unique in the scope of the ontology { Annotation property cf:xmlname is used at concept-level stating which OWLclass corresponds to which GML-object element, declared as a quali ed XML-name, e.g. ont_ps:ProtectedSite cf:xmlname "ps:ProtectedSite" or ont_ps:ResponsibleAgency cf:xmlname "ps-f:ResponsibleAgency" { Annotation property cf:xpath is used at concept-level, stating which OWLproperty corresponds to which GML-property, declared as a relative XPathexpression (only XPath forward axes), e.g. ont_ps:isManagedBy cf:xpath "ps-f:ProtectedSite/ps-f:isManagedBy/ps-f:ResponsibleAgency" With the cf:xpath-annotation, we adopt the triple-relationsship "subjectpredicate-object" to the GML-model where in the given example above the GMLobject element ps-f:ProtectedSite stands for the subject, GML-property ps-f:isManagedBy for the predicate, ps-f:ResponsibleAgency for the object. Figure 4 shows an example with annotations explained in detail subsequently: "ps:ProtectedSite"
In Fig. 4, the predicate ont_ps:siteName has a complex cf:xpath-annotation. This XPath-expression let us extract XML-information nested deeply within the XML-tree so that we can ignore verbose GML element hierarchies (e.g. ISOmetadata elements) which are not needed in triple form. The other annotations cf:langXPath and cf:targetRDFType work as transformation hints and are realized as rei cation annotations so that they are unique for every cf:xpath. The reason is that there might be the need to assign multiple cf:xpath to one OWL-predicate if di erent INSPIRE GML-properties are equally named (distinguished only by their superordinated GML-object type) and so are derived both to one OWL-predicate. Or if INSPIRE GML data models allow alternative element storage, so multiple GML element paths each as one cf:xpath must be applied. The additional annotation cf:langXPath indicates where to nd language-information about a text element directing there with a relative XPath-expression related to cf:xpath. The annotation cf:targetRDFType declares which RDF-datatype should be used for GML!OWL-transformation. Given the con guration example in Fig. 4, a transformation of this GML-snippet: <p s : P r o t e c t e d S i t e> . . . <ps:siteName> <gn:GeographicalName> <gn:language>deu</ gn:language> . . . <g n : s p e l l i n g> <gn:SpellingOfName> <g n : t e x t>K l e i n k i n z i g und Rotenbachtal</ g n : t e x t> <g n : s c r i p t x s i : n i l="t r u e "/> </ gn:SpellingOfName> </ g n : s p e l l i n g> </ gn:GeographicalName> </ ps:siteName> leads to the simple statement: ex:ProtectedSite1 ps:siteName "Kleinkinzig- und Rotenbachtal"@de
Other GML-information which is likewise related to another GML-element as the language-code could be handled in the same way. A good example is the UOM-information related to its measure-value, so there could be an annotation cf:uomXPath and so on. In order to nally prepare WFS-querying, we need at least one more annotation (i.e. cf:entityType) for OWL-classes indicating which corresponding GML-object element is expected to serve as a WFS-feature type. In this case, the OWL-class has the annotatation cf:entityType "featureType". 5
The INSPIRE test platform consists of the INSPIRE-enabled WFS "Deegree3 inspireNode"16 and representative test data. We have created two ontologies for the INSPIRE themes "Protected Sites" and "Administrative Units"17. These are tested with national Slovak protected sites (419 features, GML-size: 11 MB) and administrative units from the Dutch Kataster (443 features, GML-size: 23 MB). 16 WFS-version 1.1.0; http://www.deegree.org/ 17 soon available under: http://inspire.west.uni-koblenz.de:8080/ontologies In the INSPIRE implementation process Download Services are scheduled to be operational not until the end of 2012, so for now there is only test data available like the data we have used so far 18.
The Proxy-application is based on the Sesame framework19 acting as an
inference-layer using the "Sesame" Sail-API. Sesame was chosen due to its
wellstructured API and fast conversion of SPARQL-query to -algebra. Internally,
experimental GeoSPARQL- lters as well as programmetically generated
WFSGetFeature requests are realized with the Deegree3-API. The WFS-results are
transformed with the fast non-extracting, XPath-capable XML-parser "VTD"20.
For example the parsing of all protected sites elements is nished within 6
seconds, which also includes all further transforming into RDF-triples. Testing
federated queries is done with the Sesame-based APIs "NetworkedGraphs" and
"DistributedSAIL" from the University of Koblenz-Landau [
At least since the OGC Geospatial Semantic Web Interoperability Experiment in
2006 [
This paper presents an approach to enable federated queries over INSPIRE and LOD. We identify two key tasks, INSPIRE ontologies and support for querying, and propose how to solve them. Our solution has been tested with a prototype and turned out to be viable and e cient while establishing a semantic query layer for arbitrary WFS-services not constrained to INSPIRE data publishing.
Open issues are investigations in linking this INSPIRE- with other LODdata, e.g. the data about European directives from the "Reporting Obligations 18 http://inspire.jrc.ec.europa.eu/index.cfm/pageid/44 19 http://www.openrdf.org/ 20 http://vtd-xml.sourceforge.net/ Database"21, or the full integration of spatial reasoning as soon as the speci cation GeoSPARQL will become stable. One big challenge will be a coordinated Semantic Web-infrastructure for INSPIRE reference data and management facilities of INSPIRE ontologies.
The Semantic Web is about handling information resources directly so we focus on the WFS-service and GML-encoded geodata itself, not the metadata layer consisting of OGC Catalogue Services and ISO-metadata. But INSPIRE also builds up a vivid metadata layer so that a combination of metadata and geodata forming one harmonized distributed Semantic Web-graph will certainly be a matter for future work. 21 http://rod.eionet.europa.eu/void.rdf