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: Thu, 9 Aug 2007 10:52:52 +0100
Message-Id: <D737B017-8BF6-4C1E-8BDF-B35C011604FB@cs.man.ac.uk>
Cc: ogbujic@ccf.org, public-semweb-lifesci hcls <public-semweb-lifesci@w3.org>
To: wangxiao@musc.edu

On 9 Aug 2007, at 10:32, Xiaoshu Wang wrote:

> Bijan Parsia wrote:
>> On 8 Aug 2007, at 15:30, Xiaoshu Wang wrote:
>>> Chimezie,
>>>> The employee wants to build an ontology and doesn't have control  
>>>> over
>>>> web space.  She considers using the tag scheme instead of an  
>>>> HTTP scheme
>>>> (with a bogus domain name such as
>>>> http://example.com/clinical-medicine/surgical- 
>>>> procedures#minimally-invasive-procedure) because the latter  
>>>> scenario would result in the use of the HTTP scheme which  
>>>> incorrectly suggests (to "follow-you-nose Semantic Web agents" -  
>>>> there is growing number of such software) that they attempt to  
>>>> unnecessarily dereference the terms for more 'useful' information.
>>> But this is a "pyschological" issue, not a "technical one".
>> [snip]
>> Psychological issues *are* technical. Think HCI or accessibility.
> Fair enough. But should this social/technical issued be solved (1)  
> socially, i.e., by "best practice/education", or (2) technically by  
> building an entirely new infrastructure and community support
(See, the social snuck back in :))

> for a new URI scheme?

This is one nicely phrased question, but, for example, URN patterns  
are lighter weight that that.

>> (I don't agree with your analysis even after this. For example,  
>> one reason she might care about FYN semantic web agents is that it  
>> might be a reasoner that does *different* things when fed an HTTP  
>> uri (tries to dereference) and a URN (er...doesn't).
> That is what I was asking right? 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 (or to do something by  
POSTing, etc. etc.)

> The only benefit might be to save on a futile attempt.

Not just one futile attempt. If I published a large ontology, for  
example, with tens of thousands of terms as http uris, various  
spiders might try to collect that potential extra information. Note  
that they won't necessarily give up after one retrieval attempt (per  
URI), nor is it necessarily only one spider.

Furthermore, there is a social expectation that if you share http  
uris that you should be able to pop them into a web browser and get  
something. A 404 means the uri you gave is *broken*. So you would  
have to field lots of queries about the brokenness.

Then when you deal with certain people, even explaining that you  
didn't *mean* for them to derefernce doesn't settle the matter,  
they'll ask you to put up *SOMETHING* at that URI, if only "This is  
not meant to be dereferencable".

And there's the stability problem. If you are trying to make  
something that will last indefinitely, a bespoke URN (or URI scheme)  
which does not depend on DNS ownership might be better. (PURL does  
*something* toward this, of course.)

>   But, if this is the case and important enough, then why not  
> designate a top domain name like "tmp" to signal this.  For  
> instance, use "http://example.com.tmp/doc" as the temporary URI for  
> the eventual resource of "http://example.com/doc".

If you think that getting the technical and social infrastructure for  
a new top level domain is significantly *easier* than getting a new  
URI scheme (URNs are clearly way easier), then I suggest you think  
again :) They are comparable changes. So *that* doesn't decide  
between them at all.

>> And of course we can work out compensations for that, but c'mon.  
>> We're talking about trade offs and work arounds, not "can you make  
>> it work if you try hard enough.")
> I was talking trade-offs and not try to say "try hard to make it  
> work".  I was curious that if the intension is to use bogus URIs,  
> then anything is fine.

I don't think bogus URIs are on the table.

Received on Thursday, 9 August 2007 10:04:04 UTC

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