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

Re: [dxwg] dcat:accessURL - check constraints

From: Dan Brickley <danbri@google.com>
Date: Sun, 06 May 2018 16:12:25 +0000
Message-ID: <CAK-qy=5C7mjtcVmVZ4umBoCgcGutDUzE59JSO=i4twd=7rN=wQ@mail.gmail.com>
To: Andrea Perego via GitHub <sysbot+gh@w3.org>
Cc: Dataset Exchange Working Group <public-dxwg-wg@w3.org>
On Fri, 4 May 2018, 09:51 makxdekkers via GitHub, <sysbot+gh@w3.org> wrote:

> I still disagree. We're haggling over a URI, `accessURL` versus
> `accessService`; in my mind, URIs are basically opaque strings -- you
> should not read any meaning into them, although human-readable strings may
> help implementers to remember them more easily.


People consistently do read them, despite the formalities.

In this case, e.g. in rdfa 1.1,

  <a property="dcat:accessURL"  href="http://example.org/xyz" > ...</a>


...reads very nicely, and the strings-vs-things / levels of indirection
nuance will be lost on the majority of publishers and consumers.


But you really should not expect anything from just looking at the URI.
> What really matters is the definition of the term identified by a URI. In
> this case, the definition of `accessURL` is quite clear "_A landing page,
> feed, SPARQL endpoint or other type of resource that gives access to the
> distribution of the dataset_" -- note that it does not say "_The URL of a
> landing page ...._".
> If we wanted to include services in the definition, we could decide to
> make a minor change to the definition, e.g. "_A **service**, landing page,
> feed, SPARQL endpoint or other type of resource that gives access to the
> distribution of the dataset_".
> In my opinion, changing the URI to something that we find more elegant
> just for the sake of it is creating confusion where none is necessary.
>
> --
> GitHub Notification of comment by makxdekkers
> Please view or discuss this issue at
> https://github.com/w3c/dxwg/issues/124#issuecomment-386540688 using your
> GitHub account
>
>
Received on Sunday, 6 May 2018 16:13:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 April 2019 13:44:59 UTC