Skip to content

Design Patterns & Decisions of DCAT-AP+

DCAT-AP is currently limited regarding the ability to provide domain-specific and ontology aligned metadata on what a dataset is actually about or on the process used to create it. For specifying the subject of a dataset, there are only the properties: dcterms:description, dcterms:keyword and dcat:theme, and for specifying its creation context there is the property prov:wasGeneratedBy that expects an instance of the prov:Activity class. The former three have the limitation of either expecting only free text, or, in the case of theme, only a very small but too general controlled vocabulary. The limitation of the latter lies in the fact that the Activity class is only considered a "Supportive Entity" and thus not further specified with any properties.

DCAT-AP+ addresses this gap, by mainly reusing the Starting Point Terms of the Provenance Ontology (PROV-O), but also the QUDT ontology and the DCTerms vocabulary, as depicted in the following UML class diagram (taken from the forthcoming MTSR2025 paper) and the graphical representation of the DCAT-AP+ base pattern. DCAT-AP-PLUS UML-diagramm DCAT-AP-PLUS UML-diagramm DCAT-AP-PLUS_base_pattern_dark.svg DCAT-AP-PLUS_base_pattern_light.svg

Lifting PROV-O's Activity to a first class citizen

We added PROV-O aligned slots (e.g., had_input_entity, had_input_activity, ...) to the Activity class that allow one to further specify the input and output of an activity as well as its parts. To provide the proper ranges for these new slots, we also added the classes Entity and AgenticEntity based on PROV-O's Entity and Agent class. The renaming of the latter was made due to the fact that DCAT-AP already reuses the foaf:Agent class to refer to people or organisations somehow responsible for the provenance of a dataset. While the AgenticEntity class could be used similarly to foaf:Agnet to specify people or organisations responsible for an activity taking place, this class is rather intended to be used for specifying the tools used in activities.

Dedicated classes for the data generation context

Since DCAT-AP+ focuses particularly on the kind of activity that created a dataset (e.g., a certain spectroscopy), we defined a subclass of Activity, called DataGeneratingActivity and used it instead as the range of the was_generated_by property. This class it is related to the additional classes EvaluatedEntity and EvaluatedActivity with slots that are specializations of the ones inherited from its parent class. These two new classes represent the entity or process that was being evaluated by a DataGeneratingActivity, so what the resulting dataset is actually about. Consequently, these two classes were also related directly to the Dataset class via the is_about_entity and is_about_activity slots.

To be able to represent uses cases in which a dataset was generated by a DataGeneratingActivity that is actually an analysis of previously generated data, we also added the subclasses DataAnalysis, AnalysisDataset and AnalysisSourceData.

Providing additional characteristics

To allow describing instances of the newly introduced classes with additional qualitative or quantitative attributes in a very generic manner, we also introduced the QuantitativeAttribute class (aligned with qudt:Quantity) and the QualititativeAttribute class (aligned with prov:Entity).

Classification via domain-specific controlled vocabularies and ontologies

With the ClassifierMixin, we provide two properties for semantic annotation to all DCAT-AP+ core classes:

  • rdf_type: Mapped to the RDF property rdf:type, this allows an instance to be additionally typed with a class from an external ontology (e.g., classifying a DataGeneratingActivity instance with CHMO:0000595 for a ¹³C NMR measurement). An approach endorsed by the DCAT-AP developers [31]
  • type: Mapped to dcterms:type, this allows for classification using a term from SKOS vocabularies or other controlled term sets without making such a strong ontological commitment as with rdf_type.

On the naming and ontological alignment of DCAT-AP+ classes and slots

The classes and slots defined within this LinkML model are not to be confused with the ontological classes and properties to which they are aligned. DCAT-AP+ is, just like DCAT-AP, an application profile (aka graph shape) that specifies how certain ontologies and vocabularies are to be used/instantiated. So our DCAT-AP+ LinkML classes and slots are to be interpreted just like SHACL node and property shapes. As such it is allowed to have different classes (aka node shapes) or slots (aka property shapes) aligned to the same ontological term.