Donald, Ricardo,
I fully agree with you and Rod that we need to go forward as fast as possible and dont need yet another discussion. If everyone else is pleased with LSIDs I will keep silent, promised. LSIDs are better than nothing. But if we would use URLs we could go a lot faster 'cause its so much easier. Especially now after all the lessons learned.
Still some comments below inline Markus
On 06.06.2007, at 16:00, Ricardo Pereira wrote:
Roderic Page wrote:
This all begs the question, is there anything LSIDs give us that HTTP URIs don't?
To me, the key difference between plain HTTP URIs and LSIDs with the proxy proposal is that LSIDs name objects with pure identifiers (the capital N in URN), while HTTP URIs mix names with locations.
If we use the LSID specification with the proxy proposal, the identifier associated permanently with the object is the pure LSID in the form:
urn:lsid:authority.org:namespace:objectId
which is completely independent of transfer protocol and thus may remain associated with the object for hundreds of years. If HTTP or DNS or whatever goes away, our grandchildren can still rebuild the links between ids and objects using whatever technologies are available in year 2207. More importantly, such a hypothetical new solution would likely be elegant because that particular URN was solely designed to name objects.
How does LSID resolution work without DNS? If the DNS-less LSID is just about persistent global *naming* and not *resolution*, then we can use UUIDs and be happy
On the other hand, if we use HTTP URIs and that eventually goes away, we would need to come up with a hack to keep the ids associated with the objects. Also, HTTP URIs were originally designed to locate resources (the last T on HTTP), not to name them. So, in my opinion, using HTTP to name objects is a bit of a hack (i.e. not very elegant). You end up trying to dereference IDs that were not meant to be dereferenced, which only contribute to link rot.
Another point is in relation to link rot. Although the article "Cool URIs Don't Change" provides very useful ideas about how to make HTTP URIs permanent (which I literally use on every link on the TDWG website), they don't completely solve the link rot problem. We still have to deal with reorganizations in our web servers and managing a stack of Apache rewrite rules is no fun. LSIDs on the other hand solve part of the problem, at least those associated with path portion of the HTTP URI. LSIDs however present the same persistence problems associated with DNS. To reduce that problem, TDWG offers DNS entries of the form *.lsid.tdwg.org for LSID authorities in our domain.
I can't see any big difference between LSID based redirection and http redirection a la PURL. What makes LSIDs easier to maintain for the final provider?
So, in my opinion, these are strong reasons not to use only HTTP URIs to name our objects.
Cheers,
Ricardo
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
Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom
Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page@bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html iChat: aim://rodpage1962 reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html
Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/ portal/ Find out what we know about a species: http://ispecies.org Rod's rants on phyloinformatics: http://iphylo.blogspot.com Rod's rants on ants: http://semant.blogspot.com
tdwg-guid mailing list tdwg-guid@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-guid