Guidelines for the RDF encoding of spatial data

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

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.

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

This standard uses a number of namespace prefixes throughout; they are listed in the following table.

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.

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.

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.

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.

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.

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).

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.

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

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.

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.

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.

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:

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.

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

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.

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.

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:

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.

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:

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.

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.

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.

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.