- 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 UTC