INSPIRE Logo

INSPIRE
Infrastructure for Spatial Information in Europe

Guidelines for the RDF encoding of spatial data

Title

Guidelines for the RDF encoding of spatial data

Status

Draft

Creator

ARE3NA project "INSPIRE Re3ference Platform Phase 2"

Date

2017-07-17

Subject

INSPIRE encoding rules for representing spatial data as RDF

Publisher

ARE3NA project "INSPIRE Re3ference Platform Phase 2"

Type

Text

Description

This document specifies an experimental encoding rule for representing spatial data sets in INSPIRE as RDF. The use of RDF is optional and does not supersede or replace the requirements regarding encoding specified in Clause 9 of the Data Specifications. This optional encoding is intended to support the e-government and open data community in Europe, which is increasingly looking at RDF to represent data.

Format

HyperText Markup Language (HTML)

Licence

Creative Commons Attribution (cc-by) 4.0

Identifier

http://inspire-eu-rdf.github.io/inspire-rdf-guidelines

Language

EN

Foreword

The challenges regarding the lack of availability, quality, organisation, accessibility, and sharing of spatial information are common to a large number of policies and activities and are experienced across the various levels of public authority in Europe. In order to solve these problems it is necessary to take measures of coordination between the users and providers of spatial information. The Directive 2007/2/EC of the European Parliament and of the Council adopted on 14 March 2007 aims at establishing an Infrastructure for Spatial Information in the European Community (INSPIRE) for environmental policies, or policies and activities that have an impact on the environment.

INSPIRE is based on the infrastructures for spatial information that are created and maintained by the Member States. To support the establishment of a European infrastructure, Implementing Rules addressing the following components of the infrastructure have been specified: metadata, interoperability of spatial data sets (as described in Annexes I, II, III of the Directive) and spatial data services, network services, data and service sharing, and monitoring and reporting procedures.

INSPIRE does not require collection of new data. However, Member States have to make their data available according to the Implementing Rules within two years of the adoption of the corresponding Implementing Rules for newly collected and extensively restructured data and within 5 years for other data in electronic format still in use.

Interoperability in INSPIRE means the possibility to combine spatial data and services from different sources across the European Community in a consistent way without involving specific efforts of humans or machines. 'Interoperability' is understood as providing access to spatial data sets through network services, typically via the Internet. Interoperability may be achieved by either changing (harmonising) and storing existing data sets or transforming them via services for publication in the INSPIRE infrastructure. It is expected that users will spend less time and efforts on understanding and integrating data when they build their applications based on data delivered in accordance with INSPIRE.

In order to benefit from the endeavours of international standardisation bodies and organisations established under international law their standards and technical means have been utilised and referenced, whenever possible.

An open and participatory approach was used during the development of the data specifications on Annex I, II and III data themes and the preparation of the Implementing Rule on Interoperability of Spatial Data Sets and Services.

The INSPIRE data specifications are built on a development framework. The following two documents from the framework are particularly important for this document:

  • The Generic Conceptual Model defines the elements necessary for interoperability and data harmonisation including cross-theme issues. Among other aspects it specifies the UML profile used to specify the INSPIRE application schemas.

  • The Guidelines for the Encoding of Spatial Data defines how geographic information can be encoded to enable transfer processes between the systems of the data providers in the Member States. Even though it does not specify a mandatory encoding rule it sets GML (ISO 19136) as the default encoding for INSPIRE, which has been used by most of the data specifications.

This document specifies an additional encoding rule supporting the consistent representation of spatial data sets that meet the interoperability requirements using RDF. It builds on previous work on this subject. All issues are raised and discussed in an open forum.

The document has been prepared for the ISA Programme by PwC EU Services and interactive instruments GmbH as part of ISA Action 1.17, A Reusable INSPIRE Reference Platform (ARE3NA).

Disclaimer

The views expressed in this report are purely those of the authors and may not, in any circumstances, be interpreted as stating an official position of the European Commission.

The European Commission does not guarantee the accuracy of the information included in this study, nor does it accept any responsibility for any use thereof.

Reference herein to any specific products, specifications, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favouring by the European Commission.

All care has been taken by the author to ensure that s/he has obtained, where necessary, permission to use any parts of manuscripts including illustrations, maps, and graphs, on which intellectual property rights already exist from the titular holder(s) of such rights or from her/his or their legal representative.

1. Scope

This document specifies an encoding rule for representing spatial data sets in INSPIRE in RDF. It may be applied to spatial data sets meeting the requirements for the interoperability of spatial data sets and services specified in regulation 1089/2010 and the associated Data Specification documents for each spatial data theme.

This encoding rule is an optional encoding rule and does not supersede or replace the requirements regarding encoding specified in Clause 9 of the Data Specifications.

Supporting an RDF encoding for spatial data sets in INSPIRE is intended to support the e-government and open data community in Europe, which is increasingly looking at RDF to represent data.

In accordance with Article 7 of regulation 1089/2010, the encoding rule specified in this document conforms to ISO EN 19118:2011. In particular, it specifies

  • schema conversion rules for all spatial object types, attributes and association roles and

  • the output data structure.

The encoding rule does not provide a bijective mapping between the information items defined by the conceptual INSPIRE application schemas and their RDF encoding. For example, a transformation of a spatial object from an INSPIRE GML representation to INSPIRE RDF and back may thus result in some information loss. This is acceptable, as long as the encoding rule leads to an RDF representation that is appropriate for typical uses of INSPIRE data in an RDF context.

2. Conformance

If these technical guidelines are adopted in the future, then conformance classes for INSPIRE RDF vocabularies and instance documents will be added.

3. Normative references

GeoDCAT-AP: A geospatial extension for the DCAT application profile for data portals in Europe v1.0.1, https://joinup.ec.europa.eu/node/154143/

INSPIRE D2.5 v3.4, Generic Conceptual Model

INSPIRE D2.7 v3.3, Guidelines for the encoding of spatial data

ISA Programme Location Core Vocabulary, https://www.w3.org/ns/locn

ISO 19118:2011, Geographic information – Encoding

OGC Geography Markup Language (GML) - Extended schemas and encoding rules, OGC document number 10-129r1

OGC GeoSPARQL - A Geographic Query Language for RDF Data, OGC document number 11-052r4

OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2

OWL 2 Web Ontology Language, Structural Specification and Functional-Style Syntax (Second Edition), W3C Recommendation 11 December 2012, http://www.w3.org/TR/owl2-syntax/

OpenGIS Implementation Standard for Geographic information - Simple feature access - Part 1: Common architecture, OGC document number 06-103r4, http://portal.opengeospatial.org/files/?artifact_id=25355

RDF 1.1 Concepts and Abstract Syntax, http://www.w3.org/TR/rdf11-concepts/

W3C RDF Schema 1.1, https://www.w3.org/TR/rdf-schema/

4. Terms and abbreviations

4.1. Terms

application schema

conceptual schema for data required by one or more applications [iso_19101]

conversion rule

rule for converting instances in the input data structure to instances in the output data structure [iso_19118]

data interchange

delivery, receipt and interpretation of data [iso_19118]

data transfer

movement of data from one point to another over a medium [iso_19118]

NOTE Transfer of information implies transfer of data.

encoding

conversion of data into a series of codes [iso_19118]

encoding rule

identifiable collection of conversion rules that define the encoding for a particular data structure [iso_19118]

NOTE An encoding rule specifies the types of data to be converted as well as the syntax, structure and codes used in the resulting data structure.

transfer format

structured representation of data in a file for transfer between systems

NOTE Typically, a machine readable schema will document the structure of the data in the transfer file.

EXAMPLE GML [iso_19136] encodes the application schema in XML Schema.

simple feature

feature with all geometric attributes described piecewise by straight line or planar interpolation between sets of points [ogc_sf]

spatial data

data with a direct or indirect reference to a specific location or geographic area [inspire_directive]

spatial data set

identifiable collection of spatial data [inspire_directive]

spatial object

abstract representation of a real-world phenomenon related to a specific location or geographical area [inspire_directive]

It should be noted that the term has a different meaning in the ISO 19100 series. It is also synonymous with "(geographic) feature" as used in the ISO 19100 series.
spatial object type

classification of spatial objects [inspire_d25]

In the conceptual schema language UML a spatial object type will be described by a class with stereotype <<featureType>>.
transfer protocol

common set of rules for defining interactions between distributed systems [iso_19118]

4.2. Abbreviations

CEN

European Committee for Standardization

GCM

INSPIRE Generic Conceptual Model

IETF

Internet Engineering Task Force

INSPIRE

INfrastructure for SPatial InfoRmation in Europe

IR

Implementing Rule

ISO

International Organisation for Standardisation

LOCN

ISA Programme Location Core Vocabulary

OGC

Open Geospatial Consortium

SDI

Spatial Data Infrastructure

SDIC

Spatial Data Interest Community

TR

Technical Report

TS

Technical Specification

UML

Unified Modelling Language

URI

Uniform Resource Identifier

URN

Uniform Resource Name

UTF

Unicode Transformation Format

XML

eXtensible Markup Language

4.3. Verbal forms for the expression of provisions

In accordance with the ISO rules for drafting, the following verbal forms shall be interpreted in the given way:

  • "shall" / "shall not": a requirement, mandatory for every data specification

  • "should" / "should not": a recommendation, but an alternative approach may be chosen for a specific case if there are reasons to do so

  • "may" / "need not": a permission

To make it easier to identify the mandatory requirements, the recommendations, and the permissions for INSPIRE data specifications in the text, they are highlighted and have an identifier.

Requirement REQ/OWL/A/B/C

