Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Use Case: Profiles of DCAT-AP and various implementation resources #238
Profiles of DCAT-AP and various implementation resource
Development and governance of localised DCAT Application Profiles
Creator: Rob Atkinson (Please Andrea and Makx check details)
Deliverable(s): (DCAT1.1, AP Guidelines)
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.)
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.
[link to Makx's presentation at F2F here]
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").
6.2.1 Version subject [RVSS]
Related use cases
5.3 Responses can conform to multiple, modular profiles [ID3]
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.
@agbeltran This requirement is already present : "Profiles may inherit clauses from one or more parent profiles" Perhaps is ought to be written as "Profiles may add to or specialise clauses from one or more base specifications. Such profiles inherit all the constraints from base specifications."
This requirement is consistent across all the profiling experience but has been left out of the current discussion centered around the https://docs.google.com/document/d/13hV2tJ6Kg2Hfe7e1BowY5QfCIweH9GxSCFQV1aWtOPg/edit#heading=h.5l26dadqk5v7
If this is to be based on the information that Makx included in his presentation at F2F3, then it should include the community and maintenance management that he outlines in slides 5-9. That is missing from our requirements. Also, nothing about DCAT-AP as he describes it refers to inheritance. As you may recall, at the May 22 meeting we agreed that we would not use the term "inheritance" but would speak of relationships or dependencies between profiles. I think we need to adhere to that, here and elsewhere.
The Use Case also includes other communities further profiling DCAT-AP I dont think we need to add the governance procedures ... perhaps thats a separate Use Case if we think it introduces additional requirements.…
On Fri, 31 Aug 2018, 11:28 kcoyle ***@***.***> wrote: This use case was APPROVED at the plenary meeting of August 28, 2018 <https://www.w3.org/2018/08/28-dxwg-minutes#ResolutionSummary>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#238 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIR3YVCqR7Bp2t2WbqTwSIjzOvwFG8IOks5uWJFCgaJpZM4UD6Of> .