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

Does follow-your-nose apply in the enterprise? was: RDF for molecules, using InChI

From: Chimezie Ogbuji <ogbujic@ccf.org>
Date: Wed, 08 Aug 2007 09:52:05 -0400
To: "Booth, David (HP Software - Boston)" <dbooth@hp.com>
cc: "Alan Ruttenberg" <alanruttenberg@gmail.com>, "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: <1186581125.6447.30.camel@otherland>

I don't mean to prolong this thread, but it has trickled into
conversations about some aspects of the follow-your-nose semantic web
which should be carefully considered by people building semantic web
solutions in 'enterprise' environments.  This particular shoe does not
always fit.

On Tue, 2007-08-07 at 14:24 -0400, Booth, David (HP Software - Boston)
> > Not necessarily true. Consider schemes which have a specific
> > (and useful) formal semantics for parts of their strings. The
> > tag
> > [1] scheme
> > incorporates a date component and a mechanism to guarantee
> > uniqueness while minting tag-based URIs. The LSID scheme has
> > specific portions of the string for revision. These are all
> > parts of the URI that the author has to contend with rather
> > than begin with a clean slate for an arbitrary string with a
> > naming convention picked by the author.
> But HTTP URIs can do *exactly* the same thing, as pointed out in
> http://dbooth.org/2006/urn2http/

Understood, but my point is that being able to express (or map) these
identification components with the HTTP URI scheme should not be
misconstrued for an admonition of using other schemes.  It is not
constructive criticism. 

> > In fact I was going to lay out an example where the
> > restriction of working within an enterprise network severely
> > reduces the argument for minting HTTP URIs for terms coined by
> > employees within that enterprise who do not have control over
> > their webspace. So, follow-your-nose (which strikes me as one
> > of the primary arguments for HTTP scheme monopoly) works for
> > the open web but not the 'enterprise' web.
> Can you be more specific about this example?  

The employee wants to build an ontology and doesn't have control over
web space.  She considers using the tag scheme instead of an HTTP scheme
(with a bogus domain name such as
http://example.com/clinical-medicine/surgical-procedures#minimally-invasive-procedure) because the latter scenario would result in the use of the HTTP scheme which incorrectly suggests (to "follow-you-nose Semantic Web agents" - there is growing number of such software) that they attempt to unnecessarily dereference the terms for more 'useful' information.  

What exactly is the argument (in this scenario) for minting HTTP URIs if
1) Serving up useful information from HTTP uris is not of immediate
importance to her problem space and 2) She has no control over web space
and thus cannot pick (apriori) a domain which *may* resolve 'useful'
information at a later point.

> Are you saying that the
> employees cannot control how their URIs are minted?  Do they wish to
> share these URIs with others outside the enterprise?  

She may, but she doesn't consider direct dereference of terms as a
useful way to share these URIs (she doesn't care to be reprimanded for
putting an unnecessary load on her employers HTTP servers from
follow-your-nose semantic web agents).  Instead, she prefers to put the
OWL ontology in a single location at a later point (when she eventually
can convince her employer of the value of doing so) and broadcast that
*single* location as the authoritative ontology for her terms. Minting
these term URIs in a scheme with good semantics for identify management
(and some amount of version control) gives her decent separation of
concerns between identity management and location independence, which is
especially useful to her given her lack of authority over of web space.

> Right, but giving people the option of "follow-your-nose" does not
> prevent them from using other mechanisms also.  It's like always
> supporing the web-friendly common denominator, but allowing more
> sophisticated users to also use something more powerful.

Perhaps at the expense of the server? Consider that most HTTP clients
don't RESTfully cache quite the way they ought to.  Also, consider the
difference between URI dereference triggered from every term in a
vocabulary and URI dereference triggered from a well understood
assertion of the form:

"the terms used in this RDF graph conform to the OWL ontology located

> > [ . . . ]
> > > I'm still waiting for an example that *can't* be solved using
> > > a HTTP scheme. Do you have any?

See above, though this is not a case of a problem which *can't* be
solved by HTTP, but rather a question of if the HTTP scheme is the right
fit for a scenario where authoritative control over URI dereference is
not part of the equation.

Chimezie Ogbuji
Lead Systems Analyst
Thoracic and Cardiovascular Surgery
Cleveland Clinic Foundation
9500 Euclid Avenue/ W26
Cleveland, Ohio 44195
Office: (216)444-8593


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

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 Wednesday, 8 August 2007 13:52:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:20:29 UTC