Re: [DCAT] accessURLs vs downloadURLs

Hi all.

Apologies if this rambles - written bits at a time between meetings and work tasks.

I think the key here is that we are talking access and download URL's not URI's.

If dcat:Distribution "Represents a specific available form of a dataset. Each dataset might be available in different forms, these forms might represent different formats of the dataset or different endpoints. Examples of distributions include a downloadable CSV file, an API or an RSS feed", then it would logically stand to reason that an accessURL where you go to obtain access to the distribution and that downloadURL is the "physical" location of the distribution proper. This includes an API or end point - anything which sends data to the client side is a download.

I feel the inferences then are: downloadURL is "1:1" - each unique distribution (or manifestation of the dataset in question specified by mime type etc) can only have 1 location - even 2 identical copies of dataset on the same server will have different URL's by virtue of the simple rule that two things cannot occupy the same space at the same time.

AccessURL is both 1::many and many::1 when put against downloadURL - there may be multiple access locations I can come through in order to query or download a dataset, and multiple datasets may share a single accessURL (such as a members login area) - in short - accessURL becomes the actual linkage between different distributions - "hasaccessURL" so to speak becomes the query showing you what's available from a certain place - "hasdownloadURL" should only return me a single result for any distro.

All in all - I do not see the logic in making download a sub-prop of access - they are very different things and are not necessarily linked.

I believe the descriptions in spec are accurate and unambiguous enough as is and any change to the spec should only clarify further not change how the spec works.

-1 to "Define dcat:downloadURL as sub property of dcat:accessURL".

Cheers

Chris


Sent from my Sony Xperia™ Z Ultra

---- Richard Cyganiak wrote ----

>On 14 Nov 2013, at 13:41, Fadi Maali <fadi.maali@deri.org> wrote:
>>>>> I’d say no. I read the spec as saying that multiple downloadURLs indicate the same data in different formats.
>> 
>> The more common case is to have downloadURL pointing to the entire dataset. If this is not the case, then I'd say yes you can use multiple downloadURL. 
>> Different formats go in different instances of dcat:Distribution this instance have its format described using dct:format or dcat:mediaType
>
>You’re right. What I said above didn’t make sense.
>
>>>>> themeTaxonomy
>>>>> theme
>>>>> keyword
>>>>> contactPoint
>>>>> accessURL
>>>>> downloadURL
>>>>> byteSize
>>>>> mediaType
>>>>> 
>> 
>> The domain of these properties were not defined in the ontology because they can be of more use outside the scope of DCAT. e.g. one might want to use dcat:theme and dcat:keyword without imposing that the subject is of type dcat:Dataset.
>
>The definition of dcat:theme is: “The main category of the dataset.”
>
>Using the property on something that definitely isn’t a dcat:Dataset would be an error.
>
>Same for dcat:keyword.
>
>For an example where what you’re trying to do was done well, see SKOS:
>http://www.w3.org/TR/skos-reference/#L1541
>
>But I’m not sure that this is a good idea. If something doesn’t fit the DCAT model of catalog-dataset-distribution, then I think one shouldn’t use DCAT. DCAT isn’t a general-purpose vocabulary for tagging resources or for describing byte streams. The catalog-dataset-distribution model is sufficiently flexible to fit many use cases, but why would one want to use a handful of DCAT properties outside of use cases that fit the model?
>
>Best,
>Richard

Received on Friday, 15 November 2013 01:22:46 UTC