Copyright © 2016-2019 European Union. This document is licensed under a Creative Commons Attribution 4.0 License.

Abstract

This document presents a proposal for mapping the relevant terms from the ISA Core Location Vocabulary (LOCN) to the vCard Ontology (vCard) and to the Schema.org vocabulary (Schema.org).

Disclaimer

The views expressed are purely those of the author and may not in any circumstances be regarded as stating an official position of the European Commission.

Background

The ISA Programme Location Core Vocabulary provides a minimum set of classes and properties for describing any place in terms of its name, address or geometry. The vocabulary is specifically designed to aid the publication of data that is interoperable with EU INSPIRE Directive. It is closely integrated with the Business [[ISA-CV-LEGAL]] and Person [[ISA-CV-PERSON]] Core Vocabularies of the EU ISA Programme, now available in W3C space as, respectively, the Registered Organization vocabulary [[VOCAB-REGORG]] and ISA Person Core Vocabulary [[PERSON]].

This document presents a proposal for mapping the relevant terms from the ISA Core Location Vocabulary (LOCN) [[LOCN]] to the vCard Ontology (vCard) [[vCARD-RDF]] and to the Schema.org vocabulary (Schema.org) [[SCHEMA-ORG]], which are the two vocabularies most widely used in the Web to represent addresses and location information.

The purpose of this mapping exercise is twofold:

  1. Optimise the publication and discovery on the Web of INSPIRE data concerning addresses and location information, by supporting an alternative encoding based on commonly used Web vocabularies.
  2. Enable the sharing and re-use of data concerning addresses and location information expressed by using LOCN, vCard and Schema.org.

Methodology

The reference specifications used in this exercise are the following ones:

For the mappings, existing work has been taken into account concerning the mapping of Schema.org to other metadata standards. In particular:

The following sections include:

Summary of alignment issues

The proposed mappings can be grouped into the following classes:

1-to-1 mappings with no mapping issues

This class covers the majority of the mapped terms (9 out of 16).

Many-to-1 mappings

This class includes 2 of the mapped terms, namely, locn:thoroughfare (street name) and locn:locatorDesignator (street number).

LOCN models this information by using two distinct terms, whereas vCard and Schema.org merge this information into a single property—namely, vcard:street-address and schema:streetAddress, respectively.

This is not an issue when mapping from LOCN to vCard and Schema.org (the two fields are merged into one, preserving all the information). On the other hand, mapping from vCard / Schema.org to LOCN may require further processing to identify the two different components of a street address (namely, street name and number).

Missing mappings

This class includes 3 of the mapped terms, namely, locn:poBox, locn:locatorName, and locn:addressArea.

More precisely:

Mappings with encoding issues

This class includes 1 of the mapped terms, namely, locn:geometry.

vCard and Schema.org use specific encodings / representations for geometries, whereas LOCN supports any type of geometry encoding / representation.

This is not an issue when mapping from vCard / Schema.org to LOCN. On the other hand, mapping from LOCN to vCard and Schema.org may require further processing to convert the original geometry encoding / representation to the target one.

Based on what said above, the alignments with no severe mapping issues are able to map the following information:

Used namespaces

Prefix Namespace URI Schema & documentation
dct http://purl.org/dc/terms/ DCMI Metadata Terms [[DCTERMS]]
locn http://www.w3.org/ns/locn# ISA Programme Core Location Vocabulary [[LOCN]]
schema http://schema.org/ Schema.org [[SCHEMA-ORG]]
vcard http://www.w3.org/2006/vcard/ns# vCard Ontology [[vCARD-RDF]]

Mapping summary

The following table provides an overview of the proposed mappings between LOCN [[LOCN]], vCard [[vCARD-RDF]], and Schema.org [[SCHEMA-ORG]].

LOCN vCard Schema.org Comments
dct:Location vcard:Location schema:Place
locn:geographicName vcard:fn (vcard:Location) schema:name (schema:Place)
locn:geometry vcard:hasGeo schema:geo

It seems that vCard expects as value a point, encoded as a geo: URI (to be verified).

Schema.org expects as value an instance of schema:GeoCoordinates (for points) or schema:GeoShape (for more complex geometries).

LOCN allows any type of geometry, and any type of geometry encoding / representation—including those supported by vCard and Schema.org.

