Source: https://ies-svn.jrc.ec.europa.eu/projects/metadata/wiki/INSPIRE_profile_of_DCAT-AP_-_Reference
Timestamp: 2017-08-18 02:48:06
Document Index: 638518106

Matched Legal Cases: ['§1', '§1', '§1', '§1', '§1', '§1', '§1', '§2', '§2', '§3', '§4', '§5', '§6', '§6', '§7', '§8', '§8', '§9', '§10', '§10', '§10', '§2', '§3', '§10', '§10', '§6', '§6', '§6', '§6', '§6', '§6', '§6', '§6', '§6', '§6', '§6', '§7', '§10', '§1', '§1', '§3', '§2', '§4', '§5', '§6']

INSPIRE profile of DCAT-AP - Reference - MIWP-8: Metadata - MIG Collaboration Platform
INSPIRE profile of DCAT-AP - Reference¶
Replaced ogc:GMLLiteral (typo) with gsp:gmlLiteral in the example concerning the specification of the geographic bounding box. Here, prefix gsp is used for namespace URI http://www.opengis.net/ont/geosparql#.
Replaced dct:keyword (typo) with dcat:keyword in the examples
Replaced dct:issued (typo) with dct:modified for the metadata date in the examples - see the relevant section of this document relevant section of this document
INSPIRE profile of DCAT-AP - Reference (this document): reference document for the alignments defined in the core and extended versions of the INSPIRE profile of DCAT-AP
The DCAT Application Profile for Data Portals in Europe (DCAT-AP)
Aligning INSPIRE metadata with DCAT-AP
Conformity of INSPIRE metadata with DCAT-AP
INSPIRE resource types and the DCAT-AP notions of dataset and catalogue
The DCAT-AP notion of distribution
INSPIRE metadata on metadata and the DCAT-AP notion of catalog record
INSPIRE metadata elements not supported in DCAT-AP
Metadata and Uniform Resource Identifiers (URIs)
Proposed alignments for INSPIRE metadata elements
Metadata on metadata (metadata provenance) and resource metadata
RDF representation of metadata on metadata and resource metadata
Metadata and resource language(s)
RDF representation of elements “metadata language” and “resource language”
Resource title and resource abstract
RDF representation of elements “resource title” and “resource abstract”
RDF representation of element “resource type”
RDF representation of element “resource locator”
RDF representation of element “unique resource identifier” (datasets and series only)
RDF representation of element “coupled resource” (services only)
Topic category and keyword
Topic category and keyword in datasets and dataset series
Keyword in services
RDF representation of elements “topic category” and “keyword”
RDF representation of element “geographic bounding box”
Metadata date and temporal reference
RDF representation of elements “metadata date” and “temporal reference”
RDF representation of element “lineage” (datasets and series only)
Conditions for access and use and limitations on public access
RDF representation of elements “conditions for access and use” and “limitations on public access”
Metadata point of contact and responsible organisation
Mappings for metadata element responsible organisation
Responsible party roles
RDF representation of element “responsible organisation”
Mappings for metadata element conformity
RDF representation of element “conformity”
RDF representation of element “encoding” (datasets and series only)
RDF representation of element “character encoding” (datasets and series only)
Spatial resolution, coordinate and temporal reference systems, spatial representation type and topological consistency
This is the reference document for the alignments of INSPIRE metadata elements used in the Core and Extended versions of the INSPIRE profile of DCAT-AP (INSPIRE+DCAT-AP), which are described in separate documents:
The DCAT Application Profile for Data Portals in Europe (DCAT-AP)¶
DCAT-AP is a metadata profile developed in the framework of the EU Programme Interoperability Solutions for European Public Administrations (ISA), and based on and compliant with the W3C Data Catalog vocabulary (DCAT) - currently, one of the most widely used Semantic Web vocabularies for describing datasets and data catalogues.
The purpose of DCAT-AP is to define a common interchange metadata format for data portals of the EU and of EU Member States. In order to achieve this, DCAT-AP defines a set of classes and properties, grouped into mandatory, recommended and optional. Such classes and properties correspond to information on datasets and data catalogues that are shared by many European data portals, aiding interoperability. Although DCAT-AP is designed to be independent from its actual implementation, RDF [RDF] and Linked Data [LDBOOK] are the reference technologies.
Aligning INSPIRE metadata with DCAT-AP¶
The motivation for investigating the possiblity of aligning INSPIRE metadata with DCAT-AP is twofold:
To analyse how to use existing Semantic Web vocabularies and ontologies (including DCAT-AP) to provide a full representation of all INSPIRE metadata elements. Such a representation could potentially be recommended in the future as an alternative implementation (in addition to the current recommended one, based on ISO 19115/19119/19139), for meeting the legal requirements of the INSPIRE Metadata Regulation [INSPIRE-MD-REG].
Based on these considerations, two versions of an INSPIRE profile of DCAT-AP have been defined, namely, INSPIRE+DCAT-AP Core (addressing the requirements of point (1)) and INSPIRE+DCAT-AP Extended (addressing the requirements of point (2)). More precisely, the core version includes alignments only for the subset of INSPIRE metadata elements included in the DCAT-AP specification, whereas the extended version tries to defines alignments for all the INSPIRE metadata elements using DCAT-AP and other Semantic Web vocabularies (whenever DCAT-AP does not offer suitable candidates). As such, INSPIRE+DCAT-AP Extended is a superset of INSPIRE+DCAT-AP Core, and both are conformant with DCAT-AP.
Summary of alignment issues¶
Conformity of INSPIRE metadata with DCAT-AP¶
The DCAT-AP specification [DCAT-AP] includes a conformance statement (Section 9), according to which an application is conformant with DCAT-AP if it provides metadata about:
the datasets described in the metadata published on the catalogue;
the dataset distributions, if any;
the organisations referred to from the catalogue and dataset metadata;
the category schemes used to describe the datasets;
the categories referred to from dataset metadata.
INSPIRE metadata include all the mandatory elements of DCAT-AP, and, consequetly, an INSPIRE metadata record can be transformed into a DCAT-AP compliant format. The only exception concerns the “catalogue publisher”, which in INSPIRE metadata is not mandatory - more precisely, it is just one of the 11 possible responsible party roles that can be associated with a responsible organisation.
INSPIRE resource types and the DCAT-AP notions of dataset and catalogue¶
It is important to note that DCAT-AP is meant to describe only datasets and data catalogues. Consequently, it does not cover all the service types foreseen in INSPIRE. Moreover, the notion of dataset in DCAT-AP can be seen as broad, where it does not distinguish between the notions of dataset and dataset series found in INSPIRE.
About services, see also the next section, where the DCAT-AP notion of distribution is discussed.
The DCAT-AP notion of distribution¶
The specification of the W3C Data Catalog vocabulary (Section 5.4) defines a distribution as follows:
Represents a specific available form of a dataset. Each dataset might be available in different forms, these forms might represent different formats of the dataset or different endpoints. Examples of distributions include a downloadable CSV file, an API or an RSS feed.
INSPIRE metadata do not include a specific element for distributions (element “resource locator” can point to either a distribution or documentation of a dataset/series). This does not pose conformity issues with DCAT-AP, since distribution metadata are recommended, but not mandatory.
However, in the DCAT-AP logic, a number of INSPIRE metadata elements should be related to the distribution(s) of a dataset, and not to the dataset itself (e.g., elements “conditions for access and use”, “limitations on public access”, “encoding” and “character encoding”).
Since in the INSPIRE metadata on datasets and dataset series there is no direct link to the corresponding distributions, this poses a mapping issue, especially when multiple alternatives are specified.
It is important to note that, based on the DCAT definition of distribution, any INSPIRE service giving access to data might be modelled as a distribution. However, this solution is controversal, and it requires further investigation.
INSPIRE metadata on metadata and the DCAT-AP notion of catalog record¶
DCAT-AP includes the notion of “catalogue record” (dcat:CatalogRecord), which is meant to be, quoting the DCAT-AP specification (page 16), “A description of a Dataset’s entry in the Catalogue.” As such, dcat:CatalogRecord does not completely correspond to the purpose of the INSPIRE metadata elements concerning the metadata point of contact, date and language, which instead are meant to provide information on the provenance and characteristics of metadata records. For this reason, dcat:CatalogRecord is not suitable for modelling them.
INSPIRE metadata elements not supported in DCAT-AP¶
Spatial resolution, Coordinate reference system, Temporal reference system, Spatial representation type, Topological consistency: These elements are not foreseen in DCAT-AP. Moreover, there is no agreed way on how to model them in RDF.
Conformity: This is only partially supported, since the recommended property, dct:conformsTo, only models the case when the degree of conformity is “conformant”.
Lineage, Metadata point of contact, Metadata date, Metadata language: DCAT-AP recommends the use of the W3C PROV ontology [PROV] to model provenance information not covered in DCAT-AP. These metadata elements fall into that category. Notably, the W3C PROV ontology is partially compatible with Dublin Core [DCTerms].
Metadata and Uniform Resource Identifiers (URIs)¶
For the set of resource types listed above – namely, catalogues, datasets, distributions, organisations, categories and category schemes – DCAT-AP recommends, but does not require, the use of Uniform Resource Identifiers (URIs), as defined in RFC 3986 [IETF-RFC-3986], and, in particular, of HTTP URIs [CoolURI]. This means that these resources do not even need to have an ID and can be represented as blank nodes in RDF.
Using URIs in INSPIRE is not a problem for
the catalogue - where the service URL can be used:
categories and category schemes - they are available through the INSPIRE Registry.
However, in INSPIRE:
datasets have a Unique Resource Identifier that is not necessarily a URI;
organisations are not currently associated with a URI.
Since the use of URIs is not mandatory in DCAT-AP, no conformance issues are raised but the interest and trend in this area implies that this issue should be investigated further in the context of INSPIRE.
Requirements for controlled vocabularies¶
Section 8.1 of the final version of the DCAT-AP specification sets out a number of requirements to be satisfied by controlled vocabularies used in metadata conformant with DCAT-AP. Quoting:
Be published under an open license
Have labels in multiple languages, ideally in all official languages of the European Union
The relevant INSPIRE controlled vocabularies available through the INSPIRE Registry [INSPIRE-REGISTRY] satisfy these requirements.
Proposed alignments for INSPIRE metadata elements¶
This section discusses the proposed DCAT-AP mappings of all the INSPIRE metadata elements, by grouping them based on their characteristics.
The complete list of this reference registers is available in theappendix to this document.
A running example is used throughout this section, showing the DCAT-AP RDF-representation of the relevant metadata elements, using the Turtle syntax [TTL]. The namespace prefixes used in the examples are listed in the appendix to this document.
Full examples are provided in theINSPIRE+DCAT-AP Extended specification.
In order to provide an overview of the possible mappings between INSPIRE metadata and DCAT-AP, the following table merges all the INSPIRE metadata elements meant to describe datasets, dataset series, and services. For a summary of all INSPIRE metadata elements, their scope and cardinality constraints, see Part C of [INSPIRE-MD-REG].
In the table, term prefixes denote the relevant vocabulary. In particular:
dct: Dublin Core Metadata Terms [DCTerms]
dcat: W3C Data Catalog Vocabulary [DCAT]
Moreover, column “Reference” specifies the section in Part B of the Annex to [INSPIR-MD-REG] where the corresponding INSPIRE metadata element is defined. Elements for which no reference is specified are instead those defined in Article 13 of [INSPIRE-D&S-REG] (“Metadata required for Interoperability”).
Included in DCAT-AP
§1.1 Resource title dct:title No
§1.2 Resource abstract dct:description No
§1.3 Resource type dcat:Dataset, dcat:Catalog Yes/No DCAT-AP does not distinguish between datasets and dataset series. dcat:Catalog can be used for services.
§1.4 Resource locator dcat:landingPage No
§1.5 Unique resource identifier dct:identifier No
§1.6 Coupled resource dcat:dataset No
§1.7 Resource language dct:language No
§2.1 Topic category dcat:theme No
§2.2 Spatial data service type dcat:Catalog Yes/No DCAT-AP foresees only one type of services - i.e., data catalogues
§3 Keyword dcat:theme / dcat:keyword Yes/No dcat:keyword is for free keywords; dcat:theme for controlled vocabularies.
§4.1 Geographic bounding box dct:spatial No
§5 Temporal reference dct:temporal, dct:created, dct:issued, dct:modified No
§6.1 Lineage N/A Yes DCAT-AP suggests the use of the W3C PROV ontology to model information concerning provenance not covered in DCAT-AP.
§6.2 Spatial resolution N/A Yes
§7 Conformity dct:conformsTo Yes/No dct:conformsTo can model only one of the cases foreseen in INSPIRE. i.e., when the degree of conformity is conformant.
§8.1 Conditions for access and use dct:rights Yes/No In DCAT-AP, this is a characteristic of a data catalogue and of a data distribution, not of a dataset
§8.2 Limitations on public access dct:rights Yes/No In DCAT-AP, this is a characteristic of a data catalogue and of a data distribution, not of a dataset
§9 Responsible organisation dct:publisher, dcat:contactPoint Yes/No DCAT-AP foresees only two of the 11 responsible party roles supported in INSPIRE. However, DCAT-AP suggests the use of the W3C PROV ontology to model information concerning provenance not covered in DCAT-AP.
§10.1 Metadata point of contact N/A Yes DCAT-AP suggests the use of the W3C PROV vocabulary to model information concerning provenance not covered in DCAT-AP.
§10.2 Metadata date N/A Yes
§10.3 Metadata language N/A Yes
Coordinate reference system N/A Yes In DCAT-AP, these might be characteristics of a data distribution, not of a dataset
Temporal reference system N/A Yes
Encoding dct:format, dcat:mediaType Yes/No
Character encoding N/A Yes
Spatial representation type N/A Yes
Data quality – Logical consistency – Topological consistency N/A Yes
Metadata on metadata (metadata provenance) and resource metadata¶
INSPIRE metadata elements can be grouped into two classes:
Resource metadata, i.e., metadata describing a given spatial resource.
“Metadata on metadata”, i.e., metadata describing resource metadata, in terms of their provenance.
[DCAT, DCAT-AP] foresee terms for the description of datasets, but not of the metadata about datasets (about the [DCAT, DCAT-AP] notion of “catalogue record”, see the relevant section earlier in this document). Moreover, currently, no existing vocabularies provide a suitable candidate for modelling the INSPIRE notion of “metadata on metadata”. Consequently, the only option would be to map this notion to generic terms, such as foaf:Document [FOAF].
The proposal is to leave “metadata on metadata” untyped, and to discuss more in detail this issue in future work.
Another issue concerns how to link resource metadata to “metadata on metadata”. The proposed solution is to use foaf:isPrimaryTopicOf [FOAF], based on common practices, since this property is widely used for this purpose (and also to link a catalogue record to the corresponding dataset).
RDF representation of metadata on metadata and resource metadata¶
# Metadata on metadata
Metadata and resource language(s)¶
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, DCAT-AP], the proposal is to use for both elements is dct:language, and to specify the relevant language by using the language URI register operated by the EU Publications Office [MDR-LANG], available also in RDF format.
RDF representation of elements “metadata language” and “resource language”¶
[] dct:language <http://publications.europa.eu/resource/authority/language/DEU> ;
[ dct:language
<http://publications.europa.eu/resource/authority/language/ENG> ] .
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], a mapping from the actual value of the metadata language is needed.
Resource title and resource abstract¶
The content of these elements can be represented in RDF as a plain literal.
For the resource title, the proposed mapping is dct:title.
For the resource abstract, both dct:abstract and dct:description are possible candidates.
Based on the solution adopted in [DCAT, DCAT-AP], the proposal is to use dct:description.
dct:title and dct:description 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].
RDF representation of elements “resource title” and “resource abstract”¶
[]  dct:title "Forest / Non-Forest Map 2006"@en ;
dct:description "Pan-European Forest / Non Forest Map with target year 2006, Data Source: Landsat ETM+ and Corine
Land Cover 2006, Classes: for-est, non-forest, clouds/snow, no data; Method: automatic classification performed
with an in-house algorithm; spatial resolution: 25m. In addition, the forest map 2006 is extended to FTYPE2006 to
include forest types (broadleaf, coniferous forest) that are mapped using MODIS composites."@en .
In [DCAT], the notion of dataset is quite broad, and may include both the INSPIRE notions of dataset and dataset series.
Moreover, currently no existing vocabulary provides suitable candidates for the INSPIRE notions of dataset series – the existing ones are very generic (e.g., dctype:Collection is defined as "An aggregation of resources" [DCTerms ]).
Based on this, the proposal is to define both INSPIRE datasets and dataset series as instances of dcat:Dataset.
Moreover, in order to maintain the INSPIRE distinction between datasets and dataset series, following [INSPIRE-DC], the proposal is to denote it by using the resource type code list operated by the INSPIRE Registry, and by using dct:type.
As far as the INSPIRE notion of service is concerned, [DCAT, DCAT-AP] foresee a single class, namely, dcat:Catalog. Following the approach described above for datasets and dataset series, the proposed solution is to define any service as instance of dcat:Catalog, and to specify the spatial data service type by using dct:type with the corresponding code lists operated by the INSPIRE Registry.
RDF representation of element “resource type”¶
## Resource type for datasets
[]  a dcat:Dataset;
dct:type <http://inspire.ec.europa.eu/codelist/ResourceType/dataset>
## Resource type for series
dct:type <http://inspire.ec.europa.eu/codelist/ResourceType/series>
## Resource type for services (here, a view service)
[]  a dcat:Catalog;
dct:type <http://inspire.ec.europa.eu/codelist/ResourceType/service> ,
<http://inspire.ec.europa.eu/codelist/SpatialDataServiceType/view> .
In INSPIRE, this element, quoting, “defines the link(s) to the resource and/or the link to additional information about the resource”.
For datasets, [DCAT, DCAT-AP] foresee a property, namely, dcat:landingPage, having exactly the same purpose. By contrast, the only property foreseen in [DCAT, DCAT-AP] for linking a service to an online resource is foaf:homepage.
Based on this, the proposed mappings of element “resource locator” are the following:
dcat:landingPage for data sets and data set series;
foaf:homepage for services.
RDF representation of element “resource locator”¶
## Resource locator for datasets and series
dcat:landingPage <http://forest.jrc.ec.europa.eu/forestmap-download>
## Resource locator for services
[]  a dcat:Catalog; foaf:homepage <http://geohub.jrc.ec.europa.eu/efas_cc?service=WMS&request=GetCapabilities> .
Unique resource identifier¶
Based on [DCAT-AP], the proposed candidate for this element is property dct:identifier. The two components of this element (namespace and code), should be concatenated, using a slash (/) as separator.
Property dct:identifier should be typed as an xsd:string.
RDF representation of element “unique resource identifier” (datasets and series only)¶
dct:identifier "http://efdac.jrc.ec.europa.eu/947e5a55-e548-11e1-9105-0017085a97ab"^^xsd:string .
Coupled resource¶
This element is used to link a service to the target datasets or dataset series, by using the corresponding Unique Resource Identifiers.
[DCAT, DCAT-AP] foresee a property, namely, dcat:dataset, having exactly the same purpose.
RDF representation of element “coupled resource” (services only)¶
dcat:dataset <http://rdsi-portal.jrc.it:8080/geonetwork/srv/eng/xml_iso19139?uuid=14fda267-6da4-4024-bc6f-8bad1c0bf249> ,
<http://rdsi-portal.jrc.it:8080/geonetwork/srv/eng/xml_iso19139?uuid=489e972e-560f-4faf-b40f-ce4ae554b46e> ,
<http://rdsi-portal.jrc.it:8080/geonetwork/srv/eng/xml_iso19139?uuid=51db193b-39fa-46b1-810d-510b7653e992> ,
<http://rdsi-portal.jrc.it:8080/geonetwork/srv/eng/xml_iso19139?uuid=73b4c188-be32-4a2e-949a-f6b186b5eedd> ,
<http://rdsi-portal.jrc.it:8080/geonetwork/srv/eng/xml_iso19139?uuid=74d58a19-d494-48f0-953c-e1ba47c6af55> ,
<http://rdsi-portal.jrc.it:8080/geonetwork/srv/eng/xml_iso19139?uuid=9060b16a-9772-43a1-bfac-1095da67119c> ,
<http://rdsi-portal.jrc.it:8080/geonetwork/srv/eng/xml_iso19139?uuid=cbf13b10-9f28-4e74-ace1-4e162a0f6307> ,
<http://rdsi-portal.jrc.it:8080/geonetwork/srv/eng/xml_iso19139?uuid=e81e7e5d-488f-4468-b7c0-fc263fc2c4be> ,
<http://rdsi-portal.jrc.it:8080/geonetwork/srv/eng/xml_iso19139?uuid=f3430932-cc3f-44f1-853d-2492a8368ed7> .
Topic category and keyword¶
In INSPIRE, these two elements have specific purposes. Quoting from [INSPIRE-MD-REG] (§2.1 and §3.1, respectively):
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 and dataset series metadata are concerned, in [DCAT, DCAT-AP], 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 proposal is as follows:
Topic category is mapped to dct:subject, and expressed by the corre-sponding URI in the INSPIRE Registry.
Keywords not associated with a controlled vocabulary will be mapped to dcat:keyword;
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.
Keywords associated with other controlled vocabularies are mapped to dcat:theme, 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. Both skos:Concept and skos:ConceptScheme will be blank nodes (i.e., no URIs will be used to denote them).
In the last case, the representation of the information concerning the controlled vocabulary is illustrated in the following table.
Mappings for metadata element originating controlled vocabulary¶
Originating controlled vocabulary Title skos:ConceptScheme rdfs:label
Reference date creation dct:created
last revision dct:modified
publication dct:issued
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-MD-REG] requires using at least one of the keywords from the ISO 19119 code list of spatial data service categories.
[DCAT, DCAT-AP] do not foresee any specific property for keywords classifying either a service or the datasets / series operated by a service. Moreover, dcat:theme and dcat:keyword cannot be used for services, since their domain is restricted to dcat:Dataset.
In order to keep the distinction between these two types of keywords, the proposed solution is as follows:
Keywords from the ISO 19119 codelist of spatial data service categories are mapped to dct:type, and expressed by the corresponding URI in the INSPIRE Registry.
Keywords not associated with a controlled vocabulary will be mapped to dc:subject;
Keywords whose controlled vocabulary is the one of the INSPIRE spatial data themes are mapped to dct:subject, and expressed by the corresponding URI in the INSPIRE Registry.
Keywords associated with other controlled vocabularies are mapped to dct:subject and 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. Both skos:Concept and skos:ConceptScheme will be blank nodes (i.e., no URIs will be used to denote them).
In the last case, controlled vocabularies are represented as explained in the previous section.
RDF representation of elements “topic category” and “keyword”¶
## Datasets and series
[]  a dcat:Dataset ;
### Free keywords
dcat:keyword "CHM"@en, "RDSI"@en ;
### Keywords from controlled vocabularies
<http://inspire.ec.europa.eu/theme/lc> ,
skos:prefLabel "coniferous forest"@en ;
skos:inScheme [ a skos:ConceptScheme ;
rdfs:label "GEMET - Concepts, version 2.4"@en ;
dct:issued "2010-01-13"^^xsd:date ] ] ;
### Topic categories
dct:subject <http://inspire.ec.europa.eu/codelist/TopicCategory/geoscientificInformation> .
[]  a dcat:Catalog ;
dc:subject "hidrography"@en ;
### Keyword from ISO 19119 codelist of spatial data service categories
dct:type <http://inspire.ec.europa.eu/codelist/SpatialDataServiceCategory/humanGeographicViewer/> ;
dcat:theme <http://inspire.ec.europa.eu/theme/hy> ,
skos:prefLabel "Floods"@en ;
rdfs:label "GEOSS - Societal Benefit Areas, version 1.0"@en ;
dct:issued "2010-08-25"^^xsd:date ] ] .
Geographic bounding box¶
In [DCAT, DCAT-AP], the spatial coverage is specified by using property dct:spatial, having as range dct:Location.
When the area corresponding to the spatial coverage is denoted by a geometry, as in INSPIRE, [DCAT-AP] recommends the use of the Core Location Vocabulary [LOCN]. In [LOCN], 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 [IETF-RFC-5870], or a geohash URI [GEOHASH, GEOHASH-36]
a syntax encoding scheme - e.g., geohashes [GEOHASH, GEOHASH-36], WKT [ISO-19125], GML [GML], KML [KML], GeoJSON [GEOJSON]
a semantic representation - using vocabularies like W3C Lat/long [LAT-LONG] or schema.org [SCHEMA]
It is worth noting that currently there is no agreement on a preferred format to be used in RDF for the representation of geometries. The provisional proposal is to represent the geometry as a GML literal (gml:Envelope), as specified in [GEOSPARQL]. However, this is an issue that requires further investigation, both in the framework of the INSPIRE MIG and in relevant standardisation activities.
RDF representation of element “geographic bounding box”¶
[] dct:spatial [ a dct:Location ;
locn:geometry "<gml:Envelope srsName=\"http://www.opengis.net/def/EPSG/0/4326\">
<gml:lowerCorner>-10.58 34.56</gml:lowerCorner>
<gml:upperCorner>34.59 70.09</gml:upperCorner>
</gml:Envelope>"^^gsp:gmlLiteral ] .
Metadata date and temporal reference¶
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, DCAT-AP], temporal extent is mapped to dct:temporal, having as range dct:PeriodOfTime. The time instant or interval is specified by using properties schema:startDate and schema:endDate, respectively.
By contrast, date of publication, last revision, and creation are mapped, respectively, to dct:issued, dct:modified, and dct:created.
[DCAT, DCAT-AP] do not foresee a property equivalent to the INSPIRE metadata element metadata date. In INSPIRE, this element is defined as follows (Part B, §10.2):
Due to this ambiguity, the proposed mapping for this element is dct:modified.
RDF representation of elements “metadata date” and “temporal reference”¶
## Creation, publication and last revision dates
[]  dct:created "2010-03-01"^^xsd:date ;
dct:issued "2010-10-05"^^xsd:date ;
dct:modified "2011-09-01"^^xsd:date ;
## Temporal extent
schema:endDate "2006-12-31"^^xsd:date ;
schema:startDate "2006-01-01"^^xsd:date ] ;
## Metadata date
[ dct:modified "2012-08-13"^^xsd:date ] .
In [DCAT, DCAT-AP], no equivalent term is foreseen.
In [INSPIRE-DC], the proposed mapping is dc:description. However, an equivalent property, namely, dct:description, is used in [DCAT, DCAT-AP] for what in INSPIRE corresponds to the resource abstract element.
For these reasons, the proposed candidate is 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 rdfs:label, as illustrated in [DC-WIKI-PM].
RDF representation of element “lineage” (datasets and series only)¶
dct:provenance [ a dct:ProvenanceStatement ;
rdfs:label "Forest Map 2006 is derived from the IMAGE2006 (SPOT/LISS scenes) and CORINE2006 landcover dataset. In
addition, MODIS composites are used for the Forest type classification."@en ] .
Conditions for access and use and limitations on public access¶
In [DCAT, DCAT-AP], this 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.
[DCAT, DCAT-AP] foresee two properties to express licensing terms for data catalogues and data distributions:
dct:license, which is meant to be used to specify the URI of the relevant licence;
dct:rights, which can be used to specify the licensing terms also with free text.
Since the two relevant INSPIRE metadata elements express licensing terms as free text, the suitable candidate is dct:rights. However, using the same property for both will result in losing the distinction between the two elements in the original metadata.
In order to address this issue, and following [INSPIRE-DC], the proposed candidates for conditions for access and use and limitations on public access are, respectively, dct:rights and dct:accessRights. This does not break compatibility with DCAT-AP, which is also formally granted by the fact that dct:accessRights is a sub-property of dct:rights.
Since the range of both these properties is not a literal, but class dct:RightsStatement, the free-text content of the corresponding INSPIRE metadata elements can be expressed by using rdfs:label, as illustrated in [DC-WIKI-PM].
RDF representation of elements “conditions for access and use” and “limitations on public access”¶
dct:rights [ a dct:RightsStatement ;
Metadata point of contact and responsible organisation¶
[DCAT, DCAT-AP] foresee properties to denote the publisher and the contact point for a dataset.
By contrast, INSPIRE metadata foresee 11 possible relationships between a resource (a dataset, a dataset series, a service) and an agent (organisation), plus one for metadata. For some of them, suitable candidates exist from widely used vocabularies (in particular, [DCTerms ]). However, for some of them no suitable candidate is available in the existing vocabularies (in particular, for roles “user” and “processor”).
A possible solution is to support many-to-1 mappings whenever possible. For instance, roles “publisher” and “provider” could be both mapped to dct:publisher. However, besides losing the original semantics, this would result in creating ambiguities (e.g., two dct:publisher’s) that would not help interoperability with [DCAT-AP]. Therefore, it would be preferable to support 1-to-1 mappings only.
Another possible way of representing responsible organisations is to use the W3C PROV ontology [PROV], to specify the relationship between the resource and the responsible organisation. The W3C vCard ontology [vCard] can then be used to specify the contact information concerning the responsible party. Finally, the responsible party role can be specified by using dct:type, and using the relevant code list values from the INSPIRE Registry.
These mappings are illustrated in the following table:
Mappings for metadata element responsible organisation¶
Responsible organisation Responsible party Organisation name prov:Attribution vcard:Kind vcard:organization-name
Contact email address vcard:hasEmail
Responsible party role dct:type
This option has the advantage of preserving the semantics in the original metadata, and of preventing information loss. However, it would not help interoperability with data sources outside INSPIRE.
For these reason, the proposed solution is as follows:
Represent responsible organisations by using the PROV ontology.
If suitable candidates exist from widely used vocabularies, use them to represent the corresponding responsible parties and their roles, based on an agreed definition of 1-to-1 mappings.
The following table lists the proposed mappings for responsible party roles, taking into account only widely used vocabularies.
Responsible party roles¶
Proposed RDF mapping
Part B §10.1 Metadata point of contact This is the description of the organisation responsible for the creation and maintenance of the metadata. dcat:contactPoint stable
Part D §6.1 Resource provider Party that supplies the resource. N/A
Part D §6.2 Custodian Party that accepts accountability and responsibility for the data and ensures appropriate care and maintenance of the resource. N/A
Part D §6.3 Owner Party that owns the resource. dct:rightsHolder stable
Part D §6.4 User Party who uses the resource. N/A
Part D §6.5 Distributor Party who distributes the resource. N/A
Part D §6.6 Originator Party who created the resource. dct:creator stable
Part D §6.7 Point of contact Party who can be contacted for acquiring knowledge about or acquisition of the resource. dcat:contactPoint stable
Part D §6.8 Principal investigator Key party responsible for gathering information and conducting research. N/A
Part D §6.9 Processor Party who has processed the data in a manner such that the resource has been modified. N/A
Part D §6.10 Publisher Party who published the resource. dct:publisher stable
Part D §6.11 Author Party who authored the resource. N/A
RDF representation of element “responsible organisation”¶
[] dct:rightsHolder [ a foaf:Organization ;
foaf:mbox <mailto:efdac@jrc.ec.europa.eu> ;
foaf:name "European Union"@en ] ;
dct:type <http://inspire.ec.europa.eu/codelist/ResponsiblePartyRole/resourceProvider> ;
prov:agent [ a vcard:Kind ;
vcard:hasEmail <mailto:efdac@jrc.ec.europa.eu> ;
vcard:organization-name "European Commission, Joint Research Centre"@en ] ] ,
[ a prov:Attribution ;
dct:type <http://inspire.ec.europa.eu/codelist/ResponsiblePartyRole/author> ;
vcard:organization-name " European Commission, Joint Research Centre "@en ] ] ,
dct:type <http://inspire.ec.europa.eu/codelist/ResponsiblePartyRole/owner> ;
vcard:organization-name "European Union"@en ] ] ;
[  dcat:contactPoint [ a vcard:Kind ;
vcard:organization-name "European Commission, Joint Research Centre"@en ] ;
dct:type <http://inspire.ec.europa.eu/codelist/ResponsiblePartyRole/pointOfContact> ;
vcard:organization-name "European Commission, Joint Research Centre"@en ] ] ] .
Conformity¶
[DCAT-AP] provides a single candidate, dct:conformsTo, which however can be used to map only a conformity of degree conformant.
Considering how conformity must be expressed (see [INSPIRE-MD-REG], Part B, §7), a possible suitable candidate is the W3C Evaluation and Report Language (EARL) [EARL].
The EARL mappings for the “conformity” INSPIRE metadata element are illustrated in the following table. The degree of conformity can be expressed by property earl:outcome, using the relevant code list values available from the INSPIRE Registry.
Mappings for metadata element conformity¶
Conformity Specification Title earl:Assertion earl:test dct:title
Degree earl:result + earl:outcome
The proposal is then to use EARL for the specification of the “conformity” INSPIRE metadata element.
Moreover, in order to grant interoperability with DCAT-AP, when conformity is of degree “conformant”, the proposal is to use both EARL and dct:conformsTo.
RDF representation of element “conformity”¶
[]  dct:conformsTo [
dct:title "COMMISSION REGULATION (EC) No 976/2009 of 19 October 2009 implementing Directive 2007/2/EC of the
European Parliament and of the Council as regards the Network Services"@en ;
dct:issued "2009-10-20"^^xsd:date ] ;
wdrs:describedby [ a earl:Assertion ;
earl:outcome <http://inspire.ec.europa.eu/codelist/DegreeOfConformity/conformant> ] ;
earl:test [ dct:issued "2009-10-20"^^xsd:date ;
European Parliament and of the Council as regards the Network Services"@en ] ] .
In [DCAT, DCAT-AP], this information is specified for the distribution(s) of a dataset, and not for the dataset itself.
Two properties are foreseen:
dcat:mediaType: to be used when the format corresponds to one of the media types registered by IANA [IANA-MT]
dct:format: to be used in all the other cases
The same approach can be proposed for INSPIRE metadata.
In both cases, [DCAT-AP] recommends the use of the URI file type register [MDR-FT], operated by the Metadata Registry of the Publications Office of the EU, to specify formats/media types. However, this register does not include many of the formats/media types typically used for INSPIRE data – as, e.g., GML, shapefiles and raster files – which are available through the INSPIRE media type register [INSPIRE-MT].
The proposal is then to use [MDR-FT], if it includes the relevant format/media type, and [INSPIRE-MT] otherwise.
RDF representation of element “encoding” (datasets and series only)¶
dcat:mediaType <http://publications.europa.eu/resource/authority/file-type/TIFF> ] .
In [DCAT, DCAT-AP], the specification of the character encoding of a dataset is not explicitly foreseen.
According to RFC 4288 [IETF-RFC-4288], the character set can be part of the media type specification, but only for type “text”. By contrast, in INSPIRE the charset can be specified also for other media types.
The W3C Content vocabulary [CNT] provides a possibly suitable candidate, namely, property cnt:characterEncoding, taking as value the character set names in the IANA register [IANA-CHAR]. The proposal is to use this property.
RDF representation of element “character encoding” (datasets and series only)¶
cnt:characterEncoding "UTF-8"^^xsd:string ] .
Spatial resolution, coordinate and temporal reference systems, spatial representation type and topological consistency¶
In [DCAT, DCAT-AP], no equivalent terms are foreseen.
There are currently no candidates in existing vocabularies to represent such metadata elements.
It is worth noting that these elements are describing properties that in [DCAT, DCAT-AP] might be referred to the distribution(s) of a dataset, and not to the dataset itself – e.g., a dataset with distributions using different spatial resolution, coordinate reference systems, etc.
earl http://www.w3.org/ns/earl# Evaluation and Report Language (EARL) 1.0
wdrs http://www.w3.org/2007/05/powder-s# Protocol for Web Description Resources (POWDER): Description Resources
Part B §10.3 Metadata language http://publications.europa.eu/resource/authority/language Language register operated by the Metadata Registry of the Publications Office of the EU [MDR-LANG] testing
Part B §1.7 Resource language
Part D §1 Resource type http://inspire.ec.europa.eu/codelist/ResourceType Register operated by the INSPIRE Registry for resource types defined in ISO 19139 stable
Part D §3 Service type http://inspire.ec.europa.eu/codelist/SpatialDataServiceType Register operated by the INSPIRE Registry for service types, as defined in [INSPIRE-MD-REG] stable
Part D §2 Topic category http://inspire.ec.europa.eu/codelist/TopicCategory Register operated by the INSPIRE Registry for topic categories defined in ISO 19115 stable
Annex I, II, III to [INSPIRE-DIR] Keyword denoting one of the INSPIRE spatial data themes http://inspire.ec.europa.eu/theme INSPIRE spatial data theme register operated by the INSPIRE Registry stable
Part D §4 Keyword denoting one of the spatial data service categories http://inspire.ec.europa.eu/codelist/SpatialDataServiceCategory Register operated by the INSPIRE Registry for spatial data service categories defined in ISO 19119 stable
Part D §5 Degree of conformity http://inspire.ec.europa.eu/codelist/DegreeOfConformity Register operated by the INSPIRE Registry for degrees of conformity, as defined in [INSPIRE-MD-REG] stable
Part D §6 Responsible party role http://inspire.ec.europa.eu/codelist/ResponsiblePartyRole Register operated by the INSPIRE Registry for responsible party roles, as defined in [INSPIRE-MD-REG] stable