Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define and apply rules for definitions in DCAT #301

Closed
makxdekkers opened this issue Jul 13, 2018 · 4 comments

Comments

Projects
None yet
4 participants
@makxdekkers
Copy link
Contributor

commented Jul 13, 2018

I would like to propose that we define and apply consistent rules for definitions in DCAT.
Some issues I have encountered (looking at the 11 July 2018 draft at https://w3c.github.io/dxwg/dcat/):

  1. Some definitions are circular in the sense that they use the same word in the label and definition. There are cases where there is no chance for people to misunderstand – e.g. the definition of dcat:mediaType: “media type .. as defined by IANA” is probably OK, but dcat:service as “A service …” is maybe not so useful. Compare the definition of dcat:DataService (“A service …”) with dcat:DataDistributionService (“A site or end-point … “). The latter is less circular.
    My suggestion is to avoid circularity where it can be avoided. Less circularity may also help translators.

  2. Some definitions from external vocabularies do not use the same definition as in the source specification, e.g. dct:license.
    There I would suggest that the DCAT specification reuse the original definition in the Definition field and add the specifics for use in DCAT in a Usage note.

  3. Some definitions of properties use a template “A some characteristic (further clarification)” that states what the object of the property is (e.g. dcat:dataset, dcat:mediaType); others state that it is a link to something (e.g. dcat:catalog) or even a link to a description of something (e.g. dcat:servesDataset). Furthermore, the property dcat:distribution does not say what it is but what it does “Connect a dataset …” A minor note on the use of “The ..” in the definition: this seems to indicate that a dcat:Catalog can have only one homepage and use only one KOS for classification, which I think is not necessarily true.
    My suggestion on this point is to standardise on the template “A some characteristic (further clarification)”.

  4. I would also suggest that properties that have a URL (Literal) as object should make that explicit, e.g. dcat:downloadURL: “The URL of the downloadable file in an given format”.

I think it would be useful to enhance the consistency of the specification before publication of the next Public Working Draft.

@davebrowning

This comment has been minimized.

Copy link
Contributor

commented Aug 21, 2018

These all look like good ideas. I'm happy to work this through into the document under my current editorial sweep (in fact, I've already started)

@dr-shorthair

This comment has been minimized.

Copy link
Contributor

commented Aug 21, 2018

And in particular, we need to ensure that the text in the recommendation document matches the text in the RDF representation.

And per #174 there will need to be a subsequent sweep to align the non-English translations.

@davebrowning

This comment has been minimized.

Copy link
Contributor

commented Sep 4, 2018

PR #332 (now merged) has aligned the document text with the above rules (E&OE). RDF (en) presentation pending.

@davebrowning

This comment has been minimized.

Copy link
Contributor

commented Sep 5, 2018

PR #335 (now merged) brings the dcat.ttl file into line wioth document. Will close this issue, though not that the rules for definitions above remain valid and we should make sure that changes continue to follow them where appropriate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.