Re: [dxwg] specification of range restrictions (#1129)

Hi @bertvannuffelen, 
Thanks for your comments and our apologies for this late reply. We discussed this issue during last week's [DCAT submeeting]( 
 I am going to report the main points of the discussion below after your questions.

> Q1: Is there another Machine readible document, like shacl, that expresses then the restriction?

No, there isn't,  and we are not considering having it, at least for the moment. 
We provide the  DCAT RDF to ease the DCAT adoption, but the HTML document is the actual DCAT recommendation, which is the only expected to say what is recommended or not in the W3C  Standardization Process. 

> Also, not all language definitions in mention this restriction.

 We did our best to maintain the translations updated in the DCAT 2 RDF. However, keeping the translations updated requires revising in different languages every time a piece of definition changes, forcing complex interactions among translators. Also, the translators are volunteers not always available in the timeframes we need. 

Due to these difficulties,  we have agreed on a new policy for the translations in DCAT 3. The current deal is to maintain the English definitions while specifying DCAT 3 and ask for translations on the best-effort basis once we get a stable document at the CR phase (see issue #1352).

> Q2: Is there a policy here? what is part of the definition and what not.

The following excerpt is taken from the [section conformance]( and gives the policy to interpret the DCAT document.
"As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, and SHOULD in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here."

> For me the definition of the property is without the restriction. The restriction is an additional contraint. Using another controlled vocabulary does not change the meaning/semantics of the property.

In the specific case, we use   “SHOULD” explicitly referring to the RFC 2119 in a normative section, which implies that using this property with IANA mediaType is recommended unless there is a valid reason to ignore the indication. 

Using all the same code list improves interoperability, so I think here the suggestion is to use IANA for media type. Different courses are possible according to DCAT 2, but the full implications must be understood and carefully weighed before choosing a different course.

Do the above comments clarify your doubts? in this case, can we close this GitHub Issue, or do you think further related aspects need to be considered? 


GitHub Notification of comment by riccardoAlbertoni
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Monday, 19 April 2021 18:19:00 UTC