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

Thanks again for sharing your experiences/solutions, @bertvannuffelen! 

We do share your concerns, and we are also restrictive regarding introducing (national) extensions. We also share your point with improving natural documentations of the DataServices, which is another discussion (in general, about metadata quality of the resources that are listed in, and referred to from, a catalog). 

> Are they really searching for data services that provide data as "application/atom+xml" but not as "application/xml"?

Not necessarily while searching, but at least when evaluating _if_ a DataService that is to be found in the catalog, is reusable. A catalog (at least ours) supports its users in 1) searching for potentially reusable Datasets/Distributions/DataServices, 2) evaluating whether or not a particular Dataset/Distribution/DataService is reusable and 3) using a Dataset/Distribution/DataService that is evaluated as reusable. As we wrote under the Problem statement, "Which formats/mediaTypes a DataService may support is one of the considerations you need to take when deciding whether a DataService is (re)usable or not."

> did you explored the dct:conformsTo possibility?

As we understand it, dct:conformsTo semantically does not have the meaning as dct:format and dcat:mediaType. 

> There are 4 equivalent formats for a user listed: Excel XLS, Excel XLSX, xlsx, .xlsx

Your example and arguments against having dct:format/dcat:mediaType in dcat:DataService, may also apply to dcat:Distribution which do have dct:format and dcat:mediaType in addition to dct:conformsTo. In the context of this discussion, the user need which we suggest to cover in DCAT3, is to provide the user with the same set of metadata (dct:format, dcat:mediaType, dct:conformsTo) for a dcat:DataService as (already doing) for a dcat:Distritution. 

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

Sent via github-notify-ml as configured in

Received on Monday, 5 July 2021 10:31:36 UTC