W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > May 2018

Re: [dxwg] dcat:accessURL - check constraints

From: Simon Cox via GitHub <sysbot+gh@w3.org>
Date: Thu, 03 May 2018 15:39:14 +0000
To: public-dxwg-wg@w3.org
Message-ID: <issue_comment.created-386339114-1525361953-sysbot+gh@w3.org>
Thanks @makxdekkers 

Provided we include `accessURL` in the DCAT-2014 profile, then no harm is done to any existing implementations, which can continue to use DCAT-2014. But looking to the future rather than the past,  `dcat:accessService` will be **much** less confusing to implementers than `dcat:accessURL`. 

IMHO calling any **object-property** `aaaURL` is missing the point. A URL is a designator, not a resource. An object-property links between resources, not their identifiers. When I see a property named `aaaURL` then I expect the value to be a literal of type `xsd:anyURI` - i.e. a string which is a URI. So while I acknowledge that the textual definition of `accessURL` is almost the same as what is needed, this was a poorly designed and named property in the first place. 

I recognise and respect the backward-compatibility requirement. But I believe we should take the opportunity also correct the more obvious miss-steps so as not to confuse future adopters. My goal is to satisfy backward-compatibility while also moving people to a better option moving forward. 

How to package DCAT-2014 is not yet resolved, and perhaps we could leave `dcat:accessURL` in the main DCAT ontology, with `owl:deprecated "true"`. But leaving lots of deprecated elements in the DCAT-rev schema is undesirable, in my opinion. 

GitHub Notification of comment by dr-shorthair
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/124#issuecomment-386339114 using your GitHub account
Received on Thursday, 3 May 2018 15:39:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:42:03 UTC