W3C home > Mailing lists > Public > public-semweb-lifesci@w3.org > August 2006

Re: LSID lookup details: help? [was: All about the LSID URI/URN]

From: Benjamin H Szekely <bhszekel@us.ibm.com>
Date: Tue, 1 Aug 2006 00:00:54 -0400
To: Dan Connolly <connolly@w3.org>
Cc: Alan Ruttenberg <alanruttenberg@gmail.com>, "Henry S. Thompson" <ht@inf.ed.ac.uk>, jbarkley@nist.gov, Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, public-semweb-lifesci@w3.org, public-semweb-lifesci-request@w3.org, Sean Martin <sjmm@us.ibm.com>
Message-ID: <OFF7C23682.6356B4F7-ON852571BD.0010E0D2-852571BD.00160F41@us.ibm.com>
Ben Szekely
IBM Software Engineer
Advanced Internet Technology, Cambridge, MA
bhszekel@us.ibm.com

public-semweb-lifesci-request@w3.org wrote on 07/31/2006 10:57:30 PM:

> 
> On Mon, 2006-07-31 at 15:27 -0400, jbarkley@nist.gov wrote:
> > dan,
> > 
> > I recall reading that the PDB Resolver is offline pending 
> > upgrades.
> 
> Ah... so 404 happens in the LSID world too. :)

The answer is true, contract does not state that an authority need serve 
the named item for ever, just that it may never serve another item with 
the same name.  Thoug it doesn't resolve, the LSID still has meaning as a 
name.  For example, organizations who have made use of the PDB data, might 
have cached copies of many of the PDB LSIDs and their internal resolution 
services may continue to provide those LSIDs to their internal users. 

> 
> Wait... isn't this exactly the case where the software
> is supposed to fall back to DDNS/NAPTR stuff? Is that
> fallback mechanism not deployed in some/all/most LSID clients?

Otherway around...if you lookup an authority in DDNS/NAPTR and you don't 
find in, then fallback to Dns...unfortunately, in this case we are all out 
of luck as I don't believe the PDB has implemented the final version of 
the protocol yet (it was the site of the first experiments which is 
probably why that example persists) 

> 
> > You might try urn:lsid:gdb.org:GenomicSegment:GDB132938 
> > which does work with the BioPathways Resolver:
> > 
> > http://lsid.biopathways.org/resolver/urn:lsid:gdb.org:Genom
> > icSegment:GDB132938
> 
> I'm not sure what you mean... do I need to know a resolver
> as well as an LSID in order to look up the LSID? i.e. does
> it work like USENET news, where I need to know a nearby
> NNTP server as well as a message ID?

No you don't need to know a resolver as well as an  LSID. The resolution 
protocol finds you the appropriate data service for the authority named in 
the LSID.  In addition if we were to add to the specification the  HTTP 
Gateway  that Sean has been talking about., *any* such  gateway can 
provide the data for  *any* visible LSID. One would always be able to find 
a copy of the gateway at http://lsid.info/  using DNS, or a local version 
of the same gateway software mapped onto the name lsid.info in local DNS. 
The gateway software uses the  LSID resolution protocol to find where the 
data service for the requested LSID  resides in the same way that any LSID 
client software does and fetches the gateway a copy of the data which it 
may cache for as long as it likes and serve out on a second request for 
that LSID to that gateway.. 

> 
> 
> This perl software I found seems to do something with that LSID
> even when I don't tell it about biopathways.org...
> 
> 
> ~/src/lsid-perl-1.1.4$ perl examples/client/lsid_client.pl
> urn:lsid:gdb.org:GenomicSegment:GDB132938
> Client settings:
> Cleaning cache:
>         no
> 
> LSID Given:
>         urn:lsid:gdb.org:GenomicSegment:GDB132938
> 
> Canonicalized LSID:
>         urn:lsid:gdb.org:GenomicSegment:GDB132938
> 
> The authority is located at:
>         lsid.gdb.org:80/authority/
> 
> For the resource identified by the LSID:
> 
> Service: 'gdbSOAP', DATA can be retrieved at:
> 
> 
> Service: 'gdb', DATA can be retrieved at:
> 
> 
> Service: 'gdbSOAP', METADATA can be retreived at:
>         (soap) http://lsid.gdb.org:80/authority/metadata
> 
> 
> Service: 'gdb', METADATA can be retreived at:
>         (http)
> http://lsid.gdb.org:80/authority/metadata/?lsid=urn:lsid:gdb.org:
> GenomicSegment:GDB132938

 Correct, the Perl client software you found, is exactly what is running 
behind lsid.biopwathways.org/resolver and in this case it found a metadata 
document for that LSID retrievable either via SOAP or via http, the client 
can choose which.  

> 
> 
> 
> > jb
> > 
> > 
> > 
> > Quoting Dan Connolly <connolly@w3.org>:
> > 
> > > 
> > > In today's call, I learned a bit about how LSID lookup
> > > works:
> > > 
> > >  (1) try to find an SRV record using the domain in the
> > > LSID
> > >  (2) fall back to a DDDS lookup and NAPTR and such
> > > 
> > >[...]
> > > > 
> > > [1] http://www.omg.org/cgi-bin/doc?dtc/04-05-01
> > > [2] 
> > > http://easynews.dl.sourceforge.net/sourceforge/lsid/lsid-
> > perl-1.1.4.tar.gz
> > >  <- http://lsid.sourceforge.net/
> > > 
> -- 
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
> 
> 
Received on Tuesday, 1 August 2006 04:01:15 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:00:44 GMT