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.
I agree. That's why we are putting forward the LSID HTTP proxy recommendations (http://wiki.tdwg.org/twiki/bin/view/GUID/LsidHttpProxyUsageRecommendation). And there will be at least one LSID proxy (that at http://lsid.tdwg.org/) that will play ball pretty soon. That proxy does all that you said, but it just doesn't perform the content-negotiation bit yet. But I'm currently working on that.
In principle we can do the same sort of thing for Handles (there is code for a proxy servlet at http://www.handle.net/proxy_servlet.html).
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