The Core Location Vocabulary is a simplified, reusable and extensible data model that captures the fundamental characteristics of a location, represented as an address, a geographic name, or a geometry.


Locations can be described in three principal ways: by using a place name, a geometry or an address. The specific context will determine which method of describing a location is most appropriate. The Core Location Vocabulary provides structure for all three.

ISO 19112 defines a location as "an identifiable geographic place." With this in mind, "Eiffel Tower", "Madrid" and "California" are all locations and this is a common way of representing locations in public sector data, i.e. simply by using a recognised name. Such identifiers are common although they can be highly ambiguous as many places share the same or similar names.

In addition to a simple (string) label or name for a Location, this vocabulary defines a property that allows a Location to be defined by a URI, such as a GeoNames or DBpedia URI.

No cardinality constraints are placed on any property of the Location, Address or Geometry classes in order to maximise flexibility. A single address may be defined in different ways, a geometry may be defined using different coordinate reference systems and a single place may have no recognised name or multiple names. The Core Location Vocabulary makes a minimum number of assumptions about what data will be encoded. However, it clearly makes no sense to define any of the location classes without any properties or to provide multiple instances of the same property with conflicting values.


This Core Vocabulary has the status SEMIC Recommendation published at 2024-05-06.

Information about the process and the decisions involved in the creation of this specification are consultable at the Changelog.


Copyright © 2024 European Union. All material in this repository is published under the license CC-BY 4.0, unless explicitly otherwise mentioned.


A Core Vocabulary (CV) is a basic, reusable and extensible data specification that captures the fundamental characteristics of an entity in a context-neutral fashion. Its main objective is to provide terms to be reused in the broadest possible context. More information can be found on the SEMIC Style Guide.

This specification uses the following prefixes to shorten the URIs for readibility.
PrefixNamespace IRI


This document describes the usage of the following main entities for a correct usage of the Core Vocabulary:
| Address | Administrative Unit | Geometry | Location | Locator Designator |

The main entities are supported by:
| Resource |

And supported by these datatypes:
| Code | Literal | String | Text | URI |

Main Entities

The main entities are those that form the core of the Core Vocabulary.


A spatial object that in a human-readable way identifies a fixed location.
Usage Note
An "address representation" as conceptually defined by the INSPIRE Address Representation data type: "Representation of an address spatial object for use in external application schemas that need to include the basic, address information in a readable way.".

The representation of Addresses varies widely from one country's postal system to another. Even within countries, there are almost always examples of Addresses that do not conform to the stated national standard. However, ISO 19160-1 provides a method through which different Addresses can be converted from one conceptual model to another.

This specification was heavily based on the INSPIRE Address Representation data type. It is noteworthy that if an Address is provided using the detailed breakdown suggested by the properties for this class, then it will be INSPIRE-conformant. To this very granular set of properties, we add two further properties:

- full address (the complete address as a formatted string)
- addressID (a unique identifier for the address).

The first of these allows publishers to simply provide the complete Address as one string, with or without formatting. This is analogous to vCard's label property.

The addressID is part of the INSPIRE guidelines and provides a hook that can be used to link the Address to an alternative representation, such as vCard or OASIS xAL.

This class belongs to Core Location Vocabulary
For this entity the following properties are defined: address area , address ID , administrative unit , administrative unit level 1 , administrative unit level 2 , full address , has locator designator , locator designator , locator name , post code , post name , post office box , thoroughfare .
Property Range Card Definition Usage
[o] address area Text 0..* The name of a geographic area that groups Addresses. This would typically be part of a city, a neighbourhood or village, e.g. Montmartre. Address area is not an administrative unit.
[o] address ID Literal 0..* A globally unique identifier for each instance of an Address. The concept of adding a globally unique identifier for each instance of an address is a crucial part of the INSPIRE data spec. A number of EU countries have already implemented an ID (a UUID) in their Address Register/gazetteer, among them Denmark. OASIS xAL also includes an address identifier. It is the address Identifier that allows an address to be represented in a format other than INSPIRE whilst remaining conformant to the Core Vocabulary.

The INSPIRE method of representing addresses is very detailed, designed primarily for use in databases of addresses. Whilst data that is published in full conformance with the INSPIRE data structure can be made available using theCore Location Vocabulary the reverse is not true since the Core Vocabulary allows much greater flexibility.

Many datasets that include address data as one piece of information about something else are likely to have that data in simpler formats. These might be tailored to the specific need of the dataset, follow a national norm, or make use of a standard like vCard.

