W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > August 2007

Re: RDF for molecules, using InChI

From: Chimezie Ogbuji <ogbujic@ccf.org>
Date: Mon, 06 Aug 2007 09:08:31 -0400
To: "Alan Ruttenberg" <alanruttenberg@gmail.com>
cc: "Egon Willighagen" <egon.willighagen@gmail.com>, "public-semweb-lifesci hcls" <public-semweb-lifesci@w3.org>, "Michel_Dumontier" <Michel_Dumontier@carleton.ca>, "Jonathan A Rees" <jar@mumble.net>
Message-ID: <1186405711.6539.16.camel@otherland>

On Sun, 2007-08-05 at 01:25 -0400, Alan Ruttenberg wrote:
> I don't think it is likely that the HCLS recommendations will suggest  
> using INFO uri's. 

Is the 'recommendation' of a particular URI scheme over others on the
agenda? I would hope not.  I've yet to understand the motivation for
considering the use of a particular URI scheme over another as a 'best
practice' (the most common such suggestion being HTTP).

Note that the recent TAG finding [1] in this regard made a (guarded)
argument for how HTTP schemes can facilitate location independence,
persistence, etc..  This should not be confused for a recommendation
*for* HTTP as the a preferred URI scheme.  I would consider such
recommendations as dangerous and perhaps a misunderstanding of AWWW and
the URI mechanism: the fact that the URI syntax allows for the use of
arbitrary URI schemes is a feature not a bug.

> They haven't been championed by anyone, urn schemes  
> are generally discouraged by the W3C TAG,

Where exactly?

>   and in our discussions  
> thus far haven't seen any advantages to using them while noting  
> difficulties. 

I don't think URI schemes were meant to be thought of that way (as
mutually exclusive)

> Too many URN schemes lead to difficulties on the part  
> of clients, 

Not true, especially if the intent of a particular scheme has more to do
with identity management than network resolution (LSIDs are still useful
even without a resolution mechanism, mostly because it has a very
precise identification scheme - non-collidable UUIDs, etc.).  Consider
that you can perform inference over an RDF graph which consists of a
merge of *both* ABox assertions (and other instance-level data) and TBox
assertions (ontology assertions) without the need of a resolution
mechanism.  Being able to build such a merged graph "on-the-fly" (i.e.,
"Follow-your-nose") makes such an RDF Graph Hypertext-Web friendly but
this is not a necessary criteria.

The HTTP scheme (as I understand it) is made for the Hypertext-Web, not
every information space maps well to the Hypertext-Web and for those
where resolution is not a necessary component, it is (a bit) redundant.

> which is why there is still a lot of discord about LSIDs,  

Most of which seems to follow the tone of the URN Registries finding
(i.e., some of the problems solved by URN schemes can be solved with the
HTTP scheme - once again this should not be confused as recommendation
for a URI scheme monopoly)

> which are certainly in line before INFOs. Finally, there are better  
> alternatives.
> 
> Just a heads up.
> 
> -Alan

[1] http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html

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


===================================

Cleveland Clinic is ranked one of the top hospitals
in America by U.S. News & World Report (2007).  
Visit us online at http://www.clevelandclinic.org for
a complete listing of our services, staff and
locations.


Confidentiality Note:  This message is intended for use
only by the individual or entity to which it is addressed
and may contain information that is privileged,
confidential, and exempt from disclosure under applicable
law.  If the reader of this message is not the intended
recipient or the employee or agent responsible for
delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If
you have received this communication in error,  please
contact the sender immediately and destroy the material in
its entirety, whether electronic or hard copy.  Thank you.
Received on Monday, 6 August 2007 13:08:58 GMT

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