Interoperable Europe logo

Specification BRegDCAT-AP v.1.02

BRegDCAT-AP v.1.02

ABR Project Team
Published on: 22/04/2020 Last update: 04/05/2020 Document

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).

Categorisation

Type of document
Document

Attachment

breg-dcat-uml_1.02.png
SC380_D02.01_Final Specification of the BRegDCAT-AP_v1.02.docx
SC380_D02.01_Final Specification of the BRegDCAT-AP_v1.02.pdf
Report abusive content Share

Comments

Sebastian SKLARSS Thu, 04/06/2020 - 18:43

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?".

First:

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

  1. two registers or
  2. an applicant and data from a register in a another Member State than the application or egovernment service requests

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:

  1. What is the correct register to get this data / credential / file from?
  2. Is there a credential X in Member State II that fits to the need of the trans-national SDG conform use case? the need for describing availability and types of digital credentials / data / files hosted in a register
  3. Is there other data beside a credential X in Member State II that fits to the need of the trans-national SDG conform use case? -> the need for describing data entities hosted in a register and the flag whether this data is authoritive (this seems to be covered by BRegDCAT-AP)
  4. What are the legal, organisational, semantical and technical and operational restrictions to get this data from the MS II Register?
    1. Legal constraints:
      1. Which legal basis are used to do this trans-national register request?
      2. Which reasons are needed and have to be indicated to submit a request to the register?
        -> the need for a controlled vocabulary or concept focused on “reasons for requests”
      3. which file ID (Aktenzeichen) is the basis of this request
      4. personal data of the person (administrative steward) in the Member State I doing the request into Member State II register (to detect illegal “googleing” in foreign registers)
        -> 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? )
    2. organisational constraints
      1. GDPR-based thoughts: How to understand and respect the consent given of the citizen in Member State II to use his data by another MS register for a given time?
        -> the need for standard / concept for consensus management 
    3. Operational restrictions
      1. How to navigate to the register / How to access the base register via which concrete parameters? (might be already covered by BRegDCAT-AP 1.0.2 using DCAT-AP2.0 data service parameters)
      2. What is the concrete availability of the register? -> the need for standard / concept for expressing "availability" (this cannot be covered by the dcatap:availability)
      3. Whom to contact and how and when (-> how to express different contact points and contact means of the register
        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
        1. in case of technical problems?
        2. in case of data based problems?
        3. In case of GDPR concerns?
      4. What are the mandatory fields for what request into the register? (-> the need to define not only structure of a request but also what mandatory information has to be present in the request)
      5. What are the different ways the answer of the register request will look like? (-> the need to describe what result returning mechanism are such as “paging”)
        1. E.g. Results will be fetched using paging (50 results per request)
        2. One or no result will be given
        3. The information is given that narrower information has to be provided to get the final 1-10 results

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?

Sebastian SKLARSS Fri, 05/06/2020 - 09:54

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

This property indicates the status of the latest revision of a Dataset's entry in the Catalogue (i.e., created, deleted or updated)

there is no value "updated", "deleted" or "created" in the adms namespace:

http://purl.org/adms/status/

refers to "Completed", "Deprecated", "Under Development", "Withdrawn"

 

Shared on

Last update: 26/05/2021

Access to Base Registries

Open Source SoftwareStandardisation+2 topics
100
Collection
Login or create an account to comment.