Re: [DCAT] accessURLs vs downloadURLs

My impression was that a downloadURL is the place you download the full 
document, and accessURL is an API endpoint like OAIPMH, SPARQL or SOAP.



On 11/11/2013 12:27, John Erickson wrote:
> Thanks to Luke for the question and Richard for the response. I've
> added some (also unofficial...) comments to Richard's answer to the
> first question, below:
>
> On Mon, Nov 11, 2013 at 6:55 AM, Richard Cyganiak <richard@cyganiak.de> wrote:
>> (not an official working group response)
>>
>> On 6 Nov 2013, at 22:54, Luke Blaney <w3.mailing_lists@lukeblaney.co.uk> wrote:
>>> The main thing I noticed was the ambiguity between accessURLs and downloadURLs.   I think any spec which contains the words "...when you are not sure whether it is" could do with more clarification.
>>> Does a downloadURL need to contain the entire dataset, or is it permissible to specify multiple downloadURLs, each containing part of the dataset?  For example, if a dataset contains 3 tables, each downloadable as a separate CSV, can the links to all three be added as downloadURLs?
>> I’d say no. I read the spec as saying that multiple downloadURLs indicate the same data in different formats.
> I think that may be reading too much into it. One can also think of a
> dataset as a collection of items, with each downloadURL in the
> Distribution providing direct access to one of the items.
>
> I see this as comparable to the hierarchy in CKAN, with each
> downloadURL pointing to one of the "resources" associated with a CKAN
> dataset. In another example, if one was modelling a complete image as
> a dataset, each downloadURL could point to a different manifestation
> (resolution, format, etc).
>
> The bottom line is that additional metadata (such as from a "research
> object" ontology and/or from ORE) may be required for the application
> to unambiguously state what the relationships are.
>
>>> The definition of accessURL seems like it could be interpreted to include direct downloads.  Does this mean that downloadURL is a subProperty of accessURL?  If it is, it'd be nice to have an rdfs:subPropertyOf relationship in there.
>> This design is, in fact, what I remember from earlier working group discussions, and I was surprised that the spec doesn’t say that downloadURL is a subproperty of accessURL.
> My belief is that there are MANY interpretations of accessURL. In our
> implementation (for example) we have accessURL point to the
> high-level, descriptive dataset page in a repository, and the
> downloadURLs point to the manifestations.
>
>>> If it isn't, then perhaps the definition of accessURL needs to make this explicit.
>>>
>>> Other than that, I found the inclusion of rdfs:domain on Properties quite inconsistent.  In my view, all rdfs:Properties should have rdfs:domain and rdfs:range specified.
>> I would agree for any properties defined in the DCAT namespace. In particular, I note that the following properties don’t show an explicit domain, even though their description often implies that they only can be applied to a particular class of entities (catalog, dataset, distribution):
>>
>> themeTaxonomy
>> theme
>> keyword
>> contactPoint
>> accessURL
>> downloadURL
>> byteSize
>> mediaType
>>
>> The ship may have sailed on all of these issues, given that DCAT is in CR stage and that the WG’s charter is running out...
>>
>> Best,
>> Richard
>>
>>
>>
>>> Also, http://www.w3.org/ns/dcat.ttl doesn't seem to match everything at http://www.w3.org/TR/vocab-dcat/  Is there an up-to-date version of the ontology in RDF?
>>>
>>> Regards,
>>>      Luke Blaney
>>>
>>> P.S. Well done on linking out to other ontologies for existing concepts.  I've noticed a worrying trend recently of people minting their own concepts for everything.
>>
>
>

-- 
Christopher Gutteridge -- http://users.ecs.soton.ac.uk/cjg

University of Southampton Open Data Service: http://data.southampton.ac.uk/
You should read the ECS Web Team blog: http://blogs.ecs.soton.ac.uk/webteam/

Received on Monday, 11 November 2013 15:38:31 UTC