Re: Does follow-your-nose apply in the enterprise? was: RDF for molecules, using InChI

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 :-)

Received on Tuesday, 21 August 2007 10:55:41 UTC