[tdwg-guid] Handle System considered not interoperable with standard WWW and SW applications
m.doering at bgbm.org
Wed Jun 6 17:22:03 CEST 2007
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
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:
> 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.
>> If we go to all this trouble to make LSIDs behave as if they were
>> HTTP URIs, isn't this tell us something...?
>> On 6 Jun 2007, at 14:13, Ricardo Pereira wrote:
>>> 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
>>> 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/
>>> 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
>>> tdwg-guid mailing list
>>> tdwg-guid at lists.tdwg.org
>> 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 at 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/
>> 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 at lists.tdwg.org
More information about the tdwg-tag