To provide maximum flexibility in the Core Vocabulary, whilst remaining interoperable with INSPIRE Address Guidelines (which EU Member States are obliged to use), the Core Location Vocabulary provides the extra property of full address and makes use of INSPIRE's addressID.
[o] administrative unit Administrative Unit 0..* The adminUnit relationship links an Address with the Administrative Unit class.
[o] administrative unit level 1 Text 0..* The name of the uppermost level of the address, almost always a country. Best practice is to use the ISO 3166-1 code but if this is inappropriate for the context, country names should be provided in a consistent manner to reduce ambiguity. For example, either write 'France' or 'FRA' consistently throughout the dataset and avoid mixing the two. The Country controlled vocabulary from the Publications Office can be reused for this.
[o] administrative unit level 2 Text 0..* The name of a secondary level/region of the address, usually a county, state or other such area that typically encompasses several localities. Values could be a region or province, more granular than level 1.
[o] full address Text 0..* The complete address written as a string. Use of this property is recommended as it will not suffer any misunderstandings that might arise through the breaking up of an address into its component parts. This property is analogous to vCard's label property but with two important differences: (1) formatting is not assumed so that, unlike vCard label, it may not be suitable to print this on an address label, (2) vCard's label property has a domain of vCard Address; the fullAddress property has no such restriction. An example of a full address is "Champ de Mars, 5 Avenue Anatole France, 75007 Paris, France".
[o] has locator designator Locator Designator 0..* A number or a sequence of characters that uniquely identifies the locator within the relevant scope(s). This relation can be used instead of Address.locatorDesignator if a structured representation is preferred over a Literal.
[o] locator designator Literal 0..* A number or sequence of characters that uniquely identifies the locator within the relevant scope. In simpler terms, this is the building number, apartment number, etc. For an address such as "Flat 3, 17 Bridge Street", the locator is "flat 3, 17".
[o] locator name Text 0..* 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. 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.

The key difference between a locator designator and a locator name is that the latter is a proper name and is unlikely to include digits. For example, "Shumann, Berlaymont" is a meeting room within the European Commission headquarters for which locator name is more appropriate than locator.
[o] post code Literal 0..* The code created and maintained for postal purposes to identify a subdivision of addresses and postal delivery points. Post codes are common elements in many countries' postal address systems. One of the many post codes of Paris is for example "75000".
[o] post name Text 0..* A name created and maintained for postal purposes to identify a subdivision of addresses and postal delivery points. Usually a city, for example "Paris".
[o] post office box Literal 0..* A location designator for a postal delivery point at a post office, usually a number. INSPIRE's name for this is "postalDeliveryIdentifier" for which it uses the locator designator property with a type attribute of that name. This vocabulary separates out the Post Office Box for greater independence of technology. An example post office box number is "9383".
[o] thoroughfare Text 0..* The name of a passage or way through from one location to another. A thoroughfare is usually a street, but it might be a waterway or some other feature. For example, "Avenue des Champs-Élysées".

Administrative Unit

A detailed administrative unit organized in a hierarchy.
Usage Note
This class should be used whenever a classification mechanism is in place, in alternative to the properties adminUnitL1 and adminUnitL2 of the Address class which allow free text.
For this entity the following properties are defined: code , level , name .
Property Range Card Definition Usage
[o] code Code 0..* The classification of the administrative unit.
[o] level Code 0..* The level of the administrative unit in the hierarchy. The recommended code list to indicate the level of an Admin Unit is the Administrative territorial unit type Controlled Vocabulary maintained by the Publications Office of the EU.
[o] name Text 0..* Official, geographical name of the administrative unit, given in different languages where required.


A shape or form of a Location.
Usage Note
This class defines the notion of "geometry" at the conceptual level, and it shall be encoded by using different formats (see usage note of the locn:geometry property). Can be a point, line or polygon, expressed using coordinates in some coordinate reference system. We also refer to the Examples section of this specification for a number of different geometry examples expressed in different formats.
For this entity the following properties are defined: coordinates , crs , geometry type , gml , latitude , longitude , wkt .
Property Range Card Definition Usage
[o] coordinates String 0..* A list of geographic coordinates that define the extent of the Geometry. Can be expressed as longitude, latitude, elevation.
[o] crs URI 0..* An identifier for the coordinate reference system. Can be a coordinate-based local, regional or global system used to locate geographical entities.
[o] geometry type Code 0..* The classification of the Geometry. Can be a point, line or polygon.
[o] gml Literal 0..* The expression of the Geometry in Geography Markup Language. Use geo:gmlLiteral as type for the literal.
[o] latitude String 0..* The geographic coordinate that specifies the north / south position of the Geomerty on the Earth's surface.
[o] longitude String 0..* The geographic coordinate that specifies the east / west position of the Geometry on the Earth's surface.
[o] wkt Literal 0..* An expression of the Geometry in WKT, the Well-Known Text markup language. Use geo:wktLiteral as type for the literal.


