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.