Requirements are shown using this style.

Recommendation REC/OWL/X/Y/Z

Recommendations are shown using this style.

Permission PMS/OWL/X/Y/Z

Permissions are shown using this style.

Specific notes are also highlighted. They do not have normative character.

This is a note.

5. Overview

The INSPIRE initiative aims at improving the sharing of spatial data and services between public authorities in Europe and in particular between the Member States and the European Institutions. INSPIRE addresses the interoperability of spatial data sets and services for the exchange of data related to one of the 34 spatial data themes defined in the INSPIRE Directive. It does so through the creation of application schemas (using UML) and geospatial encodings mechanisms (using GML, plus GeoTIFF and other formats for selected data themes). Through its data specifications, INSPIRE provides a common means to describe the spatial data within the scope of all the data themes outlined in the annexes of the Directive. The GML encoding that INSPIRE uses is an open standard intended for data exchange of spatial data on the Web. It is mainly supported by geospatial technologies.

At the same time, e-government applications and tools start to use the Linked Data paradigm, based on Semantic Web languages and technologies, such as the Resource Description Framework (RDF). If INSPIRE data was available as Linked Data, these e-government applications and tools could easily link to it. INSPIRE Linked Data has potential to unlock new applications and services, not only for e-government, but also other communities following the linked data paradigm.

Moreover, the Core Location Vocabulary specified by ISA as part of the e-Government Core Vocabularies is an example of where INSPIRE data (and models) can be reused in e-government in RDF, meaning that investments made in sharing data for INSPIRE can become part of key processes in online government services. This concept can in principle be extended to offer all such INSPIRE spatial data objects as RDF, thus creating a ‘base geography’ of INSPIRE data that other data (from any sector) can be linked to.

Previous work has brought together expertise in different countries to create a draft methodology for creating the INSPIRE RDF vocabularies, explored governance issues of Persistent Identifiers (PIDs) such as URIs and has explored some of the tools that can be used to create such data.

The guidelines described in this document build on this work and include input from pilots to test draft INSPIRE RDF vocabularies and PID concepts as well as input from the community on open issues through an open forum.

While the methodology to publish INSPIRE data as GML together with the corresponding XML schemas is well-defined, a methodology for the publication of INSPIRE data as linked data so far does not exist. This document aims at filling this gap. Consistent with the requirements for spatial data sets in INSPIRE, this document covers both

  • the creation of RDF vocabularies representing the INSPIRE application schemas and

  • the transformation of INSPIRE data into RDF.

To conform to Article 7 of the INSPIRE implementing rule (regulation 1089/2010), this document specifies an encoding rule conforming to ISO EN 19118:2011. An encoding rule describes conversion rules for transforming data from an input data structure to an output data structure. Schemas have to be described for both the input and output data structure. In this case the input schemas, the INSPIRE application schemas, use the UML profile of the INSPIRE Generic Conceptual Model, the output schemas use RDFS/OWL/SKOS. The schema for the input data structure is called an application schema.

An encoding rule specifies the following aspects:

  • General encoding requirements (clause 6)

  • the input data structure (clause 7)

  • the output data structure (the "exchange format", clause 8)

  • the conversion rules, called the mapping, for converting data in the instance model to the exchange format

    • the schema conversion rules for mapping between the INSPIRE application schemas in UML to RDFS (clause 9)

    • the instance conversion rules for representing INSPIRE data in RDF as far as this is not described by the schema conversion rules (clause 10)

Sufficient examples to illustrate the rules and the encoded data are provided.

As mentioned before, the guidelines include input from pilots to test draft INSPIRE RDF vocabularies and PID concepts as well as input from the community on open issues. The input can lead to addition and revision of examples.

6. General encoding requirements

6.1. Application schema and schema language

As specified by the INSPIRE Generic Conceptual Model (GCM) [inspire_d25], the schema language for modelling INSPIRE conceptual schemas is UML.

The UML Profile of INSPIRE application schemas is defined in clause 9.6.3 of the GCM. The RDF encoding rule does not require any specific extension of this UML Profile.

6.2. Character encoding

The format used to serialize INSPIRE RDF data sets the requirements for the character encoding. The output data structure section provides further details about format requirements.

6.3. Exchange metadata

Exchange metadata is metadata about the encoded data structure. It can describe the originator of the dataset, refer to metadata information about the dataset, refer to the application schema and provide information about the encoding rule applied.

No specific metadata is defined to describe the exchange of INSPIRE RDF data. The data itself can contain metadata. In that case, the application schema defines the types and properties that contain metadata.

Consider the publication of metadata in one or more formats like schema.org, microdata, DCAT, and (Geo)DCAT-AP.

Choose the metadata format based upon the formats that are supported by the search engines with which you intend to make your data searchable. Annotations in HTML pages using the schema.org vocabulary is metadata that web crawlers are using. DCAT (and extensions like GeoDCAT-AP) are currently mostly used by e-government data portals.

6.4. Transfer unit

6.4.1. Granularity and structure

A transfer unit is a set of objects (a dataset or a subset of a dataset), each of which contains a set of properties.

6.4.2. Object identification

Requirement "REQ/OWL/ObjectIdentification

Each object contained in the transfer unit shall have a unique identifier.

Data types are not categorised as objects in the input data structure.

7. Input data structure

As the input data structure, this encoding rule uses an instance model which is based on the generic instance model defined in ISO 19118 clause 8. The instance model is capable of representing data described by INSPIRE application schemas expressed in UML.

8. Output data structure

This encoding rule is based on RDF 1.1 Concepts and Abstract Syntax.

The Resource Description Framework (RDF) is a framework for expressing information about resources. Resources can be anything, including documents, people, physical objects, and abstract concepts.

RDF is intended for situations in which information on the Web needs to be processed by applications, rather than being only displayed to people. RDF provides a common framework for expressing this information so it can be exchanged between applications without loss of meaning. Since it is a common framework, application designers can leverage the availability of common RDF parsers and processing tools. The ability to exchange information between different applications means that the information may be made available to applications other than those for which it was originally created.

In particular RDF can be used to publish and interlink data on the Web. For example, retrieving http://www.example.org/bob#me could provide data about Bob, including the fact that he knows Alice, as identified by her IRI (an IRI is an "International Resource Identifier" […​]). Retrieving Alice’s IRI could then provide more data about her, including links to other datasets for her friends, interests, etc. A person or an automated process can then follow such links and aggregate data about these various things. Such uses of RDF are often qualified as Linked Data.

— https://www.w3.org/TR/rdf11-primer/#section-Introduction

RDF 1.1 Concepts and Abstract Syntax defines a data model. It does not define a specific format to encode RDF data. A number of RDF formats exist, serving different purposes.

Recommendation REC/OWL/encoding/turtle

INSPIRE RDF data should be encoded in Turtle.

Permission PMS/OWL/encoding/other

INSPIRE RDF data may be encoded in other RDF formats, such as N-Triples and XML.

The schema for the output data structure that governs the structure of the exchange format is a combination of RDF Schema and OWL.

9. Schema conversion rules

This chapter documents the rules for converting an INSPIRE application schema to an OWL ontology

9.1. General

Rules for the conversion of an application schema package, the UML types it contains, and the properties of these types, are documented in this chapter.

9.1.1. Documentation

The documentation of UML elements (types, attributes and association roles) in INSPIRE application schemas includes:

  • A natural / human readable name

  • A definition

  • A description (optional)

Requirement REQ/OWL/documentation

The natural / human readable name, definition, and description (if available) of a UML element shall be documented using properties as shown in the following table. The values of these properties shall be provided at least in English.

Table 1. Encoding of common documentation items
Documentation item Encoding with RDF/OWL property

natural / human readable name

rdfs:label

definition

skos:definition

description

rdfs:comment

Example 1. Documentation of an OWL class

RDF/Turtle serialization

1 cp:CadastralParcel  a          owl:Class ;
2         rdfs:comment           "SOURCE [INSPIRE Directive:2007].\r\n\r\nNOTE As much as possible, in the INSPIRE context, cadastral parcels should be forming a partition of national territory. Cadastral parcel should be considered as a single area of Earth surface (land and/or water), under homogeneous real property rights and unique ownership, real property rights and ownership being defined by national law (adapted from UN ECE 2004 and WG-CPI, 2006). By unique ownership is meant that the ownership is held by one or several joint owners for the whole parcel."@en ;
3         skos:definition        "Areas defined by cadastral registers or equivalent."@en .

RDF/XML serialization

1   <owl:Class rdf:about="http://inspire.ec.europa.eu/ont/cp#CadastralParcel">
2    <rdfs:comment xml:lang="en">SOURCE [INSPIRE Directive:2007].&#xD;
3 &#xD;
4 NOTE As much as possible, in the INSPIRE context, cadastral parcels should be forming a partition of national territory. Cadastral parcel should be considered as a single area of Earth surface (land and/or water), under homogeneous real property rights and unique ownership, real property rights and ownership being defined by national law (adapted from UN ECE 2004 and WG-CPI, 2006). By unique ownership is meant that the ownership is held by one or several joint owners for the whole parcel.</rdfs:comment>
5     <skos:definition xml:lang="en">Areas defined by cadastral registers or equivalent.</skos:definition>
6   </owl:Class>

9.2. Application schema package

Requirement REQ/OWL/ontology

An application schema shall be converted into a single OWL ontology.

The UML types belonging to the namespace of the schema shall be converted as defined in this document.

No specific conversion rules are defined for the packages that belong to an application schema. These packages usually have the stereotype <<leaf>> or no stereotype. They are primarily used for structuring the conceptual schema.