An identifiable geographic place or named place.
For this entity the following properties are defined: geographic identifier , geographic name .
Property Range Card Definition Usage
[o] geographic identifier URI 0..* A reference in the form of a Uniform Resource Identifier to the Location. GeoNames.org provides stable, widely recognised identifiers for more than 10 million geographical names that can be used as links to further information. For example, http://sws.geonames.org/593116/ identifies the Lithuanian capital Vilnius. Unfortunately these URIs cannot easily be automatically deduced since the URI scheme uses simple numeric codes. Finding a GeoNames identifier for a Location is almost always a manual process. Where such identifiers are known or can be found, however, it is recommended that they be used. Where the Location Class is used to identify a country, if the geonames URI is not known, the recommendation is to use DBpedia URIs of the form http://dbpedia.org/resource/ISO\_3166-1:XX where XX is the ISO 3166 two character code for the country.

The EU's Publication Office diverges from ISO 3166-1 and uses EL and UK for Greece and the United Kingdom respectively. DBpedia sticks to the ISO codes and so the correct URIs for these countries are: - http://dbpedia.org/resource/ISO\_3166-1:GR - http://dbpedia.org/resource/ISO\_3166-1:GB even when the geographic name is given as EL or UK.
[o] geographic name Text 0..* A textual description for a Location. The INSPIRE Data Specification on Geographical Names provides a detailed model for describing a 'named place', including methods for providing multiple names in multiple scripts. INSPIRE's definition is the following: Names of areas, regions, localities, cities, suburbs, towns or settlements, or any geographical or topographical feature of public or historical interest. This is beyond what is necessary for the Core Location Vocabulary but, importantly, the concept of a geographic name used here is consistent.

A geographic name is a proper noun applied to a spatial object. Taking the example used in the INSPIRE document (page 18), the following are all valid geographic names for the Greek capital: - "Aθnνa"@gr-Grek (the Greek endonym written in the Greek script) - "Athína"@gr-Latn (the standard Romanisation of the endonym) - "Athens"@en (the English language exonym) INSPIRE has a detailed (XML-based) method of providing metadata about a geographic name and in XML-data sets that may be the most appropriate method to follow. When using the Core Location Vocabulary in data sets that are not focussed on environmental/geographical data (the use case for INSPIRE), the Code datatype or a simple language identifier may be used to provide such metadata.

The country codes defined in ISO 3166 may be used as geographic names and these are generally preferred over either the long form or short form of a country's name (as they are less error prone). The Publications Office of the European Union recommends the use of ISO 3166-1 codes for countries in all cases except two: - use 'UK' in preference to the ISO 3166 code GB for the United Kingdom; - use 'EL' in preference to the ISO 3166 code GR for Greece. Where a country has changed its name or no longer exists (such as Czechoslovakia, Yugoslavia etc.) use the ISO 3166-3 code.

Locator Designator

A number or a sequence of characters that uniquely identifies the locator within the relevant scope(s). The full identification of the locator could include one or more locator designators.
Usage Note
Locator designators are often assigned according to a set of commonly known rules which enables a user or application to "parse" the information: Address numbers are most often assigned in ascending order with odd and even numbers on each side of the thoroughfare. In a building, the floor identifier represents the level according to the traditions within the area, e.g., 1, 2, 3.
Several types of locator designators exist, such as: Address number, address number suffix, building identifier, building name. A locator could be composed by an ordered set of these.
EXAMPLE In Paris, France a locator could be composed by two locator designators: address number "18" and address number suffix: "BIS".
For this entity the following properties are defined: designator , type .
Property Range Card Definition Usage
[o] designator Literal 0..* The identifying part of the locator designator composed by one or more digits or other characters. NOTE The value is often a descriptive code assigned according to certain well known rules e.g. like ascending odd and even address numbers along the thoroughfare, or like floor identifiers: 0, 1, 2, 3.
EXAMPLE Address number "2065", Address number suffix "B", Floor identifier "7" door identifier "B707" are all locator attribute values.
[o] type Code 0..* The type of locator value, which enables an application to interpret, parse or format it according to certain rules. The type enables a user or an application to understand if the value "A" is e.g. an identifier of a specific building, door, staircase or dwelling. The usage of INSPIRES' Locator Designator Type code list is recommended.

Supportive Entities

The supportive entities are supporting the main entities in the Core Vocabulary. They are included in the Core Vocabulary because they form the range of properties.


Anything that can be described.
Usage Note
Resource is an abstract, technical class used to describe anything in RDF, see RDF Schema Resource for more details.

