Use Case: Profiles of DCAT-AP and various implementation resources #238
Description
Profiles of DCAT-AP and various implementation resource
Development and governance of localised DCAT Application Profiles
Status: proposed
Identifier:
Creator: Rob Atkinson (Please Andrea and Makx check details)
Deliverable(s): (DCAT1.1, AP Guidelines)
Tags
Profiles, Semantics
Stakeholders
Publishers and users of implementing profiles of DCAT. (This use case is evidence for a wider scope of any cases where the finer grained semantics of catalogues resources needs to address interoperability concerns.)
Problem statement
As evidenced by DCAT-AP and GeoDCAT, profiles of DCAT may be declared and then specialised by communities of practice or local jurisdictions. GeoDCAT-AP is thus a profile of both DCAT-AP and GeoDCAT, DCAT-AP-IT is an Italian profile of DCAT-AP.
Profiles may be supported by multiple resources, with different roles. DCAT-AP for example provides documents in multiple formats, SHACL validations for multiple versions of SHACL, spreadsheet templates and other types of implementation resources.
The DCAT-AP example also illustrates the practical need to describe relationships between different versions of the profile, and for each of these a unique set of implementation resources.
[link to Makx's presentation at F2F here]
Existing approaches
Current use of DCAT-AP is a clear example of the need for this pattern in practice. https://joinup.ec.europa.eu/release/dcat-ap-v11 shows this registered in a catalogue (as a sort of Dataset - which suggests generalisation of DCAT scope) along with a set of implementations resources (described as "distributions").
Links
Requirements
6.2.1 Version subject [RVSS]
6.2.3 Version identifier [RVSID]
6.8.1 Profile definition [RPFDF]
6.8.2 Profile representation [RPFRP]
Related use cases
5.3 Responses can conform to multiple, modular profiles [ID3]
5.4 Dataset Versioning Information [ID4]
5.7 Support associating fine-grained semantics for datasets and resources within a dataset [ID7]
5.20 Modelling resources different from datasets [ID20]
5.24 Harmonising INSPIRE-obligations and DCAT-distribution [ID24]
5.30 Standard APIs for metadata profile negotiation [ID30]
5.39 DCAT Metadata profile integration [ID39]
5.41 Vocabulary constraints [ID41]
Comments
The nature of profile inheritance and attached resources are implications of this Use Case that were previously inferred from the context in which, for example, the DCAT-AP example was raised, i.e. in more specific Use Cases about single aspects of DCAT expressivity. A comment was made that without a grounding in typical technical solution patterns it was insufficiently clear that these overarching governance and usage experiences directly drove the inferred requirements.