Example 2. Declaration of the Cadastral Parcels ontology

RDF/Turtle serialization

1 <http://inspire.ec.europa.eu/ont/cp>
2         a                owl:Ontology ;
3         owl:imports      <http://def.isotc211.org/iso19150/-2/2012/base> , <https://github.com/inspire-eu-rdf/inspire-rdf-vocabularies/blob/master/ad/ad.ttl> , <https://www.w3.org/ns/locn.ttl> , <http://www.w3.org/2004/02/skos/core> , <http://www.opengis.net/ont/geosparql> , <https://github.com/inspire-eu-rdf/inspire-rdf-vocabularies/blob/master/base/base.ttl> , <https://github.com/inspire-eu-rdf/inspire-rdf-vocabularies/blob/master/au/au.ttl> ;
4         owl:versionIRI   "http://inspire.ec.europa.eu/ont/cp/4.0" ;
5         owl:versionInfo  "4.0" ;
6         skos:definition  "The application schema CadastralParcels contains the feature types CadastralParcel, CadastralBoundary and CadastralIndexSet."@en .

RDF/XML serialization

 1   <owl:Ontology rdf:about="http://inspire.ec.europa.eu/ont/cp">
 2     <owl:imports rdf:resource="http://def.isotc211.org/iso19150/-2/2012/base"/>
 3     <owl:imports rdf:resource="https://github.com/inspire-eu-rdf/inspire-rdf-vocabularies/blob/master/ad/ad.ttl"/>
 4     <owl:imports rdf:resource="https://www.w3.org/ns/locn.ttl"/>
 5     <skos:definition xml:lang="en">The application schema CadastralParcels contains the feature types CadastralParcel, CadastralBoundary and CadastralIndexSet.</skos:definition>
 6     <owl:versionInfo>4.0</owl:versionInfo>
 7     <owl:imports rdf:resource="http://www.w3.org/2004/02/skos/core"/>
 8     <owl:imports rdf:resource="http://www.opengis.net/ont/geosparql"/>
 9     <owl:imports rdf:resource="https://github.com/inspire-eu-rdf/inspire-rdf-vocabularies/blob/master/base/base.ttl"/>
10     <owl:versionIRI>http://inspire.ec.europa.eu/ont/cp/4.0</owl:versionIRI>
11     <owl:imports rdf:resource="https://github.com/inspire-eu-rdf/inspire-rdf-vocabularies/blob/master/au/au.ttl"/>
12   </owl:Ontology>

9.2.1. Ontology name and namespace

Requirement REQ/OWL/ontology/name

The name of the ontology shall be constructed as follows:

ontology-name = "http://inspire.ec.europa.eu/ont/" + app-schema-code

The app-schema-code is specified by the tagged value xmlns of the <<applicationSchema>> package.

This scheme is similar but not equal to the URI scheme of INSPIRE GML Schemas. Re-using the namespace URIs of the INSPIRE GML Schemas for the INSPIRE RDF vocabularies has been considered. However, such an approach can lead to URI resolution conflicts (when trying to access an XML Schema and RDF vocabulary at the exact same URI) and has therefore been rejected.

Example 3. Ontology name for schema "CadastralParcels"

The ontology name of the INSPIRE RDF vocabulary for the <<applicationSchema>> "CadastralParcels" is: http://inspire.ec.europa.eu/ont/cp

Requirement REQ/OWL/ontology/namespace

The namespace for the ontology components shall be:

ontology-namespace = ontology-name + "#"

Hash URIs - instead of 'slash' URIs (i.e. using '/') - are used in INSPIRE ontology namespaces for the following reasons:

  • The expressions and axioms that comprise an INSPIRE ontology are often used together. In some cases there can be complex dependencies between concepts. Hash URIs ensure that a client receives all relevant information about these dependencies when it accesses the ontology.

  • An ontology that is contained in a single document can easily be published.

  • If a client recognizes that a specific term is defined by a hash URI, then it can download the ontology from this URI, cache it, and re-use it whenever another term with the same base URI is accessed. In other words, hash URIs support caching, and can thus reduce the number of HTTP round-trips and reduce access latency. The sice of the ontology document should be reasonably small, since it only contains the ontology components derived from one particular INSPIRE application schema.

  • A slash URI can still be used for individuals, i.e. RDF resources that have an INSPIRE RDF/OWL class as type.

9.2.2. Version information

Requirement REQ/OWL/ontology/version

An owl:versionInfo predicate shall be added to the ontology, with the content of the version tagged value of the <<applicationSchema>> package as value.

The version shall also be used to assign a version IRI to the ontology, which is defined as follows:

versionIRI = ontology-name + "/" + version
Recommendation REC/OWL/ontology/series

If the ontology is part of an ontology series, i.e. a set of different versions of an ontology, then it is recommended that the predicates owl:priorVersion, owl:backwardCompatibleWith, owl:incompatibleWith are assigned to the ontology as appropriate.

Checking that a new version of an ontology is or is not compatible with the prior version of the ontology typically requires manual inspection.

9.2.3. Imports

Requirement REQ/OWL/ontology/imports

If the ontology uses entities of an external ontology, it shall use an owl:imports predicate to import the external ontology.

9.3. Types

An INSPIRE application schema contains a set of UML types, i.e. classes. This chapter contains rules for converting the different categories of UML types that occur in INSPIRE application schemas, namely: spatial object types, data types, unions, enumerations, and code lists. The rules for converting UML properties are documented in a separate chapter.

It is good practice to re-use already established classes when converting an INSPIRE application schema into an ontology. With respect to UML types, that means that a UML type can be implemented by an existing RDFS/OWL class, rather than creating a new OWL class to represent the type. In other words, the UML type is mapped to an existing RDFS/OWL class. This approach has also been applied in the GML encoding of INSPIRE application schemas. There, base types, for example from ISO schemas, are implemented by / mapped to XML elements that are defined in existing XML Schemas.
If a mapping exists for a UML type, the type is not converted. Instead, the RDFS/OWL class defined by the mapping is used as the representation of the UML type (for example as the range of an OWL property, which represents a UML property that has the UML type as value type).

Example 4. Mappings for UML types

The UML type CharacterString from ISO 19103 is mapped to xsd:string, and the UML type MD_Metadata from ISO 19115 is mapped to dcat:Dataset.

If a UML type is converted to an RDFS/OWL class, then that class can be aligned with RDFS/OWL classes from other vocabularies. Our focus in this case is on inheriting semantics. An INSPIRE OWL class can be made a subclass of any number of RDFS/OWL classes (via the predicate rdfs:subClassOf), even if the UML model does not provide such relationships (note that this is one of the fundamental differences between UML and RDF/OWL). This can be used to inherit characteristics that are defined by existing RDFS/OWL classes.

Example 5. Alignment for spatial object types

Spatial object types are aligned with GeoSPARQL features. This supports querying of INSPIRE spatial object types at SPARQL endpoints that support GeoSPARQL.

Mapping and alignment facilitate re-use of ontologies and are often used by the linked data community.

Because the information for mapping or aligning types can be complex, it is not included in the UML model. Mappings and alignments are defined in human-readable documentation and/or configuration files (if the ontology is derived automatically using software).

9.3.1. Mappings

Recommendation REC/OWL/type/mapping

If an RDFS/OWL class from an existing vocabulary is known to appropriately represent the semantics of a UML type, then the type should be mapped to that class.

Permission REC/OWL/type/mapping/simplification

If applications only need a subset of the information provided by an INSPIRE type, then that type may be mapped to an RDFS/OWL class from an existing vocabulary that only supports this subset.

Example 6. Simple mapping of a UML type

The INSPIRE type GeographicalName can be mapped to rdfs:Literal. For further details, see here.

Whether or not a mapping is appropriate typically requires careful consideration.

The following subsections document known mappings. They can be extended in the future.

Permission REC/OWL/type/mapping/dataTypeAsSpatialObjectTypeRepresentation

A <<dataType>> of the INSPIRE conceptual schemas, which is primarily used as a simplified view on an INSPIRE spatial object type, may, in the RDF encoding, either be mapped to or merged with that spatial object type.

When working with linked data, you should be able to directly link to a spatial object, rather than introducing an indirection by linking to a resource which merely provides a simplified view on the spatial object.

Example 7. Mapping AddressRepresentation

The INSPIRE type 'AddressRepresentation' is mapped to the RDF/OWL representation of the INSPIRE type 'Address'. For further details, see here.

ISO 19103
Requirement REQ/OWL/type/mappings/iso/19103

Types from ISO 19103 shall be mapped to the RDFS/OWL class or datatype listed in the following table.

Table 2. Mapping of types from ISO 19103
ISO 19103 Type RDFS/OWL Class or Datatype

Boolean

xsd:boolean

CharacterString

xsd:string

Date

xsd:date

DateTime

xsd:dateTime

Decimal

xsd:decimal

Integer

xsd:integer

Number

xsd:double

Real

xsd:double

Any

rdfs:Class

Angle

base:Measure

Area

base:Measure

Distance

base:Measure

Length

base:Measure

Measure

base:Measure

Probability

base:Measure

Velocity

base:Measure

Volume

base:Measure

For all other types from ISO 19103 used in INSPIRE schemas, suitable mappings need to be found on a case-by-case basis.

  • "There is no evidence of best practice here — nor is there consensus on which data model is best for describing units of measure."

  • "The W3C Web of Things Interest Group has created a task force to address the challenges of semantic interoperability relating to units of measure, which may lead to emergence of best practices that can be adopted by spatial data publishers."

