Analysis of DCAT-AP Versus NTI

Analysis of DCAT-AP versus NTI

1  Differences

1.1  Classes:

skos:Concept, skos:CategoryScheme and foaf:Organization are not mandatory in NTI, although skos:Concept, skos:ConceptScheme appear as ranges in mandatory properties in NTI, as well as foaf:Agent (the superclass of foaf:Organization); however, organisations are described as instances of org:Organization.

1.2  Properties:

1.2.1  Catalog

·  dct:issued, dct:modified, dct:license mandatory in NTI, optional in DCAT-AP

·  dct:spatial mandatory in DCAT-AP, optional in NTI

·  dct:identifier optional in NTI, not specified in DCAT-AP – not defined for DCAT

·  dct:extent optional in NTI, not specified in DCAT-AP – not defined for DCAT

·  DCAP AP uses dct:language, NTI uses dc:language (allowing literals “en”, “es” etc.)

1.2.2  Dataset

·  dcat:keyword, dct:issued, dct:modified mandatory in DCAT-AP, optional in NTI

·  dcat:landingPage mandatory in DCAT-AP, not specified in NTI

·  dct:license, dct:valid, dct:references, dct:conformsTo optional in NTI, not specified in DCAT-AP – not defined for DCAT

·  DCAP AP uses dct:language, NTI uses dc:language (allowing literals “en”, “es” etc.)

1.2.3  Distribution

·  dct:license mandatory in DCAT-AP, not specified in NTI

·  dct:format mandatory in NTI, optional in DCAT-AP

·  dct:description, dcat:downloadURL, dct:issued, dct:modified, dcat:mediaType optional in DCAT-AP, not specified in NTI

·  dct:identifier optional in NTI, not specified in DCAT-AP – not defined for DCAT

2  Conclusion

From the perspective of DCAT-AP, NTI does not conform to the current specification of DCAT-AP for the following elements:

·  DCAT-AP requires dct:spatial for Catalog, and dcat:keyword, dct:issued, dct:modified for Dataset which are optional in NTI. While NTI does not conform, it is however possible that resources described according to NTI do contain those properties.

·  In DCAT-AP dcat:landingPage for Dataset and dct:license for Distribution are mandatory but those are not specified in NTI

·  In DCAT-AP languages are represented as URIs as values for dct:language, while NTI uses language codes for dc:language

From the perspective of NTI, DCAT-AP does not conform to the NTI specification for the following elements:

·  NTI requires dct:issued, dct:modified, dct:license for Catalog, and dct:format for Distribution which are optional in DCAT-AP. It is however possible that resources described according to DCAT-AP do contain those properties.

·  Languages are represented differently

Properties that are optional in one specification and not specified in the other do not create incompatibility as unknown properties can legally be ignored.

The only problems are dcat:landingPage for Dataset and dct:license for Distribution as those are mandatory for DCAT-AP but not specified for NTI, and the different way in which languages are represented.

It is further noted that dcat:landingPage is not in the minimum set of properties for DCAT-AP in section 8. However, dct:license is currently declared part or the minimum set for Distribution.

3  Proposed resolution

In order to solve the incompatibilities, the following is proposed:

·  DCAT-AP to refer to foaf:Agent as range for dct:publisher; organisations to be described as instances of org:Organization

·  DCAT-AP to make dcat:landingPage optional for Dataset

·  NTI to associate dct:licence with Distribution instead of with Dataset, as this is the way the base standard DCAT handles licences.

·  NTI to convert language codes to URIs, as this is the way the base standard DCAT handles languages.

Furthermore, the following could be considered to increase compatibility:

·  DCAT-AP to make dct:spatial for Catalog, and dcat:keyword, dct:issued, dct:modified for Dataset optional

·  DCAT-AP to make dct:issued, dct:modified, dct:license mandatory for Catalog

·  NTI to make dct:issued, dct:modified, dct:license for Catalog and dct:format for Distribution optional

4  Further issues

For those cases where one profile specifies properties as mandatory that are optional in the other profile, it is proposed that data aggregators should attempt not to reject data where that information is missing unless the application that uses that data would not be able to function properly without it.

Makx Dekkers with contributions from Martín Álvarez/2013-04-15