GeoDCAT-AP: Use cases and open issues

Problem statement

The ability to request metadata records following a given profile is a feature supported via query parameters by existing standards for catalogue services. E.g., this is the case for the Open Geospatial Consortium's Catalogue Service for the Web (CSW) [CSW] and the Open Archive Initiative's Protocol for Metadata Harvesting (OAI-PMH) [OAI-PMH].

The issue is that in all these cases the mechanism to request the output profile is specific to the interface used. An interface-independent mechanism, e.g., based on the use of specific HTTP headers, would be desirable for interoperability purposes.

Use case

The work concerning the implementation of GeoDCAT-AP included the development of an API, able to transform on the fly ISO 19139 records (ISO 19139 [ISO-19139] defines the standard XML-based implementation of ISO 19115).

The GeoDCAT-AP API [GeoDCAT-API] is able to return records both in the DCAT-AP and GeoDCAT-AP profiles. The former is meant to be used for harvesting purposes by catalogues only supporting the basic DCAT-AP profile, whereas the latter can be used when a catalogue is supporting also the additional metadata elements defined in GeoDCAT-AP.

More precisely, the API has been designed to re-use the standard query interface of geospatial catalogue services (i.e., CSWs [CSW]), which already supports the possibility of specifying the output metadata profile and format. The output format can also be omitted: in such a case, the GeoDCAT-AP API determines it based on HTTP content negotiation. This is however not the case for the output metadata profile, since there is currently no HTTP-based mechanism for specifying this type of requests. So, the default output metadata profile is determined by the API settings.

The approach currently used in the GeoDCAT-AP API to address this issue is to return metadata records along with a set of HTTP Link headers [HTTP-LINK] specifying:

• The URL of the source ISO 19139 record.
• The metadata profile of the returned record.
• The URLs of the alternative RDF serialisations of the returned record.

A possibility is to modify the last set of Link headers to include also the URLs of the alternative profiles of the returned record. In this scenario, getting access to the preferred metadata profile and serialisation would require retrieving all the different alternative representations until the relevant one is found.

Problem statement

Geospatial data catalogues offer effective discovery functionalities for specialists. However, as in most data portals, using basic free text search is usually far from being a satisfactory experience. Actually, users (both non-experts and specialists), when searching for data, are frequently making use of popular search engines as a first step to get to the data they are looking for. The same can be said for any other domain-specific and general-purpose data catalogue.

Improving free text search in data catalogues is unlikely to address this issue. Moreover, it would not help users who do not know in which catalogue(s) the relevant data are available. Users will keep on using in any case search engines for this purpose.

An option would be optimising data catalogues for Web discovery, by implementing consistently SEO (Search Engine Optimisation) techniques. The advantages include (but are not limited to) the following:

• Increase data visibility - as well as of the catalogues giving access to them.
• Enabling users to find the data better satisfying their requirements (in terms of spatial and temporal coverage, granularity, formats, access and licensing conditions, etc.).
• (For geospatial metadata) Enabling queries not limited to free text fields (e.g., dataset title and description), but concerning also coordinates, spatial / temporal resolution, etc.

Use case

The output formats supported by the GeoDCAT-AP API [GeoDCAT-API] include all the existing RDF serialisations, including HTML+RDFa.

HTML+RDFa [HTML-RDFa] is W3C standard defining a mechanism to embed structured metadata in HTML documents. HTML+RDFa is actually one of the mechanisms used by search engines to index Web pages.

The GeoDCAT-AP API is not the only tool addressing this issue. For example, this is the case of one of the prototypes developed in the framework of the Geonovum testbed [GNTB], where an extension to the GeoNetwork platform [GN] has been developed, able to transform ISO 19139 records into HTML+RDFa.

Additional work in this direction concerns the use of the Schema.org vocabulary to annotate Web pages via HTML+RDFa, or other mechanisms - as Microformats [Microformats], Microdata [Microdata] and HTML-embedded JSON-LD [JSON-LD] - see Section 6.20.

Schema.org is an initiative backed up by companies running popular search engines (Google, Microsoft, Yahoo and Yandex) to develop a general-purpose vocabulary for the annotation of Web pages. As such, its scope is not limited to data, but it includes also domains as e-commerce, businesses, audio-visual content.

Some work has been carried out to define mappings for DCAT-AP [DCAT-AP-Schema], whereas the Geonovum testbed mentioned earlier defined mappings for ISO 19115. In both cases, a number of gaps have been identified, making Schema.org not able to provide a full mapping of DCAT-AP and ISO 19115. Such gaps do not concern only domain-specific metadata elements (e.g., spatial resolution, coordinate reference system), but also more general requirements, as the modelling of identifiers and terms from taxonomies, thesauri, classification systems.