ISO 19107
Requirement REQ/OWL/type/mappings/iso/19107/geosparql

Types from ISO 19107 shall be mapped to the GeoSPARQL Geometry class or one of its subclasses.

The value domain of spatial properties defined in this Regulation shall be restricted to the Simple Feature spatial schema as defined in Herring, John R. (ed.), OpenGIS® Implementation Standard for Geographic information – Simple feature access – Part 1: Common architecture, version 1.2.1, Open Geospatial Consortium, 2011, unless specified otherwise for a specific spatial data theme or type.

— Commission Regulation (EU) No 1089/2010

The INSPIRE themes "Cadastral Parcels" and "Buildings" make exceptions to the rule that the domain of spatial properties shall be restricted to Simple Feature geometries. The cadastral parcels theme allows geometries with circular arcs, while the buildings theme allows 3D geometries.

Requirement REC/OWL/type/mappings/iso/19107/mapping

If a type from ISO 19107 that is used in an INSPIRE application schema can be implemented as a Simple Feature geometry, then the type shall be mapped to one of the classes from the ontology available at http://www.opengis.net/ont/sf (Simple Feature ontology). Otherwise, the type shall be mapped to one of the classes from the ontology available at http://www.opengis.net/ont/gml (GML ontology). See the following table for a list of applicable mappings.

Both ontologies define a hierarchy of subclasses of the GeoSPARQL Geometry class.
Table 3. Mapping of types from ISO 19107 to their implementations as GeoSPARQL Geometry subclasses
ISO 19107 Types Simple Feature Ontology Class GML Ontology Class

GM_Aggregate

sfowl:GeometryCollection

gmlowl:MultiGeometry

GM_Curve

sfowl:LineString

gmlowl:Curve or gmlowl:LineString

GM_MultiCurve

sfowl:MultiLineString

gmlowl:MultiCurve

GM_MultiPoint

sfowl:MultiPoint

gmlowl:MultiPoint

GM_MultiPrimitive

sfowl:GeometryCollection

gmlowl:MultiGeometry

GM_MultiSurface

sfowl:MultiPolygon

gmlowl:MultiSurface

GM_Object

sfowl:Geometry

gmlowl:AbstractGeometry

GM_Point

sfowl:Point

gmlowl:Point

GM_PolyhedralSurface

sfowl:PolyhedralSurface

gmlowl:PolyhedralSurface

GM_Primitive

sfowl:Geometry

gmlowl:AbstractGeometricPrimitive

GM_Ring

sfowl:LinearRing

gmlowl:Ring or gmlowl:LinearRing

GM_Solid

-

gmlowl:Solid

GM_Surface

sfowl:Polygon

gmlowl:Surface or gmlowl:Polygon

GM_Tin

sfowl:TIN

gmlowl:Tin

GM_Triangle

sfowl:Triangle

gmlowl:Triangle

ISO 19108
Requirement REQ/OWL/type/mappings/iso/19108

Types from ISO 19108 shall be mapped to the RDFS/OWL class or datatype listed in the following table.

Table 4. Mapping of types from ISO 19108
ISO 19108 Type RDFS/OWL Class or Datatype

TM_Position

time:TemporalPosition

For all other types from ISO 19108 used in INSPIRE schemas, suitable mappings need to be found on a case-by-case basis.

ISO 19115
Requirement REQ/OWL/type/mappings/iso/19115

Types from ISO 19115 shall be mapped to the RDFS/OWL class or datatype listed in the following table.

Table 5. Mapping of types from ISO 19115
ISO 19115 Type RDFS/OWL Class or Datatype

MD_Metadata

dcat:Dataset

MD_Resolution

rdf:langString

URL

xsd:anyURI

For all other types from ISO 19115 used in INSPIRE schemas, suitable mappings need to be found on a case-by-case basis.

  • The approach to map the complex type MD_Resolution to a simple (language tagged) string follows the approach chosen by GeoDCAT-AP (which maps the spatial resolution of a dataset, represented by an instance of MD_Resolution, to rdfs:comment; see GeoDCAT-AP Annex II, section II.13 for further details). By only mapping the type MD_Resolution to rdf:langString, we can preserve the semantics of INSPIRE properties that have MD_Resolution as type.

  • The data type CI_Date combines a date(time) with a code that provides the semantic for that date: date of creation, publication, and revision. At the moment, CI_Date is only used by the INSPIRE type DocumentCitation, which is one of the base types. Following the example from GeoDCAT-AP, an instance of CI_Date that uses one of the three date type codes (creation, publication, revision) can be implemented using one of the three properties dct:created, dct:issued, and dct:modified. This mapping is specified in the chapter on conversion of metadata instances.

ISO 19139
Requirement REQ/OWL/type/mappings/iso/19139

Types from ISO 19139 shall be mapped to the RDFS/OWL class or datatype listed in the following table.

Table 6. Mapping of types from ISO 19139
ISO 19139 Type RDFS/OWL Class or Datatype

PT_FreeText

rdf:langString

For all other types from ISO 19115 used in INSPIRE schemas, suitable mappings need to be found on a case-by-case basis.

INSPIRE Annex I - Addresses
Requirement REQ/OWL/type/mappings/inspire/annex1/addresses/AddressRepresentation

Type 'AddressRepresentation' from the 'INSPIRE Annex I - Addresses' schema shall be mapped to the RDF/OWL implementation of Type 'Address' (from that same schema).

This requirement means that the 'AddressRepresentation' is not used in RDF data. Instead, a link to a real 'Address' would be used whenever address information needs to be provided.

INSPIRE Annex I - Geographical Names

The INSPIRE type "GeographicalName" supports the provision of multiple spellings for a name, a link to an audio file for pronunciation, and more. Applications often simply just need the name in one spelling, potentially with indication of the language. In such cases, a simplification is possible.

Permission PMS/OWL/mappings/inspire/GeographicalName/SimpleLabel

The data type "GeographicalName" from INSPIRE Annex I - Geographical Names may be mapped to rdfs:Literal.

If the indication of language is needed, rdf:langString can be used instead of rdfs:Literal, since rdf:langString is a subclass of rdfs:Literal.

The INSPIRE spatial object type "NamedPlace" combines a geometry with one or more names, and thus has a more complex base model (ignoring voidable properties) than "GeographicalName". A simple mapping for "NamedPlace" is currently not available.

Simple or complex encoding

It is required that properties with INSPIRE GeographicalName as value type are aligned with the ISA Programme Location Core Vocabulary property "geographicName".

The definition of locn:geographicName states: "For INSPIRE-conformant data, provide the metadata for the geographic name using a skos:Concept as a datatype." That can easily be achieved.

Encoding a geographical name as an individual resource can be useful if complex information is available for the name, instead of just a simple label. In that case, the SKOS properties prefLabel and altLabel can be used to provide labels for the name in multiple languages, while also distinguishing preferred from alternative labels. Another case where the encoding of a geographical name as an individual resource can be useful is comparison of geographical names: if two spatial objects have "name" predicates with the same URI, then both spatial objects have the same geographic name. Resource equality can be asserted through a simple comparison of resource identifiers (the URIs). A comparison of pure labels, potentially given in different languages or spellings, would be more complex.

However, as stated before, it is allowed to map an INSPIRE GeographicalName to a simple rdfs:Literal.

Relevant issue(s):

9.3.2. Alignments

INSPIRE Annex I - Addresses
Requirement REQ/OWL/type/alignments/inspire/annex1/addresses

The RDF/OWL implementation of 'Address' from the 'INSPIRE Annex I - Addresses' schema shall be an rdfs:subClassOf the ISA Programme Location Core Vocabulary class "Address".

9.3.3. Class name

Requirement REQ/OWL/type/name

The name of the RDFS/OWL class or datatype that represents a UML type shall be encoded as:

class-name = ontology-namespace normalized-UML-type-name

The normalization of a UML type name includes:

  • Ensuring that it is given in UpperCamelCase.

  • Replacing punctuation characters other than dash and underscore with underscore characters.

  • Removing any space characters.

9.3.4. Abstractness

Requirement REQ/OWL/type/abstract

An abstract type shall be annotated with the property iso19150-2:isAbstract, using the boolean value true.

9.3.5. Inheritance

Requirement REQ/OWL/type/inheritance

If the UML type A is a subtype of another UML type B, then an rdfs:subClassOf predicate shall be added to the OWL class representing A, with the IRI of the RDF representation of B as value.

In case of multiple inheritance, i.e. a UML type is subtype of more than one UML type, this would result in multiple rdfs:subClassOf predicates.

9.3.6. Spatial object type

Requirement REQ/OWL/type/spatialobject

A spatial object type shall be converted to an OWL class.

Alignment
Requirement REQ/OWL/type/spatialobject/geosparqlfeature

A spatial object type shall be an rdfs:subClassOf the GeoSPARQL class "Feature".

This alignment will support querying of INSPIRE spatial object types encoded in RDF at SPARQL endpoints that support GeoSPARQL.

A GeoSPARQL feature is not required to have a geometry property. Thus, INSPIRE spatial object types for which the conceptual model does not define a geometry property, or which only have implicit geometry (for example provided by one or more linked spatial object types), are valid GeoSPARQL features.

Example 8. Aligning CadastralParcel to GeoSPARQL "Feature"

RDF/Turtle serialization

1 cp:CadastralParcel  a          owl:Class ;
2         rdfs:subClassOf        gsp:Feature .

RDF/XML serialization

