- From: Bert Van Nuffelen via GitHub <sysbot+gh@w3.org>
- Date: Tue, 13 Jul 2021 11:23:14 +0000
- To: public-dxwg-wg@w3.org
@jimjyang > > > > 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." Although I personally would not go for collecting this information for that purpose, I understand your request. I would persue the data services providers to improve their technical documentation which they refer to in the endpoint description. > > > 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. > indeed, but maybe it refers to more interesting information to decide if the service is reusable. > > 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. yes, I know. I have given this example to illustrate that the solution is not persé by adding new properties to DCAT, but often is in the ability of the data providers to provide meaningful/useful data. And since that is for distributions (files) non-trivial, I expect that it is for API's more difficult. Many services will offer/accept data in many different formats. If we follow your suggestion then we best take a look to all related properties for a Distribution and discuss their semantics for a Data Service: - format - mediatype - compression format - packaging format What would be good definitions for them? Are all of them meaningful? Would they make the distinction between Distribution and Data Service more vague or clearer? -- GitHub Notification of comment by bertvannuffelen Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1381#issuecomment-879004821 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 13 July 2021 11:23:15 UTC