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. In fact now that most of our URIs
are resolvable I get a lot less complaints and live a happier life :-)
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...
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.
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.
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? 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.
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, 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.
Regarding issues such as whether or not to use fragment identifiers, some
guidelines might help, but an agreement on one solution isn't essential.
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 :-)