For example, in the context of Core Vocabularies, classes like Person or Legal Entity are resources.

In other data modelling languages, this class should be mapped to their corresponding generic element.
For this entity the following properties are defined: address , geometry , location , registered address .
Property Range Card Definition Usage
[o] address Address 0..* Associates any Resource with the corresponding Address. Asserting the address relationship implies that the Resource has an Address.
[o] geometry Geometry 0..* Associates any Resource with the corresponding Geometry.

Depending on how a geometry is encoded, the range of this property may be one of the following:

For interoperability reasons, it is recommended using one of the following:

[o] location Location 0..* Associates any Resource with the corresponding Location. Asserting the location relationship implies only that the domain has some connection to a Location in time or space. It does not imply that the Resource is necessarily at that Location at the time when the assertion is made.
[o] registered address Address 0..* The registered address relationship links a Resource with the legally registered Address. It is the address to which formal communications can be sent, such as the postal address.


The following datatypes are used within this specification.
Class Definition
(create issue) An idea or notion; a unit of thought.
(create issue) The class of literal values, eg. textual strings and integers.
(create issue) The string datatype represents character strings in XML.
(create issue) The text data type is a combination of a string and a language identifier.
(create issue)
anyURI represents an Internationalized Resource Identifier Reference (IRI). An anyURI value can be absolute or relative, and may have an optional fragment identifier (i.e., it may be an IRI Reference).


Example 1 - Location WKT (GeoSPARQL)
Example 2 - Location GML (GeoSPARQL)
Example 3 - Location WGS84 lat/long
Example 4 - Location schema.org
Example 5 - Location GeoHash
Example 6 - Address

Usage Guidelines

Support for implementation

The following section provides support for implementing the Core Location Vocabulary.

JSON-LD context file

One common technical question is the format in which the data is being exchanged. For conformance with the Core Location Vocabulary, it is not mandatory that this happens in a RDF serialisation, but the exhanged format SHOULD be unambiguously be transformable into RDF. For the format JSON, a popular format to exchange data between systems, SEMIC provides a JSON-LD context file. JSON-LD is a W3C Recommendation [[[json-ld11]]] that provided a standard approach to interpret JSON structures as RDF. The provided JSON-LD context file can be used by implementers. This JSON-LD context is not normative, i.e. other JSON-LD contexts are allowed.

The JSON-LD context file downloadable here.


To verify if the data is (technically) conformant to the Core Location Vocabulary, the exchanged data can be validated using the provided SHACL shapes. SHACL is a W3C Recommendation to express constraints on a RDF knowledge graph.

To support the check whether or not a catalogue satisfies the expressed constraints in this Core Vocabulary, the constraints in this specification are expressed using SHACL [[shacl]]. Each constraint in this specification that could be converted into a SHACL expression has been included. As such this collection of SHACL expressions that can be used to build a validation check for data.

It is up to the implementers to define the validation they expect. Each implementation happens within a context, and that context is beyond the SHACL expressions here.

The shapes can be found here.

RDF representation

The RDF representation of the Core Location Vocabulary is available here.

UML representation

The UML representation from which the Core Location Vocabulary has been build is available here.


Versioning governance

All specifications produced in SEMIC will follow the versioning rule described by the SEMIC Style Guide rule PC-R3. In case a SEMIC asset is deprecated the asset will remain available through its PURI.

The serialisation will have:

Governance requirements for re-used assets

In order to adhere to the SEMIC Style Guide rule GC-R2 a specification should have quality and governance standards for the assets that are being reused.

In order for an asset to be considered for reuse within a SEMIC specification it can be requested by a community member or it requires to adhere to the following requirements:

After being taken into consideration the asset will be validated in three steps:

Once considered and validated an asset can be adopted if it is approved by the community.

Lexicalisation rules

In order to adhere to the SEMIC Style Guide rule SC-R3 a specification requires formal lexicalisation rules. The Style Guide proposes two options either by using RDFS or SKOS lexicalisation.

SEMIC uses and will use the RDFS lexicalisation for all of its specifications. More specifically:


A mapping towards Schema.org can be found here

Quick Reference of Classes and Properties

This section provides a condensed tabular overview of the mentioned classes and properties in this specification. The properties are indicated as mandatory, recommended, optional and deprecated. These terms have the following meaning.
ClassClass IRIProperty TypePropertyProperty IRI
address area
address ID
administrative unit
administrative unit level 1
administrative unit level 2
full address
has locator designator
locator designator
locator name
post code
post name
post office box
Administrative Unit
Administrative Unit
Administrative Unit
geometry type
geographic identifier
geographic name
Locator Designator
Locator Designator
registered address