Re: [DCAT] accessURLs vs downloadURLs

Hi Luke/all,

Thanks for the feedback and discussion. my input inline...
On 11 Nov 2013, at 15:37, Christopher Gutteridge <cjg@ecs.soton.ac.uk> wrote:

> 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.
> 
> 
yes

> 
> 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.

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 (and I'd also say only one format per distribution).

>> 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.
>>>> 

This sounds reasonable. Captured this into an issue at: https://www.w3.org/2011/gld/track/issues/70

>>>> 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 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 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?
>>>> 

http://www.w3.org/ns/dcat.ttl should be up-to-date. Can you please indicate what doesn't match?

Best,
Fadi
>>>> 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 Thursday, 14 November 2013 13:42:10 UTC