- From: Karen Coyle via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Jan 2022 19:49:37 +0000
- To: public-dxwg-wg@w3.org
It does make me wonder why there are two different properties in DCAT, unless (and I didn't read it that way) dcat:downloadURL is a further specification of dcat:accessURL. If the latter is a sub-property of the former then @agreiner 's analysis makes sense, and dcat:accessURL could have as its value a URL that is also appropriate in dcat:downloadURL. However, the usage note reads: >dcat:accessURL SHOULD be used for the URL of a service or location that can provide access to this distribution, typically through a Web form, query or API call. >dcat:downloadURL is preferred for direct links to downloadable resources. Which tells me that the DCAT vocabulary does see them as having different uses, albeit softened with "should" and "preferred." The issue of making only dcat:accessURL mandatory is only a problem because of how the documentation separates all properties into categories like "mandatory" "optional" "recommended". There is no technical reason why you could not have a rule stating that either dcat:accessURL or dcat:downloadURL must present, just not in the simple table form that the documentation uses. In the end, my main concern is that an application profile using terms from a vocabulary must be true to the semantics of the terms being used. The fact that DCAT 1) does not define these as disjoint and 2) uses non-binding language, probably means that the DCAT-AP is technically correct. I appreciate the practicality of Annette's use case, but also @smrgeoinfo 's rebuttal. -- GitHub Notification of comment by kcoyle Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1437#issuecomment-1022545648 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 26 January 2022 19:49:38 UTC