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: Booth, David (HP Software - Boston) <dbooth@hp.com>
Date: Mon, 20 Aug 2007 12:51:16 -0400
Message-ID: <EBBD956B8A9002479B0C9CE9FE14A6C203113B6B@tayexc19.americas.cpqcorp.net>
To: "Bijan Parsia" <bparsia@cs.man.ac.uk>
Cc: <ogbujic@ccf.org>, "public-semweb-lifesci hcls" <public-semweb-lifesci@w3.org>, <wangxiao@musc.edu>

Bijan,

Certainly we want these recommendations to have uptake, every approach
has costs, and every recommendation has its own scope of applicability.
But different people weigh the costs and benefits differently.  Yes,
some may view the cost of minting dereferenceable URIs as too high in
some situations, but I think the ubiquity of the web shows that very
many will view the cost of publishing dereferenceable URIs as low enough
-- and probably still falling -- to be outweighed by the benefits.

Perhaps one good approach to accommodate a spectrum of perceived cost
weightings would be analogous to the tiered Web Accessibility guidelines
( http://www.w3.org/WAI/WCAG20/quickref/ ).  The first-tier
recommendations could be those that we believe would yield greatest
community beneifit, but second-tier recommendations could also be
provided for cases where someone cannot meet the first-tier
recommendations.  In the Web Accessibility guidelines the tiers are
called levels A, AA and AAA to avoid stigmatizing those that don't meet
level AAA.  

Specific comments below.

> From: Bijan Parsia [mailto:bparsia@cs.man.ac.uk] 
> 
> On Aug 18, 2007, at 4:02 AM, Booth, David (HP Software - 
> Boston) wrote:
> [ . . . ]
> > 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.

Of course.  But different people have different notions of "reasonable".
And whatever the perceived costs, recommendations themselves should help
lower the costs by providing clear guidance.  

> 
> > As such:
> >
> >  - They will be recommendations, not requirements.
> 
> Yes, but you want them to have uptake :)

Of course.

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

Some qualitative notion.  Probably all of the above included.

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

Recommendations may be able to help by providing guidance on naming.

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

Can you explain specific cases in which you see usefully dereferenceable
URIs as NOT being so convenient for the discoverer?

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

Sure.

> 
> > 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 ICKY"?
> 
> That's not super community building :)

Well, I think that's an unfair characterization.  The point is that
usefully dereferenceable URIs are a courtesy that lowers the barrier to
reuse -- quite the opposite of creating an exclusivee club.  

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

Of course.  I didn't mean to imply that using HTTP URIs that dereference
to useful metadata is the *only* thing that can be done to make URIs
more accessible for reuse.  

Thanks


David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Opinions expressed herein are those of the author and do not represent
the official views of HP unless explicitly stated otherwise.
 
Received on Monday, 20 August 2007 16:52:15 GMT

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