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

On Aug 20, 2007, at 5:51 PM, Booth, David (HP Software - Boston) wrote:

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

Of course. Isn't this exactly what we're discussing?

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

I don't think the "ubiquity of the web" shows anything at all about  
large scale scientific terminology building an management. After all,  
the web contains a lot of stuff, most of it is not terminological.  
The Web has obvious problems (e.g., in terms of stability i.e., links  
break; PURLs are a workaround) for data that is intended to be long  
lived. Etc. etc.

I don't want to reiterated the arguments already made in this thread.  
But if you go back to the email of mine you responded to, i hope  
you'll see that your attempt to go meta (i.e., this is what we are  
doing) didn't help. It just avoided the technical issues.

In response to a question about whether there is a difference between  
404 and non-dereferencable URIs, I pointed out that there were  
several and several benefits. You reduced that to "well, sure, if you  
don't want your URIs dereferenced, you shouldn't use a dereferencable  
uri" but then said that 1) this was just a recommendation and 2) the  
recommendation should benefit the community as whole.

This does not advance the discussion, IMHO.

[snip]
>> 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".

I don't know why you think this is relevant. If there is no agreement  
here on what reasonable and best practice are, then I don't see what  
the point is. Even if you are defining "in group" behavior, well,  
there seem to be several people in-group who disagree.

> And whatever the perceived costs, recommendations themselves should  
> help
> lower the costs by providing clear guidance.

Well, if I would ordinarily think it's a no-brainer to use LSIDs, and  
now you have this recommendation that says, "Phooey on that; http  
baby", then I have a decision to make which I didn't have to before.  
If I make a decision that *costs* me more than the decision i'd have  
otherwise made, then it hasn't lowered my costs, however clear it may  
have been.

[snip]
>>>  - 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.

I find that unconvincing. You may as well say, "They are cool and we  
like them. Thanks" I have no problem with that, myself.

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

My point was that certain kinds of facilitations of certain kinds of  
publication and certain kinds of re-use may make naming harder enough  
that mere guidance doesn't compensate. See this thread for some  
arguments in this direction.

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

Sure. For example when they 404. Or if they cause the information to  
be presented in an awkward way (e.g., in lots of little documents so  
I have to spider rather than grep). Or when people publish multiple  
views of the same term but in different places (all using the same  
URI), so dereferencing leads me to only one view.

It may be that *judicious* links are overall better than  
systematically fine-grained links. Web pages with too many links can  
be really annoying and hard to work with.

This isn't to say I don't want to find information or find it on the  
web. But there are lots of ways HTTP uris can be used without making  
them the name of every term (why not of every axiom?).

[snip]
>>> 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.

You think I unfairly characterize my *own hypothetical*? Bit much,  
don't you think?

> The point is that
> usefully dereferenceable URIs are a courtesy that lowers the  
> barrier to
> reuse -- quite the opposite of creating an exclusivee club.

Dude, if the GOOD reasons for using non-dereferencable uris OUTWEIGH  
THE BAD, then we shouldn't recommend using HTTP URIs. Period. If  
using HTTP URIs for bio-ontologies killed kittens, I think we should  
recommend people not use them for bio-ontologies. Think of the  
KITTENS!!!! Think of the rise in PETA donations!

If the GOOD reasons outweigh the BAD, then it's not a *mere courtesy*.

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

So why not frame the recommendation situationally? I don't really see  
why HTTP uris are preferred, even as a default. Yes, I know, TAG blah  
blah Webiosity etc. But c'mon, Chimezie is as web-loving a person as  
you can find and he sees serious problems with recommending this  
"courtesy".

But enough from me :)

Cheers,
Bijan.

Received on Tuesday, 21 August 2007 00:40:05 UTC