Re: [tdwg-tag] SourceForge LSID project websites broken - role for TDWG?
I can't hold off commenting on this discussion any longer. Apologies for the tome of accumulating thoughts.
As noted, there are three aspects to recent discussions about GUIDs - the techie (easy?) bits, the social (harder?) bits and the funding/financial (hardest?) bits.
I was at the two TDWG funded meetings to decide on an appropriate GUID for the biodiversity informatics community. The (wide-ranging) group decided to support LSIDs. A number of us subsequently rounded up a library of resources (http://wiki.tdwg.org/GUID/) and drafted quite a few documents (http://www.tdwg.org/activities/guid/documents/) including the LSID Applicability Statement (the application of an existing standard to our domain).
Ricardo Pereira (among a host of other work) setup the SourceForge site (http://lsids.sourceforge.net/) and that is the ONLY TDWG LSID resource that is currently down. It is down because SourceForge changed their website
provider configuration (with previous notice) that broke our setup, and we were not able to restore it - but we are working on it (minus Ricardo - which is why the delay). To quote Ricardo: "Important pieces of the LSID infrastructure were never off-line, not even for a minute in the last year or so. Examples:
http://lsid.tdwg.org/summary/urn:lsid:ubio.org:namebank:11815
http://lsid.tdwg.org/summary/urn:lsid:ubio.org:classificationbank:1164063
http://lsid.tdwg.org/summary/urn:lsid:indexfungorum.org:names:213649
http://lsid.tdwg.org/summary/urn:lsid:gdb.org:GenomicSegment:GDB132938
http://lsid.tdwg.org/summary/urn:lsid:ipni.org:names:30000959-2
The actual LSID infrastructure, including the TDWG LSID resolver and the LSID authorities listed there have always been operational, as you can see from the links above. The open source community website that supports software developers involved in implementing LSID clients and resolvers also was never off-line:
http://sourceforge.net/projects/lsids (open source collaboration site)
http://sourceforge.net/project/showfiles.php?group_id=198923 (downloads)
http://lsids.svn.sourceforge.net/viewvc/lsids/ (version control - subversion)
http://sourceforge.net/mailarchive/forum.php?forum_name=lsid-developer (LSID developer forum)"
As has been stated previously, the 'social' aspects involved in the uptake of standards is important. As Jim said, TDWG develops standards (not software or an implementation service). We assume end-users have the skills to use the standards or that companies such as ETI (that are thin on the ground) can provide a service. This has drawn criticism. It is not an easy call as we are already spread far too thinly. We have also previously missed addressing the needs of the managers of the people in TDWG (who hold the purse strings and who make decisions). I did commission 'executive summaries' of most of the TDWG 'standards' (including at least three on LSIDs) but I agree that we need to consider deployment before a new TDWG standard is released.
One of my responsibilities as part of the TDWG Infrastructure Project (TIP) was to consider a funding model for TDWG. I found it amazing that an organization in TDWG's position has so few members. TDWG develops
standards for sharing biodiversity information. Most of us know just how central that is (as has been stated) for work such as GBIF, CoL, EoL, ALA, EDIT, OBIS, ITIS....and all museums, herbaria etc (a hell of a huge community!!). In 'biodiversity', we are also talking about one of the planets key resources!
When TIP started, TDWG had 23 individual members and 17 institutional members. Amazing isn't it!? Why? Maybe because of the small original overlap of let's call them 'biotypes' with Information Technologists? TDWG started as a club of IT inclined biotypes playing with databases. The explosion of IT has radically changed that. TDWG is still at a point where the biotypes can't easily understand the few (unbelievably valuable and overworked!) people with IT skills that TDWG had fortunately attracted.
I know that some people have not joined TDWG because they see it as 'bureaucratic': To quote Rod Page and Nike "...Just do it...". I'm convinced that TIP's restructured TDWG has addressed that. Movement is now far more dependent on the individual than the committee - and we can't do better (or worse) than that.
It was obvious to me that we needed to build TDWG membership before we look to Sugar Daddies or more handouts. With a substantial membership, we make a stronger case to potential supporters, and we can better spread the load. In 2008, we had 32 Individual members and 47 institutional members - better but still a very small percentage of the catchment of those who should be supporting TDWG in some form.
In discussing financial models, I would like to single out GBIF's support of TDWG. TDWG has a special relationship with GBIF. TDWG does have an excess of servers that can be used for infrastructure such as mentioned (thanks to TIP). These servers are housed and supported by GBIF. We GREATLY appreciate this considerable support.
How does all of this relate to the LSID discussion?
1. As an Australian media personality likes to say "It is better to have people inside the tent pissing out than outside pissing in." This on two counts. A decision was made to try and implement LSIDs. A lot of work has
been done toward that goal. The LSID Applicability Statement forms a foundation for general GUID use. If we decide something is better, evolution should not be a major hassle. Donald, as the Chairman of TDWG also deserves our support (will anyone else out there take on the role?). Ben Richardson has taken on the role of Review Manager of the LSID Applicability Statement. When it goes to public review (hopefully soon), do what you can to make the document a useful foundation for future developments. Please be constructive.
2. Do what you can to assist TDWG to build the membership and to spread the (considerable) load. A hybrid financial model is a foregone conclusion. Full stop. We need a substantial membership to fund infrastructure support (as has been discussed). Medium to long-term funding support from external agencies to support infrastructure is almost impossible. We also need substantial additional funding for specific projects that probably can't get done without it. Right now we are desperate for an effective tool for building/discussing/maintaining a TDWG ontology. TDWG is going to be increasingly dependent on an effective ontology. Unless I'm blind, this project should be in good position to attract special funding. LSID (or other GUID) infrastructure looks equally important.
Lee
Lee Belbin
TDWG Secretariat
In a rare attempt at being constructive, here are a few thoughts.
LSIDs and linked data =================
If adoption of LSIDs proceeds, then we should make efforts to see that they play nicely with Linked Data efforts. For example, a HTTP resolver would need to support 303 redirects and content negotiation. This help avoid us creating our own ghetto, but still exploit whatever advantages LSIDs have.
Roger set up something along these lines to handle Biological Collections Index (BioCol) LSIDs. There is a nice tool at http://validator.linkeddata.org/ to check whether a URI behaves as Linked Data tools expect. Sadly the proxied BioCol LSIDs (e.g., http://biocol.org/urn:lsid:biocol.org:col:15670 ) don't validate, but this should be easy to fix. The TDWG resolver similarly fails.
I've implemented a simple resolver at bioGUID that returns either raw RDF or a clumsily formatted HTML version of the XML, but which passes the http://validator.linkeddata.org tests. An example URI is http://bioguid.info/urn:lsid:indexfungorum.org:names:213649 , which validates http://tinyurl.com/cgje5n
So, my first recommendation is to ensure that a TDWG HTTP proxy passes http://validator.linkeddata.org/ . This means we can play with the Semantic Web crowd with LSIDs.
Note that getting HTTP URIs to play with Linked Data is not trivial, so whatever technology we adopt we'll need clear guidelines as to how to use it. As an aside bioGUID can make DOIs play nice as well (they don't by default), and Kinglsey Idehen http://www.openlinksw.com/blog/ ~kidehen/ of OpenLink Software is supporting LSIDs in the Linked Data tools he's developing.
Ontology =======
As part of my experiment to wikify taxonomic names, literature, etc., I've been playing with the TDWG vocabularies. I've a few grizzles, but in general they've been really useful, and I think these will be key (as Donald and Lee have emphasised).
Service ======
Ironically one of the examples Lee listed when defending the TDWG's resolver (urn:lsid:gdb.org:GenomicSegment:GDB132938) seems to have disappeared (I think TDWG has a cached copy). This raises the ongoing problem of service availability. TDWG's resolver could help here, in that could be used to generate reports on service quality and notify providers when something's wrong. Whatever GUID technology adopted this will be an issue, and the challenge is to build tools and mechanisms to manage this.
Funding ======
I've nothing useful to say here, other than to suggest that clearly the integration of biodiversity data sales pitch hasn't (yet?) succeeded. I think us techies get it, but we've not made that vision real or compelling. If we had, I think we'd have institutions falling over themselves to ensure the infrastructure exists and persists. Naive, I know, but we could ask why we haven't managed to convince those with the purse strings that this stuff matters.
One quick and dirty way that might help is if the TDWG LSID resolver stored all the metadata in the LSIDs it resolves in a triple store and exposes a SPARQL query interface to that metadata. We could then start to look for interesting links between data.
Regards
Rod
--------------------------------------------------------- Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK
Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html
On 9 Apr 2009, at 16:29, Roderic Page wrote:
Roger set up something along these lines to handle Biological Collections Index (BioCol) LSIDs. There is a nice tool at http://validator.linkeddata.org/ to check whether a URI behaves as Linked Data tools expect. Sadly the proxied BioCol LSIDs (e.g., http://biocol.org/urn:lsid:biocol.org:col:15670 ) don't validate, but this should be easy to fix. The TDWG resolver similarly fails.
What do you mean it doesn't work. Works perfectly for me! Well it does now ;)
But seriously the validator is a great tool wasn't aware of it before.
Thanks,
Roger
On Apr 9, 2009, at 11:29 AM, Roderic Page wrote:
Ironically one of the examples Lee listed when defending the TDWG's resolver (urn:lsid:gdb.org:GenomicSegment:GDB132938) seems to have disappeared
GDB was shut down last year, and the organization that hosted it shut down the domain too. I'm not sure that a community resolver should cache copies of data and/or metadata for objects owned by now-defunct entities. Wouldn't that be conflating a resolver with an archive? I.e., the onus of object persistence is with the digital object owner, not the identifier resolver, right?
(I do agree with more or less everything else you said, though.)
-hilmar
Thanks Rod. Very constructive.
Lee
Lee Belbin TDWG Secretariat
-----Original Message----- From: Roderic Page [mailto:r.page@bio.gla.ac.uk] Sent: Friday, 10 April 2009 1:30 AM To: Lee Belbin Cc: 'Technical Architecture Group mailing list' Subject: Re: [tdwg-tag] SourceForge LSID project websites broken - role for TDWG?
In a rare attempt at being constructive, here are a few thoughts.
LSIDs and linked data =================
If adoption of LSIDs proceeds, then we should make efforts to see that they play nicely with Linked Data efforts. For example, a HTTP resolver would need to support 303 redirects and content negotiation. This help avoid us creating our own ghetto, but still exploit whatever advantages LSIDs have.
Roger set up something along these lines to handle Biological Collections Index (BioCol) LSIDs. There is a nice tool at http://validator.linkeddata.org/ to check whether a URI behaves as Linked Data tools expect. Sadly the proxied BioCol LSIDs (e.g., http://biocol.org/urn:lsid:biocol.org:col:15670 ) don't validate, but this should be easy to fix. The TDWG resolver similarly fails.
I've implemented a simple resolver at bioGUID that returns either raw RDF or a clumsily formatted HTML version of the XML, but which passes the http://validator.linkeddata.org tests. An example URI is http://bioguid.info/urn:lsid:indexfungorum.org:names:213649 , which validates http://tinyurl.com/cgje5n
So, my first recommendation is to ensure that a TDWG HTTP proxy passes http://validator.linkeddata.org/ . This means we can play with the Semantic Web crowd with LSIDs.
Note that getting HTTP URIs to play with Linked Data is not trivial, so whatever technology we adopt we'll need clear guidelines as to how to use it. As an aside bioGUID can make DOIs play nice as well (they don't by default), and Kinglsey Idehen http://www.openlinksw.com/blog/ ~kidehen/ of OpenLink Software is supporting LSIDs in the Linked Data tools he's developing.
Ontology =======
As part of my experiment to wikify taxonomic names, literature, etc., I've been playing with the TDWG vocabularies. I've a few grizzles, but in general they've been really useful, and I think these will be key (as Donald and Lee have emphasised).
Service ======
Ironically one of the examples Lee listed when defending the TDWG's resolver (urn:lsid:gdb.org:GenomicSegment:GDB132938) seems to have disappeared (I think TDWG has a cached copy). This raises the ongoing problem of service availability. TDWG's resolver could help here, in that could be used to generate reports on service quality and notify providers when something's wrong. Whatever GUID technology adopted this will be an issue, and the challenge is to build tools and mechanisms to manage this.
Funding ======
I've nothing useful to say here, other than to suggest that clearly the integration of biodiversity data sales pitch hasn't (yet?) succeeded. I think us techies get it, but we've not made that vision real or compelling. If we had, I think we'd have institutions falling over themselves to ensure the infrastructure exists and persists. Naive, I know, but we could ask why we haven't managed to convince those with the purse strings that this stuff matters.
One quick and dirty way that might help is if the TDWG LSID resolver stored all the metadata in the LSIDs it resolves in a triple store and exposes a SPARQL query interface to that metadata. We could then start to look for interesting links between data.
Regards
Rod
--------------------------------------------------------- Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK
Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html
I like this compromise Rod. But I think that it is time to give up on the concept of multiple identifiers.
The existing TDWG recommendation that '5. All references to LSIDs within RDF documents should use the proxified form', basically states that LSID will never appear in any way other than bundled into an http URI - if we are also to publish data as RDF.
That sounds as if it means that those wanting to use LSID resolution will first have to extract the LSID part from the http URI which will now appear everywhere we would expect to find our unique identifier.
Donald has presented a strong case for unique identifiers conforming to the LSID specification but we have now an equally strong case that in its http form our identifier must behave as a dereferenceable URN per W3C linked data recommendations.
Acceptance of this requirement will impact on existing services expecting RDF back from the proxy service without content negotiation and require update of TDWG GUID policy and recommendations so it is important that we try to get this sorted here as soon as possible.
greg
2009/4/10 Roderic Page r.page@bio.gla.ac.uk:
In a rare attempt at being constructive, here are a few thoughts.
LSIDs and linked data
If adoption of LSIDs proceeds, then we should make efforts to see that they play nicely with Linked Data efforts. For example, a HTTP resolver would need to support 303 redirects and content negotiation. This help avoid us creating our own ghetto, but still exploit whatever advantages LSIDs have.
Roger set up something along these lines to handle Biological Collections Index (BioCol) LSIDs. There is a nice tool at http://validator.linkeddata.org/ to check whether a URI behaves as Linked Data tools expect. Sadly the proxied BioCol LSIDs (e.g., http://biocol.org/urn:lsid:biocol.org:col:15670 ) don't validate, but this should be easy to fix. The TDWG resolver similarly fails.
I've implemented a simple resolver at bioGUID that returns either raw RDF or a clumsily formatted HTML version of the XML, but which passes the http://validator.linkeddata.org tests. An example URI is http://bioguid.info/urn:lsid:indexfungorum.org:names:213649 , which validates http://tinyurl.com/cgje5n
So, my first recommendation is to ensure that a TDWG HTTP proxy passes http://validator.linkeddata.org/ . This means we can play with the Semantic Web crowd with LSIDs.
Note that getting HTTP URIs to play with Linked Data is not trivial, so whatever technology we adopt we'll need clear guidelines as to how to use it. As an aside bioGUID can make DOIs play nice as well (they don't by default), and Kinglsey Idehen http://www.openlinksw.com/blog/ ~kidehen/ of OpenLink Software is supporting LSIDs in the Linked Data tools he's developing.
Ontology
As part of my experiment to wikify taxonomic names, literature, etc., I've been playing with the TDWG vocabularies. I've a few grizzles, but in general they've been really useful, and I think these will be key (as Donald and Lee have emphasised).
Service
Ironically one of the examples Lee listed when defending the TDWG's resolver (urn:lsid:gdb.org:GenomicSegment:GDB132938) seems to have disappeared (I think TDWG has a cached copy). This raises the ongoing problem of service availability. TDWG's resolver could help here, in that could be used to generate reports on service quality and notify providers when something's wrong. Whatever GUID technology adopted this will be an issue, and the challenge is to build tools and mechanisms to manage this.
Funding
I've nothing useful to say here, other than to suggest that clearly the integration of biodiversity data sales pitch hasn't (yet?) succeeded. I think us techies get it, but we've not made that vision real or compelling. If we had, I think we'd have institutions falling over themselves to ensure the infrastructure exists and persists. Naive, I know, but we could ask why we haven't managed to convince those with the purse strings that this stuff matters.
One quick and dirty way that might help is if the TDWG LSID resolver stored all the metadata in the LSIDs it resolves in a triple store and exposes a SPARQL query interface to that metadata. We could then start to look for interesting links between data.
Regards
Rod
Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK
Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments.
Please consider the environment before printing this email.
Perhaps it would help (me at least) if we separated two meanings of "multiple identiifers":
1. Multiple identifiers for the same object, e.g. "urn:lsid:zoobank.org:pub:2C6BD020-B54A-4119-9693-3231C9FCEFA6 " and "doi: 10.3897/zookeys.7.111"
2. Multiple forms of the same identifier, e.g. "urn:lsid:zoobank.org:pub:2C6BD020-B54A-4119-9693-3231C9FCEFA6 " and "http://bioguid.info/urn:lsid:zoobank.org:pub:2C6BD020-B54A-4119-9693-3231C9F... "
I assume that you mean #2, multiple forms of the same identifier?
Personally I would argue that the RDF should always contain a canonical, un-proxied version of an identifier (whether LSID or DOI), because:
1. having only the proxied version assumes that there is only one suitable proxy (there may be multiple ones)
2. it assumes that the specified proxy will always exist (our track record in durable HTTP services is poor)
3. assumes the specified proxy will always match conform to current standards
4. it imposes an overhead on clients that want the canonical identifier (i.e., they have to strip away the proxy)
I predict that for any meaningful, successful (i.e., widely adopted) identifier there will be multiple services that will be capable of consuming that identifier, not just HTTP proxies. DOIs can be proxied (by several servers, including http://dx.doi.org/ and http://hdl.handle.net ), resolved using OpenURL resolvers, etc.
In order to play ball with Linked Data, there are several ways forward:
1. Always refer to LSIDs in their proxied form (see above for reasons why this might not be a good idea)
2. Ensure that at least one proxy exists which can resolve LSIDs in a linked data friendly way (see http://bioguid.info as an example)
3. Use/develop linked data clients that understand LSIDs (e.g., http://linkeddata.uriburner.com/ , see http://linkeddata.uriburner.com/about/html/urn:lsid:zoobank.org:pub:2C6BD020... )
2 and 3 already exist, so I'm not so keen on 1.
For me this is the biggest hurdle faced by HTTP URIs -- I have to choose one. As an analogy, I can identify a book using an ISBN (say, 0226644677). How do I represent this in RDF? Well, I could use an HTTP URI, say http://www.amazon.com/Tangled-Trees-Phylogeny-Cospeciation-Coevolution/dp/02... , or maybe http://www.worldcat.org/isbn/0226644677 . There are many, many I could choose from (see http://en.wikipedia.org/wiki/Special:BookSources/0226644677 ). However, so long as I know that the ISBN is 0226644677, I'm free to use whatever URI best suits my needs.
Imagine, for example, a publisher such as PLoS or Magnolia Press (publisher of Zootaxa). They might want to display LSIDs linked to their own LSID resolver that embellishes the metadata with information they have (e.g., they might wish to highlight links to other content they host). In a sense this is much the same idea as supported by OpenURL COinS (http://ocoins.info/), where OpenURL-format metadata is embedded in a HTML document and the user choose what resolver to use to resolve the links. Having LSIDs prefixed with a HTTP proxy makes this task a little harder.
Rod
On 15 Apr 2009, at 15:00, greg whitbread wrote:
I like this compromise Rod. But I think that it is time to give up on the concept of multiple identifiers.
The existing TDWG recommendation that '5. All references to LSIDs within RDF documents should use the proxified form', basically states that LSID will never appear in any way other than bundled into an http URI - if we are also to publish data as RDF.
That sounds as if it means that those wanting to use LSID resolution will first have to extract the LSID part from the http URI which will now appear everywhere we would expect to find our unique identifier.
Donald has presented a strong case for unique identifiers conforming to the LSID specification but we have now an equally strong case that in its http form our identifier must behave as a dereferenceable URN per W3C linked data recommendations.
Acceptance of this requirement will impact on existing services expecting RDF back from the proxy service without content negotiation and require update of TDWG GUID policy and recommendations so it is important that we try to get this sorted here as soon as possible.
greg
2009/4/10 Roderic Page r.page@bio.gla.ac.uk:
In a rare attempt at being constructive, here are a few thoughts.
LSIDs and linked data
If adoption of LSIDs proceeds, then we should make efforts to see that they play nicely with Linked Data efforts. For example, a HTTP resolver would need to support 303 redirects and content negotiation. This help avoid us creating our own ghetto, but still exploit whatever advantages LSIDs have.
Roger set up something along these lines to handle Biological Collections Index (BioCol) LSIDs. There is a nice tool at http://validator.linkeddata.org/ to check whether a URI behaves as Linked Data tools expect. Sadly the proxied BioCol LSIDs (e.g., http://biocol.org/urn:lsid:biocol.org:col:15670 ) don't validate, but this should be easy to fix. The TDWG resolver similarly fails.
I've implemented a simple resolver at bioGUID that returns either raw RDF or a clumsily formatted HTML version of the XML, but which passes the http://validator.linkeddata.org tests. An example URI is http://bioguid.info/urn:lsid:indexfungorum.org:names:213649 , which validates http://tinyurl.com/cgje5n
So, my first recommendation is to ensure that a TDWG HTTP proxy passes http://validator.linkeddata.org/ . This means we can play with the Semantic Web crowd with LSIDs.
Note that getting HTTP URIs to play with Linked Data is not trivial, so whatever technology we adopt we'll need clear guidelines as to how to use it. As an aside bioGUID can make DOIs play nice as well (they don't by default), and Kinglsey Idehen http://www.openlinksw.com/ blog/ ~kidehen/ of OpenLink Software is supporting LSIDs in the Linked Data tools he's developing.
Ontology
As part of my experiment to wikify taxonomic names, literature, etc., I've been playing with the TDWG vocabularies. I've a few grizzles, but in general they've been really useful, and I think these will be key (as Donald and Lee have emphasised).
Service
Ironically one of the examples Lee listed when defending the TDWG's resolver (urn:lsid:gdb.org:GenomicSegment:GDB132938) seems to have disappeared (I think TDWG has a cached copy). This raises the ongoing problem of service availability. TDWG's resolver could help here, in that could be used to generate reports on service quality and notify providers when something's wrong. Whatever GUID technology adopted this will be an issue, and the challenge is to build tools and mechanisms to manage this.
Funding
I've nothing useful to say here, other than to suggest that clearly the integration of biodiversity data sales pitch hasn't (yet?) succeeded. I think us techies get it, but we've not made that vision real or compelling. If we had, I think we'd have institutions falling over themselves to ensure the infrastructure exists and persists. Naive, I know, but we could ask why we haven't managed to convince those with the purse strings that this stuff matters.
One quick and dirty way that might help is if the TDWG LSID resolver stored all the metadata in the LSIDs it resolves in a triple store and exposes a SPARQL query interface to that metadata. We could then start to look for interesting links between data.
Regards
Rod
Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK
Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html
tdwg-tag mailing list tdwg-tag@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag
If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments.
Please consider the environment before printing this email.
-- Greg Whitbread Australian National Botanic Gardens Australian National Herbarium +61 2 62509482 ghw@anbg.gov.au
--------------------------------------------------------- Roderic Page Professor of Taxonomy DEEB, FBLS Graham Kerr Building University of Glasgow Glasgow G12 8QQ, UK
Email: r.page@bio.gla.ac.uk Tel: +44 141 330 4778 Fax: +44 141 330 2792 AIM: rodpage1962@aim.com Facebook: http://www.facebook.com/profile.php?id=1112517192 Twitter: http://twitter.com/rdmpage Blog: http://iphylo.blogspot.com Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html
participants (5)
-
greg whitbread -
Hilmar Lapp -
Lee Belbin -
Roderic Page -
Roger Hyam