As a consequence, the locn:geometry mapping might require further processing to encode the geometry according the encodings / representations supported in vCard and Schema.org.
locn:Geometry N/A schema:GeoCoordinates

See comments on property locn:geometry
schema:GeoShape
locn:address vcard:hasAddress schema:address
locn:Address vcard:Address schema:PostalAddress
locn:fullAddress vcard:fn (vcard:Address) schema:name (schema:PostalAddress)
locn:poBox TBD schema:postOfficeBoxNumber

vCard includes a specific property, namely, vcard:post-office-box, but its use has been deprecated.

Possible options:

  1. leave locn:poBox unmapped
  2. use vcard:post-office-box, despite it is deprecated
  3. dump it into vcard:street-address
locn:thoroughfare vcard:street-address schema:streetAddress
locn:locatorDesignator vcard:street-address schema:streetAddress
locn:locatorName TBD TBD

In LOCN, locn:locatorName is defined as follows:

Proper noun(s) applied to the real world entity identified by the locator. The locator name could be the name of the property or complex, of the building or part of the building, or it could be the name of a room inside a building.

vCard includes a specific property, namely, vcard:extended-address, but its use has been deprecated.

Schema.org does not define terms to model this information.

Possible options:

  1. leave locn:locatorName unmapped
  2. use vcard:extended-address, despite it is deprecated, and leave locn:locatorName unmapped for Schema.org
  3. dump it into vcard:street-address / schema:streetAddress
locn:addressArea TBD TBD

In LOCN, locn:addressArea is defined as follows:

The name or names of a geographic area or locality that groups a number of addressable objects for addressing purposes, without being an administrative unit. This would typically be part of a city, a neighbourhood or village. […]

vCard and Schema.org do not define terms to model this information.

Possible options:

  1. leave locn:addressArea unmapped
  2. dump it into vcard:street-address / schema:streetAddress
locn:postName vcard:locality schema:addressLocality
locn:adminUnitL2 vcard:region schema:addressRegion
locn:adminUnitL1 vcard:country-name schema:addressCountry
locn:postCode vcard:postal-code schema:postalCode
locn:addressId vcard:hasUID schema:identifier

In vCard, vcard:hasUID is formally defined as an owl:ObjectProperty, and therefore its value cannot be a literal. However, this seems to be in conflict with its informal definition, which is less restrictive—quoting:

[…] a value that represents a globally unique identifier corresponding to the object.

(to be verified)

Acknowledgements

This work has been supported by the EU Interoperability Solutions for European Public Administrations Programme (ISA) through Action 1.17: Re-usable INSPIRE Reference Platform (ARe3NA).

SPARQL implementation

This section illustrates a tentative implementation of the defined mappings, in the form of SPARQL CONSTRUCT queries [[SPARQL11-QUERY]].

The mappings have been defined in a modular way, with a separate SPARQL query for each of the LOCN classes, and related properties. A complete representation of a given resource (e.g., an address) and related resources (e.g., the address's point geometry) can be obtained by combining the relevant SPARQL queries.

The source SPARQL queries are maintained in the dedicated GitHub repository.

LOCN to vCard mapping

Mapping rules for locn:geographicName

Mapping rules for locn:geometry

NB: This mapping does not address the geometry encoding issues mentioned in the mapping summary in relation to the alignment of property locn:geometry.

Mapping rules for locn:Geometry

Because of the geometry encoding issues reported in the mapping summary about the alignment of property locn:geometry, the mapping of class locn:Geometry requires syntax processing that is not addressed in the current version of this document.

For this reason, no mapping rule is defined here for class locn:Geometry.

Mapping rules for locn:Address

LOCN to Schema.org mapping

Mapping rules for locn:geographicName

Mappings rules for locn:geometry

NB: This mapping does not address the geometry encoding issues mentioned in the mapping summary in relation to the alignment of property locn:geometry.

Mapping rules for locn:Geometry

Because of the geometry encoding issues reported in the mapping summary about the alignment of property locn:geometry, the mapping of class locn:Geometry requires syntax processing that is not addressed in the current version of this document.

For this reason, no mapping rule is defined here for class locn:Geometry.

Mapping rules for locn:Address

SKOS definition

This section illustrates a tentative SKOS [[SKOS-REFERENCE]] implementation of the defined mappings.

The source SKOS representation is maintained in the dedicated GitHub repository.

LOCN to vCard mapping







LOCN to Schema.org mapping