On 21 Aug 2007, at 11:55, Eric Jain wrote:
Bijan Parsia wrote:
This was addressed in this thread. HTTP uris create expectations
of dereferencing and are generally reported as bugs if they don't
dereference.
The thing is, quiet a few people seem to have the expectation that
they should be able to resolve anything, and I can tell you that
non-HTTP URIs won't stop them from filing bug reports.
I suspect there's a difference in kind. E.g., "your website is down"
is really quite different than "You don't use HTTP uris." But be all
this as it may.
In fact now that most of our URIs are resolvable I get a lot less
complaints and live a happier life :-)
I'd be interested in the sort of complaints. Having a recommendation
for http uris will definitely up the number of "please use http uri"
complaints.
I still have some URIs that won't dereference at the moment (e.g.
http://purl.uniprot.org/annotation/PRO_0000000088), but does that
mean I should use a different kind of URI for these, and then all
of a sudden replace them once I get around to fix this? Doesn't
make sense to me...
But that's a different context, one wherein you've already made a
committed to having http URIs. The best practices are different once
you've made a commitment.
I think DNS sorta helps with the second. Sorta. (and it fights a
bit with the first) Using DNS for prefixing, of course, is not
restricted to http uris. So I fail to see why this is part of an
argument for *http* uris specifically.
It isn't, it's an argument against any scheme that does not make
use of the domain name system. Note that what I'm talking about
here is really basic, i.e. the ability to guarantee that there are
no unintentional conflicts due to two organizations using the same
URI for something completely unrelated.
I identified 3 problems, and this is only one. However, DNS doesn't
even do that *if I reuse your URIs*, or if I reuse your URI space
(which you may want me to do). E.g., I say
http://ex.org/#Bijan a Philosopher.
and you say
http://ex.org/#Bijan a PerfumeMaker.
I believe these uses point to completely unrelated thing (in speakers
meaning, at least). I am most likely trying to get at the person who
wrote this page:
http://www.cs.man.ac.uk/~bparsia/
And you are most likely trying to get at the person who profits from:
http://www.fragrancex.com/products/_cid_perfume-am-lid_B-am-
pid_757W__products.html
Now, I know the line is that one of these uses is *authoritative*,
i.e., the "owner" of the URI is "right" about it (let's put aside how
crazy I think that is :)) But suppose all the URI owner says is:
http://ex.org/#Bijan a Person.
And you and I want to say something about...Bijan. Because we think
Bijan rocks and want to say so.
Does something need to be accepted as widely? I see that there's a
"most practical solution" modifier up there, but all I see backing
it up is the widespread acceptability point.
If you want to have a system that guarantees that there are no
unintentional conflicts, then yes, it has to be widely accepted.
I want a pony too! :)
I worry about the illusion that unintentional conflicts are
impossible with DNS based thingies. They aren't. And the mechanism of
coining your own version of a term has big costs.
If you set up some registry that manages e.g. urn:bm:* URNs, how do
you guarantee that someone else (perhaps in Bermuda...) won't start
assigning their own urn:bm:* URNs?
I think my fanciful example is more realistic than *your* fanciful
example...but I would, wouldn't I? :)
This may not be a problem in a closed world, but it is a problem
for anyone who may want to do Google-scale integration.
Well, people overload google search terms all the time. Because
google search terms are natural language. And those search terms work
really well in a lot of cases. So I don't understand your point.
3. If you do want to dereference, and do so with a generic tool
that wasn't specially written to handle life sciences data (most
won't), you are likely to be out of luck if you encounter some
domain-specific resolution system.
I'm sorry, I got lost parsing this. Do you mean that most won't
use a specially written tool or that most won't use a generic tool?
What I'm trying to get at is that there are quite a few non-life-
sciences- specific applications out there that benefit from being
able to resolve URIs,
Is there a list I can see of what you have in mind? I mean, that are
being used now by people interesting in life science terminology.
Even a few examples would help me out here.
but I don't see any of these supporting domain-specific URIs such
as LSID. Of course if the URI isn't resolvable anyway it doesn't
matter (see #1), but if it is, this does seem to be a strong
argument in favor of URLs.
I am generally in favor of stable URLs, but I'm not so sanguine
about the technical simplicity. Perhaps for big databases this is
true: I wouldn't know. Oh, and you do mean HTTP URLs? There are
lots of choices involved there. For example, do I make all my
terms using frag ids or not? This can have a variety of non-
obvious long term effects.
I'll admit it's not at all trivial to have truly stable URIs -- to
be honest, not all of our URIs would meet the criteria at the
moment, either.
But some simple PURL-like system should be within reach of anyone.
Isn't this what's in dispute? In any case, doesn't PURLing sorta kill
the DNS argument? I'm so confused and I fear for the kittens!
Regarding issues such as whether or not to use fragment
identifiers, some guidelines might help, but an agreement on one
solution isn't essential.
This is one of those things that one needs to make a decision on if
one is going to use HTTP uris. It seems mean to recommend people use
HTTP uris and punt on this crucial point.
I certainly find that trying to get people to do stuff that is non-
obviously overall beneficial to them and has uncertain or nebulous
benefits to the common weal is a thankless task. Literally :)
Well, no one in their right mind is going to expend much effort
towards something they don't see as beneficial to themselves :-)
Yep. So if the benefit is *non-obvious* or otherwise diffuse, it's
not going to be a great selling point.
Cheers,
Bijan.
