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?

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:35 UTC