W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > July 2006

Re: BioRDF: URI Best Practices

From: Chimezie Ogbuji <ogbujic@bio.ri.ccf.org>
Date: Fri, 21 Jul 2006 10:59:04 -0400 (EDT)
To: w3c semweb hcls <public-semweb-lifesci@w3.org>
Message-ID: <Pine.GSO.4.60.0607211048310.29218@joplin.bio.ri.ccf.org>





On Fri, 21 Jul 2006, Alan Ruttenberg wrote:

>
> Nice idea. I've added a similar proposal to the same wiki page[1].
>
> Basically, I would  argue that there are three aspects to dereferencing, with 
> the problem being that there is no one thing that you always want 
> dereferencing to get you.
>
> 1. The kind of information you want to get by dereferencing - You might want 
> the primary data if it is an information resource. You might want metadata of 
> various kinds in all cases (definition, policy, history, picture-of).  303 
> notwithstanding, I'd rather know that I am dealing with a non-information 
> resource *before* I touch the network.
> 2. The representation type - I think this is handled by mime types
> 3. The transport - http etc.
>
> So my proposal suggests a class that defines ways of transforming the URI you 
> find in a SW document into URLs that get specific types of information. The 
> fact that a transform to URL is provided means you get the transport (because 
> it is part of the transformed URL). Different properties of the class let you 
> retrieve different patterns for different sorts of information (1.). The 
> representation 2., is not explicitly represented, it should instead be part 
> of the definitions of the properties. We typically want to know *before* we 
> dereference, what we would get back.
>
> I would further argue that as much as possible about this should be 
> represented explicitly in your ontology, as Matthias has suggested.

As Xiaoshu pointed out, content negotiation (specific accept headers 
dispatched to a URL) give you *most* of this functionality purely at the 
transport level - assuming there are appropriate mime types for the 
representation you have in mind for a URL.

So, it would seem more useful for such a class to identify 1) whether a 
URI is a resolvable resource and 2) the mime-types it is 'registered' to 
respond to - perhaps with some human-readable annotation documenting exactly what 
is expected from a particular mime-type.  Where there is only one 
associated representation for a URL, it is sufficient to simply identify 
the URI as a resolvable identifier and for a client to do a GET without 
any accept headers (since the lack of any registered mime-types indicates 
that the URL only has one representation modality)

I like the idea of guiding the dereferencing process in 
a formal way, but I think content negotiation is the better 'hook' for 
retrieving various representations of the same URL.

I'll update the Wiki accordingly

Chimezie Ogbuji
Lead Systems Analyst
Thoracic and Cardiovascular Surgery
Cleveland Clinic Foundation
9500 Euclid Avenue/ W26
Cleveland, Ohio 44195
Office: (216)444-8593
ogbujic@ccf.org
Received on Friday, 21 July 2006 14:59:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:00:44 GMT