Skip to content

Cataloguing data services

Jump to bottom
Simon Cox edited this page May 16, 2018 · 28 revisions

This page is for proposals related to the cataloguing data services milestone.

Two of the listed use-cases relate to the description of data services:

Early drafts of DCAT v1 had WebService, Download and Feed as subclasses of dcat:Distribution, but they are marked "deprecated" in the published vocabulary. In the current core DCAT model dcat:Distribution is a second-class resource, and individuals are often implemented as RDF blank-nodes because a Distribution is not expected to be accessed or described separately from the dcat:Dataset that it represents. GeoDCAT-AP uses dctype:Service for WMS, WFS, WCS (etc) services in the catalog.

Alternative views

There are a number of alternative breakdowns, abstractions, and subclass hierarchies. Depending on your point of view these might simplify or complicate the construction of DCAT catalogues. In order to support the discussion some of the options are shown in the diagram below.

Some options for cataloguing services and other things

Chosen solution

In the 2018-04-25 meeting of the DCAT sub-group it was resolved to adopt a combination of options E and F. This offers both backward compatibility and scalability going forward. The following figure attempts to summarize this:

Chosen solution for cataloguing services and other things

Note the following:

  • the DCAT 2014 backbone is shown in bold
  • new class- and property- names are only indicative and might change
  • the set of sub-classes of DataService is not complete
  • the catalog-membership predicates (in blue) are all sub-properties of dct:hasPart
    • dcat:dataset is a sub-property of dct:hasPart in DCAT 2014 already
  • natural extensibility points are shown in green

The sub-classes of DataService might be constructed using a dct:type property rather than by formal sub-classing. Type vocabularies such as the INSPIRE Spatial data service type vocabulary are available for this.

Simon's revised proposal

  • three/five new classes
    1. dcat:CataloguedItem - the super-class for all members of a dcat:Catalog
    2. dcat:DataService - the class of all catalogued services
    3. dcat:DataDistributionService
    4. dcat:DataTransformationService (to be confirmed)
    5. dcat:DiscoveryService (to be confirmed)

DCAT core model with generic CataloguedItem and Services added

A dcat:DataService is expected to have a value for dcterms:type (inherited from dcat:CataloguedItem) and dcterms:conformsTo.

The value of dcterms:type should be taken from a classification (controlled vocabulary) of service-types (e.g. discovery, view, download, interpolation, coordinate-transformation). The service types shown here might have dcterms:type fixed to values from the INSPIRE Spatial data service type vocabulary. Individuals of the specialized service types might alternatively be implemented as individuals of the 'generic' dcat:Service, with the dcterms:type property bound to a value from a suitable service-type taxonomy.

dcterms:conformsTo should be used to indicate the service definition or standard (e.g. OGC WMS, WFS, SOS, WCS, SPARQL-query, OAI-ORE, ...)

  • five new properties
    1. dcat:service - property to link a catalog to a service description
    2. dcat:catalog - property to link a catalog to a member catalog
    3. dcat:servesDataset - property to link a dcat:DataDistributionService to a dcat:Dataset which it can serve
    4. dcat:accessService - property to link a dcat:Distribution to a dcat:DataDistributionService which can serve it
      • accessService specializes dcat:accessURL which had no range constraints
    5. dcat:hasDatasetPart - property to link a dcat:Dataset to another dcat:Dataset which is part of it

DCAT catalog-membership predicates

  • The catalog-membership predicates dcat:dataset, dcat:service and dcat:catalog are sub-properties of dcterms:hasPart and rdfs:member.

  • The links dcat:servesDataset and dcat:accessService still need discussing.

  • The predicates dcat:hasDatasetPart is a sub-property of dcterms:hasPart and supports relationships with components and sub-sets - still need discussing.

This enhanced DCAT model allows Datasets, DataServices, other Catalogs, or anything else to be cataloged explicitly, all considered to be sub-classes of dcat:CataloguedItem, and also for DataDistributionServices to clearly indicate the Datasets served.

Clone this wiki locally