Re: IDs + 5; everybody - 10

Well, to do a fair comparison of LSID URIs and HTTP URIs, you would
have to take all the features you need, see how to best implement them
in both contexts, and then make an overall assessment. I think I can
see now how to replicate the features I've heard stated as good about
LSIDs using a useful subset of HTTP URIs (an interesting exercise; I'm
sorry but I haven't written this up yet, please be patient, but hint:
it involves use of RDF). The question is whether the URI-based
solutions are too much work to implement, too inefficient for general
use, or otherwise fail in some way, compared to the cost of using

What is your worry, by the way? Would bringing the benefits of LSIDs
to other parts of the URI space be a bad thing?

The only LSID benefit I'm not really clear about is the idea that they
should not be suggestive of use as a locator. I find this a bit
confusing since you can use them as locators: look up authority with
DNS, get resolver WSDL, etc. - sure you bounce from the naming
authority to the resolver but that's not hugely different from HTTP
30x's that bounce from the named host to some other host. Yes, the
data can be located in other ways as well, but that's also true of

My opinion is that if you want to avoid the locator suggestion
entirely, go the route of handles and use names for authorities that
don't look at all like domain names.

There is the criticism of HTTP URIs that they cannot be used as
identifiers, and I admit that the pun with URLs can be misleading.
However, like it or not, they are being used as identifiers. My
opinion is that even though it makes some people squirm and invites
misinterpretation, this approach can probably be made to work. I don't
see the identifier/locator pun (hateful to some, essential to others,
an apparently unresolvable debate) as sufficient reason for W3C HCLSIG
to be incompatible with W3C. There may be other reasons, but I don't
think this one is strong enough to be a deal breaker.

To repeat, I'm just trying to be objective. I am not in a position to
make decisions; I am just trying to elucidate the comparison between
the two naming schemes so that HCLS can make a rational decision. I
was the one at the Amsterdam HCLS meeting, at which there were no LSID
defenders, saying that we ought to listen to what LSID users have to
say, and in many private conversations I have been coming to the
defense of benefits that LSIDs have that HTTP URIs so far lack. And
I've finally gotten around to reading the darned spec. So I hope you
LSIDers don't think you're being dissed.


On 7/16/07, Phillip Lord <> wrote:
> My apologies. I wasn't sure, which is why I asked. I just found your idea of
> reproducing LSIDs advantages (and implicitly DOI) in http a little worrying.
> I may have misread your email.
> Phi
> >>>>> "JR" == Jonathan Rees <> writes:
>   JR> I never said LSID or DOIs shouldn't be used, and I don't see how my
>   JR> message can be construed as saying this. I'm trying to be fair to all
>   JR> solutions by talking about real technical requirements. If the W3C HCLS
>   JR> SIG wants to recommend the use - even minting - of LSIDs, that's fine
>   JR> with me. But I don't think any decisions have been reached.
>   JR> LSID users are committed to using HTTP URIs. For example, anyone who
>   JR> uses both LSID and RDF is committed to using the HTTP URI
>   JR>
>   JR> Jonathan
>   JR> On 7/16/07, Phillip Lord <> wrote:
>   >> >>>>> "JR" == Jonathan Rees <> writes:
>   >>
>   JR> It may look like unnecessary replication, but it's not really, since
>   JR> we're already committed to the http: space and all the issues that LSID
>   JR> addressed are issues there as well.
>   >>
>   JR> The same remarks apply to handles, DOIs in particular.
>   >>
>   >>
>   >> Are you suggesting that DOIs shouldn't be used either?
>   >>
>   >> Phil
>   >>
> --
> Phillip Lord,                           Phone: +44 (0) 191 222 7827
> Lecturer in Bioinformatics,             Email:
> School of Computing Science,  
> Claremont Tower Room 909,               skype: russet_apples
> Newcastle University,
> NE1 7RU

Received on Wednesday, 18 July 2007 03:38:19 UTC