1 <owl:Class rdf:about="http://inspire.ec.europa.eu/ont/cp#CadastralParcel">
2   <rdfs:subClassOf rdf:resource="http://www.opengis.net/ont/geosparql#Feature"/>
3  </owl:Class>
Documentation
Requirement REQ/OWL/type/spatialobject/documentation

The inspireConcept tagged value of a spatial object type provides a URI reference to the feature concept in the INSPIRE Feature Concept Dictionary Register. An rdfs:isDefinedBy predicate with this URI shall be added to the OWL class that represents the spatial object type.

9.3.7. Data type

Requirement REQ/OWL/type/datatype

A data type shall be converted to an OWL class.

This requirement does not necessarily apply to all data types. For further details, see this permission.

9.3.8. Union

A <<union>> represents a choice between multiple properties. The properties can carry a specific meaning. They can have different value types. They can have a multiplicity other than exactly 1.

The <<union>> can be represented in OWL using a logical combination of unqualified cardinality restrictions. The according class expression ensures that values are only given for one of the union properties.

However, if the <<union>> was represented as an OWL class, then encoding of actual data would require the creation of individuals that just represent the "choice". A more natural approach would be to encode the "choice" where it is actually of interest, i.e. where the <<union>> is used as value type.

Requirement REQ/OWL/type/union

A <<union>> shall not be converted to an OWL class. Instead, it shall be transformed as follows:

  • Each UML property (P) that has the <<union>> as value type is replaced by new properties, one for each option (O) of the <<union>>.

    • The name of a new property shall represent the specific combination of P and O, and shall be unique among the names of the properties that belong to the class that P belongs to.

      • NOTE: As shown in the two examples below, simply concatenating the property names - for example using the pattern "P-name '_by_' O-name" is not always advisable. That is why the names of new properties can be assigned manually.

    • The value type of the new property will be the value type of O. The multiplicity is set as follows: the lower bound is always 0, while the upper bound is the product of the maximum multiplicity of P and O - or unbounded if one of them is unbounded.

    • The documentation (natural / human readable name, definition, description) of P and O are merged.

    • The tagged values from O shall be used.

  • For each UML property (P) that is replaced by new properties as described before AND that has a maximum multiplicity of one, create a logical combination of class expressions and add it to the class that P belongs to:

    • For each new property (N):

      • Create a set of unqualified cardinality restrictions, to express that the minimum cardinality of N is 0 (so there can be any number of values for this property, it can also be omitted completely), and the cardinality of the other new properties is restricted to exactly 0.

      • Combine the cardinality restrictions within an intersection class expression. The meaning of this expression is that if a value is given for N, then no values can be provided for the other new properties.

    • Combine the intersection class expressions within a single OWL union class expression. This essentially represents the meaning of the <<union>>: if a value is given for one of the options, then there must not be values for the other options.

    • NOTE: If the maximum multiplicity of P is greater than one, then it can have values from more than one option. In that case, it would not be correct to add a class expression that restricts values to only one of the new properties.

EXAMPLE: The following figure depicts the INSPIRE <<union>> Age, and the <<dataType>> BiomarkerThematicMetadata where the value type of property meanAge is Age.

union example age
Figure 1. <<union>> Age - example from the INSPIRE model

The conversion results in (only showing BiomarkerThematicMetadata and the class expression that captures the <<union>> semantics):

Example 9. Conversion of a union

RDF/Turtle serialization

 1 :BiomarkerThematicMetadata a owl:Class ;
 2 
 3    rdfs:subClassOf [
 4       a owl:Class ;
 5       owl:unionOf (
 6          [ owl:intersectionOf (
 7             [ a owl:Restriction ;
 8               owl:onProperty :meanAgeByMonth ;
 9               owl:minCardinality "0"^^xsd:integer]
10             [ a owl:Restriction ;
11               owl:onProperty :meanAgeByWeek ;
12               owl:cardinality "0"^^xsd:integer]
13             [ a owl:Restriction ;
14               owl:onProperty :meanAgeByYear ;
15               owl:cardinality "0"^^xsd:integer]) ;
16          a owl:Class]
17          [ owl:intersectionOf (
18             [ a owl:Restriction ;
19              owl:onProperty :meanAgeByMonth ;
20              owl:cardinality "0"^^xsd:integer]
21             [ a owl:Restriction ;
22               owl:onProperty :meanAgeByWeek ;
23               owl:minCardinality "0"^^xsd:integer]
24             [ a owl:Restriction ;
25               owl:onProperty :meanAgeByYear ;
26               owl:cardinality "0"^^xsd:integer]) ;
27          a owl:Class]
28          [ owl:intersectionOf (
29             [ a owl:Restriction ;
30               owl:onProperty :meanAgeByMonth ;
31               owl:cardinality "0"^^xsd:integer]
32             [ a owl:Restriction ;
33               owl:onProperty :meanAgeByWeek ;
34               owl:cardinality "0"^^xsd:integer]
35             [ a owl:Restriction ;
36               owl:onProperty :meanAgeByYear ;
37               owl:minCardinality "0"^^xsd:integer]) ;
38          a owl:Class])] .

RDF/XML serialization

  1 <?xml version="1.0" encoding="UTF-8"?>
  2 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  3  xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">
  4  <owl:Class rdf:about="http://inspire.ec.europa.eu/ont/hh#BiomarkerThematicMetadata">
  5   <rdfs:subClassOf>
  6    <owl:Class>
  7     <owl:unionOf>
  8      <rdf:Description>
  9       <rdf:first>
 10        <owl:Class>
 11         <owl:intersectionOf>
 12          <rdf:Description>
 13           <rdf:first>
 14            <owl:Restriction>
 15             <owl:onProperty rdf:resource="http://inspire.ec.europa.eu/ont/hh#meanAgeByMonth"/>
 16             <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#integer"
 17              >0</owl:minCardinality>
 18            </owl:Restriction>
 19           </rdf:first>
 20           <rdf:rest>
 21            <rdf:Description>
 22             <rdf:first>
 23              <owl:Restriction>
 24               <owl:onProperty rdf:resource="http://inspire.ec.europa.eu/ont/hh#meanAgeByWeek"/>
 25               <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#integer"
 26                >0</owl:cardinality>
 27              </owl:Restriction>
 28             </rdf:first>
 29             <rdf:rest>
 30              <rdf:Description>
 31               <rdf:first>
 32                <owl:Restriction>
 33                 <owl:onProperty rdf:resource="http://inspire.ec.europa.eu/ont/hh#meanAgeByYear"/>
 34                 <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#integer"
 35                  >0</owl:cardinality>
 36                </owl:Restriction>
 37               </rdf:first>
 38               <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>
 39              </rdf:Description>
 40             </rdf:rest>
 41            </rdf:Description>
 42           </rdf:rest>
 43          </rdf:Description>
 44         </owl:intersectionOf>
 45        </owl:Class>
 46       </rdf:first>
 47       <rdf:rest>
 48        <rdf:Description>
 49         <rdf:first>
 50          <owl:Class>
 51           <owl:intersectionOf>
 52            <rdf:Description>
 53             <rdf:first>
 54              <owl:Restriction>
 55               <owl:onProperty rdf:resource="http://inspire.ec.europa.eu/ont/hh#meanAgeByMonth"/>
 56               <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#integer"
 57                >0</owl:cardinality>
 58              </owl:Restriction>
 59             </rdf:first>
 60             <rdf:rest>
 61              <rdf:Description>
 62               <rdf:first>
 63                <owl:Restriction>
 64                 <owl:onProperty rdf:resource="http://inspire.ec.europa.eu/ont/hh#meanAgeByWeek"/>
 65                 <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#integer"
 66                  >0</owl:minCardinality>
 67                </owl:Restriction>
 68               </rdf:first>
 69               <rdf:rest>
 70                <rdf:Description>
 71                 <rdf:first>
 72                  <owl:Restriction>
 73                   <owl:onProperty
 74                    rdf:resource="http://inspire.ec.europa.eu/ont/hh#meanAgeByYear"/>
 75                   <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#integer"
 76                    >0</owl:cardinality>
 77                  </owl:Restriction>
 78                 </rdf:first>
 79                 <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>
 80                </rdf:Description>
 81               </rdf:rest>
 82              </rdf:Description>
 83             </rdf:rest>
 84            </rdf:Description>
 85           </owl:intersectionOf>
 86          </owl:Class>
 87         </rdf:first>
 88         <rdf:rest>
 89          <rdf:Description>
 90           <rdf:first>
 91            <owl:Class>
 92             <owl:intersectionOf>
 93              <rdf:Description>
 94               <rdf:first>
 95                <owl:Restriction>
 96                 <owl:onProperty
 97                  rdf:resource="http://inspire.ec.europa.eu/ont/hh#meanAgeByMonth"/>
 98                 <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#integer"
 99                  >0</owl:cardinality>
100                </owl:Restriction>
101               </rdf:first>
102               <rdf:rest>
103                <rdf:Description>
104                 <rdf:first>
105                  <owl:Restriction>
106                   <owl:onProperty
107                    rdf:resource="http://inspire.ec.europa.eu/ont/hh#meanAgeByWeek"/>
108                   <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#integer"
109                    >0</owl:cardinality>
110                  </owl:Restriction>
111                 </rdf:first>
112                 <rdf:rest>
113                  <rdf:Description>
114                   <rdf:first>
115                    <owl:Restriction>
116                     <owl:onProperty
117                      rdf:resource="http://inspire.ec.europa.eu/ont/hh#meanAgeByYear"/>
118                     <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#integer"
119                      >0</owl:minCardinality>
120                    </owl:Restriction>
121                   </rdf:first>
122                   <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>
123                  </rdf:Description>
124                 </rdf:rest>
125                </rdf:Description>
126               </rdf:rest>
127              </rdf:Description>
128             </owl:intersectionOf>
129            </owl:Class>
130           </rdf:first>
131           <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>
132          </rdf:Description>
133         </rdf:rest>
134        </rdf:Description>
135       </rdf:rest>
136      </rdf:Description>
137     </owl:unionOf>
138    </owl:Class>
139   </rdfs:subClassOf>
140  </owl:Class>
141 </rdf:RDF>