On this topic, it is worth noting that Google recently started a project, titled Science Datasets, aiming to investigate how to improve the description and discovery of scientific datasets by using Schema.org. On the other hand, the mapping exercises mentioned above raise also the question on whether a full mapping is really needed, given that the mapped vocabularies address different use cases.

Problem statement

This is a domain-independent issue, but a key one for geospatial metadata.

In the geospatial domain, data are typically made accessible via services (e.g., a view or download service), that, to be used, require specific clients. In metadata, the link to such services is usually pointing to an XML document describing the service's "capabilities". This of course puzzles non-expert users, who expect instead to get the actual "data".

Moreover, an additional issue is that a service may provide access to more than one dataset. As a consequence, users do not know how to get access to the subset of relevant data accessible via a service.

Some catalogue platforms (as GeoNetwork [GN] and, to some extent, CKAN [CKAN]) are able to make this transparent for some services (typically, view services), but not for all. It would therefore be desirable to agree on a cross-domain and cross-platform approach to deal with this issue.

Use case

In the framework of the DCAT-AP implementation guidelines [DCAT-AP-IG], a proposal has been developed to describe a service/API by using an OpenSearch document [OpenSearch] - see issue DT2: Service-based data access on JoinUp.

This approach has the advantage of adopting a general-purpose solution (applicable also to non-geo services), that could be used by catalogues as well as Web applications to make data access more transparent to users, or at least to provide some guidance on how to use the service. Moreover, the same approach would enable machine-based data access.

Problem statement

Here, the notion of "data quality" is used in its broadest sense, including:

• Fit-for-purpose.
• Data precision / accuracy.
• Compliance with given quality benchmarks, standards, specifications.
• Quality assessments based on data review / users' feedback.

There is of course no single solution to address all this, so, the following use cases focus on some practical issues identified during the development of DCAT-AP and its domain-specific extensions - namely, GeoDCAT-AP (for geospatial metadata) and StatDCAT-AP (for statistical metadata) [StatDCAT-AP].

Use case

Currently, the DCAT-AP family of metadata profiles cover the following aspect of data quality:

• Metadata conformance with a metadata standard (DCAT-AP).
• Data conformance with a given data schema/model (DCAT-AP).
• Data conformance with a given reference system (spatial or temporal) (GeoDCAT-AP).
• Data conformance with a given quality specification / benchmark (GeoDCAT-AP).
• Associating data with a quality report (StatDCAT-AP).

The first four ones are modelled by using dct:conformsTo, whereas the last one makes use of the W3C Data Quality Vocabulary (DQV) [DQV]. Moreover, GeoDCAT-AP provides an alternative and extended way of expressing "conformance" by using the W3C PROV Ontology [PROV], allowing the specification of additional information about conformance tests (when this has been carried out, by whom, etc.).

An example of the GeoDCAT-AP PROV-based representation of conformance is provided by the following code snippet:

a:Dataset a dcat:Dataset ;
  prov:wasUsedBy a:TestingActivity .
  
a:TestingActivity a prov:Activity ;
  prov:generated a:TestResult ;
  prov:qualifiedAssociation [ a prov:Association ;
# Here you can specify which is the agent who did the test, when, etc.
    prov:hadPlan a:ConformanceTest ] .
      
# Conformance test result
a:TestResult a prov:Entity ;
  dct:type <http://inspire.ec.europa.eu/metadata-codelist/DegreeOfConformity/conformant> .

a:ConformanceTest a prov:Plan ;
# Here you can specify additional information on the test
  prov:wasDerivedFrom <http://data.europa.eu/eli/reg/2014/1312/oj> .

# Reference standard / specification
<http://data.europa.eu/eli/reg/2014/1312/oj> a prov:Entity, dct:Standard ;
  dct:title "Commission Regulation (EU) No 1089/2010 of 23 November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial data sets and services"@en
  dct:issued "2010-11-23"^^xsd:date .

There are however some aspects of data quality not yet addressed. As far as GeoDCAT-AP is concerned, these include the following ones:

• Spatial resolution.
• Data quality assessments expressed with quantitative test results.

Finally, another potentially relevant use case is related to exploiting users' feedback to assess data quality. This may include feedback from data consumers (e.g., reporting errors in a dataset), as well as data peer reviewing.

This information need not be part of dataset metadata, and it can be collected and stored separately. Requirements include contextual information (who's providing feedback, when, etc.), that can be used to aggregate feedback data according to given criteria.

To address such gaps, the possible use of DQV and of the W3C Dataset Usage Vocabulary (DUV) [DUV] is being considered. In particular:

• The DQV specification includes a number of examples describing how to model spatial resolution - see Section 6.13. Notably, such an approach can also be used to model also "temporal resolution", and, more in general, the notion of "data granularity".
• DQV also provides a means to express quantitative quality assessments - see Section 6.1.

When used in conjunction with DQV, DUV allows the representation of annotations about data quality, carrying also provenance information.