Re: [dxwg] Drop the range of dcat:keyword (#1585)

I support the reaction from @jakubklimek. In this case the usage situation is clear and clean, and not restrictive.

In short:
- When there is need to associate a term, not controlled by any list and in some language, and it is not the intend to add additional metadata about that term to a Dataset, then I want to express it as a literal. Hence, I use dcat:keyword.
- When there is a need for additional control on the term, e.g. legally certified translations or an agreement by a group, then I use a controlled vocabulary.   Hence, I want skos:Concepts (or similar) and not a literal. Hence I use a subproperty of dct:subject.

In the last case, dcat:theme is a special subproperty: namely the theme to which the Dataset is associated in the Catalogue. In this special case there is hopefully also not the discussion whether that could be a Literal. And note that for one profile the theme of another profile can be considered another categorisation. 

So instead calling this a bad practice, in this case the range Literal versus Concept is corresponding to a business need. Both nicely address two distinct levels of harmonisation in the area of associating term to datasets to make them easiers findable in a catalogue by freetext search or facetted browsing.

By mixing, as illustrated by Jakub, DCAT states that the implementations must accept and being able to process both at the same time. It will create more implementation friction than gain. Lifting the distinction between data property and object property must be done care. And in this case it will not create added value, but more confusion. 

Maybe you stumble over that the subproperty of dct:subject is not named 'keyword' when you use it in an implementation just as a keyword: that is a different discussion.   


-- 
GitHub Notification of comment by bertvannuffelen
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1585#issuecomment-1933541526 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 8 February 2024 08:02:05 UTC