+GeoDCAT-AP is an extension of the DCAT application profile for data portals in Europe ([[[DCAT-AP-3]]]) for describing geospatial datasets, dataset series, and services. Its basic use case is to make spatial datasets, dataset series, and services searchable on general data portals, thereby making geospatial information better findable across borders and sectors. For this purpose, GeoDCAT-AP provides an RDF vocabulary and the corresponding RDF syntax binding for the union of metadata elements of the core profile of ISO 19115:2003 [[ISO-19115]] and those defined in the framework of the INSPIRE Directive [[INSPIRE-DIR]] of the European Union.
+
+
+
+
+
+ Introduction
+
+
+
This document contains version 3.0.0 of the specification for GeoDCAT-AP, an extension of the DCAT application profile for data portals in Europe [[DCAT-AP-3]] for describing geospatial datasets, dataset series, and services.
+
+
Its basic use case is to make spatial datasets, dataset series, and services searchable on general data portals, thereby making geospatial information better findable across borders and sectors. For this purpose, GeoDCAT-AP provides an RDF vocabulary and the corresponding RDF syntax binding for the union of metadata elements of the core profile of ISO 19115:2003 [[ISO-19115]] and those defined in the framework of the INSPIRE Directive [[INSPIRE-DIR]].
+
+
The GeoDCAT-AP specification does not replace the INSPIRE Metadata Regulation [[?INSPIRE-MD-REG]] nor the INSPIRE Metadata technical guidelines [[INSPIRE-MD]] based on ISO 19115 and ISO 19119. Its purpose is to give owners of geospatial metadata the possibility to achieve more by providing the means of an additional implementation through harmonised RDF syntax bindings. Conversion rules to RDF syntax would allow Member States to maintain their collections of INSPIRE-relevant datasets following the INSPIRE Metadata technical guidelines based on [[ISO-19115]] and [[ISO-19119]], while at the same time publishing these collections on [[DCAT-AP-3]]-conformant data portals. A conversion to an RDF representation allows additional metadata elements to be displayed on general-purposed data portals, provided that such data portals are capable of displaying additional metadata elements. Additionally, data portals may be capable of providing machine-to-machine interfaces where additional metadata could be provided.
+
+
+
+
Context
+
+
With a view to fostering Europe's digital transformation, the European Commission is investing in frameworks and agreements to provide governments and businesses with the appropriate resources to digitalise their services. There are, for instance, building blocks available for creating a single market for data, where data flows freely within the EU and across sectors for the benefit of businesses, researchers and public administrations.
+
+
To this direction, the European Commission launched the European Data Strategy [[DataStrategy]], as part of the European Commission's priorities for 2019-2024 in order to make the EU a leader in a data-driven society.
+
+
Studies previously conducted on behalf of the European Commission (e.g., [[Vickery]]) shed light on the importance of having data findable and available in machine readable format in order to stimulate its reuse. This vision led to several legislative actions to reduce barriers and promote data sharing, such as the Open Data Directive [[OPENDATA-DIR]], which turned out to be a driving force towards a more transparent and fair access to government data.
+
+
With this regard, the wide range of (open) data portals developed by European public administrations is the result of this mission. These Web-based interfaces allow access to data by providing users means to explore a catalogue of datasets. To facilitate the sharing, discovery and re-use of the data beyond the (open) data portal, common agreements for the exchange of catalogues of datasets are needed. These interoperability agreements enable to connect (open) data catalogues into a pan-european catalogue of datasets.
+
+
The DCAT Application Profile specifies the generic agreements for (open) data portals operated by public administrations in Europe. This specification extends DCAT-AP with additional requirements for geospatial data.
+
+
The current document is the result of the major semantic change release process described in the Change and Release Management Policy for DCAT-AP [[DCAT-AP-CRMP]] and was built starting from GeoDCAT-AP version 2.0.0 [[GeoDCAT-AP-20201223]], with the purpose of aligning it with DCAT-AP version 3.x.x [[DCAT-AP-3]] and with version 2.1.3 of the INSPIRE Metadata Technical Guidelines [[INSPIRE-MD-20230731]].
+
+
This work has been carried out in the context of the European Commission’s Interoperable Europe initiative [[INTEROPERABLE-EUROPE]].
+
+
+
+
+
+
Scope of the Application Profile
+
+
The objective of this work is to produce an updated release of GeoDCAT-AP based on requests for change coming from real-world implementations of the specification and an alignment with [[DCAT-AP-3]] and [[INSPIRE-MD-20230731]].
+
+
As [[[DCAT-AP-3]]], the Application Profile specified in this document is based on the specification of the Data Catalog Vocabulary (DCAT). DCAT is originally developed under the responsibility of the Government Linked Data Working Group [[GLD]] at W3C, and was significantly revised in 2020 by the W3C Dataset Exchange Working Group [[DXWG]]. DCAT is an RDF [[RDF11-CONCEPTS]] vocabulary designed to facilitate interoperability between data catalogues published on the Web.
+
+
+
The objective of this work is to produce an extension of [[DCAT-AP-3]] based on numerous requests for change coming from real-world implementations of the specification listed on the GitHub issues section since the previous release [[GeoDCAT-AP-20201223]]. For that purpose the [[DCAT-AP-3]] specification is extended with improved definitions, usage notes and usages constraints such as cardinalities for properties and the usage of controlled vocabularies. Additional classes and properties are re-used or introduced where necessary.
+
+
+
The work does not cover implementation issues like mechanisms for exchange of data and expected behaviour of systems implementing the Application Profile other than what is defined in the Conformance Statement in section [[[#conformance]]].
+
+
+
+
The Application Profile is intended to facilitate data exchange and therefore the classes and properties defined in this document are only relevant for the data to be exchanged; there are no requirements for communicating systems to implement specific technical environments. The only requirement is that the systems can export and import data in RDF in conformance with this Application Profile.
+
+
+
The work does not cover implementation issues like mechanisms for exchange of data and expected behaviour of systems implementing the Application Profile other than what is defined in the Conformance Statement in .
+
+
+
The Application Profile is intended to facilitate data exchange and therefore the classes and properties defined in this document are only relevant for the data to be exchanged; there are no requirements for communicating systems to implement specific technical environments. The only requirement is that the systems can export and import data in RDF in conformance with this Application Profile.
+
+
+
As mentioned in the context, the prime objective of the Application Profile is to enhance data findability and promote reusability.
+To achieve this goal, datasets should be coherently documented.
+To enable this, the Application Profile considers several essential aspects, including among others:
+
+
Understanding the data or service structure, and how to get access to the data
+
Information on scope or purpose of the data
+
Legal information
+
Knowledge on data publishers, and any other agents involved
+
Knowledge of data availability and change policies
+
+These are addressed with the aim to facilitate effective data reuse, allowing users to locate, understand and utilise the available data resources more efficiently.
+
+
+
+
+
DCAT-AP Context
+
+
Around 2010, on behalf of the European Commission the access to public sector information was studied. These studies showed that businesses and citizens faced many difficulties in finding and reusing public sector information.
+The studies indicated that the availability of the information in a machine-readable format as well as a thin layer of commonly agreed metadata could facilitate data cross-reference and interoperability and therefore considerably enhance its value for reuse.
+Therefore, to overcome these hurdles, the European Commission invested in policies [[PSI]], data interoperability [[SEMIC]] and infrastructure [[DEU]].
+
+
+
Interoperable Europe, within its mission to stimulate the data interoperability in Europe, manages this specification on the metadata agreements for sharing dataset descriptions between data portals.
+The governance is taken care by the SEMIC action within Interoperable Europe.
+Initially, the scope of the specification was the exchange between Open Data Portals in Europa.
+Although this is still at the core of the specification, DCAT-AP is not limited to public accessible Open Data, but can be applied to any kind of datasets.
+In the past decade, DCAT-AP has grown from a single specification to a whole ecosystem of related and interconnected specifications.
+
+
+
+
+
+
Revision history
+The first GeoDCAT-AP specification was released in December 2015. The subsequent release 1.0.1 improved the specification. These specifications are aligned with the core profile of ISO 19115:2003 [[ISO-19115]] and those defined in the framework of the INSPIRE Directive [[INSPIRE-DIR]].
+Five years later in December 2020 the second version of GeoDCAT-AP was released. W3C DCAT 2 restructured DCAT by introducing the notions of a generic Catalogued Resource of which Datasets and Data Services are special cases. As a consequence both DCAT-AP and GeoDCAT-AP required a major revision ensuring alignment between the different specifications.
+In 2023, the adoption of W3C DCAT 3 [[vocab-dcat-3]] triggered a new alignment for DCAT-AP, and consquently for GeoDCAT-AP.
+W3C DCAT 3 extends the profile with the Dataset Series notion.
+This document is the combination of addressing issues raised by the community and this alignment.
+
+
Notes on alignment with DCAT 3
+Being an extension of [[DCAT-AP-3]], GeoDCAT-AP inherits the changes that were introduced in [[[DCAT-AP-3]]] due to the aligment with [[[vocab-dcat-3]]]. The introduction of Dataset Series in DCAT is an additive operation from semantical, data modeling perspective.
+Therefore the impact on existing GeoDCAT-AP 2.x, exchanges is limited.
+Nevertheless, publishers may face substantial impact on the existing catalogues as the new terminology for Dataset Series may require to revisit the publisher's metadata guidelines.
+For instance, if the publisher had chosen to document a Dataset Series as a Dataset with multiple Distributions, then the alignment with Dataset Series as expressed in this specification will require a substantial effort.
+This impact goes beyond the specification and dependent on the usage of the shared information.
+In the context of GeoDCAT-AP and in line with the conformance expectations and [[DCAT-AP-3]], the term Dataset Series will be solely used for resources that are explicitly identified by the class Dataset Series.
+The situation, as mentioned, where a Dataset has multiple Distributions, will be considered as a Dataset with multiple Distributions and not as a Dataset Series.
+This way, receivers of GeoDCAT-AP metadata can rely on the classes to process the metadata.
+
+The sole data model impact DCAT 3 creates, is by deprecating the use of some URIs and introducing new URIs in the DCAT namespace for the use case of Dataset versioning.
+As these properties are optional and since there is an equivalence between the deprecated and the new ones, catalogue owners can easily realign.
+
+
+
+GeoDCAT-AP 3 is the result of an alignment with DCAT 3, DCAT-AP 3 and improvements to harmonise the interoperability between DCAT-AP and GeoDCAT-AP.
+These changes are listed in detail in the Changelog.
+To support the review, the changes are also highlighted on the diagram below.
+
+
+In order to conform to this Application Profile, an application that provides metadata MUST:
+
+
Provide a description of the Catalogue, including at least the mandatory properties specified for the class Catalogue.
+
Provide information for the mandatory properties for Catalogue Records, if descriptions of Catalogue Records are provided – please note that the provision of descriptions of Catalogue Records is optional.
+
Provide descriptions of Datasets in the Catalogue, including at least the mandatory properties for the class Dataset.
+
Provide descriptions of Distributions, if any, of Datasets in the Catalogue, including at least the mandatory properties for the class Distribution.
+
+
Provide descriptions of Data Services, if any, of Datasets in the Catalogue, including at least the mandatory properties for the class Data Service.
+
+
Provide descriptions of all organisations involved in the descriptions of Catalogue and Datasets, including at least the mandatory properties for the class Agent.
+
Apply the publication requirements for the controlled vocabularies as mentioned in section [[[#controlled-vocs]]].
+
+
+For the properties listed in the table in section [[[#controlled-vocs]]], the associated controlled vocabularies MUST be used. Additional controlled vocabularies MAY be used.
+In addition to the mandatory properties, any of the recommended and optional properties defined in section [[[#quick-reference]]] MAY be provided.
+
Receiver requirements
+In order to conform to this Application Profile, an application that receives metadata MUST be able to:
+
Process information for all classes and properties specified in section [[[#quick-reference]]].
+
Process information for all controlled vocabularies specified in section [[[#controlled-vocs]]].
+"Processing" means that receivers must accept incoming data and transparently provide these data to applications and services.
+It does neither imply nor prescribe what applications and services finally do with the data (parse, convert, store, make searchable, display to users, etc.).
+
+
+
+
+
+
+
+
+
Terminology
+
+An Application Profile is a specification that reuses terms from one or more base standards, adding more specificity by identifying mandatory, recommended and optional elements to be used for a particular application, as well as recommendations for controlled vocabularies to be used.
+
+A Dataset is a collection of data, published or curated by a single source, and available for access or download in one or more formats.
+A Data Portal is a Web-based system that contains a data catalogue with descriptions of datasets and provides services enabling discovery and reuse of the datasets.
+
+
Used prefixes
+
+
+
+
Prefix
Namespace IRI
+
+
adms
http://www.w3.org/ns/adms#
+
dcat
http://www.w3.org/ns/dcat#
+
dcatap
http://data.europa.eu/r5r/
+
dct
http://purl.org/dc/terms/
+
dctype
http://purl.org/dc/dcmitype/
+
foaf
http://xmlns.com/foaf/0.1/
+
locn
http://www.w3.org/ns/locn#
+
odrl
http://www.w3.org/ns/odrl/2/
+
owl
http://www.w3.org/2002/07/owl#
+
prov
http://www.w3.org/ns/prov#
+
rdf
http://www.w3.org/1999/02/22-rdf-syntax-ns#
+
rdfs
http://www.w3.org/2000/01/rdf-schema#
+
skos
http://www.w3.org/2004/02/skos/core#
+
spdx
http://spdx.org/rdf/terms#
+
time
http://www.w3.org/2006/time#
+
vcard
http://www.w3.org/2006/vcard/ns#
+
xsd
http://www.w3.org/2001/XMLSchema#
+
org
http://www.w3.org/ns/org#
+
content
http://www.w3.org/2011/content#
+
dqv
http://www.w3.org/ns/dqv#
+
sdmx-attribute
http://purl.org/linked-data/sdmx/2009/attribute#
+
geodcatap
http://data.europa.eu/930/
+
+
+
+
+
+
+
+
Overview
+
+
+This Application Profile extends [[DCAT-AP-3]] by including
+
additional classes and properties;
+
additional recommendations on the use of classes and properties;
+
additional controlled vocabularies (documented in 9. Controlled Vocabularies to be used, along with the ones used in [[DCAT-AP-3]]).
+
+These extensions are meant to provide a DCAT-AP-conformant representation of geospatial metadata, identified by defining RDF syntax mappings covering the union of the elements in the INSPIRE metadata schema [[INSPIRE-MD-REG]], [[INSPIRE-MD]] and the core profile of [[ISO-19115]], following the criteria illustrated in A. INSPIRE and ISO 19115 Mappings.
+
+The current specification does not change the set of geospatial metadata elements already covered in its previous version [[GeoDCAT-AP-20201223]], but rather it updates some of the corresponding mappings based on the new classes and properties included in [[DCAT-AP-3]], following the release of version 2 of the W3C Data Catalog (DCAT) Vocabulary [[vocab-dcat-3]], and aligns them with version 2.2.0 of the INSPIRE Metadata Technical Guidelines [[INSPIRE-MD]].
+
+
+
Application profile diagram
+
+An overview of GeoDCAT-AP is shown by the UML diagram below. The UML diagram illustrates the specification described in this document. For readability purposes, the representation has been condensed as follows:
+
+
no ranges for data properties are shown, because some of them are expressed as unions of XSD types
+
The figure contain the key classes with some important supporting classes. Other object properties (relationships) are listed as properties on the UML class with their target range.
+
The class dcat:Resource has been included to ease to see the connection with W3C DCAT. GeoDCAT-AP treats it as an abstract notion.
+
+The cardinalities and qualifications are included in the figure.
+
+
+The main entities are those that form the core of the Application Profile.
+The properties and their associated constraints that apply in the context of this profile are listed in a tabular form.
+Each row corresponds to one property.
+In addition to the constraints also cross-references are provided to DCAT. To save space, the following abbreviations are used to indicate in short the difference with DCAT:
+
+
A: reused as-is defined and expressed in DCAT-AP, or if it has been reused as-is from DCAT in case the property was not explicitly mentioned in DCAT-AP
+
E: reused with additional usage notes or additional restrictions compared to DCAT-AP (or DCAT)
+
P: GeoDCAT-AP profile specific extension where DCAT-AP had no requirements earlier on specified
+
+This reuse qualification assessement is w.r.t. a specific version of DCAT.
+Therefore it may vary over time when new versions of DCAT-AP are created.
+
+
+
+
+
+
+
+
+
+
+
+
+
+ If the Agent is an organisation, the use of the Organization Ontology [[ORG]] is recommended.
+For the purpose of this application profile, Agent from the FOAF Vocabulary [[FOAF]] is used as a unifying class, also representing Agent from Dublin Core [[DC-TERMS]] and Agent from the W3C Provenance Ontology (PROV-O) [[PROV-O]].
+
+ Information regarding access or restrictions based on privacy, security, or other policies.
+
+
+ For INSPIRE metadata, this property SHOULD be used with the URIs of the "Limitations on public access" code list operated by the INSPIRE Registry [[INSPIRE-LPA]].
+
+ This property refers to a geographic region that is covered by the Catalogue. When multiple values are used for spatial coverage, this may be interpreted as a spatial union, or as alternative representations of spatial coverage that might fit, with no explicit spatial relation.
+
+ A knowledge organization system used to classify the Resources that are in the Catalogue.
+
+
+ This property refers to a knowledge organization system used to classify the Catalogue's Datasets. It must have at least the value NAL:data-theme as this is the manatory controlled vocabulary for dcat:theme.
+
+ In GeoDCAT-AP, this property MAY be used to specify a testing Activity over a Catalogue, against a given Standard, producing as output a conformance degree.
+
+ A link to the Dataset, Data service or Catalog described in the record.
+
+
+ A catalogue record will refer to one entity in a catalogue. This can be either a Dataset or a Data Service. To ensure an unambigous reading of the cardinality the range is set to Catalogued Resource. However it is not the intend with this range to require the explicit use of the class Catalogued Record. As abstract class, an subclass should be used.
+
+ Information regarding access or restrictions based on privacy, security, or other policies.
+
+
+ For INSPIRE metadata, this property SHOULD be used with the URIs of the "Limitations on public access" code list operated by the INSPIRE Registry [[INSPIRE-LPA]].
+
+ An established (technical) standard to which the Data Service conforms.
+
+
+ The standards referred here SHOULD describe the Data Service and not the data it serves. The latter is provided by the dataset with which this Data Service is connected.
+
+For instance the data service adheres to the OGC WFS API standard, while the associated dataset adheres to the INSPIRE Address data model.
+
+ A description of the services available via the end-points, including their operations, parameters etc.
+
+
+ The property gives specific details of the actual endpoint instances, while the property application profile (dct:conformsTo) is used to indicate the general standard or specification that the endpoints implement.
+
+ The reference system used in the Data Service.
+
+
+ Spatial reference systems SHOULD be specified by using the corresponding URIs from the "EPSG coordinate reference systems" register operated by OGC [[OGC-EPSG]].
+
+ Spatial resolution as free-text, when it cannot be specified via dqv:hasQualityMeasurement and dcat:spatialResolutionInMeters. Represents the capabilities of the data service, i.e. in which spatial resolutions it can serve the data.
+
+ In GeoDCAT-AP, this property MAY be used to specify a testing Activity over a Data Service, against a given Standard, producing as output a conformance degree.
+
+ If a Dataset is used as part of a Dataset Series, the properties listed below can be used additionally, or slightly differently to those listed for the Dataset outside of a Dataset Series.
+For this usage, consult the usage guidelines of DCAT-AP.
+
+ Information that indicates whether the Dataset is publicly accessible, has access restrictions or is not public.
+
+
+ For INSPIRE metadata, this property SHOULD be used with the URIs of the "Limitations on public access" code list operated by the INSPIRE Registry [[INSPIRE-LPA]].
+
+ A geographic region that is covered by the Dataset.
+
+
+ This property refers to a geographic region that is covered by the Dataset. When multiple values are used for spatial coverage, this may be interpreted as a spatial union, or as alternative representations of spatial coverage that might fit, with no explicit spatial relation.
+
+ In GeoDCAT-AP, this property is used to specify "spatial resolution", as defined in [[INSPIRE-MD-REG]], [[ISO-19115]], and [[ISO-19115-1]]. Describes the spatial resolution of the original data in the dataset, i.e. regardless of how it is distributed using distributions.
+
+ Spatial resolution as free-text, when it cannot be specified via dqv:hasQualityMeasurement and dcat:spatialResolutionInMeters. Describes the spatial resolution of the original data in the dataset, i.e. regardless of how it is distributed using distributions.
+
+ In GeoDCAT-AP, this property MAY be used to specify a testing Activity over a Dataset, against a given Standard, producing as output a conformance degree.
+
+ It is recommended to avoid Dataset Series without a dataset in the collection. Therefore at least one Dataset should refer to a Dataset Series using the property in series (dcat:inSeries).
+
+ Information that indicates whether the Dataset Series is publicly accessible, has access restrictions or is not public.
+
+
+ For INSPIRE metadata, this property SHOULD be used with the URIs of the "Limitations on public access" code list operated by the INSPIRE Registry [[INSPIRE-LPA]].
+
+ This property can be repeated for parallel language versions.
+
+It is recommended to provide an indication about the dimensions the Dataset Series evolves.
+
+ A geographic region that is covered by the Dataset Series.
+
+
+ When spatial coverage is a dimension in the dataset series then the spatial coverage of each dataset in the collection should be part of the spatial coverage. In that case, an open ended value is recommended, e.g. EU or a broad bounding box covering the expected values.
+
+ An entity (organisation) responsible for ensuring the coherency of the Dataset Series
+
+
+ The publisher of the dataset series may not be the publisher of all datasets.
+E.g. a digital archive could take over the publishing of older datasets in the series.
+
+ The reference system used in accordance with OGC EPSG Coordinate Reference Systems Register [[OGC-EPSG]].
+
+
+ Spatial reference systems SHOULD be specified by using the corresponding URIs from the "EPSG coordinate reference systems" register operated by OGC [[OGC-EPSG]].
+
+ The date of formal issuance (e.g., publication) of the Dataset Series.
+
+
+ The moment when the dataset series was established as a managed resource.
+
+This is not equal to the release date of the oldest dataset in the collection of the dataset series.
+
+ A temporal period that the Dataset Series covers.
+
+
+ When temporal coverage is a dimension in the dataset series then the temporal coverage of each dataset in the collection should be part of the temporal coverage. In that case, an open ended value is recommended, e.g. after 2012.
+
+ In GeoDCAT-AP, this property MAY be used to specify a testing Activity over a Dataset Series, against a given Standard, producing as output a conformance degree.
+
+ Information regarding access or restrictions based on privacy, security, or other policies.
+
+
+ For INSPIRE metadata, this property SHOULD be used with the URIs of the "Limitations on public access" code list operated by the INSPIRE Registry [[INSPIRE-LPA]].
+
+ Information about the format in which an Distribution is released. This is different from the file format as, for example, a ZIP file (file format) could contain an XML schema (representation technique).
+
+
+ In GeoDCAT-AP, this property SHOULD be used to express the spatial representation type (grid, vector, tin), by using the URIs of the corresponding code list operated by the INSPIRE Registry [[INSPIRE-SRT]].
+
+ It can be represented using a controlled vocabulary or with geographic coordinates. In the latter case, the use of the Core Location Vocabulary is recommended, following the approach described in the GeoDCAT-AP specification.
+
+The supportive entities are supporting the main entities in the Application Profile.
+They are included in the Application Profile because they form the range of properties.
+
+
+
+
+
+
+
+ An activity is something that occurs over a period of time and acts upon or with entities; it may include consuming, processing, transforming, modifying, relocating, using, or generating entities.
+
+
+
+In GeoDCAT-AP, this class SHOULD be used to specify a testing activity over a resource, against a given Standard, producing as output a conformance
+
+ The entity (e.g., a Catalogue, a Dataset, a Data Service) which was the subject of the Activity.
+
+
+ This property MAY be omitted in case its inverse property prov:wasUsedBy is specified.
+
+
+
+
+
+
+ P
+
+
+
+
+
+
+
+
+
+
+ shows the use of class prov:Activity to specify the results of a testing activity assessing the conformance of a given resource against a given specification - as illustrated in .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ An activity association is an assignment of responsibility to an agent for an activity, indicating that the agent had a role in the activity. It further allows for a plan to be specified, which is the plan intended by the agent to achieve some goals in the context of this activity.
+
+ Attribution is the ascribing of an entity to an agent. When an entity e is attributed to agent ag, entity e was generated by some unspecified activity that in turn was associated to agent ag. Thus, this relation is useful when the activity is not known, or irrelevant.
+
+ A function of an entity or agent with respect to another entity or resource.
+
+
+ In GeoDCAT-AP, this property SHOULD take as value one of the URIs of the "Responsible party roles" code list operated by the INSPIRE Registry [[INSPIRE-RPR]].
+
+ A SKOS concept can be viewed as an idea or notion; a unit of thought. However, what constitutes a unit of thought is subjective, and this definition is meant to be suggestive, rather than restrictive.
+
+ A SKOS concept scheme can be viewed as an aggregation of one or more SKOS concepts. Semantic relationships (links) between those concepts may also be viewed as part of a concept scheme.
+
+ The locn:Geometry class provides the means to identify a location as a point, line, polygon, etc. expressed using coordinates in some coordinate reference system.
+
+ The definition and properties of the Legal Resource class are aligned with the ontology included in "Council conclusions inviting the introduction of the European Legislation Identifier (ELI)". For describing the attributes of a Legal Resource (labels, preferred labels, alternative labels, definition, etc.) we refer to the (ELI) ontology.
+
+In this data specification the use is restricted to instances of this class that follow the (ELI) URI guidelines.
+
+
+
+
+ Properties
+
+
+
+ This specification does not impose any additional requirements to properties for this entity.
+
+ A literal value such as a string or integer; Literals may be typed, e.g. as a date according to xsd:date. Literals that contain human-readable text have an optional language tag as defined by BCP 47 [[RFC5646]].
+
+ Represents a standard to measure a quality dimension. An observation (instance of dqv:QualityMeasurement) assigns a value in a given unit to a Metric.
+
+
+
+
+ Usage Note
+
+
+ In GeoDCAT-AP, this class is used to define individuals corresponding to the different types of spatial resolution. See Metric in Data on the Web Best Practices: Data Quality Vocabulary [[VOCAB-DQV]].
+
+ The dimensions a quality metric, certificate and annotation allow a measurement of.
+
+
+ In GeoDCAT-AP, this property is used in the definition of the instances of dqv:Metric corresponding to the different types of spatial resolution (see Instances of Metric). When used for this purpose, it MUST always take as value dqv:precision.
+
+ Represents a collection of people organized together into a community or other social, commercial or political structure. The group has some common purpose or reason for existence which goes beyond the set of people belonging to it and can act as an Agent. Organizations are often decomposable into hierarchical structures.
+
+
+
+
+ Usage Note
+
+
+ See Organization in The Organization Ontology [[ORG]].
+
+
+
+
+ Properties
+
+
+
+ This specification does not impose any additional requirements to properties for this entity.
+
+ A statement of any changes in ownership and custody of a resource since its creation that are significant for its authenticity, integrity, and interpretation.
+
+ In GeoDCAT-AP, this property is used to specify the type of spatial resolution being described, by taking as object one of the instances of dqv:Metric documented in Instances of Metric.
+
+ The unit in which the data values are measured.
+
+
+ In GeoDCAT-AP, this property is used to specify, when relevant, the unit of measure of the spatial resolution being described, by taking as object the relevant term from the QUDT Units Vocabulary [[QUDT-UNITS]].
+
+ In GeoDCAT-AP, this property is used to specify the value of the spatial resolution being described via a typed literal. The datatype MUST correspond to the one specified via property dqv:expectedDataType in the definition of the corresponding instance of dqv:Metric.
+
+ A statement about the intellectual property rights (IPR) held in or over a resource, a legal document giving official permission to do something with a resource, or a statement about access rights.
+
+ The main identifier for the Standard, e.g. the URI or other unique identifier in the context of the Catalogue, or of a reference register (e.g., the ISO, OGC, W3C catalogues of their standards, the OGC "EPSG coordinate reference systems" register [[OGC-EPSG]]).
+
+ In GeoDCAT-AP, when the Standard is a spatial or temporal reference system, the relevant URIs from the INSPIRE glossary SHOULD be used [[INSPIRE-GLOSSARY]].
+
+ rdfs:Literal encoded using the relevant [[ISO8601]] Date and Time compliant string and typed using the appropriate XML Schema datatype (xsd:gYear, xsd:gYearMonth, xsd:date, or xsd:dateTime).
+
+ Decimal represents a subset of the real numbers, which can be represented by decimal numerals. The ·value space· of decimal is the set of numbers that can be obtained by multiplying an integer by a non-positive power of ten, i.e., expressible as i × 10^-n where i and n are integers and n >= 0.
+
+ Duration represents a duration of time. The ·value space· of duration is a six-dimensional space where the coordinates designate the Gregorian year, month, day, hour, minute, and second components defined in § 5.5.3.2 of [[ISO8601]], respectively.
+
+ Number derived from integer by setting the value of minInclusive to be 0.
+
+
+
+
+
+
+
+
+
+
+
+
Controlled Vocabularies
+
+
Requirements for controlled vocabularies
+
+
The following is a list of requirements that were identified for the controlled vocabularies to be recommended in this Application Profile.
+
+
Controlled vocabularies SHOULD:
+
+
+
Be published under an open licence.
+
Be operated and/or maintained by an institution of the European Union, by a recognised standards organisation or another trusted organisation.
+
Be properly documented.
+
Have labels in multiple languages, ideally in all official languages of the European Union.
+
Contain a relatively small number of terms (e.g. 10-25) that are general enough to enable a wide range of resources to be classified.
+
Have terms that are identified by URIs with each URI resolving to documentation about the term.
+
Have associated persistence and versioning policies.
+
+
+
These criteria do not intend to define a set of requirements for controlled vocabularies in general; they are only intended to be used for the selection of the controlled vocabularies that are proposed for this Application Profile.
+
+
+
+
+
+
Expected usage of controlled vocabularies
+
+To increase the interoperability, the value spaces of properties can be further harmonised using shared controlled vocabularies.
+This kind of restriction may be subject to a varying interpretation on what the expected usage of a controlled vocabulary is.
+To ensure a common interpretation the following expectations are defined:
+
+
+
The property MUST use as range values codes from {codelist}
+This expectation results in that the value space is closed under the codelist.
+Validation systems SHOULD produce errors.
+All profiles in the ecosystem MUST avoid conflicts by creating subproperties.
+
+
+
The property MUST have at least one value from {codelist}
+This expectation makes the value space minimally constrained.
+Validation systems SHOULD produce warnings.
+All profiles in the ecosystem MUST adopt this interpretation in case they want to restrict the value space.
+Adopting the former expectation will lead to cross-profile interpretations challenges.
+
+
+
The property IS RECOMMENDED to use as range values codes from {codelist}
+The value space is closed under the codelist, but other values are tolerated.
+Recommending means expressing a strong preference.
+To make this stronger direction towards harmonisation visible in the data exchanges, validation systems SHOULD produce warnings.
+
+
+
The property MAY use as range values codes from {codelist}
+The value space is closed under the codelist, but other values are accepted.
+This expectation is more a hint to be used.
+As there is no obligation nor strongly suggestion expressed here, the use of other codelists is valid is all cases.
+Therefore validation systems MAY produce warnings but users are free to ignore them.
+No validation in this case is also acceptable.
+
+
+
+
+The first two (and preferably also the others) SHOULD only be used for requirements that can be verified by a machine.
+If the validation can only be realised with the involvement of humans, then a less strong requirement (RECOMMMENDED or MAY) is used,
+even if the intention is to be very strict.
+This is to ensure that the provided SHACL representations correspond closely to all use cases possible.
+Stronger enforcements are left for implementations as they have control on actual data exchange.
+
+
+
+
+
+
+
+
+
Controlled vocabularies to be used
+
+
+The table is organised per property and then per class.
+This is because mostly the used controlled vocabulary is connected with the property and not with the usage context in a class.
+However this is not mandatory, and it may happen (as it is the case for dct:type) that the same property uses a different controlled vocabulary per class.
+To disambiguate the usage multiple rows are created.
+In some cases controlled vocabulary usage is more complicated.
+For instance in the case of dct:spatial and dct:publisher the usage of the controlled vocabulary is dependent on the actual value used.
+The value space these properties encompass is very large and there is no universal EU controlled vocabulary at hand that covers the whole value space.
+
+
+
+The last column is a first assessment of the usage of the controlled vocabularies and is open for discussion.
+
+
MUST is applied to those cases where the binding between the property and the controlled vocabulary is strong.
+
+
MUST is applied where DCAT-AP also expects the controlled vocabulary and it was adopted by GeoDCAT-AP.
+
+
AT-LEAST is applied on cases where instances of supporting classes are created and it is possible that other profiles would apply a different choice for this supporting class.
+
+
MAY is applied to dct:publisher and dct:spatial as the controlled vocabularies do not cover the whole value space and a correct application cannot be verified by a machine.
+
+
dcat:theme, dct:accrualPeriodicity and dct:accessRights are to addressed in collaboration with DCAT-AP. There are specific INSPIRE codelists which are mappable to the DCAT-AP codelists. Therefore the suggestion is to keep a MUST for the DCAT-AP requirements and provide a mapping table for the INSPIRE codelists.
+
+
+
+
+
Compared with DCAT-AP, GeoDCAT-AP makes use of additional controlled vocabularies mandated by [[INSPIRE-MD-REG]], and operated by the INSPIRE Registry - with the only exceptions of the coordinate reference systems register maintained by OGC [[OGC-EPSG]].
+
+
For two of these controlled vocabularies, namely the INSPIRE spatial data themes [[INSPIRE-THEMES]] and the ISO topic categories [[INSPIRE-TC]], the GeoDCAT-AP Working Group has defined a set of harmonised mappings to the EU Vocabularies Data Themes [[EUV-THEMES]], in order to facilitate the identification of the relevant theme in [[EUV-THEMES]] for geospatial metadata. The status of this work, along with links to a machine readable representation of the mappings, is documented on a dedicated page in Joinup [[?GeoDCAT-ACV]].
The Corporate bodies NAL MUST be used for European institutions and a small set of international organisations. In case of other types of organisations, national, regional or local vocabularies should be used.
The EU Vocabularies Name Authority Lists must be used for continents, countries and places that are in those lists; if a particular location is not in one of the mentioned Named Authority Lists, [[GEONAMES]] URIs must be used.
In addition to the proposed common vocabularies in , which are mandatory to ensure minimal interoperability, implementers are encouraged to publish and to use further region or domain-specific vocabularies that are available online. While those may not be recognised by general implementations of the Application Profile, they may serve to increase interoperability across applications in the same region or domain. Examples are the full set of concepts in EuroVoc [[?EUV-EUROVOC]], the CERIF standard vocabularies [[?CERIF-VOCS]], the Dewey Decimal Classification [[?DDC]] and numerous other schemes.
+
+
For geospatial metadata, the working group has identified the following additional vocabularies:
GeoDCAT-AP supports the 11 agent roles defined in [[INSPIRE-MD-REG]] and [[ISO-19115]] by using two different but not mutually exclusive approaches.
+
+
In the first approach, roles are mapped to specific properties. In particular, GeoDCAT-AP makes use of the relevant properties from [[DCAT-AP-3]] and [[DCTERMS]], which overall cover 4 of the relevant roles - namely, dcat:contactPoint, dct:creator, dct:publisher, and dct:rightsHolder (not supported in [[DCAT-AP-3]]). The remaining 7 are covered by the corresponding properties defined in the GeoDCAT-AP namespace - namely, geodcatap:custodian, geodcatap:distributor, geodcatap:originator, geodcatap:principalInvestigator, geodcatap:processor, geodcatap:resourceProvider, and geodcatap:user.
+
+
It is important to note that, following [[INSPIRE-MD-REG]] and [[ISO-19115]], in GeoDCAT-AP all these agent roles can be specified on Catalogues, Catalogue Records, Datasets, and Data Services.
+
+
The second and more general approach is based on [[PROV-O]], where agent roles are specified via a “qualified attribution” (prov:qualifiedAttribution). More precisely, the relevant Agent is specified via property prov:agent, whereas the role is specified with property dcat:hadRole, which takes as value a skos:Concept describing that role - as those included in the relevant code list operated by the INSPIRE Registry [[INSPIRE-RPR]]. .
+
+
The [[PROV-O]]-based approach is meant to give data providers an extension mechanism to specify, in a harmonised way, any kind of role, and, possibly, to attach additional information to the role and the associated Agent. As such, it MAY be used in combination with or to complement the property-based approach, but it MUST NOT replace it. For instance, it can be used to specify roles not covered by the agent role properties used in GeoDCAT-AP, and/or to specify additional information that cannot be expressed via a property (as the period during which an Agent covered a given role).
+
+
More details on these solutions are available in .
+
+
+
Accessibility and Multilingual Aspects
+
+Accessibility in the context of this Application Profile is limited to information about the technical format of distributions of datasets. The properties dcat:mediaType and dct:format provide information that can be used to determine what software can be deployed to process the data. The accessibility of the data within the datasets needs to be taken care of by the software that processes the data and is outside of the scope of this Application Profile.
+
+
+Multilingual aspects related to this Application Profile concern all properties whose contents are expressed as strings (i.e. rdfs:Literal) with human-readable text. Wherever such properties are used, the string values are of one of two types:
+
+
+
The string is free text. Examples are descriptions and labels. Such text may be translated into several languages.
+
The string is an appellation of a ‘named entity’. Examples are names of organisations or persons. These names may have parallel versions in other languages but those versions don’t need to be literal translations.
+
+
+
+Wherever values of properties are expressed with either type of string, the property can be repeated with translations in the case of free text and with parallel versions in case of named entities. For free text, e.g. in the cases of titles, descriptions and keywords, the language tag is mandatory.
+
+
+Language tags to be used with rdfs:Literal are defined by [[BCP47]], which allows the use of the "t" extension for text transformations defined in [[RFC6497]] with the field "t0" [[CLDR]] indicating a machine translation.
+
+
+A language tag will look like: "en-t-es-t0-abcd", which conveys the information that the string is in English, translated from Spanish by machine translation using a tool named "abcd".
+
+
+For named entities, the language tag is optional and should only be provided if the parallel version of the name is strictly associated with a particular language. For example, the name ‘European Union’ has parallel versions in all official languages of the union, while a name like ‘W3C’ is not associated with a particular language and has no parallel versions.
+
+
+For linking to different language versions of associated web pages (e.g. landing pages) or documentation, a content negotiation [[CONNEG]] mechanism may be used whereby different content is served based on the Accept-Languages indicated by the browser. Using such a mechanism, the link to the page or document can resolve to different language versions of the page or document.
+
+
+All the occurrences of the property dct:language, which can be repeated if the metadata is provided in multiple languages, must have a URI as their object, not a literal string from the [[ISO-639]] code list.
+
+
+How multilingual information is handled in systems, for example in indexing and user interfaces, is outside of the scope of this Application Profile.
+
+
+
+
+
+
+
High Value Datasets
+
+
+In light of the growing importance of data, the European Commission has adopted an implementing regulation focused on high-value datasets on 21 December 2022 [[HVD]].
+The ambition of the High-Value Datasets implementing regulation (HVD IR) is to improve the quality, the accessibility and use of a selective number of core datasets within the public sector.
+To achieve this the HVD IR sets, among others, requirements on the metadata associated with the disclosed datasets.
+
+
+To foster a common approach on using DCAT-AP metadata to describe Datasets that are in scope of the HVD IR a dedicated DCAT-AP annex DCAT-AP HVD [[DCAT-AP-HVD]] is provided.
+The requirements expressed in DCAT-AP HVD are additional constraints and usages notes which can be directly applied to GeoDCAT-AP 3.0.0.
+
+
+Because GeoDCAT-AP is also applicable for datasets that are not within the scope of the HVD IR, the constraints of DCAT-AP HVD are not included in this specification.
+Implementers of the HVD IR should consult DCAT-AP HVD for the specific requirements of the HVD IR.
+However, since GeoDCAT-AP is mainly used as the DCAT view derived from the INSPIRE ISO metadata [[[#inspire-and-iso-19115-mappings]]],
+the implementation of the DCAT-AP HVD in the context of a GeoDCAT-AP mapping requires to implement additional mapping rules.
+Currently the metadata guidelines for HVD in INSPIRE are under design by the INSPIRE Action 2.5 subgroup.
+When the guidelines become available a reference implementation will be shared here.
+
+
+
+
+
+
+
Legal information
+
+
+The considerations for expressing legal information follow the guidelines and approach of DCAT-AP.
+Readers should consult the DCAT-AP section on legal information.
+
+The HVD IR [[HVD]] imposes additional quality requirements on legal information.
+An elaboration of these is found in the section legal information in DCAT-AP HVD.
+
+Implementers of mappings from INSPIRE ISO metadata should take these considerations into account to ensure that the legal information is shared correctly.
+
+
+
+
Privacy and security considerations
+
+
GeoDCAT-AP supports the attribution of data and metadata to various participants such as resource creators, publishers and other parties or agents, and as such defines terms that may be related to personal information. In addition, it also supports the association of rights and licenses with catalogued Resources and Distributions. These rights and licenses could potentially include or reference sensitive information such as user and asset identifiers as described in [[VOCAB-ODRL]].
+
+
Implementations that produce, maintain, publish or consume such vocabulary terms must take steps to ensure security and privacy considerations are addressed at the application level.
+
+
+
+
+
+
+
+
Conformance Test Results
+
+
Following [[INSPIRE-MD-REG]] and [[ISO-19115]], GeoDCAT-AP supports the specification of test results to assess the degree of conformity of a resource (i.e., a Catalogue, a Dataset, a Data Service) with a given specification (e.g., a standard, a set of implementing rules, a set of data quality or interoperability criteria).
+
+
For this purpose, GeoDCAT-AP makes use of two different but not mutually exclusive approaches. More precisely, property dct:conformsTo is used when the test result states that a resource is conformant with a given specification. The more general approach is based on [[PROV-O]], and it specifies conformance test results as a testing activity (prov:Activity) that generates a result (specified with property prov:generated), corresponding to one of the degrees of conformity defined in [[INSPIRE-MD-REG]], and available from the INSPIRE Registry [[INSPIRE-DoC]]. The specification against which the testing activity is carried out is specified via a “qualified association” (prov:qualifiedAssociation), linked to a “plan” (prov:hadPlan) derived from (prov:wasDerivedFrom) the specification itself.
+
+
+
+
More details on these solutions are available in .
+
+
+
+
+
+
+
Validation of GeoDCAT-AP
+
+
Validation of a catalogue according to GeoDCAT-AP can be approached from different perspectives.
+One perspective is to consider GeoDCAT-AP as an extension to DCAT-AP and thus implement a two staged process:
+first validation against DCAT-AP and then additionally validate the GeoDCAT-AP specific constraints.
+Another perspective is to consider this specification as a standalone specification and validate all constraints at once.
+Besides these there are many other validation perspectives possible.
+For additional considirations on validation consult the section Validation in DCAT-AP.
+
+As there is yet not preferred perspective decided nor requested by the community, a similar to DCAT-AP SHACL artefact with all the constraints is provided.
+The shape is downloadable here.
+
+
+
+
+
+
+
+
+
INSPIRE and ISO 19115 Mappings
+
+
+
+
Objectives
+
+
The objective of this work is to define an RDF syntax that can be used for the exchange of descriptions of spatial datasets, dataset series, and services among data portals. The RDF syntax should extend the DCAT Application Profile for data portals in Europe [[DCAT-AP-3]].
+
+
+
To provide an RDF syntax binding for the union of the elements in the INSPIRE metadata schema [[INSPIRE-MD-REG]], [[INSPIRE-MD]] and the core profile of ISO 19115:2003 [[ISO-19115]]. The guiding design principle is to make the resulting RDF syntax as simple as possible; thereby maximally using existing RDF vocabularies – such as the Dublin Core [[DCTERMS]] and [[DCAT-AP-3]] –, and as much as possible avoiding minting new terms. The defined syntax binding must enable the conversion of metadata records from ISO 19115 / INSPIRE to a harmonised RDF representation. The ability to convert metadata records from RDF to ISO 19115 / INSPIRE is not a requirement.
+
+
To update the reference XSLT implementation [[GeoDCAT-XSLT]] of the mappings defined in the GeoDCAT-AP specification.
+
To take into account and refer to alignment of relevant controlled vocabularies (e.g., the alignments between GEMET, INSPIRE themes, EuroVoc carried out by the Publications Office of the EU [[EUV-EUROVOC]]).
+
+
Additionally, the following outcomes may be achieved, outside the context of this specification:
+
+
To define new controlled vocabularies or define mappings between controlled vocabularies.
+
+
To define an RDF syntax binding for the elements in ISO 19115-1:2014 [[?ISO-19115-1]].
+
+
+
+
+
+
+
Motivation and use cases
+
+
+
The basic use case that GeoDCAT-AP intends to enable is a cross-domain data portal search for datasets, as documented in the DCAT-AP specification [[DCAT-AP-3]]. GeoDCAT-AP will make it easier to share descriptions of spatial datasets between spatial data portals and general data portals, and thus help increase public and cross-sector access to such high value datasets. The datasets could include:
+
+
+
Datasets on the INSPIRE Geoportal
+
+
The INSPIRE Geoportal aggregates metadata for over 100k datasets across Europe. It provides the means to search for spatial data sets and spatial data services, and subject to access restrictions, to view spatial data sets from the EU Member States within the framework of the INSPIRE Directive. The metadata stored on this portal is structured according to the INSPIRE Metadata Technical Guidelines [[INSPIRE-MD]]. In order to maximise visibility and re-use, spatial datasets could also be listed on general-purpose Open Data Portals, such as the European Union Open Data Portal (EU ODP) and the European Data Portal (EDP).
+
Datasets on national SDIs
+
GeoDCAT-AP would facilitate the integration of SDIs operated by EU Member States with any data catalogue able to consume [[DCAT-AP-3]]-compliant metadata.
+
General geospatial datasets
+
The geospatial community shares a common background and makes consistent use of consolidated standards and technologies. In particular, as far as metadata are concerned, it is widespread to use standards like [[ISO-19115]] / [[ISO-19139]], for the representation and encoding of metadata, and OGC’s [[?CSW]] (Catalog Service for the Web) for accessing and querying metadata records. These standards are also those currently recommended in INSPIRE.
+
+
+
An additional RDF syntax for INSPIRE and ISO 19115 metadata elements is beneficial, especially when other data portals support the [[DCAT-AP-3]] metadata elements only.
+
Conversion rules to RDF syntax would allow Member States to maintain their collections of INSPIRE-relevant datasets following the INSPIRE Metadata Technical Guidelines [[INSPIRE-MD]], while at the same time publishing these collections on [[DCAT-AP-3]]-conformant data portals. A conversion to RDF syntax – using for example the GeoDCAT-AP XSLT script [[GeoDCAT-XSLT]] - allows additional metadata elements to be displayed on general-purposed data portals, provided that such data portals are capable of displaying additional metadata elements. Furthermore, data portals are frequently complemented by a triple store, making the full set of GeoDCAT-AP metadata queryable through a SPARQL endpoint [[SPARQL11-QUERY]].
+
+
+
+
+
+
Supported tooling
+
+
To support the transformation from INSPIRE metadata to GeoDCAT-AP compliant metadata an XSLT tool was developed. This tool has been updated to transform data to be compliant with GeoDCAT-AP 3.0.0. The GeoDCAT-AP XSLT can be found on the dev branch of the GitHub repository. The XSLT can be run directly on the output of a CSW or on single metadata records, by using any of the programming languages supporting XSLT conversion. Additionally, a proof-of-concept API has been developed to facilitate the testing of the XSLT on single metadata records or on top of a CSW endpoint.
+
+
+
+
+
+
Methodology and summary of results
+
+
Methodologically, the development of GeoDCAT-AP implies three main interrelated tasks:
+
+
Definition of alignment criteria and requirements.
+
Identification of the metadata elements to be covered by GeoDCAT-AP.
+
Definition of alignments for the metadata elements to be covered by GeoDCAT-AP.
+
+
These tasks and their results are described in the following sections.
+
+
+
+
Alignment criteria and requirements
+
+
The overall objective of GeoDCAT-AP is twofold:
+
+
+
Provide a [[DCAT-AP-3]]-conformant representation of geospatial metadata.
+
Provide an as much as possible comprehensive RDF-based representation of geospatial metadata, based on widely used vocabularies, trying, at the same time, to avoid semantic loss and to promote cross-domain re-use.
+
Ensure backward compatibiliy with previous versions of GeoDCAT-AP.
+
+
+
The first two goals, having a different scope and applying to different use cases (see ), are reflected in the two mapping profiles of GeoDCAT-AP, core and extended, described in .
+
+
Note that point (1) implies that:
+
+
+
GeoDCAT-AP must include, at least, all the mandatory [[DCAT-AP-3]] elements.
+
Vocabularies different from [[DCAT-AP-3]] can be used only for those geospatial metadata elements not supported in [[DCAT-AP-3]].
+
+
+
Another key criterion was to base as much as possible the defined alignments on existing practices, in particular those contributed by the GeoDCAT-AP WG. The objective was to build upon experiences having already addressed issues in scope of GeoDCAT-AP, and to avoid a negative impact on existing implementations.
+
+
Finally, as already mentioned in , whenever no suitable candidates were available in existing vocabularies to represent geospatial metadata elements, the possibility of defining new terms was not excluded. However, this option needed to be carefully assessed, and discarded whenever it might have led to a specification that was conflicting with standards under preparation.
+
+
As it will be explained in , no new terms have been defined in the current version of GeoDCAT-AP.
+
+
+
+
+
+
Metadata elements to be covered by GeoDCAT-AP
+
+
The general criterion used for this task was that GeoDCAT-AP would ideally cover all the metadata elements of the core profile of [[ISO-19115]] and those defined in INSPIRE, with the requirement that only optional elements MAY be excluded.
+
Based on this, the current version of GeoDCAT-AP covers the following set of metadata elements:
+
+
+
All the metadata elements in the core profile of [[ISO-19115]].
+
All the metadata elements defined in INSPIRE, with the exclusion of those not common to all the INSPIRE spatial data themes.
+
+
More precisely, the supported INSPIRE metadata elements include:
+
+
The set of metadata elements defined in the INSPIRE Metadata Regulation [[?INSPIRE-MD-REG]].
+
The set of metadata elements defined in the INSPIRE Data and Services Regulation (Article 13: “Metadata required for Interoperability”) [[INSPIRE-SDSS-REG]]. These elements are also listed in Appendix C.3 to the INSPIRE Metadata Technical Guidelines (version 2.1.3) [[INSPIRE-MD-20230731]].
+
The set of metadata elements recommended as common to most of the INSPIRE spatial data themes in the INSPIRE Data Specifications Technical Guidelines, and listed in the first table included in Appendix C.7 to the INSPIRE Metadata Technical Guidelines (version 2.0.1) [[INSPIRE-MD-20170302]]. These elements are the following ones:
+
+
Maintenance information.
+
Conceptual and domain consistency (Data quality – Logical consistency).
+
+
+
+
The full list of metadata elements covered by the current version of GeoDCAT-AP is available in to this document.
+
+
The metadata elements not supported in the current version of GeoDCAT-AP are those recommended only for specific INSPIRE spatial data themes in the INSPIRE Data Specifications Technical Guidelines, and listed in Appendix C.7 to the INSPIRE Metadata Technical Guidelines (version 2.1.3) [[INSPIRE-MD-20230731]].
+
+
These elements have been excluded in the current version of GeoDCAT-AP for the following reasons:
+
+
+
The priority was to support all those elements relevant to any dataset.
+
These elements are all optional.
+
+
Support to these metadata elements might be provided in future versions of GeoDCAT-AP.
+
+
+
+
+
+
Alignments defined in GeoDCAT-AP
+
+
The alignments defined in the current version of GeoDCAT-AP are the result of an iterative revision process of [[GeoDCAT-AP-20201223]], following the criteria illustrated in the previous sections and the review of the GeoDCAT-AP WG. Alignments for [[ISO-19115-1]] have not been defined. contains an overview of the most important changes with respect to [[ISO-19115]].
+
+
The work started with the review of [[DCAT-AP-3]], [[VOCAB-DCAT-3]], and [[INSPIRE-MD-20230731]], with the purpose of identifying possible disalignments of the mappings defined in [[GeoDCAT-AP]], as well as possible gaps in [[DCAT-AP-3]] and [[VOCAB-DCAT-3]], which may require the use of different vocabularies or the definition of new classes and/or properties in the GeoDCAT-AP namespace. In all these cases, backward compatibility with [[GeoDCAT-AP-20201223]] has been taken into account when implementing revisions.
+
Finally, the GeoDCAT-AP WG has worked in close coordination with the DCAT-AP WG, in order to ensure mutual compliance of the proposed solutions.
+
+
+
+
The results of this work, reflected in the current version of GeoDCAT-AP, can be summarised as follows:
+
+
+
Backward compatibility with [[GeoDCAT-AP-20201223]] is ensured: The revised mappings have been deprecated, but maintained in the mapping rules implemented in [[GeoDCAT-XSLT]] along with the new one, in the extended mapping profile of GeoDCAT-AP, and their support has been included in .
+
Compliance with [[DCAT-AP-3]] is ensured: The geospatial metadata elements covered by the defined mappings include all those that in [[DCAT-AP-3]] are mandatory, plus a subset of those that are recommended and optional.
+
GeoDCAT-AP offers alignments for all the metadata elements illustrated in , by using existing vocabularies, and without defining new terms.
+
+
+
The majority of the alignments defined in GeoDCAT-AP provide a complete representation of the corresponding geospatial metadata elements, but some metadata elements have open issues:
+
+
+
Partial mappings: For some metadata elements, only a partial mapping is available. This concerns data quality and maintenance information, for which only the mandatory components have been mapped (for more details, see and , respectively). This decision was taken because existing vocabularies did not offer the ability to represent all the components of these metadata elements.
+
+
+
The details of the alignments defined in GeoDCAT-AP are illustrated in the following section.
+
+
+
+
+
+
+
+
RDF syntax bindings for INSPIRE and ISO 19115 metadata elements
+
+
The following sections provide the list of the bindings defined in GeoDCAT-AP for the RDF representation of INSPIRE metadata and the core profile of [[ISO-19115]].
+
+
For detailed usage notes and examples of each of the metadata elements covered by GeoDCAT-AP, we refer the reader to (the relevant section is specified in the “comments” column of the mapping table).
+
+
+
+
Overview of bindings for GeoDCAT-AP Core
+
+
This section provides an overview of GeoDCAT-AP Core. This includes bindings for metadata elements of the INSPIRE metadata and metadata elements in the core profile of [[ISO-19115]] core for which DCAT-AP provides an RDF syntax binding. Those metadata elements for which [[DCAT-AP-3]] does not provide a binding are part of the GeoDCAT-AP Extended mapping profile described in .
+
+
GeoDCAT-AP Core is meant to enable the harvesting and re-use of spatial metadata records through [[DCAT-AP-3]]-conformant applications and services, including data portals and APIs. The alignments for INSPIRE and [[ISO-19115]] metadata elements that are not included in GeoDCAT-AP Core are defined in GeoDCAT-AP Extended, see .
+
+
In the following table, the starred elements (*) are used to indicate the corresponding metadata element in the core profile of [[ISO-19115]]. For each element, it is indicated whether the element is mandatory (M), optional (O), conditional (C), or recommended (R) in either specification.
See . dcat:Catalog can be used for catalogue / discovery services, in addition to dcat:DataService.
+
+
+
+
+
Resource locator (C)
+
*On-line resource (O)
+
+
+
+
+
See . The defined encoding depends whether the resource is a service or a dataset or data series. Also, the value of the function code (CI_OnlineFunctionCode) is to be taken into account.
+
+
+
+
+
+
For services
+
+
+
+
foaf:homepage
+
dcat:endpointURL
+
dcat:endpointDescription
+
+
+
+
dcat:Catalog
+
dcat:DataService
+
+
+foaf:Document
+rdfs:Resource
+foaf:Document
+
+
See . Properties dcat:endpointURL and dcat:endpointDescription are used when the resource locator points to a service endpoint.
+
+
+
+
+
+
For dataset and data series (function code not provided)
+
+
+
dcat:landingPage (O)
+
+
dcat:Dataset
+
dcat:DatasetSeries
+
+
foaf:Document
+
See .
+
+
+
+
+
+
For dataset and data series (‘download’ function code)
+
+
+
dcat:accessURL (M)
+
dcat:Distribution
+
rdfs:Resource
+
See . Property dcat:accessURL is also used whenever the resource locator points to a service endpoint.
+
+
+
+
+
+
For dataset and data series (‘information’ function code)
+
+
+
foaf:page
+
+
+
dcat:Dataset
+
dcat:DatasetSeries
+
+
foaf:Document
+
See .
+
+
+
+
+
+
For dataset and data series (‘offlineAccess’ function code)
+
+
+
dcat:accessURL (M)
+
dcat:Distribution
+
rdfs:Resource
+
See . Property dcat:accessURL is also used whenever the resource locator points to a service endpoint.
+
+
+
+
+
+
For dataset and data series (‘order’ function code)
+
+
+
dcat:accessURL (M)
+
dcat:Distribution
+
rdfs:Resource
+
See . Property dcat:accessURL is also used whenever the resource locator points to a service endpoint.
+
+
+
+
+
+
For dataset and data series (‘search’ function code)
+
+
+
foaf:page
+
+
dcat:Dataset
+
dcat:DatasetSeries
+
+
foaf:Document
+
See .
+
+
+
+
+
Unique resource identifier (M)
+
*not in ISO 19115 core
+
+
dct:identifier (O)
+
+
dcat:Dataset
+
dcat:DatasetSeries
+
+
rdfs:Literal
+
See . In RDF, this could also be represented as the URI of the dataseti or of the dataset series.
+
+
+
+
+
Resource language (C)
+
*Dataset language (M)
+
+
dct:language (O for dcat:Dataset and dcat:DatasetSeries, R for dcat:Catalog)
+
+
dcat:Dataset
+
dcat:DatasetSeries
+
dcat:Catalog
+
+
dct:LinguisticSystem
+
See .
+
+
+
+
+
+
+
Keyword value (M)
+
*not in ISO 19115 core
+
+
dcat:keyword (R)
+
dcat:theme (R)
+
(see also binding for GeoDCAT-AP Extended)
+
+
dcat:Dataset
+
+
rdfs:Literal
+
+
See . For datasets and data series, dcat:keyword is used for free keywords; dcat:theme for controlled vocabularies.
+
Keywords whose controlled vocabulary is the one of the INSPIRE spatial data themes are mapped to dcat:theme, and expressed by the corresponding URI in the INSPIRE Registry. See controlled vocabulary for theme in .
+
For services a syntax binding is provided in GeoDCAT-AP Extended only.
+
+
+
+
+
+
Geographic bounding box (M)
+
*Geographic location of the dataset (by four coordinates or by geographic identifier) (C)
+
+
dct:spatial (O)
+
+
dcat:Catalog
+
dcat:Dataset
+
dcat:DatasetSeries
+
+
dct:Location
+
See on the preferred format to be used in RDF for the representation of geometries.
+
+
+
+
+
Temporal extent (C)
+
*Additional extent information for the dataset (vertical and temporal) (O)
+
+
dct:temporal (O)
+
+
dcat:Dataset
+
dcat:DatasetSeries
+
+
dct:PeriodOfTime
+
See .
+
+
+
+
+
Date of publication (C)
+
*Dataset reference date (M) – publication
+
+
dct:issued (R for dcat:Catalog and O for dcat:Dataset and dcat:DatasetSeries)
dct:license (R for dcat:Catalog and dcat:Distribution, O for dcat:DataService), dct:rights (O)
+
+
dcat:Catalog
+
dcat:Distribution
+
dcat:DataService
+
+
+
dct:LicenseDocument
+
See .
+
+
+
+
+
Limitations on public access (C)
+
*not in ISO 19115 core
+
+
dct:accessRights (O)
+
+
dcat:DataService
+
+
dct:RightsStatement
+
See .
+
+
+
+
+
Responsible party (M)
+
*Dataset responsible party (O)
+
+
+
dct:publisher (M)
+
dct:creator (O)
+
+
+
dcat:Catalog
+
+
+
foaf:Agent
+
+
See . [[DCAT-AP-3]] supports only 3 of the 11 responsible party roles supported in INSPIRE. GeoDCAT-AP Extended makes use of [[PROV-O]] to specify information concerning provenance not covered in [[DCAT-AP-3]].
+
+
+
+
+
dct:publisher (R)
+
dcat:contactPoint (R)
+
dct:creator (O)
+
+
+
dcat:Dataset
+
dcat:DatasetSeries
+
+
+
foaf:Agent
+
vcard:Kind
+
foaf:Agent
+
+
+
+
+
+
Encoding (M)
+
*Distribution format (O)
+
+
dct:format (R), dcat:mediaType (O)
+
dcat:Distribution
+
dct:MediaTypeOrExtent
+
See . See controlled vocabularies for encoding in .
+
+
+
+
+
Maintenance information (R)
+
*not in ISO 19115 core
+
+
dct:accrualPeriodicity (O)
+
+
dcat:Dataset
+
dcat:DatasetSeries
+
+
dct:Frequency
+
See .
+
+
+
+
*Metadata standard
+
dct:conformsTo (R)
+
+
dcat:CatalogRecord
+
dct:Standard
+
See . This element, not existing in ISO 19115, is just meant to provide the context for the specification of the metadata standard name and version.
+
+
+
+
*Metadata standard name (O)
+
dct:title
+
+
dct:Standard
+
rdfs:Literal
+
See .
+
+
+
+
*Metadata standard version (O)
+
owl:versionInfo
+
+
dct:Standard
+
+
rdfs:Literal
+
See . This can be part of the information specified for metadata standard name.
This section provides an overview of the RDF syntax bindings in GeoDCAT-AP Extended. This GeoDCAT-AP mapping profile covers elements defined in INSPIRE and the core profile of [[ISO-19115]], for which [[DCAT-AP-3]] does not provide a syntax binding. GeoDCAT-AP Extended is a superset of GeoDCAT-AP Core.
+
+
The following table contains the defined RDF syntax binding for INSPIRE metadata. In the table below, the starred elements (*) are used to indicate the corresponding metadata element in the core profile of [[ISO-19115]]. For each metadata element, it is indicated whether the element is mandatory (M), optional (O), conditional (C), or recommended (R) in either specification.
+
+
Please note that some metadata elements have an RDF syntax binding in both the GeoDCAT-AP Core and Extended mapping profile. These elements fall in one of these categories:
+
+
+
Partial coverage by a [[DCAT-AP-3]] binding: This concerns conformity (only degree of conformity equal to “conformant” is supported) and responsible organisation (only responsible party roles creator, publisher, and point of contact are supported).
+
Subsumption by a GeoDCAT-AP RDF binding: ISO metadata elements available in GeoDCAT-AP Core, but for which only a many-to-one mapping is supported in [[DCAT-AP-3]].
+
+
+
In order to preserve the original semantics, the extended mapping profile of GeoDCAT-AP defines additional alignments to those included in GeoDCAT-AP Core. The two sets of alignments are not mutually exclusive, and can coexist without creating conflicts.
+
+
+
+
+
+
+
INSPIRE metadata
+
*ISO 19115:2003 Core Profile
+
+
Property
+
Domain
+
Range
+
Comments
+
+
+
+
+
+
+
Resource type (M)
+
*not in ISO 19115 core
+
+
geodcatap:resourceType
+
+
dcat:Catalog
+
dcat:Dataset
+
dcat:DatasetSeries
+
dcat:DataService
+
+
skos:Concept
+
See and the controlled vocabulary for resource type in . [[DCAT-AP-3]] supports the use of dct:type on dct:Dataset only.
+
+
+
+
+
Unique resource identifier (M)
+
*not in ISO 19115 core
+
+
dct:identifier
+
+
dcat:Catalog
+
dcat:DatasetSeries
+
dcat:DataService
+
+
rdfs:Literal
+
See . In RDF, this could also be represented as the URI of the resource.
+
+
+
+
+
Resource language (C)
+
*Dataset language (M)
+
+
dct:language
+
+
dcat:DatasetSeries
+
dcat:DataService
+
+
dct:LinguisticSystem
+
See .
+
+
+
+
+
Topic category (M)
+
*Dataset topic category (M)
+
+
geodcatap:topicCategory
+
+
dcat:Catalog
+
dcat:Dataset
+
dcat:DatasetSeries
+
dcat:DataService
+
+
+
skos:Concept
+
See and the controlled vocabulary for topic category in .
+
+
+
+
+
Spatial data service type (M)
+
*not in ISO 19115
+
+
geodcatap:serviceType
+
+
dcat:DataService
+
+
skos:Concept
+
See . See controlled vocabulary for spatial data service type in .
+
+
+
+
+
Keyword value (M)
+
*not in ISO 19115 core
+
+
+
dcat:keyword
+
dcat:theme
+
geodcatap:serviceCategory
+
+
+
dcat:Catalog
+
dcat:DatasetSeries
+
dcat:DataService
+
+
+
rdfs:Literal
+
skos:Concept
+
+
See .
+
+
+
+
+
Originating controlled vocabulary (C)
+
*not in ISO 19115 core
+
+
skos:inScheme
+
skos:Concept
+
skos:ConceptScheme
+
+
See .
+
+
+
+
+
Geographic bounding box (M)
+
*Geographic location of the dataset (by four coordinates or by geographic identifier) (C)
+
+
dct:spatial (O)
+
+
dcat:DataService
+
+
dct:Location
+
See on the preferred format to be used in RDF for the representation of geometries.
+
+
+
+
+
Temporal extent (C)
+
*Additional extent information for the dataset (vertical and temporal) (O)
See . Property dcat:spatialResolutionInMeters can only be used when spatial resolution is expressed as distance in metres. Property dqv:hasQualityMeasurement can be used to specify any type of spatial resolution. Property geodcatap:spatialResolutionAsText is used only in case spatial resolution is specified as free-text.
+
+
+
+
+
dqv:hasQualityMeasurement
+
+
+
dcat:Dataset
+
dcat:DatasetSeries
+
dcat:DataService
+
+
dqv:QualityMeasurement
+
+
+
+
+
geodcatap:spatialResolutionAsText
+
+
rdfs:Literal
+
+
+
+
+
Conformity (M)
+
*not in ISO 19115 core
+
+
prov:wasUsedBy
+
+
prov:Entity
+
dcat:Dataset
+
dcat:DatasetSeries
+
dcat:DataService
+
+
prov:Activity
+
See .
+
+
+
+
+
Conformity Specification (M)
+
*not in ISO 19115 core
+
+
prov:wasDerivedFrom
+
prov:Entity
+
prov:Entity
+
See .
+
+
+
+
+
Conformity degree (M)
+
*not in ISO 19115 core
+
+
prov:generated
+
prov:Activity
+
prov:Entity
+
See and the controlled vocabulary for conformity degree in .
+
+
+
+
+
Topological Consistency (C)
+
*not in ISO 19115 core
+
+
-
+
-
+
-
+
See . No syntax binding is provided for data quality, other than data conformity.
See . No syntax binding is provided for data quality, other than conformity.
+
+
+
+
+
Limitations on public access (C)
+
*not in ISO 19115 core
+
+
dct:accessRights (O), dct:rights (O)
+
+
dcat:Catalog
+
dcat:Distribution
+
dcat:DataService
+
+
dct:RightsStatement
+
See .
+
+
+
+
+
Responsible party (M)
+
*Dataset responsible party (O)
+
+
+
dct:publisher
+
dct:creator
+
+
+
dcat:CatalogRecord
+
dcat:DataService
+
+
foaf:Agent
+
See .
+
+
+
+
dcat:contactPoint
+
+
dcat:Catalog
+
dcat:CatalogRecord
+
dcat:DataService
+
+
vcard:Kind
+
+
+
+
+
dct:rightsHolder
+
geodcatap:custodian
+
geodcatap:distributor
+
geodcatap:originator
+
geodcatap:principalInvestigator
+
geodcatap:processor
+
geodcatap:resourceProvider
+
geodcatap:user
+
+
+
dcat:Catalog
+
dcat:Dataset
+
dcat:DatasetSeries
+
dcat:CatalogRecord
+
dcat:DataService
+
+
foaf:Agent
+
+
+
+
prov:qualifiedAttribution
+
+
prov:Entity
+
dcat:Catalog
+
dcat:Dataset
+
dcat:DatasetSeries
+
dcat:CatalogRecord
+
dcat:DataService
+
+
prov:Attribution
+
+
+
+
Responsible party role (M)
+
dcat:hadRole
+
+
prov:Attribution
+
+
dcat:Role
+
See and controlled vocabulary for responsible party role in .
+
+
+
+
*Metadata file identifier (O)
+
dct:identifier
+
+
dcat:CatalogRecord
+
rdfs:Literal
+
See . In RDF, this could also be represented as the URI of the metadata / catalogue record.
+
+
+
+
+
Metadata point of contact (M)
+
*Metadata point of contact (M)
+
+
dcat:contactPoint
+
+
dcat:CatalogRecord
+
vcard:Kind
+
See .
+
+
+
+
prov:qualifiedAttribution
+
+
dcat:CatalogRecord
+
prov:Attribution
+
+
+
+
+
*Metadata character set (C)
+
-
+
-
+
-
+
Metadata in GeoDCAT-AP are always in UTF-8. See .
+
+
+
+
Coordinate Reference System (M)
+
*Reference System (0)
+
geodcatap:referenceSystem
+
+
dcat:Catalog
+
dcat:Dataset
+
dcat:DatasetSeries
+
dcat:DataService
+
dcat:Distribution
+
+
skos:Concept
+
See .
+
+
+
+
Temporal Reference System (C)
+
*Reference System (0)
+
geodcatap:referenceSystem
+
+
dcat:Catalog
+
dcat:Dataset
+
dcat:DatasetSeries
+
dcat:DataService
+
dcat:Distribution
+
+
skos:Concept
+
See .
+
+
+
+
Character Encoding (C)
+
*Dataset character set (C)
+
cnt:characterEncoding
+
dcat:Distribution
+
rdfs:Literal
+
See .
+
+
+
+
Spatial representation type – (M)
+
*Spatial representation type (O)
+
adms:representationTechnique
+
dcat:Distribution
+
skos:Concept
+
See .
+
+
+
+
+
+
+
+
+
+
+
+
Overview of metadata elements covered by GeoDCAT-AP
+
+
The following table provides an overview of the metadata elements in the INSPIRE metadata schema and in the core profile of [[ISO-19115]], and the available mappings in [[DCAT-AP-3]] and GeoDCAT-AP. Columns titled with “obligation” specify whether the corresponding metadata elements are mandatory (M), conditional (C), and optional (O) (where “conditional” means “mandatory under given conditions”).
+
Note that the mappings covered by [[DCAT-AP-3]] correspond to those defined in GeoDCAT-AP core, whereas those covered only by GeoDCAT-AP correspond to those defined in the GeoDCAT-AP extended.
+
+
+
+
+
+
INSPIRE
+
Obligation
+
ISO 19115 Core
+
Obligation
+
DCAT-AP
+
GeoDCAT-AP
+
+
+
+
+
+
Metadata point of contact
+
M
+
Metadata point of contact
+
M
+
+
Yes
+
+
+
+
Metadata date
+
M
+
Metadata date stamp
+
M
+
Yes
+
Yes
+
+
+
+
Metadata language
+
M
+
Metadata language
+
C
+
Yes
+
Yes
+
+
+
+
+
+
Metadata character set
+
C
+
+
+
Always UTF-8
+
+
+
+
+
Metadata file identifier
+
O
+
+
Yes
+
+
+
+
+
+
Metadata standard name
+
O
+
+
Yes
+
+
+
+
+
Metadata standard version
+
O
+
+
Yes
+
+
+
+
Resource title
+
M
+
Dataset title
+
M
+
Yes
+
Yes
+
+
+
+
Temporal reference - Date of creation / publication / last revision
+
C
+
Dataset reference date
+
M
+
Partially (creation date not included)
+
Yes
+
+
+
+
Resource abstract
+
M
+
Abstract describing the dataset
+
M
+
Yes
+
Yes
+
+
+
+
Resource language
+
C
+
Dataset language
+
M
+
Yes
+
Yes
+
+
+
+
Topic category
+
M
+
Dataset topic category
+
M
+
+
Yes
+
+
+
+
Geographic bounding box
+
M
+
Geographic location of the dataset (by four coordinates or by geographic identifier)
+
C
+
Yes
+
Yes
+
+
+
+
Character encoding
+
C
+
Dataset character set
+
C
+
+
Yes
+
+
+
+
Temporal reference - Temporal extent
+
C
+
Additional extent information for the dataset (vertical and temporal)
+
O
+
Partially (temporal extent only)
+
Partially (temporal extent only)
+
+
+
+
Lineage
+
M
+
Lineage
+
O
+
Yes
+
Yes
+
+
+
+
Spatial representation type
+
M
+
Spatial representation type
+
O
+
+
Yes
+
+
+
+
Encoding
+
M
+
Distribution format
+
O
+
Yes
+
Yes
+
+
+
+
Spatial resolution
+
C
+
Spatial resolution of the dataset
+
O
+
Yes (but only as horizontal ground distance)
+
Yes
+
+
+
+
Responsible organisation
+
M
+
Dataset responsible party
+
O
+
Partially (only 3 of the 11 responsible party roles are supported)
+
Yes
+
+
+
+
Resource locator
+
C
+
On-line resource
+
O
+
Yes
+
Yes
+
+
+
+
Coordinate reference system; Temporal reference system
+
M; C
+
Reference system
+
O
+
+
Yes
+
+
+
+
Conformity
+
M
+
+
+
Yes
+
Yes
+
+
+
+
Resource type
+
M
+
+
+
Yes
+
Yes
+
+
+
+
Spatial data service type
+
M
+
+
+
+
Yes
+
+
+
+
Keyword
+
M
+
+
+
Partially (only for datasets and dataset series)
+
Yes
+
+
+
+
Coupled resource
+
C
+
+
+
Yes
+
Yes
+
+
+
+
Unique resource identifier
+
M
+
+
+
Yes
+
Yes
+
+
+
+
Conditions for access and use
+
M
+
+
+
Yes
+
Yes
+
+
+
+
Limitations on public access
+
M
+
+
+
Yes
+
Yes
+
+
+
+
Maintenance information
+
O
+
+
+
Partially (only maintenance and update frequency)
+
Partially (only maintenance and update frequency)
+
+
+
+
Data quality – Logical consistency – Topological consistency
+
C
+
+
+
+
Partially (only conformance results)
+
+
+
+
Data quality – Logical consistency – Conceptual consistency
+
O
+
+
+
+
Partially (only conformance results)
+
+
+
+
Data quality – Logical consistency – Domain consistency
+
O
+
+
+
+
Partially (only conformance results)
+
+
+
+
+
+
+
+
+
Detailed usage notes and examples
+
+
This annex contains further usage notes and examples on the mappings summarised in .
+
+
+
+
Resource title - *Dataset title
+
+
The content of the element ‘resource title’ can be represented in RDF as a plain literal, and by using property dct:title.
+
+
This binding may also include the specification of the language by using attribute @xml:lang [[XML]]. The language to be specified is the one indicated by element metadata language, mapped to the language identifiers defined by IETF BCP 47 [[BCP47]].
+
+
+
+
+
+
+
+
Resource abstract - *Abstract describing the dataset
+
+
The content of the elements ‘resource abstract’ can be represented in RDF as a plain literal, and by using property dct:description.
+
+
This binding may also include the specification of the language by using attribute @xml:lang [[XML]]. The language to be specified is the one indicated by element metadata language, mapped to the language identifiers defined by IETF BCP 47 [[BCP47]].
+
+
+
+
+
+
+
+
Resource type - *not in ISO 19115 core
+
+
+
+
+
+
[[VOCAB-DCAT-3]] and [[DCAT-AP-3]] provide specific classes that can be used to represent the INSPIRE notions of dataset, dataset series, and service, namely, dcat:Dataset, dcat:DatasetSeries, and dcat:DataService.
+
+
In order to explicitly indicate the correspondence with the relevant INSPIRE resource types, following the work on aligning INSPIRE Metadata and Dublin Core [[?INSPIRE-DC]], in the extended mapping profile of GeoDCAT-AP they will be denoted by using the resource type code list operated by the INSPIRE Registry [[INSPIRE-RT]], and by using geodcatap:resourceType. More precisely, the following URIs SHOULD be used to denote, respectively, dataset, series, and services:
Additionally, the spatial data service type can be specified by using geodcatap:serviceType with the corresponding code lists operated by the INSPIRE Registry [[INSPIRE-SDST]].
+
+
+
+
+
+
+
+
+
+
Resource locator - *On-line resource
+
+
In INSPIRE, this element, quoting, defines the link(s) to the resource and/or the link to additional information about the resource. [[VOCAB-DCAT-3]] has a property, namely, dcat:landingPage, having exactly the same purpose.
+
+
+
+
[[ISO-19115]] offers however the ability to specify the “type” of resource locator by using a specific code list (CI_OnlineFunctionCode), described in the following table:
+
+
+
+
+
ISO 19115 – CI_OnlineFunctionCode
+
Description
+
+
+
+
+
+
download
+
online instructions for transferring data from one storage device or system to another
+
+
+
+
information
+
online information about the resource
+
+
+
+
offlineAccess
+
online instructions for requesting the resource from the provider
+
+
+
+
order
+
online order process for obtaining the resource
+
+
+
+
search
+
online search interface for seeking out information about the resource
+
+
+
+
+
+
Based on this, the mappings of element “resource locator” for data sets and data set series will vary depending on the function code (when available), based on the following table.
+
+
+
+
+
+
ISO 19115 – CI_OnlineFunctionCode
+
Property
+
Domain
+
Range
+
+
+
+
+
+
(not provided)
+
dcat:landingPage
+
dcat:Dataset
+
foaf:Document
+
+
+
+
download
+
dcat:accessURL
+
dcat:Distribution
+
rdfs:Resource
+
+
+
+
Information
+
foaf:page
+
dcat:Dataset
+
foaf:Document
+
+
+
+
offlineAccess
+
dcat:accessURL
+
dcat:Distribution
+
rdfs:Resource
+
+
+
+
order
+
dcat:accessURL
+
dcat:Distribution
+
rdfs:Resource
+
+
+
+
search
+
foaf:page
+
dcat:Dataset
+
foaf:Document
+
+
+
+
+
+
However, whenever the URL points to a service endpoint, the resource locator SHOULD be always mapped to property dcat:accessURL, and complemented by additional two properties, namely, dcat:endpointURL and dcat:endpointDescription.
+
+
More precisely, if the URL is recognised as pointing to a capabilities document, the URL is mapped to property dcat:endpointDescription, whereas property dcat:endpointURL will take as value the URL without it query string component.
+
+
Properties dcat:endpointURL and dcat:endpointDescription will have as domain class dcat:DataService, linked to the dataset distribution via property dcat:accessService.
+
+
Finally, whenever it is possible to recognise the service protocol, this information will be specified by property geodcatap:serviceProtocol, taking as value the URI of the relevant specification from the INSPIRE Registry's code list for protocol values [[INSPIRE-PV]].
+
+
+
+
As far as services are concerned, the resource locator SHOULD be mapped to properties dcat:endpointURL, dcat:endpointDescription, and dct:conformsTo, as described above.
+
+
+
+
+
+
+
+
Unique resource identifier - *not in ISO 19115 core
+
+
In INSPIRE, this element is meant to uniquely identify a resource (dataset, series or service), and it is mandatory for datasets and series. It is specified by (a) a mandatory character string code and by (b) an optional character string namespace.
+
+
Based on [[DCAT-AP-3]], unique resource identifiers are mapped to dct:identifier (see ). The actual value is obtained by the concatenation of the values of the namespace (if specified) and of the code in the original metadata record.
+
+
+
+
If the unique resource identifier is specified with or can be encoded as an HTTP URI, it can be used as the URI of the resource (see ).
+
+
+
+
+
+
+
+
Coupled resource - *not in ISO 19115 core
+
+
This element is used to link a service to the target datasets or dataset series.
+
+
Following [[VOCAB-DCAT-3]] and [DCAT-AP-3], this relationship is specified by using property dcat:servesDataset.
+
+
+
+
The target dataset or series SHOULD be preferably referred to by using its unique resource identifier, as in .
+
+
+
+
+
+
+
+
Resource language and metadata language - *Dataset language and Metadata language
+
+
In INSPIRE metadata, metadata and resource languages (which may be different) are specified by using the three-letter language codes defined in [[?ISO-639-2]].
+
+
Based on [[DCAT-AP-3]], both elements are specified with property dct:language, with the URI of the relevant language available from the relevant register operated by the EU Publications Office [[EUV-LANG]].
+
+
assumes that the metadata language is Dutch, and the resource language is German.
+
+
+
+
The metadata language can be also used to specify the language of textual elements of resource metadata by using the @xml:lang attribute [[XML]].
+
+
Since @xml:lang takes as value language identifiers defined by IETF BCP 47 [[BCP47]], a mapping from the actual value of the metadata language is needed.
+
+
+
+
+
+
Topic category, originating controlled vocabulary, and keyword value - *Dataset topic category
+
+
In INSPIRE, these two elements have specific purposes. Quoting from the INSPIRE Metadata Regulation [[?INSPIRE-MD-REG]] (§2.1 and §3.1, respectively):
+
+
+
The topic category is a high-level classification scheme to assist in the grouping and topic-based search of available spatial data resources.
+
The keyword value is a commonly used word, formalised word or phrase used to describe the subject. While the topic category is too coarse for detailed queries, keywords help narrowing a full text search and they allow for structured keyword search.
+
+
+
Moreover, two types of keywords are allowed:
+
+
+
free keywords;
+
keywords taken from a controlled vocabulary.
+
+
+
Finally, topic categories apply only to datasets and dataset series.
+
+
+
+
Topic category and keyword in datasets and dataset series
+
+
As far as dataset metadata are concerned, in both [[VOCAB-DCAT-3]] and [[DCAT-AP-3]], a distinction is made only between free keywords and keywords from controlled vocabularies, associated with a URI. For the former, dcat:keyword is used, whereas for the latter dcat:theme (which is a sub-property of dct:subject). Since the INSPIRE Registry operates URI registers for topic categories and INSPIRE spatial data themes, and in order to keep the distinction existing in INSPIRE between topic categories and keywords, the mapping is as follows:
Keywords not associated with a controlled vocabulary will be mapped to dcat:keyword;
+
INSPIRE spatial data themes are mapped to dcat:theme and expressed by the corresponding URI in the INSPIRE Registry – reference register http://inspire.ec.europa.eu/theme;
+
Keywords associated with other controlled vocabularies are mapped to dcat:theme.
+
+
+
Following [[DCAT-AP-3]] recommendations, keywords from controlled vocabularies SHOULD be preferably specified with dereferenceable HTTP URIs. In such a case, the information concerning the originating controlled vocabulary can be omitted.
+
+
When keywords cannot be specified with HTTP URIs, they SHOULD be typed as a skos:Concept associated with a skos:ConceptScheme (used to type the originating controlled vocabulary), and annotated with the textual content and reference date(s) in the relevant INSPIRE metadata elements.
+
+
The representation of the information concerning the controlled vocabulary is illustrated in the following table.
+
+
+
+
+
+
Metadata Element
+
Proposed mapping
+
+
+
+
+
+
Originating controlled vocabulary
+
Title
+
skos:ConceptScheme
+
dct:title
+
+
+
+
Reference date
+
creation
+
dct:created
+
+
+
+
last revision
+
dct:modified
+
+
+
+
publication
+
dct:issued
+
+
+
+
+
+
For conformance with [[DCAT-AP-3]], GeoDCAT-AP records MUST also include keywords from the EU Vocabularies Data Theme Named Authority List [[EUV-THEMES]].
+
+
In order to ensure consistency, the relevant EU Vocabularies Data Theme keywords SHOULD be selected based on mappings with the controlled vocabularies used in INSPIRE / ISO 19115 metadata.
+
+
+
+
+
+
+
+
Keyword in services
+
+
As far as service metadata are concerned, keywords can classify either a service or the datasets / series operated by the service itself. For the latter, INSPIRE Metadata Regulation requires using at least one of the keywords from the ISO 19119 code list of spatial data service categories.
+
+
+
+
In order to keep the distinction between these two types of keywords, the adopted solution is as follows:
Keywords not associated with a controlled vocabulary will be mapped to dcat:keyword, and represented as un-typed literals;
+
INSPIRE spatial data themes are mapped to dcat:theme, and expressed by the corresponding URI in the INSPIRE Registry – reference register http://inspire.ec.europa.eu/theme
+
+
Keywords associated with other controlled vocabularies are mapped to dcat:theme. If not denoted by an HTTP URI, they SHOULD be expressed as a skos:Concept associated with a skos:ConceptScheme, and annotated with the textual content and reference date(s) in the relevant INSPIRE metadata elements.
+
+
+
+
+
+
+
+
+
+
+
Spatial data service type - *not in ISO 19115 core
+
+
See on resource type.
+
+
+
+
+
+
Geographic bounding box - *Geographic location of the dataset (by 4 coordinates or by geographic identifier)
+
+
In the core profile of [[ISO-19115]], spatial coverage can be specified either with a bounding box (a geometry) or a geographic identifier. INSPIRE is more restrictive, in that it requires using a bounding box
+
+
Based on that, GeoDCAT-AP specified spatial coverage as illustrated in the following sections.
+
+
+
+
+
+
Bounding box
+
+
As a general rule, when the area corresponding to the spatial coverage is denoted by a geometry, as in INSPIRE, [[DCAT-AP-3]] recommends the use of the Core Location Vocabulary [[LOCN]], where this is done by using property locn:geometry, having as range a geometry specified as
+
+
+
a URI - e.g., by using the geo URI scheme (IET RFC-5870) [[?RFC5870]], or a geohash URI [[?GEOHASH]], [[?GEOHASH-36]];
+
a syntax encoding scheme - e.g., geohashes [[?GEOHASH]], [[?GEOHASH-36]], WKT [[?ISO-19125-1]], GML [[?GML]], KML [[?KML]], GeoJSON [[?RFC7946]]; or
+
a semantic representation - using vocabularies like W3C Lat/long [[?W3C-BASIC-GEO]] or schema.org [[?SCHEMA-ORG]].
+
+
+
However, in case the geometry is a bounding box or a centroid, properties dcat:bbox and dcat:centroid, respectively, SHOULD be used instead of locn:geometry.
+
+
It is worth noting that currently there is no agreement on a preferred format to be used in RDF for the representation of geometries. In GeoDCAT-AP, geometries can be provided in any, and possibly multiple, encodings, but at least one of the following must be made available: WKT or GML. An additional requirement concerns the coordinate reference system (CRS) used, which may vary on a country or territory basis. The CRS must be specified in the GML or WKT encoding as required by GeoSPARQL [[GeoSPARQL11]]. Geometries shall be interpreted using the axis order defined in the spatial reference system used. For example, for CRS84 the axis order is longitude / latitude, whereas for WGS84 the axis order is latitude / longitude. Summarising:
+
+
+
Geometries MAY be provided in multiple encodings, but at least one of the following MUST be made available: GML and WKT.
+
For GML and WKT, the CRS MUST be specified as defined in GeoSPARQL [[GeoSPARQL11]].
+
+
+
As geometries may be provided in multiple encodings, the corresponding datatype SHOULD be always specified to ensure that the geometry literal is correctly interpreted.
+
+
For GML and WKT, the [[GeoSPARQL11]] datatypes gsp:gmlLiteral and gsp:wktLiteral, respectively, MUST be used.
+
+
For GeoJSON [[?RFC7946]], datatype gsp:geoJSONLiteral, defined in GeoSPARQL, version 1.1 [[?GeoSPARQL11]], SHOULD be used.
+
+
For the other geometry encodings, no datatype is currently available. Therefore, their interoperability is not ensured when metadata records are shared or harvested across catalogues.
+
+
+
+
+
+
+
+
+
+
+
+
Geographic identifier
+
+
[[ISO-19115]] core also allows specifying the geographic location using a geographic identifier. Following [[DCAT-AP-3]], for this, it is RECOMMENDED to use an HTTP URI from one of the following registers / gazetteers:
+
+
+
The Named Authority Lists operated by the Metadata Registry of the EU Publications office concerning continents [[EUV-CONT]], countries [[EUV-COUNTRIES]], and places [[EUV-PLACES]].
+
+
If none of the above provides the relevant geographic identifiers, Geonames [[?GEONAMES]] SHOULD be used.
+
If an HTTP URI is not available, the geographic identifier MUST be expressed with skos:prefLabel, and the reference to the originating controlled vocabulary (if any) MUST be specified with skos:inScheme. The controlled vocabulary will be described by a name (dct:title) and a last modified data (dct:modified).
+
+
+
+
As far as geographic identifiers are concerned, following [[DCAT-AP-3]], GeoDCAT-AP does not prevent the use other vocabularies in addition to the recommended ones. The vocabularies identified by the GeoDCAT-AP WG are listed in .
+
+
+
+
+
+
+
+
+
+
+
+
Temporal reference and metadata date –*Additional extent information for the dataset (vertical and temporal) and *Metadata date stamp
+
+
Temporal reference is a composite element consisting of the following possible child elements:
+
+
+
temporal extent (temporal coverage);
+
date of publication, last revision, and/or creation.
+
+
+
Based on [[DCAT-AP-3]], temporal extent is mapped to dct:temporal, having as range dct:PeriodOfTime. The time instant or interval is specified by using properties dcat:startDate and dcat:endDate, respectively.
+
+
By contrast, date of publication, last revision, and creation are mapped, respectively, to dct:issued, dct:modified (both core and extended GeoDCAT-AP mapping profiles), and dct:created (only for the extended mapping profile of GeoDCAT-AP).
+
+
[[DCAT-AP-3]] does not have a property equivalent to the INSPIRE metadata element metadata date. In INSPIRE, this element is defined as follows (see [[INSPIRE-MD-REG]], Part B, §10.2):
+
+
+
The date which specifies when the metadata record was created or updated.
+
+
+
Due to this ambiguity, the defined mapping for this element is dct:modified.
+
+
+
+
+
+
+
+
Lineage - *Lineage
+
+
Following [[DCAT-AP-3]], this element is mapped to property dct:provenance.
+
+
Since the range of dct:provenance is not a literal, but class dct:ProvenanceStatement, the free-text content of element “lineage” can be expressed by using dct:description.
+
+
+
+
+
+
+
+
Spatial resolution – Spatial resolution of the dataset
+
+
[[VOCAB-DCAT-3]] and [[DCAT-AP-3]] provide property dcat:spatialResolutionInMeters, to specify spatial resolution as distance in metres. Morever, [[VOCAB-DCAT-3]] and [[?SDW-BP]] recommend the use of [[VOCAB-DQV]] to specify other types of spatial resolution, via property dqv:hasQualityMeasurement.
+
+
Based on this, GeoDCAT-AP specifies spatial resolution as follows:
+
+
+
Property dcat:spatialResolutionInMeters is used for spatial resolution when it is expressed as distance in metres.
+
Property dqv:hasQualityMeasurement is used for all types of spatial resolution. In such a case, the type of spatial resolution is specified by using property dqv:isMeasurementOf, which takes as value the relevant instance of class dqv:Metric defined in GeoDCAT-AP for this purpose (see Instances of Metric).
+
Property geodcatap:spatialResolutionAsText is used when spatial resolution is specified as free-text.
+
+
+
The core mapping profile of GeoDCAT-AP, following [[DCAT-AP-3]], supports only the use property dcat:spatialResolutionInMeters, and, therefore, the other types of spatial resolution are left unmapped.
+
+
+
+
+
+
+
+
Conformity and data quality - *not in ISO 19115 core
+
+
In [[ISO-19115]], conformance and quality information is encoded as a quality report containing the result of a test (an evaluation) of a given quality measure, according to an evaluation method, with either a quantitative result (a metric) or a conformance result (pass or fail) as most important outcome.
+
+
The current version of GeoDCAT-AP only defines a syntax binding for conformity and not for data quality in general, making use of property dct:conformsTo and the W3C Provenance Ontology (PROV-O) [[PROV-O]], as explained in the following paragraphs.
+
+
+
+
[[DCAT-AP-3]] provides a single candidate, dct:conformsTo, which however can be used to map only a conformity of degree ‘conformant’. This is suitable for the core mapping profile of GeoDCAT-AP.
+
+
Considering how conformity must be expressed in extended mapping profile of GeoDCAT-AP (see [[INSPIRE-MD-REG]], Part B, §7), possible candidates are the W3C Evaluation and Report Language (EARL) [[?EARL10]] and the W3C Provenance Ontology (PROV-O) [[PROV-O]]. The latter candidate was chosen by the GeoDCAT-AP Working Group, since it would enable wider re-use with respect to the EARL vocabulary, which is more specific, and its use is limited.
+
+
[[PROV-O]] allows encoding conformity as a test activity (prov:Activity) that generated a result specified with property prov:generated, corresponding to the degree of conformity, for which the INSPIRE Registry maintains a URI set [[INSPIRE-DoC]]. The specification against which the conformance is asserted is specified via a qualified association (prov:qualifiedAssociation) with a test plan (a prov:Plan) in turn derived from a standard (dct:Standard, also prov:Entity). These associations are made via a property chain: prov:qualifiedAssociation, prov:hadPlan, and prov:wasDerivedFrom.
+
+
This pattern is illustrated in the following table.
In order to grant interoperability with [[DCAT-AP-3]], when conformity is of degree “conformant”, the proposal is to use both [[PROV-O]] and dct:conformsTo for GeoDCAT-AP Extended.
+
+
+
+
+
+
+
+
+
+
Conditions for access and use and limitations on public access – Use limitation and access / other constraints
+
+
In [[DCAT-AP-3]], licensing information is specified on (a) data catalogues (services) and on (b) the distribution(s) of a dataset, and not on the dataset itself. The principle is that different dataset distributions may be associated with different licensing terms. Moreover, [[DCAT-AP-3]] recommends the use of dct:accessRights for specifying access conditions. Both licenses and access rights should be indicated by their corresponding URIs.
+
+
Based on this, GeoDCAT-AP specifies use and access limitations by using, respectively, dct:license and dct:accessRights whenever the value is available as a URI. Otherwise, since the range of these properties is not a literal, but, respectively, classes dct:LicenseDocument and dct:RightsStatement, the free-text content of the corresponding ISO 19115 / INSPIRE metadata elements can be expressed using dct:description on the dct:RightsStatement instance, connected using the dct:rights property.
+
+
+
+
+
+
+
+
+
+
Responsible party and metadata point of contact - *Dataset responsible party and *Metadata point of contact
+
+
[[DCAT-AP-3]] supports properties to denote the publisher, the creator, and the contact point for a dataset.
+
+
By contrast, [[ISO-19115]] and [[INSPIRE-MD-REG]] support 11 possible relationships between a resource (a dataset, a dataset series, a service) and an agent (organisation), plus one for metadata. However, for only some of them suitable candidates exist from widely used vocabularies (in particular, DCMI Metadata Terms [[DCTERMS]]).
+
+
In order to fill this gap, specific properties have been defined in the GeoDCAT-AP namespace to complement those available in [[DCAT-AP-3]] and [[DCTERMS]].
+
+
The following table lists the mappings between responsible party roles and the corresponding properties used in GeoDCAT-AP.
+
+
+
+
+
+
[[ISO-19115]]
+
[[INSPIRE-MD-REG]]
+
Description
+
Proposed RDF mapping
+
+
+
+
+
+
Resource provider
+
Part B, §6.1
+
Party that supplies the resource.
+
geodcatap:resourceProvider
+
+
+
+
Custodian
+
Part B, §6.2
+
Party that accepts accountability and responsibility for the data and ensures appropriate care and maintenance of the resource.
+
geodcatap:custodian
+
+
+
+
Owner
+
Part B, §6.3
+
Party that owns the resource.
+
dct:rightsHolder
+
+
+
+
User
+
Part B, §6.4
+
Party who uses the resource.
+
geodcatap:user
+
+
+
+
Distributor
+
Part B, §6.5
+
Party who distributes the resource
+
geodcatap:distributor
+
+
+
+
Originator
+
Part B, §6.6
+
Party who created the resource.
+
geodcatap:originator
+
+
+
+
Point of contact
+
Part B, §6.7
+
Party who can be contacted for acquiring knowledge about or acquisition of the resource.
+
dcat:contactPoint
+
+
+
+
Principal investigator
+
Part B, §6.8
+
Key party responsible for gathering information and conducting research
+
geodcatap:principalInvestigator
+
+
+
+
Processor
+
Part B, §6.9
+
Party who has processed the data in a manner such that the resource has been modified.
+
geodcatap:processor
+
+
+
+
Publisher
+
Part B, §6.10
+
Party who published the resource
+
dct:publisher
+
+
+
+
Author
+
Part B, §6.11
+
Party who authored the resource.
+
dct:creator
+
+
+
+
+
+
The extended mapping profile of GeoDCAT-AP also supports the use of the W3C PROV ontology [[PROV-O]] and [[VOCAB-DCAT-3]] to specify the relationship between the resource and the responsible organisation. The FOAF Vocabulary [[FOAF]] is used to specify the contact information concerning the responsible party. Finally, the responsible party role will be specified by using dcat:hadRole, and using the relevant code list values from the INSPIRE Registry – reference register [[INSPIRE-RPR]]:
It is important to note that the [[PROV-O]]-based mappings are semantically equivalent to the property-based ones illustrated earlier in this section. Their use is therefore only accessory, and functional to possible requirements from the data provider side.
+
+
For these reasons, the GeoDCAT-AP overall approach is as follows:
+
+
+
Responsible parties and their roles MUST be represented by the corresponding properties, based on an agreed definition of 1-to-1 mappings.
+
The property-based representation MAY be complemented with the [[PROV-O]]-based approach.
+
+
+
As mentioned earlier, the latter option is supported only in the extended mapping profile of GeoDCAT-AP.
+
+
+
+
+
+
+
+
+
+
*Metadata file identifier
+
+
This element identifies a metadata record.
+
+
Metadata file identifiers are mapped to dct:identifier.
+
+
+
+
If the metadata file identifier is or can be encoded as an HTTP URI, it can also be used as the URI of the catalogue record (see ).
+
+
+
+
+
+
+
+
*Metadata standard name, *Metadata standard version
+
+
Following [[DCAT-AP-3]], GeoDCAT-AP uses dct:conformsTo to specify the metadata standard, and properties dct:title and owl:versionInfo are used to specify the standard name and version, respectively.
+
+
This pattern is illustrated in the following table.
+
+
+
+
+
+
Metadata element
+
Proposed mapping
+
+
+
+
+
+
Metadata standard
+
Metadata standard name
+
dct:conformsTo (range dct:Standard)
+
dct:title
+
+
+
+
Metadata standard version
+
owl:versionInfo
+
+
+
+
+
+
shows a GeoDCAT-AP metadata record obtained from one conformant with [[ISO-19115]].
+
+
+
+
To represent the standard name and version of the source ISO record, the GeoDCAT-AP metadata record must be extended as in .
+
+
+
+
+
+
+
+
*Metadata characterset
+
+
Since in RDF serializations always use UTF-8, the metadata characterset is not reflected in the GeoDCAT-AP.
+
+
+
+
+
+
Metadata point of contact - *Metadata point of contact
+
+
See .
+
+
+
+
+
+
Metadata date - *Metadata date stamp
+
+
See .
+
+
+
+
+
+
Metadata language - *Metadata language
+
+
See .
+
+
+
+
+
+
Coordinate reference systems and Temporal reference systems – *Reference System
+
+
In GeoDCAT-AP, these elements are mapped to property geodcatap:referenceSystem. Moreover, in order to indicate which type of a reference system the object of geodcatap:referenceSystem denotes, an additional statement with predicate dct:type is added, with a code list value defining the notion of (spatial / temporal) reference system, taken from the glossary operated by the INSPIRE Registry [[INSPIRE-GLOSSARY]].
+
+
More precisely, the following URIs SHOULD be used to denote, respectively, spatial and temporal reference systems:
The reference system identifier SHOULD be preferably represented with an HTTP URI. In particular, spatial reference systems should be specified by using the corresponding URIs from the “EPSG coordinate reference systems” register operated by the Open Geospatial Consortium [[OGC-EPSG]].
+
+
In this register, the URI prefix for coordinate reference systems is the following one:
identifies coordinate reference system EPSG 4258, corresponding to ETRS89 (European Terrestrial Reference System 1989).
+
+
+
+
In case the reference system is not specified as an HTTP URI, the mapping covers also other information included in the source metadata - as the identifier (dct:identifier), name (dct:title), and version (owl:versionInfo), plus a reference to the relevant register, if available (skos:inScheme). If a reference register is available, the reference system is implicitly also a skos:Concept, and its name can be specified by using skos:prefLabel.
+
+
+
+
+
+
If not represented with an HTTP URI, the reference system identifier MUST be mapped to dct:identifier, as in .
+
+
+
+
+
+
+
+
Character encoding - *Dataset character set and *Metadata character set
+
+
In [[VOCAB-DCAT-3]] and [[DCAT-AP-3]], the specification of the character encoding of a dataset and the character encoding of a metadata record is not explicitly supported. Moreover, since GeoDCAT-AP is an RDF-based specification, the metadata represented using GeoDCAT-AP are always in the UTF-8 encoding.
+
+
According to [[?RFC4288]], the character set can be part of the media type specification, but only for type “text”. By contrast, in INSPIRE the character set can be specified also for other media types.
+
+
The W3C Content vocabulary [[Content-in-RDF10]] provides a possibly suitable candidate, namely, property cnt:characterEncoding, taking as value the character set names in the IANA register [[IANA-CHARSETS]]. GeoDCAT-AP uses this property.
+
+
Character encoding in [[ISO-19115]] metadata is specified with a code list that can be mapped to the corresponding codes in [[IANA-CHARSETS]], as shown in the following table (entries with 1-to-many mappings are in italic).
+
+
+
+
+
ISO 19115 - MD_CharacterSetCode
+
Description
+
IANA
+
+
+
+
+
+
ucs2
+
16-bit fixed size Universal Character Set, based on ISO/IEC 10646
+
ISO-10646-UCS-2
+
+
+
+
ucs4
+
32-bit fixed size Universal Character Set, based on ISO/IEC 10646
+
ISO-10646-UCS-4
+
+
+
+
utf7
+
7-bit variable size UCS Transfer Format, based on ISO/IEC 10646
+
UTF-7
+
+
+
+
utf8
+
8-bit variable size UCS Transfer Format, based on ISO/IEC 10646
+
UTF-8
+
+
+
+
utf16
+
16-bit variable size UCS Transfer Format, based on ISO/IEC 10646
+
UTF-16
+
+
+
+
8859part1
+
ISO/IEC 8859-1, Information technology - 8-bit single byte coded graphic character sets - Part 1 : Latin alphabet No.1
+
ISO-8859-1
+
+
+
+
8859part2
+
ISO/IEC 8859-2, Information technology - 8-bit single byte coded graphic character sets - Part 2 : Latin alphabet No.2
+
ISO-8859-2
+
+
+
+
8859part3
+
ISO/IEC 8859-3, Information technology - 8-bit single byte coded graphic character sets - Part 3 : Latin alphabet No.3
+
ISO-8859-3
+
+
+
+
8859part4
+
ISO/IEC 8859-4, Information technology - 8-bit single byte coded graphic character sets - Part 4 : Latin alphabet No.4
+
ISO-8859-4
+
+
+
+
8859part5
+
ISO/IEC 8859-5, Information technology - 8-bit single byte coded graphic character sets - Part 5 : Latin/Cyrillic alphabet
+
ISO-8859-5
+
+
+
+
8859part6
+
ISO/IEC 8859-6, Information technology - 8-bit single byte coded graphic character sets - Part 6 : Latin/Arabic alphabet
+
ISO-8859-6
+
+
+
+
8859part7
+
ISO/IEC 8859-7, Information technology - 8-bit single byte coded graphic character sets - Part 7 : Latin/Greek alphabet
+
ISO-8859-7
+
+
+
+
8859part8
+
ISO/IEC 8859-8, Information technology - 8-bit single byte coded graphic character sets - Part 8 : Latin/Hebrew alphabet
+
ISO-8859-8
+
+
+
+
8859part9
+
ISO/IEC 8859-9, Information technology - 8-bit single byte coded graphic character sets - Part 9 : Latin alphabet No.5
+
ISO-8859-9
+
+
+
+
8859part10
+
ISO/IEC 8859-10, Information technology - 8-bit single byte coded graphic character sets - Part 10 : Latin alphabet No.6
+
ISO-8859-10
+
+
+
+
8859part11
+
ISO/IEC 8859-11, Information technology - 8-bit single byte coded graphic character sets - Part 11 : Latin/Thai alphabet
+
ISO-8859-11
+
+
+
+
8859part13
+
ISO/IEC 8859-13, Information technology - 8-bit single byte coded graphic character sets - Part 13 : Latin alphabet No.7
+
ISO-8859-13
+
+
+
+
8859part14
+
ISO/IEC 8859-14, Information technology - 8-bit single byte coded graphic character sets - Part 14 : Latin alphabet No.8 (Celtic)
+
ISO-8859-14
+
+
+
+
8859part15
+
ISO/IEC 8859-15, Information technology - 8-bit single byte coded graphic character sets - Part 15 : Latin alphabet No.9
+
ISO-8859-15
+
+
+
+
8859part16
+
ISO/IEC 8859-16, Information technology - 8-bit single byte coded graphic character sets - Part 16 : Latin alphabet No.10
+
ISO-8859-16
+
+
+
+
jis
+
japanese code set used for electronic transmission
+
JIS_Encoding
+
+
+
+
shiftJIS
+
japanese code set used on MS-DOS machines
+
Shift_JIS
+
+
+
+
eucJP
+
japanese code set used on UNIX based machines
+
EUC-JP
+
+
+
+
usAscii
+
United States ASCII code set (ISO 646 US)
+
US-ASCII
+
+
+
+
ebcdic
+
IBM mainframe code set
+
IBM037
+
+
+
+
eucKR
+
Korean code set
+
EUC-KR
+
+
+
+
big5
+
traditional Chinese code set used in Taiwan, Hong Kong of China and other areas
+
Big5
+
+
+
+
GB2312
+
simplified Chinese code set
+
GB2312
+
+
+
+
+
+
+
+
+
+
+
+
Encoding - *Distribution format
+
+
In both [[VOCAB-DCAT-3]] and [[DCAT-AP-3]], this information is specified for the distribution(s) of a dataset, and not for the dataset itself.
+
+
Two properties are available:
+
+
+
dcat:mediaType: to be used when the format corresponds to one of the media types registered by IANA [[IANA-MEDIA-TYPES]].
+
dct:format: to be used in all the other cases, to be used with file type register operated by the Publications Office of the EU [[EUV-FT]].
+
+
+
The same approach is used in GeoDCAT-AP for ISO 19115 / INSPIRE metadata.
+
+
+
+
+
+
+
+
+
+
Spatial representation type – *Spatial representation type
+
+
In [[DCAT-AP-3]], no equivalent term is provided.
+
+
In [[ISO-19115]], element “Spatial representation type” is meant mainly to describe the “method used to represent geographic information in the dataset”, by using a code list (see the table below).
+
+
+
+
The ADMS vocabulary [[VOCAB-ADMS]] includes a property, namely, adms:representationTechnique that could be used for this purpose. It is worth noting that, in the ADMS specification, adms:representationTechnique decribes a distribution, and not the dataset. Moreover, the [[ISO-19115]] code list of spatial representation types is available as a URI register from the INSPIRE Registry [[INSPIRE-SRT]].
+
+
+
+
+
+
+
+
Based on this, GeoDCAT-AP specifies this information by using property adms:representationTechnique, with the spatial representation type URIs operated by the INSPIRE Registry [[INSPIRE-SRT]].
+
+
This mapping is supported only in the extended mapping profile of GeoDCAT-AP.
+
+
The spatial representation types defined in [[ISO-19115]] are listed in the following table. It is important to note that, as stated in the INSPIRE Data Specifications, the only spatial representation types in scope of INSPIRE are the following ones: “vector”, “grid”, and “tin”.
+
+
+
+
+
ISO 19115 - MD_SpatialRepresentionTypeCode
+
Description
+
In scope of INSPIRE?
+
+
+
+
+
+
vector
+
vector data is used to represent geographic data
+
Yes
+
+
+
+
grid
+
grid data is used to represent geographic data
+
Yes
+
+
+
+
textTable
+
textual or tabular data is used to represent geographic data
+
No
+
+
+
+
tin
+
triangulated irregular network
+
Yes
+
+
+
+
stereoModel
+
three-dimensional view formed by the intersecting homologous rays of an overlapping pair of images
+
No
+
+
+
+
video
+
scene from a video recording
+
No
+
+
+
+
+
+
+
+
+
+
+
+
Maintenance information - *not in ISO 19115 core
+
+
In [[ISO-19115]], element “Maintenance information” is meant mainly to describe how frequently a resource is updated.
+
+
In [[DCAT-AP-3]], the update frequency is expressed through dct:accrualPeriodicity, with the frequency codes defined in the the EU Vocabularies Frequency Named Authority List [[EUV-FREQ]], which can be partially mapped to the ones used in [[ISO-19115]], as shown in the following table.
+
+
+
+
+
ISO 19115 - MD_MaintenanceFrequencyCode
+
Dublin Core Collection Description Frequency Vocabulary [[?CLD-FREQ]]
+
EU Vocabularies Frequency Named Authority List [[EUV-FREQ]]
+
+
+
+
+
+
continual
+
continuous
+
UPDATE_CONT / CONT
+
+
+
+
daily
+
daily
+
DAILY
+
+
+
+
weekly
+
weekly
+
WEEKLY
+
+
+
+
fortnightly
+
biweekly
+
BIWEEKLY
+
+
+
+
monthly
+
monthly
+
MONTHLY
+
+
+
+
quarterly
+
quarterly
+
QUARTERLY
+
+
+
+
biannually
+
semiannual
+
ANNUAL_2
+
+
+
+
annually
+
annual
+
ANNUAL
+
+
+
+
asNeeded
+
-
+
AS_NEEDED
+
+
+
+
Irregular
+
irregular
+
IRREG
+
+
+
+
notPlanned
+
-
+
NOT_PLANNED
+
+
+
+
unknown
+
-
+
UNKNOWN
+
+
+
+
-
+
triennial
+
TRIENNIAL
+
+
+
+
-
+
biennial
+
BIENNIAL
+
+
+
+
-
+
threeTimesAYear
+
ANNUAL_3
+
+
+
+
-
+
bimonthly
+
BIMONTHLY
+
+
+
+
-
+
semimonthly
+
MONTHLY_2
+
+
+
+
-
+
threeTimesAMonth
+
MONTHLY_3
+
+
+
+
-
+
semiweekly
+
WEEKLY_2
+
+
+
+
-
+
threeTimesAWeek
+
WEEKLY_3
+
+
+
+
-
+
-
+
OTHER
+
+
+
+
+
+
+
+
+
+
The [[ISO-19115]] code list of maintenance frequency codes is available as a URI register from the INSPIRE Registry [[INSPIRE-MF]].
+
+
+
+
+
+
Based on this, maintenance frequency is specified in GeoDCAT-AP by using dct:accrualPeriodicity with the EU Vocabularies Frequency Named Authority List [[EUV-FREQ]].
+
+
For the frequency codes not covered by the EU Vocabularies Frequency code list, the approach will be as follows:
+
+
+
In the core mapping profile of GeoDCAT-AP these codes will be ignored.
+
The extended mapping profile of GeoDCAT-AP will use the code list of ISO maintenance frequency codes operated by the INSPIRE Registry [[INSPIRE-MF]].
+
+
+
+
+
+
+
+
+
+
+
+
+
Comparison between INSPIRE and ISO 19115-1:2014
+
+
In [[?ISO-19115-1]] the concept of ‘Core metadata’ was removed; it was translated into a normative annex (Annex F) “Discovery metadata for geographic resources”. In the Annex F metadata elements for the discovery are listed in 2 tables:
+
+
+
the metadata elements to be used for discovery of geographic datasets and series are identified in F.1;
+
the metadata elements to be used for discovery of service resources are identified in F.2.
+
+
+
+
+
Spatial dataset and spatial dataset series
+
+
The table below compares the core requirements of ISO 19115:2003 (see Table 3 in 6.5 of [[?ISO-19115]]), the requirements of INSPIRE for spatial dataset and spatial dataset series as defined in the Implementing Rules for metadata and the discovery metadata for geographic datasets and series (see Table F.1 in annex F of [[?ISO-19115-1]]). For those last metadata elements in the last field of the table the path is indicated. For each element, in brackets the obligation/max occurrence (3rd field).
+
+
+
+
+
+
ISO 19115 Core
+
INSPIRE Implementing Rules for Metadata
+
ISO 19115-1:2014 Discovery metadata for datasets and series (Table F.1)
MD_Metadata.identificationInfo > MD_Identification.spatialResolution > MD_Resolution.equivalentScaleMD_Resolution.distance, MD_Resolution.vertical, or MD_Resolution.angularDistance, or MD_Resolution.levelOfDetail
The table below compares the core requirements of ISO 19115:2003 (see Table 3 in 6.5 of ISO 19115:2003), the requirements of INSPIRE for services as defined in the Implementing Rules for metadata and the discovery metadata for services (see Table F.2 in annex F of ISO 19115-1:2014). For those metadata elements in the last field of the table the path is indicated. For each element, in brackets the obligation/max occurrence (3rd field).
+
+
+
+
+
+
ISO 19115 Core
+
INSPIRE
+
ISO 19115-1:2014 Discovery metadata for services (Table F.2)
+
+This section provides a condensed tabular overview of the mentioned classes and properties in this specification.
+The properties are grouped under headings mandatory, recommended, optional and deprecated. These terms have the following meaning.
+
+
Mandatory property: a receiver MUST be able to process the information for that property; a sender MUST provide the information for that property.
+
Recommended property: a receiver MUST be able to process the information for that property; a sender SHOULD provide the information for that property if it is available.
+
Optional property: a receiver MUST be able to process the information for that property; a sender MAY provide the information for that property but is not obliged to do so.
+
Deprecated property: a receiver SHOULD be able to process information about instances of that property; a sender SHOULD NOT provide the information about instances of that property.
+
+The editors gratefully acknowledge the contributions made to this document by all members of the working group.
+Especially we would like to express our gratetude for the former editor and author Andrea Perego.
+
+This work was elaborated by a Working Group under SEMIC by Interoperable Europe in collaboration with DG Environment and JRC.
+Interoperable Europe of the European Commission was represented by Pavlina Fragkou.
+DG Environment was represented by Joeri Robbrecht and JRC by Jordi Escrui.
+Jakub Klímek, Bert Van Nuffelen, Pavlina Fragkou, Jitse De Cock, and Arthur Schiltz were the editors of this specification.
+