June 2006 - tdwg-tag - lists.tdwg.org

GUID-2 Report
by Ricardo Scachetti Pereira 29 Jun '06

29 Jun '06

Dear mailing list subscriber, The Taxonomic Databases Working Group (TDWG, http://www.tdwg.org/) with support from the Gordon and Betty Moore Foundation has just held the second of two workshops to address the need for a system of globally unique identifiers (GUID) for use in biodiversity informatics. The report describing the outcomes of the meeting and the plans for deployment of LSIDs in our community is available at: http://www.tdwg.gbif.org/fileadmin/subgroups/tip/GUID2Report.pdf (PDF) http://wiki.gbif.org/guidwiki/wikka.php?wakka=GUID2Report (web page) We are encouraging feedback on the report and particularly the deployment strategy. Please send your comments to the TDWG-GUID mailing list at tdwg-guid(a)mailman.nhm.ku.edu, or add them to the TDWG-GUID wiki at http://wiki.gbif.org/guidwiki/wikka.php?wakka=GUID2ReportComments. Sincerely, Donald Hobern, Ricardo Pereira and Lee Belbin

1 0

[Tdwg-guid] Paper
by Lee Belbin 28 Jun '06

28 Jun '06

Dear all Rod Page has just published an excellent paper "Taxonomic names, metadata, and the Semantic Web" http://jbi.nhm.ku.edu/index.php/jbi This paper spurred me to ask Ricardo to start setting up a list of LSID-related resources on the new TDWG web site. If you are aware of any, please send the link to Ricardo and we will keep you posted on developments. Cheers Lee Lee Belbin Manager, TDWG Infrastructure Project Email: lee(a)tdwg.org Phone: +61(0)419 374 133

1 0

[Tdwg-guid] GUID-2 Report
by Ricardo Scachetti Pereira 27 Jun '06

27 Jun '06

Dear TDWG-GUID mailing list subscriber, The Taxonomic Databases Working Group (TDWG, http://www.tdwg.org/) with support from the Gordon and Betty Moore Foundation has just held the second of two workshops to address the need for a system of globally unique identifiers (GUID) for use in biodiversity informatics. The report describing the outcomes of the meeting and the plans for deployment of LSIDs in our community is available at: http://www.tdwg.gbif.org/fileadmin/subgroups/tip/GUID2Report.pdf (PDF format) http://wiki.gbif.org/guidwiki/wikka.php?wakka=GUID2Report (web page) We are encouraging feedback on the report and particularly the deployment strategy. Please send your comments to the TDWG-GUID mailing list at tdwg-guid(a)mailman.nhm.ku.edu, or add them to the TDWG-GUID wiki at http://wiki.gbif.org/guidwiki/wikka.php?wakka=GUID2ReportComments. Sincerely, Donald Hobern, Ricardo Pereira and Lee Belbin

1 0

Mailing list will be unavailable on Monday
by Ricardo Scachetti Pereira 27 Jun '06

27 Jun '06

Dear TDWG mailing list subscriber, This mailing list will be unavailable from Monday, June 26, 2006 at 3:00 PM to Tuesday, June 27, 2006 at approximately 11:00 AM (UTC time), due to a scheduled migration between servers. The migration will be transparent to you (except for the downtime) as we will transfer all of your subscription information to the new server and will keep this list web and email addresses the same. We will let you know when the mailing list is back on-line. Thanks for your understanding and sorry for the inconvenience. Regards, Ricardo PS. This message does not apply to TDWG nor TDWG-GUID mailing lists.

1 1

Re: [Tdwg-guid] Throttling searches [ Scanned for viruses ]
by Paul Kirk 20 Jun '06

20 Jun '06

It can be a problem but I'm not sure if there is a simple solution ... and how different is the LSID crawler scenario from an http://www.ipni.org/ipni/plantsearch?id= 1,2,3,4,5 ... 9999999 scenario? Paul -----Original Message----- From: tdwg-guid-bounces(a)mailman.nhm.ku.edu [mailto:tdwg-guid-bounces@mailman.nhm.ku.edu]On Behalf Of Sally Hinchcliffe Sent: 15 June 2006 12:08 To: tdwg-guid(a)mailman.nhm.ku.edu Subject: [Tdwg-guid] Throttling searches [ Scanned for viruses ] Hi all another question that has come up here. As discussed at the meeting, we're thinking of providing a complete download of all IPNI LSIDs plus a label (name and author, probably) which will be available as an annually produced download Most people will play nice and just resolve one or two LSIDs as required, but by providing a complete list, we're making it very easy for someone to write a crawler that hits every LSID in turn and basically brings our server to its knees Anybody know of a good way of enforcing more polite behaviour? We can make the download only available under a data supply agreement that includes a clause limiting hit rates, or we could limit by IP address (but this would ultimately block out services like Rod's simple resolver). I beleive Google's spell checker uses a key which has to be passed in as part of the query - obviously we can't do that with LSIDs Any thoughts? Anyone think this is a problem? Sally *** Sally Hinchcliffe *** Computer section, Royal Botanic Gardens, Kew *** tel: +44 (0)20 8332 5708 *** S.Hinchcliffe(a)rbgkew.org.uk _______________________________________________ TDWG-GUID mailing list TDWG-GUID(a)mailman.nhm.ku.edu http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid

9 21

[Tdwg-guid] Interest in versions - evidence from IPNI logs
by Sally Hinchcliffe 20 Jun '06

20 Jun '06

Hi all, As promised I've had a look at the ipni logs to see whether people are interested in particular versions of records or not. At the moment, the logs don't record that information directly, but I can see whether a user has clicked on the link to see the history of a record (a pre-requisite for clicking on an older version). I eliminated obvious crawlers and looked at just one server's queries for the week of 4th - 10th June, comparing the number of drill downs (into an individual record) with the number of history requests. Basically there were just under 5000 drill downs, of which 570 (10%) were followed by history requests, which was a slightly higher percentage than I was expecting. Some of these may simply be idle clickers looking out of curiosity, of course, but it does suggest that while most people aren't interested in versions, there is a significant minority who may have a need/interest/desire to see specific versions of records. Sally *** Sally Hinchcliffe *** Computer section, Royal Botanic Gardens, Kew *** tel: +44 (0)20 8332 5708 *** S.Hinchcliffe(a)rbgkew.org.uk

1 0

Re: [Tdwg-guid] Throttling searches [ Scanned for viruses ]
by Kevin Richards 19 Jun '06

19 Jun '06

The LSID framework has provision for basic security (HTTP credentials), so this could be used for identifying end users and controlling the degree of their activity. Kevin >>> Roger Hyam <roger(a)tdwg.org> 19/06/2006 9:30 p.m. >>> I think the only way to throttle in these situations is to have some notion of who the client is and the only way to do that is to have some kind of token exchange over HTTP saying who they are. Basically you have to have some kind of client registration system or you can never distinguish between a call from a new client and a repeat call. The use of IP address is a pain because so many people are now behind some kind of NAT gateway. How about this for a plan: You could give a degraded services to people who don't pass a token (a 5 second delay perhaps) and offer a quicker service to registered users who pass a token (but then perhaps limit the number of calls they make). This would mean you could offer a universal service even to those with naive client software but a better service to those who play nicely. You could also get better stats on who is using the service. So there are ways that this could be done. I expect people will come up with a host of different ways. It is outside LSIDs though. Roger Sally Hinchcliffe wrote: It's not an LSID issue per se, but LSIDs will make it harder to slow searches down. For instance, Google restricts use of its spell checker to 1000 a day by use of a key which is passed in with each request. Obviously this can't be done with LSIDs as then they wouldn't be the same for each user.The other reason why it's relevant to LSIDs is simply that providing a list of all relevant IPNI LSIDs (not necessary to the LSID implementation but a nice to have for caching / lookups for other systems using our LSIDs) also makes life easier for the datascrapers to operateAlso I thought ... here's a list full of clever people perhaps they will have some suggestions Sally Is this an LSID issue? LSIDs essential provide a binding service between an name and one or more web services (we default to HTTP GET bindings). It isn't really up to the LSID authority to administer any policies regarding the web service but simply to point at it. It is up to the web service to do things like throttling, authentication and authorization.Imagine, for example, that the different services had different policies. It may be reasonable not to restrict the getMetadata() calls but to restrict the getData() calls.The use of LSIDs does not create any new problems that weren't there with web page scraping - or scraping of any other web service.Just my thoughts...RogerRicardo Scachetti Pereira wrote: Sally, You raised a really important issue that we had not really addressed at the meeting. Thanks for that. I would say that we should not constrain the resolution of LSIDs if we expect our LSID infrastructure to work. LSIDs will be the basis of our architecture so we better have good support for that. However, that is sure a limiting factor. Also server efficiency will likely vary quite a lot, depending on underlying system optimizations and all. So I think that the solution for this problem is in caching LSID responses on the server LSID stack. Basically, after resolving an LSID once, your server should be able to resolve it again and again really quickly, until something on the metadata that is related to that id changes. I haven't looked at this aspect of the LSID software stack, but maybe others can say something about it. In any case I'll do some research on it and get back to you. Again, thanks for bringing it up. Cheers,RicardoSally Hinchcliffe wrote: There are enough discontinuities in IPNI ids that 1,2,3 would quickly run into the sand. I agree it's not a new problem - I just hate to think I'm making life easier for the data scrapersSally It can be a problem but I'm not sure if there is a simple solution ... and how different is the LSID crawler scenario from an http://www.ipni.org/ipni/plantsearch?id= 1,2,3,4,5 ... 9999999 scenario?Paul-----Original Message-----From: tdwg-guid-bounces@mailman.nhm.ku.edu[mailto:tdwg-guid-bounces@mailman.nhm.ku.edu]On Behalf Of SallyHinchcliffeSent: 15 June 2006 12:08To: tdwg-guid(a)mailman.nhm.ku.eduSubject: [Tdwg-guid] Throttling searches [ Scanned for viruses ]Hi allanother question that has come up here. As discussed at the meeting, we're thinking of providing a complete download of all IPNI LSIDs plus a label (name and author, probably) which will be available as an annually produced downloadMost people will play nice and just resolve one or two LSIDs as required, but by providing a complete list, we're making it very easy for someone to write a crawler that hits every LSID in turn and basically brings our server to its kneesAnybody know of a good way of enforcing more polite behaviour? We can make the download only available under a data supply agreement that includes a clause limiting hit rates, or we could limit by IP address (but this would ultimately block out services like Rod's simple resolver). I beleive Google's spell checker uses a key which has to be passed in as part of the query - obviously we can't do that with LSIDsAny thoughts? Anyone think this is a problem? Sally*** Sally Hinchcliffe*** Computer section, Royal Botanic Gardens, Kew*** tel: +44 (0)20 8332 5708*** S.Hinchcliffe(a)rbgkew.org.uk_______________________________________________TDWG-GUID mailing listTDWG-GUID@mailman.nhm.ku.eduhttp://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid_______________________________________________TDWG-GUID mailing listTDWG-GUID@mailman.nhm.ku.eduhttp://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid *** Sally Hinchcliffe*** Computer section, Royal Botanic Gardens, Kew*** tel: +44 (0)20 8332 5708*** S.Hinchcliffe(a)rbgkew.org.uk_______________________________________________TDWG-GUID mailing listTDWG-GUID@mailman.nhm.ku.eduhttp://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid _______________________________________________TDWG-GUID mailing listTDWG-GUID@mailman.nhm.ku.eduhttp://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782------------------------------------- *** Sally Hinchcliffe*** Computer section, Royal Botanic Gardens, Kew*** tel: +44 (0)20 8332 5708*** S.Hinchcliffe(a)rbgkew.org.uk -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782------------------------------------- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WARNING: This email and any attachments may be confidential and/or privileged. They are intended for the addressee only and are not to be read, used, copied or disseminated by anyone receiving them in error. If you are not the intended recipient, please notify the sender by return email and delete this message and any attachments. The views expressed in this email are those of the sender and do not necessarily reflect the official views of Landcare Research. Landcare Research http://www.landcareresearch.co.nz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: [Tdwg-guid] Throttling searches [ Scanned for viruses ]
by Paul Kirk 19 Jun '06

