This all begs the question, is there anything LSIDs give us that HTTP URIs don't?
If we go to all this trouble to make LSIDs behave as if they were HTTP URIs, isn't this tell us something...?
Roderic Page wrote:
Ricardo,
I think your arguments pretty much apply to LSIDs as well. By themselves, they don't play ball with the WWW or the Semantic Web.
For LSIDs we need a proxy that understands SOAP, can talk to the DNS, read WSDL files, and then do an HTTP look-up. You only get LSIDs to play ball by using a proxy that plays ball.
Only if handle types fully matched the standard WWW content types. They could match if we defined handle types for our own community, but they won't ever match with the types defined by other communities like DOI and others using Handles.
On the other hand, LSID spec allows us to implement standard content negotiation seamlessly because the semantics of the argument *accepted_formats* in the LSID getMetadata call is appropriate for that purpose.
I'm not necessarily defending Handles, but I think our choice needs to be well-informed. I still don't think the case for LSIDs has really been made (or, at least, some of the arguments advanced in favour of LSIDs apply equally well, if not better, to other technologies).
I agree with you on this. The case for LSIDs wasn't strong enough because the original proposal doesn't integrate well with HTTP. That is exactly why we are putting forward the LSID HTTP proxy proposal. It was the missing point in the LSID case.
In any case, I suppose we will talk more about this in the near future.
Cheers,
Ricardo
_______________________________________________
tdwg-guid mailing list
----------------------------------------------------------------------------------------------------------------
Professor Roderic D. M. Page