[tdwg-guid] Handle System considered not interoperable with standard WWW and SW applications

[Ricardo Pereira]

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.

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.

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 at 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 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/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
>
>