The fifth release of the Specification of Registry of Registries as a stable draft (version 1.00).
This document has been updated after the release of the major release of DCAT-AP and the ABR WG meeting held in October 2019. It includes the proposed solutions to the open issues discussed during the meeting.
This model should be aligned with the future releases of DCAT and DCAT-AP, as well as with the rest of the Core Vocabularies. The vocabulary and model must be validated with existing implementations. Also, some other vocabularies such as VoID may be taken into account to describe datasets, it the current approach does not cover all the cases.
You will find a data model in XMI format as well in the attached 'zip' file. In order to use it, you need to extract the file.
Comments
There is an UML model in the document. Is it possible to get the model in re-usable format (XMI for example - https://www.omg.org/spec/XMI/)?
Dear Ott,
Thank you for your comment! We have uploaded the file in 'zip' format, since XMI format is not yet being supported by Joinup platform. You will see it under the documents. In order to use it, please extract the file.
We also warmly welcome you to join ABR Collection: https://joinup.ec.europa.eu/collection/access-base-registries/abr-catalogue-solutions-0, as well as our Specification page https://joinup.ec.europa.eu/solution/abr-specification-registry-registries, as this year we will be working on tuning the specification, and piloting it with some useful tools in a few MS. This might be interesting for you to follow, and participate in.
Kind regards,
ABR Team
Optional class Media type or extent (dct:MediaTypeOrExtent): Any reason why this is not aligned with DCAT-AP 2.0, Media type (dct:MediaType)?
Distribution - accessURL: Any reason why the cardinality (1..1) is not aligned with DCAT-AP v2.0.0 (1..n)?
Several properties that are in the UML-model in Fig. 2, are missing in Chap. 3 Application Profile Properties per Class. For example, dct:hasPart and dct:isPartOf for dcat:Dataset.
Chap. 2. Application Profile Classes, Mandatory Classes, Registry Catalogue: What does it mean to have two different URIs for the same class? Does it mean that one must (should/may) choose one of these URIs in an actual application of BRegDCAT-AP? E.g., a registry of datasets (dcat:Catalog) vs. a registry of data services (cv:Output)?
In addition, conf. page 38, under Registry (Catalogue): What does "Registry Catalogue is [...] considered as a cv:Output" mean?
Chap. 3 Application Profile Properties per Class, Component Specification, Optional properties for Component Specification, dimension (qb:componentRequired): The "Usage note" used there is (partly) for measure (qb:measure).
Chap. 4 Controlled Vocabulary, "Used in Class": Several class names used here are not exactly the same as defined elsewhere in the specification, e.g. "Catalogue" (instead of "Registry Catalogue") and "Registry Service" (instead of "Public Registry Service"). It is also more precise to quote the URIs to the classes (e.g. dcat:Catalog and cpsv:PublicService) instead of or in addition to the class names.
Chap. 4, Controlled Vocabularies, Controlled vocabularies to be used, "Usage note": In the context of a specification/requirement, what do "... will be used" and "... is used" mean? (while the text above the table says "The use of the following controlled vocabularies is mandatory to guarantee a minimum level of interoperability")
"Contact point": shouldn't we have same representation of contact point in this specification? Now it is vcard:Kind in Dataset (dcat:Dataset) from DCAT-AP, and schema:ContactPoint in Public Registry Service (cpsv:PublicService) from CPSV-AP.
Some mismatch between the UML-diagram and the textual descriptions of the properties, concerning "recommended"/"optional" and cardinality. Examples: eli:LegalResource and cpsv:Rule.
"Internal identifier": Several places in the specification, the identifiers are described as “internal”. Why and what does “internal” mean? For example, dct:identifier is described in the “Usage note” as an internal identifier for cpsv:Rule in BRegDCAT-AP, while CPSV-AP-2.2.1 does say “internal” at all.
dcat:downloadURL in dcat:Distribution: Any reason to set 0..1 here (while it is 0..n in DCAT-AP 2.0)?
dcat:Dataset, mandatory:
Dear Jim,
Thank you very much for your in-depth review. We have included all the comments you suggested in the specification. You can see the main changes in the announcement of version 1.02 of the document.
The only issues that we keep open are:
We hope we have more points of view regarding these open issues. Also, we look forward to testing this specification with your model and see if they are aligned properly.
Typo: Class Distribution and Legal Resources are mentioned twice under Chap. 2 Application Profile Classes, Recommended classes.