In this example creating the name of the new properties using concatenation was straightforward. However, the names of <<union>> options can also follow a different pattern:

union example areaOfResponsibilityType
Figure 2. <<union>> AreaOfResponsibilityType - example from the INSPIRE model

Here, the names of the <<union>> options already include the name of the property that has the <<union>> as value type. Concatenating the name of the property that is being replaced and the name of an option would lead to duplication.

Clearly, a single approach to creating the names of new properties would not suffice if the names of <<union>> types and their options follow different patterns. When automatically converting <<union>> types, a manual review should therefore be performed.

9.3.9. Enumeration

Requirement REC/OWL/type/enumeration

If the meaning of the codes of an enumeration is obvious, or if the codes are self-describing, then the enumeration should be represented by an OWL DataOneOf, i.e. an RDFS datatype that specifies the restricted list of literals using an owl:oneOf declaration.

Otherwise, the enumeration shall be encoded like a code list (see next chapter).

Example 10. Conversion of an enumeration as OWL DataOneOf
1 base:Sign
2   a           rdfs:Datatype ;
3   owl:oneOf   ( "+" "-" ) ;
Example 11. Conversion of an enumeration as a code list

The INSPIRE Registry contains SKOS representations of enumerations defined in INSPIRE application schemas. One example is the enumeration TechnicalStatusValue. An HTML page is available, with links to other representations of the enumeration, for example RDF.

9.3.10. Code list

Requirement REQ/OWL/type/codelist

INSPIRE code lists - and extensions - shall be represented as SKOS concept schemes, their codes as SKOS concepts. They shall be published and managed in the INSPIRE registry.

Example 12. Conversion of a code list

The INSPIRE Registry contains SKOS representations of code lists used in INSPIRE application schemas. One example is the code list Natura2000DesignationValue. An HTML page is available, with links to other representations of the code list, for example RDF.

9.4. Properties

This chapter documents the rules for converting the properties (attributes and association roles) of types, i.e. classes, defined in INSPIRE application schemas.

It is good practice to re-use already established properties when converting an INSPIRE application schema into an ontology. With respect to UML properties, that means that a UML property can be implemented by an existing RDF/OWL property, rather than creating a new OWL property to represent the UML property. In other words, the UML property is mapped to an existing RDF/OWL implementation.

If a mapping exists for a UML property, the property is not converted. Instead, the RDF/OWL property defined by the mapping is used as the representation of the UML property.

Requirement REQ/OWL/property/general

If a UML property (attribute or navigable association role) is not mapped to an existing RDF/OWL property, then it shall be converted to:

  • an OWL object property if the value type of the UML property is represented as an OWL class

  • an OWL datatype property if the value type of the UML property is represented as an OWL datatype or literal

If multiple UML properties from INSPIRE application schemas have the same semantics, then these properties should be implemented as a single RDF/OWL property that does not have a domain restriction. The UML properties can then be mapped to / implemented by that property. For further details, see chapter Domain.

When converting a UML property to an OWL property, that OWL property can also be aligned to an existing RDF/OWL property (see chapter Alignment). The conversion of specific properties can also be omitted (see chapter Omission).

Mapping and alignment facilitate re-use of ontologies and are often used by the linked data community.

Because the information for mapping, aligning, and omitting properties can be complex, it is not included in the UML model. This information can be provided via human-readable documentation and via (machine readable) configuration files.

9.4.1. Mappings

Recommendation REC/OWL/property/mapping

If an RDF/OWL property from an existing vocabulary is known to appropriately represent the semantics of a UML property, then the property should be mapped to that RDF/OWL property.

Requirement REQ/OWL/property/mapping/consistencyWithTypeMapping

If a mapping is defined for a UML property to an existing RDF/OWL property, and a mapping is defined for the value type of the UML property, then the range of the RDF/OWL property (if defined), shall be the RDFS/OWL class or data type to which the value type of the UML property is mapped - or one of their subclasses.

This ensures consistency of property mappings.

Example 13. Consistent mapping for property "name"

Let us assume that a property "name" has "GeographicalName" as value type. If "GeographicalName" is mapped to rdfs:Literal, then a consistent mapping for property "name" is rdfs:label, since its range is rdfs:Literal.

Whether or not a mapping is appropriate typically requires careful consideration.

Recommendation REC/OWL/property/mapping/common

Common INSPIRE properties, i.e. properties with same semantics defined by multiple INSPIRE types, should be mapped as defined in the following table.

Table 7. Mapping of common properties
Property RDF/OWL Property

beginLifespanVersion

base:beginLifespanVersion

endLifespanVersion

base:endLifespanVersion

This table can be extended in the future, if additional common properties have been identified.

An example of an INSPIRE vocabulary, that defines commonly used concepts, is available online.

Permission REC/OWL/property/mapping/valueTypeGeographicalName

A UML property that has GeographicalName as value type may be mapped to rdfs:label.

9.4.2. Alignment

If a UML property is converted to an RDF/OWL property, then that property can be aligned with RDF/OWL properties from other vocabularies. Our focus in this case is on inheriting semantics. In RDF, a property can be made a sub-property of any number of RDF/OWL properties (via the predicate rdfs:subPropertyOf). This can be used to inherit characteristics that are defined by existing RDF/OWL properties.

The following requirements support alignment of INSPIRE RDF vocabularies with common linked data vocabularies, while keeping the semantics of properties from INSPIRE application schemas.

Geometry
Requirement REQ/OWL/property/alignment/locn/geometry

A UML property owned by a UML type T that:

  • is encoded as an OWL property, and

  • has a value type from ISO 19107

shall be an rdfs:subPropertyOf the ISA Programme Location Core Vocabulary property "geometry".

Requirement REQ/OWL/property/alignment/geosparql/hasDefaultGeometry

A UML property owned by a spatial object type T that:

  • is encoded as an OWL property,

  • has a value type from ISO 19107,

  • has maximum multiplicity of 1,

  • is a spatial representation of T, and

  • represents the default geometry of T to be used in spatial calculations (whenever no specific geometry-valued property of T is specified for such calculations)

shall be an rdfs:subPropertyOf the GeoSPARQL property "hasDefaultGeometry".

Requirement REQ/OWL/property/alignment/geosparql/hasGeometry

If a UML property owned by a UML type T is not already encoded as an rdfs:subPropertyOf GeoSPARQL "hasDefaultGeometry", and:

  • is encoded as an OWL property,

  • has a value type from ISO 19107, and

  • is a spatial representation of T

then the property shall be an rdfs:subPropertyOf the GeoSPARQL property "hasGeometry".

The property "hasDefaultGeometry" is defined by GeoSPARQL as an rdfs:subPropertyOf "hasGeometry". Therefore, if a property is an rdfs:subPropertyOf GeoSPARQL "hasDefaultGeometry", this entails that the property is also an rdfs:subPropertyOf GeoSPARQL "hasGeometry".

Example 14. Aligning property "geometry" of CadastralParcel

RDF/Turtle serialization

1 cp:CadastralParcel.geometry
2         a                   owl:ObjectProperty ;
3         rdfs:subPropertyOf  locn:geometry , gsp:hasDefaultGeometry .

RDF/XML serialization

1  <owl:ObjectProperty rdf:about="http://inspire.ec.europa.eu/ont/cp#CadastralParcel.geometry">
2   <rdfs:subPropertyOf rdf:resource="https://www.w3.org/ns/locn#geometry"/>
3   <rdfs:subPropertyOf rdf:resource="http://www.opengis.net/ont/geosparql#hasDefaultGeometry"/>
4  </owl:ObjectProperty>
Geographical name
Requirement REQ/OWL/property/alignment/locn/geographicName

A property that:

  • is encoded as an OWL property,

  • belongs to a spatial object type, and

  • has INSPIRE GeographicalName as value type

shall be an rdfs:subPropertyOf the ISA Programme Location Core Vocabulary property "geographicName".

Example 15. Aligning property "name" of CadastralZoning

RDF/Turtle serialization

1 cp:CadastralZoning.name
2         a                   owl:ObjectProperty ;
3         rdfs:domain         cp:CadastralZoning ;
4         rdfs:range          gn:GeographicalName ;
5         rdfs:subPropertyOf  locn:geographicName ;

RDF/XML serialization

1   <owl:ObjectProperty rdf:about="http://inspire.ec.europa.eu/ont/cp#CadastralZoning.name">
2     <rdfs:range rdf:resource="http://inspire.ec.europa.eu/ont/ad#GeographicalName"/>
3     <rdfs:domain rdf:resource="http://inspire.ec.europa.eu/ont/cp#CadastralZoning"/>
4     <rdfs:subPropertyOf rdf:resource="https://www.w3.org/ns/locn#geographicName"/>
5   </owl:ObjectProperty>

9.4.3. Omission

When converting an INSPIRE application schema to an ontology, the conversion of specific properties (of UML types defined in that schema) can be omitted.

Requirement REQ/OWL/property/omission/inspireId

Properties with name "inspireId" shall not be encoded in the ontology.

When encoding a spatial object in RDF, the "inspireId" will form the URI that identifies the RDF resource that represents the spatial object.

