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: Sat, 18 Aug 2007 10:37:35 +0100
Message-Id: <5DC6894C-C7D8-4A23-913C-8B136ABE62AB@cs.man.ac.uk>
Cc: <ogbujic@ccf.org>, "public-semweb-lifesci hcls" <public-semweb-lifesci@w3.org>, <wangxiao@musc.edu>
To: "Booth, David (HP Software - Boston)" <dbooth@hp.com>

On Aug 18, 2007, at 4:02 AM, Booth, David (HP Software - Boston) wrote:

>> From: Bijan Parsia
>> On 9 Aug 2007, at 10:32, Xiaoshu Wang wrote:
>>> [ . . . ]
>>> What kind of difference does it
>>> make to an agent for the following two resources.
>>> a) http://404/a/b/c - returns a 404
>>> b) lsid:404:a:b:c    - non-dereferenciable
>> Clearly it marks a difference in intent. It allows me, the term
>> coiner, to communicate the fact that I don't intend for you to find
>> information directly by GETting that uri  [ . . . ]
> If you never intend to make your URI dereferenceable then there
> certainly is no point in making it an http URI.  You might as well  
> use a
> non-dereferenceable URN.

Please note that in the above exchange, IIRC, we were merely  
discussing whether there *was* a difference (to an agent) between a  
404  and a non-dereferanceable one.

> However, the purpose of this discussion is to come up with community
> recommendations on minting URIs.

Sure. But there's a bit of a leap from "Use StudlyCaps in your local  
names for classes" and "Set up a web server before making up any  
names". Recommendations that 1) vary widely from reasonable practice  
and 2) cost effort are generally idle recommendations.

> As such:
>  - They will be recommendations, not requirements.

Yes, but you want them to have uptake :)

>  - They should be designed to best benefit the community as a whole.

That's tendencious. (Do you mean as summed? on average? with a high  
median? or some sort of qualitative notion? Are you trying to grow  
the community? or make its overall costs lower? or...)

> It seems clear that any such recommendations should be designed to  
> best
> facilitate the publication and re-use of URIs by others,

This is one benefit. The other is to make them easy to mint. Naming  
is hard.

> and making URIs
> dereferenceable to useful metadata is certainly one convenient way to
> help do so.

Really? The point of these examples is that there are a variety of  
cases which for a variety of reasons it's not so convenient  
(actually, either for the minter or the discoverer). So the  
recommendation can say, "When its convenient and helpful, use http  
uris, otherwise, don't" But that's not so great a recommendation.

> In short, I think your example has nicely illustrated the fact that a
> particular URI owner could still have good (or bad) reasons *not* to
> make its URIs dereferenceable, and hence may choose to use URNs.

And presumably there are good and bad ways to do that.

> That
> is its prerogative.  But that does not mean that our *recommendations*
> should encourage such practice.

Why not, if the good reasons out weight the bad? I mean, what more  
would that be than saying, "eww, if you have to for a variety of  
excellent reasons not be in our HTTP club, well, ok, but you're still  

That's not super community building :)

Presumably there's things people can do which will make their URNs or  
non-dereferencable URIs more or less accessible for reuse. Publishing  
a term index at an HTTP dereferencable URI is just one example.

Received on Saturday, 18 August 2007 09:38:06 UTC

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