W3C home > Mailing lists > Public > public-gld-wg@w3.org > February 2012

Re: ISSUE-7 (whyAccessUrl): Drop dcat:accessUrl, use the URI of the dcat:Download resource instead [DCAT]

From: Richard Cyganiak <richard@cyganiak.de>
Date: Fri, 10 Feb 2012 09:56:17 +0000
Cc: Government Linked Data Working Group WG <public-gld-wg@w3.org>, Government Linked Data Working Group Issue Tracker <sysbot+tracker@w3.org>
Message-Id: <417E485E-4E03-4136-B884-FC2617028FBD@cyganiak.de>
To: Sarven Capadisli <sarven.capadisli@deri.org>
On 10 Feb 2012, at 04:53, Sarven Capadisli wrote:
>>> I agree with Ed Summers' proposal to drop dcat:accessURL and simply use dcat:distribution.
>> The problem is that accessURL is optional  some datasets are not distributed online but through other means. In that case, what would be used as the node representing the dcat:Distribution? A blank node? A made-up URI? So there needs to be a special case in both production and consumption code to deal with this case, and that just increases the probability that implementers with less RDF experience get it wrong.
> I find Ed's example [3] fairly straight forward:
> ex:dataset1
>    a dcat:Dataset ;
>    dcat:distribution <http://example.gov/downloads/1> .
> <http://example.gov/downloads/1>
>    dcat:format "text/csv" .
> No bnode or made-up URI. As far as I understand, this approach can still be used to access any distribution method.

I said the problem is datasets that are distributed *not* online but through some other means, that is, datasets where you know the available formats, but don't know the accessURL for the specific distribution for some reason. A concrete example that occurs on data.gov.uk would be a dataset where we know that it's available in CSV and XLS, but don't have the specific download link for each of the formats but we only have a single URL of a generic download HTML page, which in turn contains links to the two versions. How do you model that in this simplified scheme?

Received on Friday, 10 February 2012 09:56:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:52:00 UTC