9.4.4. Property name

Requirement REQ/OWL/property/name

The name of the OWL property shall be encoded as:

property-name = ontology-namespace [normalized-UML-type-name "."] normalized-UML-property-localName
property-localName = UML-attribute-name | UML-role-name

The normalization of the UML property local name includes:

  • Ensuring that it is given in lowerCamelCase.

  • Replacing punctuation characters other than dash and underscore with underscore characters.

  • Removing any space characters.

The UML type name is included if the property is not converted to a global property (see next section).

9.4.5. Domain - local vs. global

In UML, an attribute belongs to the class that defines it. Likewise, an association role is a property that belongs to a specific class. In RDF, a property can be described in terms of the class to which it applies (as its domain), but it can also be described independently of any class (by not declaring a domain axiom for the property).

Apparently there is a mismatch between UML and RDF: in UML, a property belongs to its class, while in RDF, a property can be used by multiple classes. In other words: in UML, a property is always scoped to a specific class, while in RDF the scope of properties can be global.

One solution for converting UML properties would be to convert each UML property to a uniquely corresponding OWL property, scoping it to a specific class by:

  1. adding the class name that the property belongs to in UML to the OWL property name (so that the OWL property declaration is unique in the ontology), and

  2. declaring the OWL representation of its owning UML class as the domain of the OWL property.

However, if multiple properties with the same name and the same semantics exist in an application schema, this approach will lead to repetition that would clearly be undesirable and not in the spirit of RDF.

Recommendation REC/OWL/property/globalScope

Properties that "mean the same thing" should not be implemented as locally scoped properties. They should be implemented by a property with global scope.

Permission PMS/OWL/property/globalScope/definitionInOntology

A globally scoped property may be defined in the INSPIRE ontology that represents a given INSPIRE theme, but may also be defined in a base ontology, especially if the property was used by multiple other INSPIRE ontologies.

Example 16. Declaring property "referencePoint" (used by CadastralParcel and CadastralZoning) with global scope

RDF/Turtle serialization

1 cp:referencePoint  a        owl:ObjectProperty ;
2         rdfs:comment        "EXAMPLE The centroid of the cadastral object geometry."@en ;
3         rdfs:range          gsp:Geometry ;
4         rdfs:subPropertyOf  locn:geometry , gsp:hasGeometry ;
5         skos:definition     "A point within the cadastral object."@en .

RDF/XML serialization

1  <owl:ObjectProperty rdf:about="http://inspire.ec.europa.eu/ont/cp#referencePoint">
2   <rdfs:range rdf:resource="http://www.opengis.net/ont/geosparql#Geometry"/>
3   <rdfs:subPropertyOf rdf:resource="https://www.w3.org/ns/locn#geometry"/>
4   <rdfs:subPropertyOf rdf:resource="http://www.opengis.net/ont/geosparql#hasGeometry"/>
5   <rdfs:comment xml:lang="en">EXAMPLE The centroid of the cadastral object geometry.</rdfs:comment>
6   <skos:definition xml:lang="en">A point within the cadastral object.</skos:definition>
7  </owl:ObjectProperty>

Identifying suitable properties typically requires manual review and can only be achieved on a case-by-case basis.

Examples of properties that are candidates for being globally scoped: thematicId, beginLifespanVersion, endLifespanVersion, name.

9.4.6. Range

Requirement REQ/OWL/property/range

If a UML property from the application schema is encoded as an OWL property in the application schema ontology (NOTE: the alternative would be to map it to another RDF/OWL property) then:

  • If the value type of the UML property is a <<codeList>>, then the IRI http://www.w3.org/2004/02/skos/core#Concept shall be used as range of the OWL property.

  • Otherwise, the IRI of the RDFS or OWL class or datatype that represents the value type shall be set as the range of the OWL property.

9.4.7. Multiplicity

The multiplicity of a UML property specifies how many values the property can have. In an ontology, under the open world assumption, an instance of a class can have zero or any number of values for a given property.

The validation of multiplicity from the UML model is not a use case for INSPIRE data represented in RDF. Therefore, multiplicity is not converted.

OWL cardinality restrictions are only used to define the semantics of a <<union>>. For further details, see the section about conversion of union types.

9.4.8. Voidable

The stereotype <<voidable>> is not converted.

The voidable concept used in INSPIRE is in some ways interesting as it allows explicitly stating that something, for example the name of a road, is not known (no value, but reason 'unknown' is provided) and distinguishes this from stating that a road is known to have no name (no value and no specific reason). I.e., the INSPIRE application schemas, although generally based on the closed-world assumption, support unknown facts.

In RDF not stating a property is equivalent to setting the property to nil in the GML encoding.

RDF has no proper mechanism to explicitly state that the name of a road is unknown (to some person(s) or organizations). RDF adheres to the open world assumption which takes into account that, in this example, someone else could have a name for the road.

Thus, without a natural way to express such facts in an INSPIRE RDF representation, the RDF representation will state that no road name is known. While this is a loss of information, it is not essential for most applications.

An INSPIRE ontology provides the means to share all the (positive) information a data provider has. If a certain piece of information is not available at a data provider, chances are that they simply do not know them. The case where the absence of data is explicitly known should be quite rare.

Therefore, a specific conversion of the voidable concept is not necessary.

Relevant issue(s):

9.4.9. Vocabulary reference

The UML profile of the INSPIRE Generic Conceptual Model describes the tagged value 'vocabulary' for code list types as: URI of the vocabulary/code list in the INSPIRE code list registry or in some external registry. The value has to be provided, if an online version of the vocabulary exists.

INSPIRE code lists are represented as SKOS concept schemes, and their codes as SKOS concepts (see here). Consequently, the range of a property with a code list as value type can only be specified using the generic class skos:Concept. By just looking at the ontology definition of the property, any skos:Concept is allowed as value.

Requirement REQ/OWL/property/vocabularyReference

If the value type of a UML property, that is encoded as an OWL property, has the tag "vocabulary" with an actual URI as value, then an rdfs:seeAlso statement shall be added, with the OWL property as subject and the URI from the "vocabulary" tag as object.

With this informal reference, the ontology definition of the INSPIRE property at least provides a hint for implementers on which SKOS concept scheme and according SKOS concepts should be used.

Example 17. Vocabulary reference for property 'level' of spatial object type 'CadastralZoning'

RDF/Turtle serialization

1 cp:CadastralZoning.level
2         a                owl:ObjectProperty ;
3         rdfs:domain      cp:CadastralZoning ;
4         rdfs:range       skos:Concept ;
5         rdfs:seeAlso     <http://inspire.ec.europa.eu/codelist/CadastralZoningLevelValue> ;
6         skos:definition  "Level of the cadastral zoning in the national cadastral hierarchy."@en .

RDF/XML serialization

1   <owl:ObjectProperty rdf:about="http://inspire.ec.europa.eu/ont/cp#CadastralZoning.level">
2     <rdfs:seeAlso rdf:resource="http://inspire.ec.europa.eu/codelist/CadastralZoningLevelValue"/>
3     <rdfs:range rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/>
4     <rdfs:domain rdf:resource="http://inspire.ec.europa.eu/ont/cp#CadastralZoning"/>
5     <skos:definition xml:lang="en">Level of the cadastral zoning in the national cadastral hierarchy.</skos:definition>
6   </owl:ObjectProperty>

9.4.10. Attribute

No specific rules are defined for the conversion of UML attributes.

9.4.11. Association role

No specific rules are defined for the conversion of UML association roles.

9.5. Association class

In UML, an association class has both association and class properties (see UML Superstructure 2.1.2, section 7.3.4). It connects a set of classifiers and also defines a set of properties that belong to the relationship itself and not to any of the classifiers.

The OGC GML 3.3 standard defines a rule for converting an association class from a conceptual schema in UML to GML (see GML 3.3, section 12.3). The rule is based upon a mapping into a semantically equivalent intermediate type.

Requirement REQ/OWL/associationClass/general

An association class from an INSPIRE application schema shall be converted into a semantically equivalent type, following the rule defined by GML 3.3. The equivalent type shall then be converted to RDF as defined in this document.

9.6. Constraint

UML classes and properties can have constraints that express additional requirements. For example, a constraint can restrict the value range of an integer-valued property to the interval [0:20], or restrict the type of a property inherited from a supertype. Constraints add precision to models.

The INSPIRE Generic Conceptual Model defines the following:

To model constraints on the spatial object types and their properties, in particular to express data/data set consistency rules, OCL shall be used as described in ISO/TS 19103, whenever possible. In addition, all constraints shall be described in the application schema in English, too.

— INSPIRE Generic Conceptual Model - requirement 24
Requirement REQ/OWL/constraint/general

When converting an INSPIRE application schema to an ontology, only the description of an OCL constraint shall be converted. The description shall be added to the OWL class that represents the UML type for which the constraint is defined, using an iso19150-2:constraint annotation.

Example 18. Conversion of OCL constraint "areaValueUoM" from CadastralParcel

RDF/Turtle serialization

1 cp:CadastralParcel  a          owl:Class ;
2         iso19150-2:constraint  "areaValueUoM: Value of areaValue shall be given in square meters." .

RDF/XML serialization

1 <owl:Class rdf:about="http://inspire.ec.europa.eu/ont/cp#CadastralParcel">
2   <iso19150-2:constraint>areaValueUoM: Value of areaValue shall be given in square
3    meters.</iso19150-2:constraint>
4  </owl:Class>

10. Instance conversion rules

10.1. From input to output data structure

An object from the input structure is converted to an RDF resource. Object properties are represented by RDF resource properties. A dataset is represented by an RDF graph.

