Re: [DCAT] accessURLs vs downloadURLs

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



-- 
John S. Erickson, Ph.D.
Director, Web Science Operations
Tetherless World Constellation (RPI)
<http://tw.rpi.edu> <olyerickson@gmail.com>
Twitter & Skype: olyerickson

Received on Monday, 11 November 2013 12:27:39 UTC