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

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

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Tue, 21 Aug 2007 10:41:17 +0100
Message-Id: <9680642C-9C34-4EE3-8CF6-FBDFF43549A8@cs.man.ac.uk>
Cc: "Booth, David (HP Software - Boston)" <dbooth@hp.com>, ogbujic@ccf.org, public-semweb-lifesci hcls <public-semweb-lifesci@w3.org>
To: Eric Jain <Eric.Jain@isb-sib.ch>

On 21 Aug 2007, at 10:12, Eric Jain wrote:

> Bijan Parsia wrote:
>> I don't really see why HTTP uris are preferred, even as a default.
> I think the argument is really simple:


> 1. If you do not want to dereference, I don't see why you would  
> care whether a URI is a URL or a URN or whatnot -- as long as it is  
> unique.

This was addressed in this thread. HTTP uris create expectations of  
dereferencing and are generally reported as bugs if they don't  

> 2. The most practical solution to the uniqueness problem is to  
> build on top of an established registration system such as the  
> domain name system.

Would you mind restating the uniqueness problem for me? It seems that  
there are several possible problems:

	1. I make a new name for something that already has a name.
	2. I use a name for two things.
	3. I have alternative conflicting statements involving a name (but  
there's no belief that the name names two things or there's another  
name for the object of discussion)

I think DNS sorta helps with the second. Sorta. (and it fights a bit  
with the first) Using DNS for prefixing, of course, is not  
restricted  to http uris. So I fail to see why this is part of an  
argument for *http* uris specifically.

(Presumably 1 is to be handled by them being "more discoverable". But  
as far as I can tell the marginal gain of using HTTP uris for  
individual terms is the follow-your-nose-discoverability stuff which  
requires its own justification.

> If you think you can come up with something better that's going to  
> be accepted as widely, that's great, but forgive me for not holding  
> my breath...

Does something need to be accepted as widely? I see that there's a  
"most practical solution" modifier up there, but all I see backing it  
up is the widespread acceptability point.

Lest I seem too nitpicky,

> 3. If you do want to dereference, and do so with a generic tool  
> that wasn't specially written to handle life sciences data (most  
> won't), you are likely to be out of luck if you encounter some  
> domain-specific resolution system.

I'm sorry, I got lost parsing this. Do you mean that most won't use a  
specially written tool or that most won't use a generic tool?

> If the W3C can encourage life science databases to provide stable  
> URLs (which is simple enough that it shouldn't be a technical  
> problem for any of them, don't even need to buy into any of the  
> semantic web stuff to see that this is useful), this would already  
> make the world a better place (TM).

I am generally in favor of stable URLs, but I'm not so sanguine about  
the technical simplicity. Perhaps for big databases this is true: I  
wouldn't know. Oh, and you do mean HTTP URLs? There are lots of  
choices involved there. For example, do I make all my terms using  
frag ids or not? This can have a variety of non-obvious long term  

> (The more cynical point of view would be that people are not  
> influenced by such recommendations, in which case this discussion  
> is rather pointless :-)

I certainly find that trying to get people to do stuff that is non- 
obviously overall beneficial to them and has uncertain or nebulous  
benefits to the common weal is a thankless task. Literally :)

Anyhoo. This seems neither here nor there. Perhaps it's worth  
phrasing some of these disputes in a problem statement then pro-con  
various solutions way? I have three possible problems with minting or  
using terms list above, perhaps we could start with one of those and  
try to capture all the considerations? We could do this on the wiki  
or in email. It might be more productive than an inherently  
argumentative exchange.

Received on Tuesday, 21 August 2007 09:40:18 UTC

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