10.2. Resource identifiers

Recommendation REC/OWL/instance/identifier/spatialobject

The identifier of an RDF resource that represents a spatial object should be constructed from its 'inspireId'. However, the identifier should not contain the 'versionId' from the 'inspireId'.

Versioning is a known open issue (see the Generic Conceptual Model, section 9.7.2), and therefore not addressed by this specification.

Recommendation REC/OWL/instance/identifier/httpuri

If an RDF resource has a unique identifier, the identifier should be a globally unique persistent HTTP URI.

This recommendation follows Best Practice #7 in the Spatial Data on the Web Best Practices, but also takes into account additional considerations on spatial objects.

When designing an HTTP URI, take into account the recommendations from Annex H of the INSPIRE Generic Conceptual Model as well as the ISA studies on persistent URIs and RDF & PIDs.

Permission PMS/OWL/instance/identifierForStructuredValue

When representing a structured value - also called data type - as an RDF resource, a data provider may assign a unique identifier for the resource.

A structured value / data type does not have identity (see the UML Profile defined in clause 9.6.3 of the INSPIRE Generic Conceptual Model), and therefore has only local scope.

In some concrete RDF syntaxes (for example RDF XML, Turtle, and N-Triples), such a structured value can be encoded as an RDF blank node, i.e. an RDF resource without identifier. As explained in the RDF 1.1 Concepts and Abstract Syntax, "The blank node identifiers introduced by some concrete syntaxes have only local scope and are purely an artifact of the serialization."

When representing a structured value as an RDF resource, a data provider therefore has a choice between creating an identifier for the structured value, and representing it as a blank node.

10.3. Considerations on spatial objects

According to the definition of the [inspire_directive], a spatial object is an abstract representation of a real-world phenomenon related to a specific location or geographical area.

Most attributes and roles of a spatial object represent properties of the real-world phenomenon. It is common practice to model both properties that describe the real-world phenomenon and properties that describe the spatial object document, i.e. which are spatial object metadata, as spatial object properties.

In INSPIRE, most properties are properties that describe the real-world phenomenon. However, there are exceptions:

  • Properties that represent life-cycle information (in particular, the beginLifespanVersion and endLifespanVersion attributes) are marked with the stereotype <<lifeCycleInfo>>.

  • Properties that have a value type from ISO 19115 are often feature metadata. However, this is not always the case, in particular for CI types. An example is ProtectedSite.legalFoundationDocument with value type CI_Citation.

  • There are also some properties that require a closer review to identify them as metadata. Examples are CadastralZoning.estimatedAccuracy with value type Length or CadastralZoning.originalMapScaleDenominator with value type Integer. These properties are not properties of the real-world phenomenon, but of the spatial object.

It is important in linked data and the semantic web to be clear about the subject of a property. It might therefore be tempting to use two subjects for the properties of a spatial object: one subject for all properties providing information about the real-world phenomenon and one subject for all properties that are about the spatial object itself (like life-cycle information) or that provide metadata. Such a separation of spatial object data is NOT recommended, because there is no actual benefit in doing so.

From the perspective of RDF vocabularies there is no distinction between the two types of properties. In RDF, a property is a relationship between a subject resource and an object resource. "Anything can be a resource, including physical things, documents, abstract concepts, […​]" [w3c_rdf11_concepts] The semantic of a spatial object property has to provide information whether the property represents metadata or actual data that describes the real-world phenomenon. This condition must be fulfilled, otherwise the model would be ambiguous. If the condition is fulfilled, then assigning spatial object properties to two different subjects, just to identify data about the real-world phenomenon and metadata, is not necessary.

Another argument that has been made for separating data about the real-world phenomenon from metadata is that such a separation would facilitate gaining additional knowledge, i.e. finding more information, about the same real-world phenomenon. This would be achieved through the ability to assert equality between two resources which, in this case, represent the same real-world phenomenon.

Before we discuss the topic of equality in more detail, we need to consider that multiple communities can define RDF/OWL classes to abstract the same real-world phenomenon, but in their particular "worlds" (their "universe of discourse"). Typically, these abstractions differ. The sets of properties used to describe the phenomenon can be different. If the same properties are used, then their values can still be different. For example, the geometry of a building can be represented as a solid, a polygon, or a point. The height of the building can be given in different formats ("10m", "100ft", "100", "small", "Code_T"). As we can see, the information provided for a real-world phenomenon depends on how a community abstracts this phenomenon.

Coming back to the topic of equality: With pure RDF semantics, properties with the same subject belong to the same resource. If two communities used the same identifier for their abstractions of real-world phenomena, then these abstractions would be the same resource. Consequently, the information captured by both communities about the phenomenon would be available for that resource.

On first glance, this sounds useful. However, this approach can cause problems for users that want to gain new knowledge about a resource. Whenever two representations of the same resource share the same properties (e.g. "geometry" or "creationDate"), but with different values (e.g. a polygon vs a point, "1954-04-28" vs "1954-05-02"), then the user must decide what to do with this information. Should information be ignored (e.g. use the polygon instead of the point), or does it need to be processed to derive new information (e.g. computing the mean of two creation dates)? This problem will get bigger if more resources are "equal".

This problem is a general one. It can occur whenever two resources are equal. Equality can also be asserted, usually using the property owl:sameAs. Communities often do not use shared identifiers for their resources. In these situations, owl:sameAs predicates can be used to assert equality between two resources. That different identifiers are used for resources that represent the same real-world phenomenon is common, and is independent of a separation between resources with properties that only provide information about the real-world phenomenon and resources with properties that provide metadata.

As we can see, gaining new knowledge from linked data is a hard problem. It is not solved by simply establishing equality (by using the same resource identifier, or by using owl:sameAs). In fact, abstractions of real-world phenomena created by different communities can rarely considered to be equal / the same. The abstractions will very likely be different, to a greater or lesser extent.

Best practice No 1 of the The Spatial Data on the Web Best Practices also recommends caution when using owl:sameAs: "Care must always be taken when using owl:sameAs to determine that [the] two URIs actually refer to the same resource, rather than two resources that are similar. Warning: don’t say it if you’re not sure it’s true!"

How can INSPIRE RDF data support referencing the real-world phenomena that are abstracted, without requiring resource equality? The link between an INSPIRE resource and one or more real-world phenomena can be established with a property that does not imply resource equality. Unfortunately, the semantic web standards do not define a property with these semantics.

We can conclude that:

  • A separation of an INSPIRE spatial object into two resources, one with the properties that exclusively describe the real-world phenomenon that is being abstracted by the spatial object and one with the other properties, creates no actual benefit.

  • Full equality between two resources often does not exist. Care should be taken when assigning equality.

10.4. Encoding geometry

Requirement REQ/OWL/instance/geometry

An instance of an ISO 19107 geometry shall be serialized as a GeoSPARQL geometry as follows:

  • If the geometry is compliant to a Simple Feature geometry, it shall be serialized using the WKT Serialization defined by GeoSPARQL.

  • Otherwise, it shall be serialized using the GML Serialization defined by GeoSPARQL.

Properties from INSPIRE application schemas that have a value type from ISO 19107 are aligned with GeoSPARQL and the ISA Programme Location Core Vocabulary (LOCN) - see the property alignment requirements in the schema conversion rules chapter. Both specifications (GeoSPARQL and LOCN) support WKT and GML for serializing a geometry.

The requirement establishes WKT and GML as the main formats for encoding geometry information in INSPIRE RDF data. At the same time, however, the requirement does not preclude addition of predicates from GeoSPARQL (gsp:hasGeometry) and LOCN (locn:geometry) with other geometry serializations. In summary, the requirement establishes a suitable level of interoperability while offering enough flexibility to encode geometry in other formats.

10.5. Encoding metadata

According to the GeoDCAT-AP specification, "GeoDCAT-AP provides an RDF syntax binding for the union of metadata elements of the core profile of ISO 19115:2003 and those defined in the framework of the INSPIRE Directive". It is therefore well-suited to implement MD_Metadata in the context of INSPIRE.

Requirement REQ/OWL/instance/metadata/geodcatap

An instance of MD_Metadata, implemented as dcat:Dataset, shall be compliant to GeoDCAT-AP.

Requirement REQ/OWL/instance/metadata/CI_Date

An instance of CI_Date shall be represented by one of the DCMI Metadata Terms properties created, modified, and issued:

  • dct:created - if the date type of the CI_Date is 'creation'

  • dct:issued - if the date type of the CI_Date is 'publication'

  • dct:modified - if the date type of the CI_Date is 'revision'

Relevant issue(s):

10.6. Value collections

Requirement REQ/OWL/instance/valuecollections

Multiple values for a single property shall be encoded as multiple property assertions, rather than using an RDF collection (rdf:List) or RDF containers (rdf:Bag, rdf:Seq, rdf:Alt).

These RDF constructs do not add particular value, since the INSPIRE application schemas do not make use of ordering and uniqueness indicators for properties with multiplicity greater than one.

10.7. Extensions

A publisher may have more information about a spatial object than what is covered by the INSPIRE schemas. When encoding the spatial object as an RDF resource, the information that is covered by the INSPIRE schemas should be encoded as defined by this document. The additional information can be added to that resource in any way the publisher likes.

This extensibility is one of the benefits of RDF: a resource can be of any type, also multiple types - with according information expressed via RDF statements where the resource is the subject.

Annex A - Vocabulary examples (informative)

Vocabularies created based upon the guidelines from this document are available at https://github.com/inspire-eu-rdf/inspire-rdf-vocabularies.

Bibliography