- From: Simon Cox via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Jun 2018 04:20:31 +0000
- To: public-dxwg-wg@w3.org
@andrea-perego wrote: > It would break existing implementations, I guess the problem is that the existing implementation have ``` dcat:downloadURL <http://www.example.org> ; ``` rather than ``` dcat:downloadURL "http://www.example.org"^^xsd:anyURI ; ``` That is definitely an incompatibility. > I don't think we have any use cases supporting this revision. True. I'm primarily seeking consistency with the definitions, but of course that cannot be at the expense of functionality. And even if we do find some errors and infelicities, some we just have to accept as history. Note that the documentation is ambiguous: in the [RDF representation of DCAT-2014](https://www.w3.org/ns/dcat.ttl) in the definition of `dcat:downloadURL` there is a usage-note that says "The value is a URL" which would support my proposition. However, the comment says "This is a direct link ..." which is consistent with it being an object-property. If it is an object-property there is nothing in the RDF/OWL framework to stop it being a blank-node, which is inconsistent with the usage note. Maybe SHACL or ShEX could help? > Moreover, having them as object properties would enable cross-linking of related resources (as services and distributions). I need to understand the details here. We have (provisionally) added a new property `dcat:accessService` to complement `dcat:accessURL`. If you are suggesting that `accessURL` can cross-link to a service description in the catalog (and not just to an external service endpoint) then there is no difference between them. -- GitHub Notification of comment by dr-shorthair Please view or discuss this issue at https://github.com/w3c/dxwg/issues/249#issuecomment-394935412 using your GitHub account
Received on Wednesday, 6 June 2018 04:20:33 UTC