19 Jun '06

right behind Sally on this one. for there is a potential bigger problem here than just the unwanted attention of data scrapers - I prefer harvesters - like army ants ... ;-) ... because the effect of harvesting could be the same. All Species did it to Index Fungorum, if they had 'cornered the market', serving their rapidy past it's sell by date harvest (and apologetic acknowledgement of source) it could kill Index Fungorum and then where would we all be? Picking up the pieces and trying to fill in the gap between the death of IF and the birth of it's replacement ... Paul -----Original Message----- From: tdwg-guid-bounces(a)mailman.nhm.ku.edu [mailto:tdwg-guid-bounces@mailman.nhm.ku.edu]On Behalf Of Roderic Page Sent: 19 June 2006 10:15 To: S.Hinchcliffe(a)kew.org Cc: tdwg-guid(a)mailman.nhm.ku.edu Subject: Re: [Tdwg-guid] Throttling searches [ Scanned for viruses ] I gotta ask -- what is so bad about making life easy for data scrapers (of which I'm one)? Isn't this rather the point -- we WANT to make it easy :-) But, I do realise that providers may run into a problem of being overwhelmed by requests (though, wouldn't that be nice -- people actually want your data). The NCBI throttles by asking people not to hammer the service, and some people leave around half a sec between requests to avoid being blocked. Connotea is thinking of "making the trigger be >10 requests within the last 15 seconds; requests arriving faster than that will be give a 503 response with a Retry-After header.", if that makes any sense. You could also provide a service for data scrapers where they can get an RDF dump of the IPNI names, rather than have to scrape them. Regards Rod On 19 Jun 2006, at 10:02, Sally Hinchcliffe wrote: > It's not an LSID issue per se, but LSIDs will make it harder to slow > searches down. For instance, Google restricts use of its spell > checker to 1000 a day by use of a key which is passed in with each > request. Obviously this can't be done with LSIDs as then they > wouldn't be the same for each user. > The other reason why it's relevant to LSIDs is simply that providing > a list of all relevant IPNI LSIDs (not necessary to the LSID > implementation but a nice to have for caching / lookups for other > systems using our LSIDs) also makes life easier for the datascrapers > to operate > > Also I thought ... here's a list full of clever people perhaps they > will have some suggestions > > Sally > >> >> Is this an LSID issue? LSIDs essential provide a binding service >> between >> an name and one or more web services (we default to HTTP GET >> bindings). >> It isn't really up to the LSID authority to administer any policies >> regarding the web service but simply to point at it. It is up to the >> web >> service to do things like throttling, authentication and >> authorization. >> >> Imagine, for example, that the different services had different >> policies. It may be reasonable not to restrict the getMetadata() calls >> but to restrict the getData() calls. >> >> The use of LSIDs does not create any new problems that weren't there >> with web page scraping - or scraping of any other web service. >> >> Just my thoughts... >> >> Roger >> >> >> Ricardo Scachetti Pereira wrote: >>> Sally, >>> >>> You raised a really important issue that we had not really >>> addressed >>> at the meeting. Thanks for that. >>> >>> I would say that we should not constrain the resolution of LSIDs >>> if >>> we expect our LSID infrastructure to work. LSIDs will be the basis of >>> our architecture so we better have good support for that. >>> >>> However, that is sure a limiting factor. Also server efficiency >>> will >>> likely vary quite a lot, depending on underlying system optimizations >>> and all. >>> >>> So I think that the solution for this problem is in caching LSID >>> responses on the server LSID stack. Basically, after resolving an >>> LSID >>> once, your server should be able to resolve it again and again really >>> quickly, until something on the metadata that is related to that id >>> changes. >>> >>> I haven't looked at this aspect of the LSID software stack, but >>> maybe others can say something about it. In any case I'll do some >>> research on it and get back to you. >>> >>> Again, thanks for bringing it up. >>> >>> Cheers, >>> >>> Ricardo >>> >>> >>> Sally Hinchcliffe wrote: >>> >>>> There are enough discontinuities in IPNI ids that 1,2,3 would >>>> quickly >>>> run into the sand. I agree it's not a new problem - I just hate to >>>> think I'm making life easier for the data scrapers >>>> Sally >>>> >>>> >>>> >>>> >>>>> It can be a problem but I'm not sure if there is a simple solution >>>>> ... and how different is the LSID crawler scenario from an >>>>> http://www.ipni.org/ipni/plantsearch?id= 1,2,3,4,5 ... 9999999 >>>>> scenario? >>>>> >>>>> Paul >>>>> >>>>> -----Original Message----- >>>>> From: tdwg-guid-bounces(a)mailman.nhm.ku.edu >>>>> [mailto:tdwg-guid-bounces@mailman.nhm.ku.edu]On Behalf Of Sally >>>>> Hinchcliffe >>>>> Sent: 15 June 2006 12:08 >>>>> To: tdwg-guid(a)mailman.nhm.ku.edu >>>>> Subject: [Tdwg-guid] Throttling searches [ Scanned for viruses ] >>>>> >>>>> >>>>> Hi all >>>>> another question that has come up here. >>>>> >>>>> As discussed at the meeting, we're thinking of providing a complete >>>>> download of all IPNI LSIDs plus a label (name and author, probably) >>>>> which will be available as an annually produced download >>>>> >>>>> Most people will play nice and just resolve one or two LSIDs as >>>>> required, but by providing a complete list, we're making it very >>>>> easy >>>>> for someone to write a crawler that hits every LSID in turn and >>>>> basically brings our server to its knees >>>>> >>>>> Anybody know of a good way of enforcing more polite behaviour? We >>>>> can >>>>> make the download only available under a data supply agreement that >>>>> includes a clause limiting hit rates, or we could limit by IP >>>>> address >>>>> (but this would ultimately block out services like Rod's simple >>>>> resolver). I beleive Google's spell checker uses a key which has to >>>>> be passed in as part of the query - obviously we can't do that with >>>>> LSIDs >>>>> >>>>> Any thoughts? Anyone think this is a problem? >>>>> >>>>> Sally >>>>> *** Sally Hinchcliffe >>>>> *** Computer section, Royal Botanic Gardens, Kew >>>>> *** tel: +44 (0)20 8332 5708 >>>>> *** S.Hinchcliffe(a)rbgkew.org.uk >>>>> >>>>> >>>>> _______________________________________________ >>>>> TDWG-GUID mailing list >>>>> TDWG-GUID(a)mailman.nhm.ku.edu >>>>> http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid >>>>> >>>>> _______________________________________________ >>>>> TDWG-GUID mailing list >>>>> TDWG-GUID(a)mailman.nhm.ku.edu >>>>> http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid >>>>> >>>>> >>>> *** Sally Hinchcliffe >>>> *** Computer section, Royal Botanic Gardens, Kew >>>> *** tel: +44 (0)20 8332 5708 >>>> *** S.Hinchcliffe(a)rbgkew.org.uk >>>> >>>> >>>> _______________________________________________ >>>> TDWG-GUID mailing list >>>> TDWG-GUID(a)mailman.nhm.ku.edu >>>> http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> TDWG-GUID mailing list >>> TDWG-GUID(a)mailman.nhm.ku.edu >>> http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid >>> >>> >> >> >> -- >> >> ------------------------------------- >> Roger Hyam >> Technical Architect >> Taxonomic Databases Working Group >> ------------------------------------- >> http://www.tdwg.org >> roger(a)tdwg.org >> +44 1578 722782 >> ------------------------------------- >> >> > > *** Sally Hinchcliffe > *** Computer section, Royal Botanic Gardens, Kew > *** tel: +44 (0)20 8332 5708 > *** S.Hinchcliffe(a)rbgkew.org.uk > > > _______________________________________________ > TDWG-GUID mailing list > TDWG-GUID(a)mailman.nhm.ku.edu > http://mailman.nhm.ku.edu/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(a)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 ___________________________________________________________ Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html _______________________________________________ TDWG-GUID mailing list TDWG-GUID(a)mailman.nhm.ku.edu http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid

