Donald,

I agree with you that the most important thing right now is getting something working and stop debating. Perfection being the enemy of the good and all that. There are new projects in the works that will be forced to go their own way if TDWG doesn’t choose a standard, if they have not already. The worst thing of all would be to wind up with no interoperability because we couldn’t stop debating.

If LSID is to continue to be the path forward and it is accepted as a standard by the TDWG acceptance process, then I am back to my original appeal:

We need a clear, specific, unambiguous, usable definition of what an LSID is – that is, data, metadata, data+metadata, etc. Perhaps we could make “The Bratislava Declaration” or something that would be a decision, in writing and could be referred to anytime the “LSID isn’t” debate starts up again.

Chuck

Chuck Miller

VP-IT & CIO

Missouri Botanical Garden

St. Louis, MO, USA

From: tdwg-guid-bounces@lists.tdwg.org [mailto:tdwg-guid-bounces@lists.tdwg.org] On Behalf Of Donald Hobern
Sent: Wednesday, June 06, 2007 8:47 AM
To: Roderic Page
Cc: tdwg-guid@lists.tdwg.org
Subject: Re: [tdwg-guid] Handle System considered not interoperable withstandard WWW and SW applications

Rod,

I know we disagree on this one, and I certainly don't want to force the issue against everyone else's better judgment but I think the critical issue is that we need to get moving with trying something seriously and for real. Switching technology later should not be too painful once we get the basic principles right (and the basic principles are the same quite independent of technology).

Some quick points.

1. In answer to your latest question, the (non-technical, more social) issues I mentioned in my previous message are the key reasons I would give for choosing something other than HTTP URIs. We are dealing with a wider community than just IT professionals and need to make a clear separation between assigning an identifier and putting up a web page.

2. LSIDs occupy a space (in my thinking) somewhere between the open, easy, hard-to-control world of HTTP URIs, and the potentially over-centralised administratively heavy world of Handles and DOIs.

3. If we go with LSIDs and subsequently decide we should just use HTTP URIs, we can do so immediately and easily using a proxy like the one TDWG has set up.

4. If we go with HTTP URIs and subsequently decide we should use something like LSIDs, it is likely to be significantly harder to clean up the mess.

Right now we are in a position where a good number of projects has converged on giving LSIDs a serious try. I honestly believe we should build on this and start learning how to use GUIDs in the real world. We can all debate options forever (and go around in circles: "LSIDs are better than URIs because..." - "Handles are better than LSIDs because..." - "URIs are better than Handles because..."), but we must get down to providing some working solutions.

Thanks as ever,

Donald

------------------------------------------------------------

Donald Hobern (dhobern@gbif.org)

Deputy Director for Informatics

Global Biodiversity Information Facility Secretariat

Universitetsparken 15, DK-2100 Copenhagen, Denmark

Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480

------------------------------------------------------------

On Jun 6, 2007, at 3:22 PM, Roderic Page wrote:

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...?

Regards

Rod

On 6 Jun 2007, at 14:13, Ricardo Pereira wrote:

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 all that you said, 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

_______________________________________________

tdwg-guid mailing list

tdwg-guid@lists.tdwg.org

http://lists.tdwg.org/mailman/listinfo/tdwg-guid