Version 1.02 of the BRegDCAT-AP specification.
This version is the evolution of the 1.01 (aligned with SGD/TOOP), and including the feedback by Mr. Jianhua Yang. The main changes are related to the compatibility with DCAT-AP-2:
Class Media type or extent (dct:MediaTypeOrExtent) is now changed to Media type (dct:MediaType)
Changed cardinality of accessURL (Domain Distribution) to [1..n]
Alignment of UML diagram with the specification. All the classes now included, but not all linked to simplify readability.
Corrected the usage note of the dimension (qb:dimension) adding some examples.
Names of classes described in the controlled vocabularies now are normalised according to the rest of the specification.
The controlled vocabularies section now includes a more concrete text to express they are required.
Multiple cardinalities in optional properties in CatalogRecord.
The cardinality of qb:componentRequired is [0..1] now.
dcat:Dataset has two different identifiers (the main one: dcterms:identifier, and another identifier: adms:identifier) to be compatible with both and DCAT-AP and CPSV-AP.
The cardinality of dcat:compressFormat (domain Distribution) is [0..1].
dct:identifier [0..n] of LegalResource is now recommended, and the dct:relation with other resources is optional.
A Rule could be of multiple types (dct:type) [0..n].
Added a clarification text for the Registry Catalogue represented as a dcat:Catalog, but it is also considered a cv:Output. A footnote with more information was added to avoid confusion: "An instance of Registry Catalogue is considered to be also a cv:Output since it is the range of the property cpsv:produces." It is not mandatory to describe a catalogue as cv:Output explicitly (it is inferred since is the range of the property).
The following ticket is regarding the question raised in April 2020 Webinar about "completeness of the current BRegDCAT-AP model regarding the use cases aimed?".
I understood that BRegDCAT-AP tries to describe the data and its structure in base registers in order to prepare for a central backbone of information about registers.
This backbone will be called Registry of Base Registers and will helps to realise SDG and GDPR eIDAS driven once only use cases in the form of bilateral data exchange between two parties (public servants, end users and or registers) in two Member States.
Please let me challenge the question of completeness of the current spec with the following concepts in bold that to my understanding are needed in a transnational federated register environement:
For the real operational transnational data exchange purpose between
Far more information seems needed than currently foreseen in the current BRegDCAT-AP specification:
Typical questions that may arise at runtime (! not at design time) of a register component in Member State 1 requiring "SDG-alike once only" information from another Member States register 2:
-> the need for a controlled vocabulary or concept focused on “reasons for requests”
-> the need for a concept for identity of an administrative agent / organisation doing a request” (are the given dcat-ap properties (vcard and foaf:agent)sufficient for tracing who did the query? )
-> the need for standard / concept for consensus management
I understand that these roles would have to be defined in a controlled vocabulary to be used in dcat:hadRole (https://www.w3.org/TR/vocab-dcat-2/#qualified-relationship ).
Will BRegDCAT-AP provide a controlled vocabulary for the different roles of contact points of a register or will we use only "contact point?" Roles that do exist are contact points
A more detailed gap analysis can and might follow from our side.
Is there a place where all the requirements that BReg-DCAT-AP.de tries to cover are documented?
The chapter on adms:status on page 21needs still to be aligned with DCAT-AP 2.0.0 :
While BRegDCAT-AP states regarding adms:status
there is no value "updated", "deleted" or "created" in the adms namespace:
refers to "Completed", "Deprecated", "Under Development", "Withdrawn"