[tdwg-guid] Handle System considered not interoperable with standard WWW and SW applications
ricardo at tdwg.org
Wed Jun 6 15:13:24 CEST 2007
Roderic Page wrote:
> 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
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
> 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.
More information about the tdwg-tag