1 0

Re: [Tdwg-guid] Simple LSID resolver [ Scanned for viruses ]
by Paul Kirk 19 Jun '06

19 Jun '06

lsid.ipni.org doesn't ping either ... ;-) first I've heard of a requirement for a 'subdomain' lsid.indexfungorum.org ... do I need to set one up? Paul -----Original Message----- From: tdwg-guid-bounces(a)mailman.nhm.ku.edu [mailto:tdwg-guid-bounces@mailman.nhm.ku.edu]On Behalf Of Roderic Page Sent: 19 June 2006 08:06 To: Kevin Richards Cc: tdwg-guid(a)mailman.nhm.ku.edu Subject: Re: [Tdwg-guid] Simple LSID resolver [ Scanned for viruses ] Ricardo notes that I've duplicated what Biopathways.org already provides (albeit with the use longer URLs). However, there are a couple of reasons for persisting in this. Firstly, I like short URLs. Secondly, I find having another implementation (and one that I can play with) to be useful. For example, Biopathways.org caches the metadata, so the links given by Ricardo work. I don't cache the metadata, and hence discover that the IndexFungorum LSID authority seems broken. The LSID resolves to host lsid.indexfungorum.org:8080, but if I ping lsid.indexfungorum.org I get nothing back, and my LSID resolver eventually fails with HTTP 504. What I think would be nice is to return metadata with a XSLT style sheet, so that the browser displays nice HTML, but view-source displays XML (which is also what a script would get), so that it supports both people and machines. For an example of this, see the handle demo for a paper on ants (http://hdl.handle.net/2254/20791) and view the source. Lastly, I need a LSID client for my ant stuff, so developing the resolver helps me debug this code. Regards Rod On 18 Jun 2006, at 23:54, Kevin Richards wrote: > Ok, I think I see where you are coming from now. > You want a URL that you can prepend to ANY LSID to resolve the > metadata for it, without having to go through any of the standard > resolution steps. > In theory the correct way to do this is as I suggested - resolve the > authority name to get the urls to use, eg resolve > urn:lsid:example.org:... to get the metadata and data url addresses (I > wasnt assuming just using port 80 at the domain name specified in the > LSID). But if you dont want to use any resolution (ie you must be > doing somehting like a search and replace of all LSIDs in a document?) > then you will need a static url that will resolve any LSID, as you > have suggested. > > In this case I think it is a great idea, and will be interested to see > some use cases/examples in action for where you need to do this, and > normal resolution cannot be used. > > Kevin > > >>> Roderic Page <r.page(a)bio.gla.ac.uk> 15/06/2006 11:20 p.m. >>> > OK, I've grabbed lsidres.org, so to resolve a LSID straight to > metadata, stick http://lsidres.org in front of the LSID, e.g.: > > urn:lsid:lsid.zoology.gla.ac.uk:predicates:objectiveSynonym > > becomes > > http://lsidres.org/urn:lsid:lsid.zoology.gla.ac.uk:predicates: > objectiveSynonym > > and > > urn:lsid:ubio.org:namebank:2735664 > > becomes > > http://lsidres.org/urn:lsid:ubio.org:namebank:2735664 > > So now, it's as easy as DOIs... > > Regards > > Rod > > > On 15 Jun 2006, at 11:56, Roderic Page wrote: > > > Dear Kevin, > > > > The reasons against doing what you suggest (which I agree works in > most > > cases) are: > > > > 1. An LSID with authority example.org need not be handled by > > example.org. For example, ipni.org resolves to > > http://beta.ipni.org:9090 > > > > 2. You're assuming that we're all going to use port 80, whereas some > > may serve metadata and data over a different port (e.g., IPNI use > > 9090). > > > > 3. I feel having a standard prefix before the LSID that remains the > > same makes it easier for people to remember (i.e., we don't have to > > think, "gee, so what bit of the LSID to I extract, and what was that > > mumbo jumbo I stick on the end?"). Probably we should make it even > > simpler by grabbing a short domain name to make it even easier. > > Remember, DOIs make it simple - just tack the DOI onto the end of > > http://dx.doi.org, and it's resolved. > > > > Regards > > > > Rod > > > > > > > > > > > > > > > > On 15 Jun 2006, at 10:32, Kevin Richards wrote: > > > >> The theory is that most lsid resolvers/authorities will implement > the > >> http get protocol for resolving lsids. > >> This means that: > >> > >> http://example.org/authority/?lsid=urn:lsid.... will return the wsdl > >> equivalent to the getAvailableServices SOAP call > >> > >> http://example.org/authority/data/?lsid=urn:lsid... will return the > >> data > >> for that lsid > >> > >> http://example.org/authority/metadata/?lsid=urn:lsid... will return > >> the > >> metadata for that lsid > >> > >> so why not just use these urls if you want to use urls? > >> > >> Kevin > >> > >>>>> Roderic Page <r.page(a)bio.gla.ac.uk> 06/15/06 10:13 AM >>> > >> Dear Steve, > >> > >> It's written in PHP, and is basically a cleaner version of the LSID > >> test. I developed it on my iBook running Apache and PHP 4.3.10, and > >> deployed it on Fedora Core 4 with PHP 5. I've not tested it on > >> Windows, > >> > >> the issue would be whether the Net:DNS module I use to do the > >> resolution also works on Windows (who in their right mind uses > Windows > >> as a server ;-) > >> > >> Yep, the error reporting is bad, but I could work on this. It tries > to > >> trap some errors and report them in XML, but I put it together when > I > >> should have been listening to the talks at GUID2, so it's a bit > rough > >> and ready. > >> > >> Having a HTTP GET service sounds like a good idea, if it helps > people > >> play with this stuff. Maybe it could be as simple as a convention > that > >> if the "LSID" lacks a namespace and id (i.e., is just the authority) > >> the service returns metadata about the authority. For data, perhaps > >> the > >> > >> prefix "data" could be inserted before the LSID, rather like a lot > of > >> static URLs have the format of the data embedded in them, such as > >> http://www.connotea.org/rss/recent/user/rdmpage?q=Formicidae (an RSS > >> feed). > >> > >> Not elegant, but simple. > >> > >> Regards > >> > >> Rod > >> > >> > >> On 14 Jun 2006, at 17:07, Steven Perry wrote: > >> > >>> Hi Rod, > >>> > >>> This is pretty cool. What language is it in? What kind of server > >>> does it require (application server, apache, etc.)? > >>> When I tried to put in an LSID that I knew didn't exist, I got an > XML > >> > >>> parsing error. No worries, since this is an early prototype, but I > >>> was wondering if you're planning on trapping these kinds of errors > >>> and > >> > >>> returning an HTTP status code like 204 (NO_CONTENT), 404 > (NOT_FOUND), > >> > >>> or 410 (GONE), or if you had something else in mind. > >>> > >>> I've also been thinking about an HTTP-GET based LSID resolution > >>> gateway that might be exposed as a service. It could support > several > >> > >>> additional functions besides (the default) getMetadata(): > >>> > >>> getAuthorityInfo :: given an LSID, return information (in RDF) > about > >>> the authority extracted from the authority metadata > >>> getData:: might work a bit differently from the spec in that it > >>> always > >> > >>> sends through HTTP and it tries to set the correct mime type. > >>> > >>> However getMetadata is the critical function and these others may > >>> not, > >> > >>> upon more reflection, make much sense. > >>> > >>> Given that we want to be able to integrate with existing semantic > web > >> > >>> apps and tools that can't currently understand the LSID resolution > >>> process, I think we'll come to depend upon these kinds of services. > >>> They also provide convenience to developers who are working with > >>> languages that don't yet have a resolution client API. It might be > >>> nice to work out how such a service ought to behave and present it > to > >> > >>> TAG. > >>> > >>> -Steve > >>> > >>> > >>> Roderic Page wrote: > >>>> It was good to see everybody who made it to sunny Edinburgh over > the > >> > >>>> weekend. > >>>> > >>>> I've put together a very simple LSID resolver that returns RDF > >>>> metadata for a LSID. I wanted something very simple, so all you > do > >>>> is stick your LSID on the end of http://lsid.zoology.gla.ac.uk/, > >>>> e.g. > >>>> > >>>> http://lsid.zoology.gla.ac.uk/urn:lsid:ubio.org:namebank:2735664 > >>>> > >>>> http://lsid.zoology.gla.ac.uk/urn:lsid:lsid.zoology.gla.ac.uk: > >>>> predicate:isBasionymOf > >>>> > >>>> It's far from bullet proof, and not as pretty as other resolvers. > >>>> However, it means you see the RDF straight away, and if you > wanted > >>>> to > >> > >>>> aggregate the RDF for a LSID you could use this to do the > >>>> resolution > >> > >>>> for you. > >>>> > >>>> Regards > >>>> > >>>> Rod > >>>> > >>>> > >>>> > >> > ---------------------------------------------------------------------- > >>>> -- ---------------------------------------- > >>>> 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(a)bio.gla.ac.uk > >>>> web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html > >>>> 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 > >>>> > >>>> > >>>> _______________________________________________ > >>>> TDWG-GUID mailing list > >>>> TDWG-GUID(a)mailman.nhm.ku.edu > >>>> http://mailman.nhm.ku.edu/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(a)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 > >> > >> > >> > >> _______________________________________________ > >> TDWG-GUID mailing list > >> TDWG-GUID(a)mailman.nhm.ku.edu > >> http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid > >> > >> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> + > >> +++++ > >> WARNING: This email and any attachments may be confidential and/or > >> privileged. They are intended for the addressee only and are not to > be > >> read, > >> used, copied or disseminated by anyone receiving them in error. If > >> you are > >> not the intended recipient, please notify the sender by return email > >> and > >> delete this message and any attachments. > >> > >> The views expressed in this email are those of the sender and do not > >> necessarily reflect the official views of Landcare Research. > >> > >> Landcare Research > >> http://www.landcareresearch.co.nz > >> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> + > >> +++++ > >> > >> > >> > >> > > > ----------------------------------------------------------------------- > > - > > ---------------------------------------- > > 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(a)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 > > > > > > > > _______________________________________________ > > TDWG-GUID mailing list > > TDWG-GUID(a)mailman.nhm.ku.edu > > http://mailman.nhm.ku.edu/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(a)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 > > > > _______________________________________________ > TDWG-GUID mailing list > TDWG-GUID(a)mailman.nhm.ku.edu > http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++ > WARNING: This email and any attachments may be confidential and/or > privileged. They are intended for the addressee only and are not to > be read, > used, copied or disseminated by anyone receiving them in error. If > you are > not the intended recipient, please notify the sender by return email > and > delete this message and any attachments. > > The views expressed in this email are those of the sender and do not > necessarily reflect the official views of Landcare Research. > > Landcare Research > http://www.landcareresearch.co.nz > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++ > > ------------------------------------------------------------------------ ---------------------------------------- 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(a)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 ___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" - The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html _______________________________________________ TDWG-GUID mailing list TDWG-GUID(a)mailman.nhm.ku.edu http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid

2 1

Re: [Tdwg-guid] Simple LSID resolver
by Roderic Page 19 Jun '06

19 Jun '06

Ricardo notes that I've duplicated what Biopathways.org already provides (albeit with the use longer URLs). However, there are a couple of reasons for persisting in this. Firstly, I like short URLs. Secondly, I find having another implementation (and one that I can play with) to be useful. For example, Biopathways.org caches the metadata, so the links given by Ricardo work. I don't cache the metadata, and hence discover that the IndexFungorum LSID authority seems broken. The LSID resolves to host lsid.indexfungorum.org:8080, but if I ping lsid.indexfungorum.org I get nothing back, and my LSID resolver eventually fails with HTTP 504. What I think would be nice is to return metadata with a XSLT style sheet, so that the browser displays nice HTML, but view-source displays XML (which is also what a script would get), so that it supports both people and machines. For an example of this, see the handle demo for a paper on ants (http://hdl.handle.net/2254/20791) and view the source. Lastly, I need a LSID client for my ant stuff, so developing the resolver helps me debug this code. Regards Rod On 18 Jun 2006, at 23:54, Kevin Richards wrote: > Ok, I think I see where you are coming from now. > You want a URL that you can prepend to ANY LSID to resolve the > metadata for it, without having to go through any of the standard > resolution steps. > In theory the correct way to do this is as I suggested - resolve the > authority name to get the urls to use, eg resolve > urn:lsid:example.org:... to get the metadata and data url addresses (I > wasnt assuming just using port 80 at the domain name specified in the > LSID). But if you dont want to use any resolution (ie you must be > doing somehting like a search and replace of all LSIDs in a document?) > then you will need a static url that will resolve any LSID, as you > have suggested. > > In this case I think it is a great idea, and will be interested to see > some use cases/examples in action for where you need to do this, and > normal resolution cannot be used. > > Kevin > > >>> Roderic Page <r.page(a)bio.gla.ac.uk> 15/06/2006 11:20 p.m. >>> > OK, I've grabbed lsidres.org, so to resolve a LSID straight to > metadata, stick http://lsidres.org in front of the LSID, e.g.: > > urn:lsid:lsid.zoology.gla.ac.uk:predicates:objectiveSynonym > > becomes > > http://lsidres.org/urn:lsid:lsid.zoology.gla.ac.uk:predicates: > objectiveSynonym > > and > > urn:lsid:ubio.org:namebank:2735664 > > becomes > > http://lsidres.org/urn:lsid:ubio.org:namebank:2735664 > > So now, it's as easy as DOIs... > > Regards > > Rod > > > On 15 Jun 2006, at 11:56, Roderic Page wrote: > > > Dear Kevin, > > > > The reasons against doing what you suggest (which I agree works in > most > > cases) are: > > > > 1. An LSID with authority example.org need not be handled by > > example.org. For example, ipni.org resolves to > > http://beta.ipni.org:9090 > > > > 2. You're assuming that we're all going to use port 80, whereas some > > may serve metadata and data over a different port (e.g., IPNI use > > 9090). > > > > 3. I feel having a standard prefix before the LSID that remains the > > same makes it easier for people to remember (i.e., we don't have to > > think, "gee, so what bit of the LSID to I extract, and what was that > > mumbo jumbo I stick on the end?"). Probably we should make it even > > simpler by grabbing a short domain name to make it even easier. > > Remember, DOIs make it simple - just tack the DOI onto the end of > > http://dx.doi.org, and it's resolved. > > > > Regards > > > > Rod > > > > > > > > > > > > > > > > On 15 Jun 2006, at 10:32, Kevin Richards wrote: > > > >> The theory is that most lsid resolvers/authorities will implement > the > >> http get protocol for resolving lsids. > >> This means that: > >> > >> http://example.org/authority/?lsid=urn:lsid.... will return the wsdl > >> equivalent to the getAvailableServices SOAP call > >> > >> http://example.org/authority/data/?lsid=urn:lsid... will return the > >> data > >> for that lsid > >> > >> http://example.org/authority/metadata/?lsid=urn:lsid... will return > >> the > >> metadata for that lsid > >> > >> so why not just use these urls if you want to use urls? > >> > >> Kevin > >> > >>>>> Roderic Page <r.page(a)bio.gla.ac.uk> 06/15/06 10:13 AM >>> > >> Dear Steve, > >> > >> It's written in PHP, and is basically a cleaner version of the LSID > >> test. I developed it on my iBook running Apache and PHP 4.3.10, and > >> deployed it on Fedora Core 4 with PHP 5. I've not tested it on > >> Windows, > >> > >> the issue would be whether the Net:DNS module I use to do the > >> resolution also works on Windows (who in their right mind uses > Windows > >> as a server ;-) > >> > >> Yep, the error reporting is bad, but I could work on this. It tries > to > >> trap some errors and report them in XML, but I put it together when > I > >> should have been listening to the talks at GUID2, so it's a bit > rough > >> and ready. > >> > >> Having a HTTP GET service sounds like a good idea, if it helps > people > >> play with this stuff. Maybe it could be as simple as a convention > that > >> if the "LSID" lacks a namespace and id (i.e., is just the authority) > >> the service returns metadata about the authority. For data, perhaps > >> the > >> > >> prefix "data" could be inserted before the LSID, rather like a lot > of > >> static URLs have the format of the data embedded in them, such as > >> http://www.connotea.org/rss/recent/user/rdmpage?q=Formicidae (an RSS > >> feed). > >> > >> Not elegant, but simple. > >> > >> Regards > >> > >> Rod > >> > >> > >> On 14 Jun 2006, at 17:07, Steven Perry wrote: > >> > >>> Hi Rod, > >>> > >>> This is pretty cool. What language is it in? What kind of server > >>> does it require (application server, apache, etc.)? > >>> When I tried to put in an LSID that I knew didn't exist, I got an > XML > >> > >>> parsing error. No worries, since this is an early prototype, but I > >>> was wondering if you're planning on trapping these kinds of errors > >>> and > >> > >>> returning an HTTP status code like 204 (NO_CONTENT), 404 > (NOT_FOUND), > >> > >>> or 410 (GONE), or if you had something else in mind. > >>> > >>> I've also been thinking about an HTTP-GET based LSID resolution > >>> gateway that might be exposed as a service. It could support > several > >> > >>> additional functions besides (the default) getMetadata(): > >>> > >>> getAuthorityInfo :: given an LSID, return information (in RDF) > about > >>> the authority extracted from the authority metadata > >>> getData:: might work a bit differently from the spec in that it > >>> always > >> > >>> sends through HTTP and it tries to set the correct mime type. > >>> > >>> However getMetadata is the critical function and these others may > >>> not, > >> > >>> upon more reflection, make much sense. > >>> > >>> Given that we want to be able to integrate with existing semantic > web > >> > >>> apps and tools that can't currently understand the LSID resolution > >>> process, I think we'll come to depend upon these kinds of services. > >>> They also provide convenience to developers who are working with > >>> languages that don't yet have a resolution client API. It might be > >>> nice to work out how such a service ought to behave and present it > to > >> > >>> TAG. > >>> > >>> -Steve > >>> > >>> > >>> Roderic Page wrote: > >>>> It was good to see everybody who made it to sunny Edinburgh over > the > >> > >>>> weekend. > >>>> > >>>> I've put together a very simple LSID resolver that returns RDF > >>>> metadata for a LSID. I wanted something very simple, so all you > do > >>>> is stick your LSID on the end of http://lsid.zoology.gla.ac.uk/, > >>>> e.g. > >>>> > >>>> http://lsid.zoology.gla.ac.uk/urn:lsid:ubio.org:namebank:2735664 > >>>> > >>>> http://lsid.zoology.gla.ac.uk/urn:lsid:lsid.zoology.gla.ac.uk: > >>>> predicate:isBasionymOf > >>>> > >>>> It's far from bullet proof, and not as pretty as other resolvers. > >>>> However, it means you see the RDF straight away, and if you > wanted > >>>> to > >> > >>>> aggregate the RDF for a LSID you could use this to do the > >>>> resolution > >> > >>>> for you. > >>>> > >>>> Regards > >>>> > >>>> Rod > >>>> > >>>> > >>>> > >> > ---------------------------------------------------------------------- > >>>> -- ---------------------------------------- > >>>> 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(a)bio.gla.ac.uk > >>>> web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html > >>>> 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 > >>>> > >>>> > >>>> _______________________________________________ > >>>> TDWG-GUID mailing list > >>>> TDWG-GUID(a)mailman.nhm.ku.edu > >>>> http://mailman.nhm.ku.edu/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(a)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 > >> > >> > >> > >> _______________________________________________ > >> TDWG-GUID mailing list > >> TDWG-GUID(a)mailman.nhm.ku.edu > >> http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid > >> > >> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> + > >> +++++ > >> WARNING: This email and any attachments may be confidential and/or > >> privileged. They are intended for the addressee only and are not to > be > >> read, > >> used, copied or disseminated by anyone receiving them in error. If > >> you are > >> not the intended recipient, please notify the sender by return email > >> and > >> delete this message and any attachments. > >> > >> The views expressed in this email are those of the sender and do not > >> necessarily reflect the official views of Landcare Research. > >> > >> Landcare Research > >> http://www.landcareresearch.co.nz > >> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> + > >> +++++ > >> > >> > >> > >> > > > ----------------------------------------------------------------------- > > - > > ---------------------------------------- > > 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(a)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 > > > > > > > > _______________________________________________ > > TDWG-GUID mailing list > > TDWG-GUID(a)mailman.nhm.ku.edu > > http://mailman.nhm.ku.edu/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(a)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 > > > > _______________________________________________ > TDWG-GUID mailing list > TDWG-GUID(a)mailman.nhm.ku.edu > http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++ > WARNING: This email and any attachments may be confidential and/or > privileged. They are intended for the addressee only and are not to > be read, > used, copied or disseminated by anyone receiving them in error. If > you are > not the intended recipient, please notify the sender by return email > and > delete this message and any attachments. > > The views expressed in this email are those of the sender and do not > necessarily reflect the official views of Landcare Research. > > Landcare Research > http://www.landcareresearch.co.nz > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++ > > ------------------------------------------------------------------------ ---------------------------------------- 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(a)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 ___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html

1 0