- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Thu, 9 Aug 2007 10:52:52 +0100
- To: wangxiao@musc.edu
- Cc: ogbujic@ccf.org, public-semweb-lifesci hcls <public-semweb-lifesci@w3.org>
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. [snip] I don't think bogus URIs are on the table. Cheers, Bijan.
Received on Thursday, 9 August 2007 10:04:04 UTC