>> and share your comments in the dedicated section below under 'Create comment'

Regarding the current use of British English(BE) and American English (AE) in the diagram and in the Specification V0.03:

I see "Registry Catalogue" (BE), organization (AE)  in the diagram 

and "driver licenses" (AE) and "licences" (BE)  used both non normative in the text of the specification V0.03.
 

Can you please inform us on the English-Policy intended for BReg-DCAT-AP now that we are in BREXIT-times?

(This reminds me on former discussions on interoperability concerns of ISA² specification dcat-ap here at Joinup:

https://joinup.ec.europa.eu/discussion/naming-issue-catalogue-vs-catalog )

Thank you for this comment. Good point.

Since this document is an early draft to have a minimum base for discussion during the webinar, it is incomplete and it has some inconsistencies. This specification will follow the same approach as the previous DCAT-AP specifications did. This document will use British spelling (i.e., 'catalogue' and 'licence' for the noun; 'license' for the verb). There are some exceptions like Identifiers (URIs) from W3C specifications that will use American English spelling. Those inconsistencies will be corrected in the next version of the document.  

As mentioned during the webinar, we are working on a model in Belgium (federal level, regional level probably has another model) for "authentic sources"

Draft SHACL can be found here: https://vocab.belgif.be/shacl/authsrc.ttl

Two major differences:

• description of the separate data elements that are part of a data set (like a field or property that says "email", "person name"... but not down to the datatype or length... just a description)
• a property "isAuthoritative" to indicate that a data element or data set is _the_ official base registry source (a base registry can be a mix of authoritative and non-authoritative elements, e.g. a company base registry may also contain addresses because the official address registry is not yet in production)

This is mainly for future use, e.g. when linked to / reused by GDPR or other applications (because it is assumed that e.g. corrections requested by a citizen under GDPR should probably be made in the authentic source)

Thanks, Bart. 

Very useful feedback. I see this as an interesting approach to model the type of data contained by the registries. Let me wrap up some pieces that could be of interest in the work of this specification.

1. Data Source (~Dataset) ->[has]-> Data Element(s)
2. isAuthoritative is a flag that must be specified for both DataSource and DataElement.
3. I see that dcat:theme for DataSource (subClassOf dcat:Dataset) uses a taxonomy of twelve top-level themes, that are already aligned with http://publications.europa.eu/resource/authority/data-theme. 
4. DataElements are "the pieces" contained by DataSources (e.g., locations, organisations, people, etc.), and the theme of these elements is defined by the dcterms:type and a SKOS classification [http://vocab.belgif.be/auth/authsrc-element]
5. There are roles associated with data sources: consumers, providers, initiators, and responsible. I presume all of them are "Agents".

I thing it is important to have a common taxonomy of data themes (point 4, above -> type of data elements). Do you plan to continue with this scheme of concepts? 

Regarding roles of agents related to data sources: An Initiator is a delegated (authorised) entity in charge of the management of the data in a registry? 

Just a minor comment: I noted some inconsistencies in the documentation (https://vocab.belgif.be/ns/authsrc): ranges of hasConsumer, hasProvider… But the SHACL rules are right.

Thanks again for your feedback.