@NielsHoffmann ,
In DCAT-AP-NL dcat:DataService there are a number of mandatory properties, in addition to DCAT-AP required ones. Some of them, seem difficult to implement in practice when we are talking about APIs and similar services, and I do not see a strong need to include them. Hence I would like to suggest that some of then are relaxed on to recommended or optional properties.
I have a hunch that some of these mandatory properties will either discourage implementations of DCAT-AP-NL to describe DataService, or they will be incomplete (not fulfilling all required properties) .
From the following mandatory dcat:DataService properties, I am highlighting ones, which I consider to be candidates to become recommended/optional
- dct:accessRights (1..1)
- dcat:contactPoint (1..1)
- dct:description (1..n)
- dcat:endpointDescription (1..n)
- dcat:endpointURL (1..1)
- dct:identifier (1..1)
- dct:license (1..1)
- dct:publisher (1..1)
- dcat:theme (1..1)
In my view the dct:identifier is the most problematic and missleading. What exactly is an identifier for an API? I do not see this as necessary, dcat:endpointURL seems enough
dct:publisher makes a bit more sense to me, but still when we refer to APIs we rarely talk about the entity that maintains it as a publisher. Contact point seems enough there
dcat:theme are also a bit redundant when we have those same properties for the classes dcat:Dataset and dcat:Catalog. Essentially we will be saying that the data theme of a API is ie ECON/TECH when I doubt that is factually correct, for most use cases.
Let me know what you think
@NielsHoffmann ,
In DCAT-AP-NL dcat:DataService there are a number of mandatory properties, in addition to DCAT-AP required ones. Some of them, seem difficult to implement in practice when we are talking about APIs and similar services, and I do not see a strong need to include them. Hence I would like to suggest that some of then are relaxed on to recommended or optional properties.
I have a hunch that some of these mandatory properties will either discourage implementations of DCAT-AP-NL to describe DataService, or they will be incomplete (not fulfilling all required properties) .
From the following mandatory dcat:DataService properties, I am highlighting ones, which I consider to be candidates to become recommended/optional
In my view the dct:identifier is the most problematic and missleading. What exactly is an identifier for an API? I do not see this as necessary, dcat:endpointURL seems enough
dct:publisher makes a bit more sense to me, but still when we refer to APIs we rarely talk about the entity that maintains it as a publisher. Contact point seems enough there
dcat:theme are also a bit redundant when we have those same properties for the classes dcat:Dataset and dcat:Catalog. Essentially we will be saying that the data theme of a API is ie ECON/TECH when I doubt that is factually correct, for most use cases.
Let me know what you think