Re: [dxwg] Suggestion to add dct:format and dcat:mediaType to dcat:DataService (#1381)


the challenge I see with the proposal is that I am not sure that it will address your catalog users request. Are they really searching for data services that provide data as "application/atom+xml" but not as "application/xml"? 

It seems natural to include more technical details from data services into a meta data description, but this has its drawbacks. 
I am more inclined to train teams to improve the natural documentation of the services, rather that a generic catalogue would provide means for that.  In the end the technical documentation has to be read by the developer in order to work with the service. For me format information is part of the technical documentation of a service. Training the maintainers/developers of services to build services according to common technical guidelines including e.g. providing content negotiation with support for xml and json with a fixed mediatype is probably more valuable and sustainable.  

To illustrate the topic: see for instance the formats in
There are 4 equivalent formats for a user listed: Excel XLS, Excel XLSX, xlsx, .xlsx 
Without additional constraints and agreements on the teams to support the _same mediatypes_ your catalogue will show this kind of things, and then it becomes less valuable.  And then the next step you will consider as catalogue is start to do mappings from every IANA media type to one of the supported ones in your portal. But that has as consequence that catalogue users will face the situation that although 2 services claim to use XML, they use different media types. 
This experience learns me that it is not because we can record it, it automatically leads to usable data. 

Although I can understand your request, I am reluctant to include it as a specific properties for data services. I would rather for this case first apply it in an profile and see how it turns out, before adopting it in DCAT at this level.  

This request is for me connected with the conformsTo discussion. I think that is a more valuable discussion. As the format is actually a consequence of that value. If the dataservice conforms to the Norwegian REST API guidelines I know as developer a lot more than the format. I know that it will handle errors in a certain way, which headers are supported, etc. Example of such guideline are here: 

Illustrating the above with the first example:
_:s1 a dcat:DataService;
      dct:format "application/atom+xml"
      dct:format "application/xml"

_:s2 a dcat:Dataservice:
      dct:conformsTo ""
For me the second dataservice description is more informative than the first.  The first is reflecting one detail aspect of the second. As such this is for me the core of my reluctance: with the format property proposal the effort in the catalog metadata is towards a derived information rather than recording the source of the decision. 
@jimjyang did you explored the dct:conformsTo possibility?

Another source of reluctance is that we should not try to transfer all properties of DCAT1.0 Distribution to DCAT2.0 DataServices. If we do that then the distinction between both entities becomes more blurry. The fact that a DataService does not have a format in the core DCAT and Distribution has, is maybe an good aid to distinguishing them.  

I would rather avoid lifting all the technical aspects of data services to the core DCAT and leave that to profiles.  



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

Sent via github-notify-ml as configured in

Received on Friday, 2 July 2021 08:56:20 UTC