On 21 Aug 2007, at 10:12, Eric Jain wrote:
Bijan Parsia wrote:
I don't really see why HTTP uris are preferred, even as a default.
I think the argument is really simple:
Thanks!
1. If you do not want to dereference, I don't see why you would
care whether a URI is a URL or a URN or whatnot -- as long as it is
unique.
This was addressed in this thread. HTTP uris create expectations of
dereferencing and are generally reported as bugs if they don't
dereference.
2. The most practical solution to the uniqueness problem is to
build on top of an established registration system such as the
domain name system.
Would you mind restating the uniqueness problem for me? It seems that
there are several possible problems:
1. I make a new name for something that already has a name.
2. I use a name for two things.
3. I have alternative conflicting statements involving a name (but
there's no belief that the name names two things or there's another
name for the object of discussion)
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.
(Presumably 1 is to be handled by them being "more discoverable". But
as far as I can tell the marginal gain of using HTTP uris for
individual terms is the follow-your-nose-discoverability stuff which
requires its own justification.
If you think you can come up with something better that's going to
be accepted as widely, that's great, but forgive me for not holding
my breath...
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.
Lest I seem too nitpicky,
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?
If the W3C can encourage life science databases to provide stable
URLs (which is simple enough that it shouldn't be a technical
problem for any of them, don't even need to buy into any of the
semantic web stuff to see that this is useful), this would already
make the world a better place (TM).
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.
(The more cynical point of view would be that people are not
influenced by such recommendations, in which case this discussion
is rather pointless :-)
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 :)
Anyhoo. This seems neither here nor there. Perhaps it's worth
phrasing some of these disputes in a problem statement then pro-con
various solutions way? I have three possible problems with minting or
using terms list above, perhaps we could start with one of those and
try to capture all the considerations? We could do this on the wiki
or in email. It might be more productive than an inherently
argumentative exchange.
Cheers,
Bijan.
