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 12:23:39 +0100
Message-Id: <02A7EDEC-2166-40DE-B5C5-D71B06D7D9B8@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 11:55, Eric Jain wrote:

> Bijan Parsia wrote:
>> This was addressed in this thread. HTTP uris create expectations  
>> of dereferencing and are generally reported as bugs if they don't  
>> dereference.
> The thing is, quiet a few people seem to have the expectation that  
> they should be able to resolve anything, and I can tell you that  
> non-HTTP URIs won't stop them from filing bug reports.

I suspect there's a difference in kind. E.g., "your website is down"  
is really quite different than "You don't use HTTP uris." But be all  
this as it may.

> In fact now that most of our URIs are resolvable I get a lot less  
> complaints and live a happier life :-)

I'd be interested in the sort of complaints. Having a recommendation  
for http uris will definitely up the number of "please use http uri"  

> I still have some URIs that won't dereference at the moment (e.g.  
> http://purl.uniprot.org/annotation/PRO_0000000088), but does that  
> mean I should use a different kind of URI for these, and then all  
> of a sudden replace them once I get around to fix this? Doesn't  
> make sense to me...

But that's a different context, one wherein you've already made a  
committed to having http URIs. The best practices are different once  
you've made a commitment.

>> 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.
> It isn't, it's an argument against any scheme that does not make  
> use of the domain name system. Note that what I'm talking about  
> here is really basic, i.e. the ability to guarantee that there are  
> no unintentional conflicts due to two organizations using the same  
> URI for something completely unrelated.

I identified 3 problems, and this is only one. However, DNS doesn't  
even do that *if I reuse your URIs*, or if I reuse your URI space  
(which you may want me to do). E.g., I say
	http://ex.org/#Bijan a Philosopher.

and you say
	http://ex.org/#Bijan a PerfumeMaker.

I believe these uses point to completely unrelated thing (in speakers  
meaning, at least). I am most likely trying to get at the person who  
wrote this page:

And you are most likely trying to get at the person who profits from:

Now, I know the line is that one of these uses is *authoritative*,  
i.e., the "owner" of the URI is "right" about it (let's put aside how  
crazy I think that is :)) But suppose all the URI owner says is:
	http://ex.org/#Bijan a Person.

And you and I want to say something about...Bijan. Because we think  
Bijan rocks and want to say so.

>> 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.
> If you want to have a system that guarantees that there are no  
> unintentional conflicts, then yes, it has to be widely accepted.

I want a pony too! :)

I worry about the illusion that unintentional conflicts are  
impossible with DNS based thingies. They aren't. And the mechanism of  
coining your own version of a term has big costs.

> If you set up some registry that manages e.g. urn:bm:* URNs, how do  
> you guarantee that someone else (perhaps in Bermuda...) won't start  
> assigning their own urn:bm:* URNs?

I think my fanciful example is more realistic than *your* fanciful  
example...but I would, wouldn't I? :)

> This may not be a problem in a closed world, but it is a problem  
> for anyone who may want to do Google-scale integration.

Well, people overload google search terms all the time. Because  
google search terms are natural language. And those search terms work  
really well in a lot of cases. So I don't understand your point.

>>> 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?
> What I'm trying to get at is that there are quite a few non-life- 
> sciences- specific applications out there that benefit from being  
> able to resolve URIs,

Is there a list I can see of what you have in mind? I mean, that are  
being used now by people interesting in life science terminology.  
Even a few examples would help me out here.

> but I don't see any of these supporting domain-specific URIs such  
> as LSID. Of course if the URI isn't resolvable anyway it doesn't  
> matter (see #1), but if it is, this does seem to be a strong  
> argument in favor of URLs.
>> 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 effects.
> I'll admit it's not at all trivial to have truly stable URIs -- to  
> be honest, not all of our URIs would meet the criteria at the  
> moment, either.
> But some simple PURL-like system should be within reach of anyone.

Isn't this what's in dispute? In any case, doesn't PURLing sorta kill  
the DNS argument? I'm so confused and I fear for the kittens!

> Regarding issues such as whether or not to use fragment  
> identifiers, some guidelines might help, but an agreement on one  
> solution isn't essential.

This is one of those things that one needs to make a decision on if  
one is going to use HTTP uris. It seems mean to recommend people use  
HTTP uris and punt on this crucial point.

>> 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 :)
> Well, no one in their right mind is going to expend much effort  
> towards something they don't see as beneficial to themselves :-)

Yep. So if the benefit is *non-obvious* or otherwise diffuse, it's  
not going to be a great selling point.

Received on Tuesday, 21 August 2007 11:22:33 UTC

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