November 2005 - tdwg-tag - lists.tdwg.org

Various thoughts
by Roderic Page 05 Nov '05

05 Nov '05

Hear are some thoughts on some recent posts (I got sidetracked on my iSpecies toy -- http://iSpecies.org -- which manages to show the power of searching multiple information sources, and the limitations of taxonomic names as a means to link those sources). 2 problems --------------- Regarding Ricardo's post (Can we break down GUID problem into 2 hierarchical sub-problems?), I think the answer is clearly yes. For some further insight, Lincoln Stein's article in Nature Reviews Genetics (http://dx.doi.org/10.1038/nrg1065 -- there are PDFs online in various places: http://scholar.google.com/scholar? hl=en&lr=&c2coff=1&safe=off&cluster=8495832052860440576) outlines Lincoln's notion that biological databases could be integrated using a combination of "knuckles" and "nodes" . Nodes are databases, knuckles are services that map items in different databases. I think we have lots of "nodes", and part of our challenge is to integrate these. Step one is to have GUIDs for items in our databases, so that we can always uniquely identify and retrieve data. Step two is to map the items we are interested in. This is where I think much of the taxonomic concept stuff comes in. What gets a GUID? ------------------------ I think it's clear from Richard's responses that he's thought a lot more about names than I have. Perhaps I'm too wedded to keeping things simple, but is it reasonable to suppose that there are basically three levels that we might operate at: 1. Names as text strings (orthographic variants may belong here) 2. Names as elements of nomenclature (i.e., date and authorship) 3. Names as concepts (i.e., linked to explicit usage) So, why not have GUIDs at all three levels, and have databases be explicit about what the serve? For example, my understanding is that uBio is essentially about name strings, IPNI is a database of plant nomenclature, whereas TROPICOS/VAST is about concepts (in the sense of what is the accepted name for a plant). So 1. uBio 2. IPNI 3. TROPICOS/VAST (Ducks incoming brickbats) So, one could imagine that a nomenclatural database could link its names to namestring GUIDs, and a concept database could link to nomenclatural GUIDs. From the user's perspective, they can choose what kind of entity they want to refer to. Why so many levels? Well, if we want to use names in the rest of biology we'll need to accommodate all levels of certainty about what a name means. At a minimum, we would map a name in a paper or some database to a name GUID. Through links to nomenclatural and concept databases, other users would at least see the range of possible meanings for that name. If the source was explicit about a name (e.g., "Aus bus" sensu "J. Doe", or a connection to another object such as a specimen or a sequence). I think Richard is concerned that if we just have GUIDs for name strings then we're not gaining much. I disagree. We need to support all kinds of names, and in many cases name strings are all we have. One could ask do we need GUIDs for name if we can simply search nomenclatural and concept databases using text strings (i.e., why should names get GUIDs?). Well, I guess the answer is because I think we need a database of names that has information on where the name came from, in what content it was used (e.g., in a book on flies so it's probably a fly name, a web-based checklist of plants of some island), and so on. Plus there are a lot of informal names ("A. sp"), names in different naming systems (Phylocode and less formal phylogenetic names), and so on. These won't necessarily be captured in nomenclatural databases. I think we get some benefits from this: 1. Everybody is explicit about what they provide 2. People can get on with doing what they want to do (and/or do best). uBio grabs names from wherever it can find them, IPNI provides detail on the authorship of names, TROPICOS/VAST suggests which name to use. 3. Users decide what level is appropriate for them. They may just link to a name, they may link to a concept. 4. Interlinking becomes easier because the nature of the link could be made explicit (e.g., this name occurs in my database as this concept, the name also occurs in ITIS, but I'm linking solely by name). Regarding Richard's option 2: "How to use GUIDs to dramatically change the way biological data is exchanged (higher cost, slower implementation, fundamental improvements)." I feel this is only going to happen if it's simple and easy to use, and does in fact yield demonstrable improvements. Which leads me to the next point. Who is going to use this stuff? -------------------------------------- If we think the audience is other taxonomists, and other taxonomic database providers, then we are being far too inward looking. I think we need to consider all sorts of things, particularly major bioinformatics databases (think GenBank), geographers (think Google Earth), and information providers (think journal publishers). For example, some journals (such as those hosted by BioOne) have all strings that look like taxonomic names linked to ITIS (whether the name exists or not!). This provides added value -- click on the name and you learn more. Now, publishers are very keen on adding value, and simple, resolvable identifiers would be a bonus (after all, they got behind DOIs). Now, asking publishers to tag using concepts is going to be asking too much. Asking authors of papers is going to be a stretch as well, although some may well do so, many may balk at yet more stuff getting in the way of their work (which is doing the fun stuff and writing it up). In my opinion we need to keep thinking of simple solutions (they might not be simple under the hood) that work, and that scale, and that have a low barrier to entry. Concept bank ------------------- Sally's (not entirely serious) suggestion of "ConceptBank" bears thinking about, especially as one could populate it initially by automated searches. For example, studies that use DNA sequences will have GenBank accession numbers for sequences, which we could use to link together different studies on the same organism (i.e., if you use the same sequence you're talking about the same thing - probably). Likewise, one could text mine PubMed and build lists of (name,publication) pairs. There are limits to this of course, but it would at least be a starting point. For me a major issue in all of this is scale. If we're serious we need to think big, look at automation, think about distributed, social approaches, and be willing to accept a degree of error. These aren't attributes of the typical taxonomist. 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 at http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species at http://ispecies.org

1 0

Re: Various thoughts
by Richard Pyle 05 Nov '05

05 Nov '05

Thanks, Rod -- great stuff! > What gets a GUID? > ------------------------ > > I think it's clear from Richard's responses that he's thought a lot > more about names than I have. Perhaps I'm too wedded to keeping things > simple, but is it reasonable to suppose that there are basically three > levels that we might operate at: > > 1. Names as text strings (orthographic variants may belong here) > 2. Names as elements of nomenclature (i.e., date and authorship) > 3. Names as concepts (i.e., linked to explicit usage) > > So, why not have GUIDs at all three levels, and have databases be > explicit about what the serve? Unfortunately, there are more than three levels in current use (from least to most taxonomically specific): 1. Names as raw text strings (including orthographic variants, homonyms not distinguished) 2. Names as raw text strings (including orthographic variants, homonyms distinguished) 3. Names as complete sets of one or more name-units (including orthographic variants, homonyms distinguished) 4. Names as complete sets of one or more name-units (excluding orthographic variants, homonyms distinguished) 5. Names as semi-complete sets of one or more name-units (including orthographic variants, homonyms distinguished) 6. Names as semi-complete sets of one or more name-units (excluding orthographic variants, homonyms distinguished) 7. Names as terminal units only (excluding orthographic variants, homonyms distinguished) 8. Names in context of usage (Name SEC Usage instance) Note: Monomials have one name-unit, binomials have two, trinomials have three, the name "Centropyge (Xiphypops) fisheri falvicauda" has four, and so on. There are actually more possibilities than these (e.g., whether or not autonyms/nominotypical names are treated as distinct), but the above list covers the main range of what I know to already be "out there". (Let's not even open the Pandora's box of hybrid name formulae...) I believe that your work and that of uBio typically involves #1 & #2 (#1 is a Google search; #2 is usually in the form of Name+authors). Taxonomic authorities for specimen databases sometimes operate on #3 & #4. ITIS works at #5 ("semi-complete" because infrageneric names are not strictly included for names at rank of species and lower, and they also allow only one level of infraspecific name-unit. #6 is the botanical approach, and I *think* the way that IPNI and/or IF do it (in this case, semi-complete excludes infrageneric name-units for species and lower, but im not sure how many simultaneous levels of infraspecific names they accomodate -- Sally??) #7 is the zoological perspective, and #8 is concepts. Actually, #8 is only one flavor of concept -- but concepts don't really even belong on this list at all. It seems that most people can agree that a concept is represented by a Name-Usage instance [yes, Jessie -- "Usage" can be sensu-stricto here! :-) ] -- e.g., "Name+Publication". We haven't begun the war over what constitutes a "Publication" (I prefer the term "Documentation"), but that war doesn't need to be started here. I think we can reasonably safely say that concepts can be thought of as Name+Publication, and so for this discussion we really only need to focus on what a "Name" is. So....I think we can probably reduce the list of 1-7 above down to perhaps 3 different items -- but I wouldn't go with exactly the three you listed. We can eliminate #1 of my list, because the name-string itself is the GUID (or rather, the provider+namestring itself can serve as the GUID). The main difference between #2 and #3 is that #3 parses and distinguishes the ranks of the individual name-units. In other words, it's smart enough to know that the name: "Centropyge (Xiphypops) fisheri falvicauda (Fraser-Brunner 1933)" consists of GenusName+SubgenusName+SpeciesEpithet+SubspeciesEpithet -- which is slightly more informative than #2, which understands only a text string consisting of 63 consecutive ASCII characters. Also, ITIS technically could be represented as #3 (instead of #5), because it actually tracks infrageneric name-units via hierarichal "parent_tsn" links. Also, #3 requires less work to sort out than #5 (e.g., #3 doesn't need to recognize that "Centropyge flavicauda" and "Centropyge flavicaudus" derive from the same basionym), so more existing datasets could conform to it with less work to scrutinize each name record. #4 is the least common of the first five (in my experience), and could also be "dumbed down" to fit into #3 fairly painlessly, or possibly even "smartened up" to fit into #6 in some cases So....of the first five in the list, we could probably get by with just #3 (which would more or less correspond to your #1, only a bit more explicitly defined). I think we should definitely keep #6 as a GUID candidate, because it fits the botanical practice. Same with #7 for zoological practice. Thus, I do have hope that we could reduce the list to these three name-GUID domains: 1. Names as complete sets of one or more name-units (including orthographic variants, homonyms distinguished) (for names-only records, inclusive of authors to distinguish homonyms) 2. Names as semi-complete sets of one or more name-units (excluding orthographic variants, homonyms distinguished) (for IPNI/IF and botanical datasets) 3. Names as terminal units only (excluding orthographic variants, homonyms distinguished) (for zoological datasets -- particularly ZooBank). There are several other reasons why these three "domains" of name-GUIDs make sense to me (this message is too long as it is, so I won't go into those reasons now). But bear in mind that each one of them would need some explicit rules about things like autonyms/nominotypical names and such. And eventually we *will* need to open the "hybrid" Pandora's box....but I think this set of three could be a useful start. Any one of the three could be placed in the context of a Usage instance (=Publication), and thereby represent a concept. The main question I have for you, Rod, is: would the "Names as complete sets of one or more name-units" be too information-rich to be practical? In other words, is it reasonable to force name providers (who want to conform to a TDWG Name-GUID standard) to minimally: 1) distinguish homonyms, and 2) identify ranks of individual name-units in a multi-unit name (e.g, distinguish a trinomial of Genus+Subgenus+species [Octopus (Octopus) octopus] as different from a trinomial of Genus+species+subspecies [Octopus octopus octopus])? If these bits of metadata are not unreasonable, then we might just find a path to mutual agreement on this issue! I hope the fact that I embrace your "three alternate GUIDs for names" approach (i.e., the bulk of your last message) is self-evident from all the text I have written above! As for the section of your email under this heading: > Who is going to use this stuff? > -------------------------------------- I agree with everything you wrote. My thoughts regarding "How to use GUIDs to dramatically change the way biological data is exchanged" are focused not just on helping taxonomists, but also on concealing the complexities and subtleties of taxonomy from non-taxonomists, to allow more direct access to the information they are most likely to be searching for. > Concept bank > ------------------- If I'm not mistaken, this is one of the things the SEEK folks have set out to do (Jessie?) As for the rest of your message that I did not comment on above, it is clear that you and I agree on MUCH more than we disagree on! Aloha, Rich Richard L. Pyle, PhD Database Coordinator for Natural Sciences and Associate Zoologist in Ichthyology Department of Natural Sciences, Bishop Museum 1525 Bernice St., Honolulu, HI 96817 Ph: (808)848-4115, Fax: (808)847-8252 email: deepreef(a)bishopmuseum.org http://hbs.bishopmuseum.org/staff/pylerichard.html

1 0

Re: simple explanation of a taxon concept
by Kennedy, Jessie 04 Nov '05

04 Nov '05

Hi Sally The simplest definition I could give (without going into detail of representation) would be a scientific name as defined in a particular publication. For example, Utricularia foliosa L. As defined in: Taylor, P. 1989. The Genus Urticularia: A Taxonomic Monograph. Kew Bulletin Additional Series XIV. Royal Botanic Gardens, Kew. London. The important issue being that the name is directly associated to at least one and only one definition i.e. that where it was defined - unless of course the database is capturing a new(revised) definition of a concept in which case I would hope that it contain a good unambiguous description of the concept as they see it - otherwise they should refer to a defined concept they agree with) Jessie > -----Original Message----- > From: Taxonomic Databases Working Group GUID Project [mailto:TDWG- > GUID(a)LISTSERV.NHM.KU.EDU] On Behalf Of Sally Hinchcliffe > Sent: 04 November 2005 16:26 > To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU > Subject: simple explanation of a taxon concept > > Hi all, > can any of you people point me towards a web resource where one of > our data managers (specialising in economic botany) can have this > question answered: > > I must admit I'm not altogether sure what is meant by the term taxon > "concepts" (is there a simple explanation?) > > I'm circulating Donald's questions around the various Kew staff who > are involved in databases and some of them for some reason don't seem > to have kept up with the recent fevered debate on TCS-LC and other > fora > > Thanks > *** Sally Hinchcliffe > *** Computer section, Royal Botanic Gardens, Kew > *** tel: +44 (0)20 8332 5708 > *** S.Hinchcliffe(a)rbgkew.org.uk This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender. It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University.

1 0

[tdwg-tapir] TapirLite - dev demo
by Roger Hyam 04 Nov '05

04 Nov '05

Hi Everyone, In order to help understand the issues involved in the TapirLite concept I have been developing a very lightweight provider. The remit I gave myself was PHP + MySQL with no extra libraries or pluggins - i.e. the kind of thing you might get from a cheap ISP or mean IT department. My thinking was that if it can be done in this technology then MS Access plus ASP or similar is equally possible. You can see how far I have got here: http://www.tdwg.hyam.net/TapirLite/ What I will try and do is improve on this and incorporate any changes that are made to the Tapir protocol. The second issue I am addressing is how to develop a Nomenclator API (consisting of parameterized Tapir views). The views will be mappings of TCS into a response structure that is identical to TCS but with DublinCore - not Darwin :) - embedded for the metadata elements. This is still very much work in progress but I thought I would reveal it to the world before the Tapir meeting next week. Please let me know what you think. Any suggestions most welcome. All the best, Roger -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

1 0

simple explanation of a taxon concept
by Sally Hinchcliffe 04 Nov '05

04 Nov '05

Hi all, can any of you people point me towards a web resource where one of our data managers (specialising in economic botany) can have this question answered: I must admit I'm not altogether sure what is meant by the term taxon "concepts" (is there a simple explanation?) I'm circulating Donald's questions around the various Kew staff who are involved in databases and some of them for some reason don't seem to have kept up with the recent fevered debate on TCS-LC and other fora Thanks *** Sally Hinchcliffe *** Computer section, Royal Botanic Gardens, Kew *** tel: +44 (0)20 8332 5708 *** S.Hinchcliffe(a)rbgkew.org.uk

1 0

Re: AW: Topic 3: GUIDs for Taxon Names and Taxon Concepts
by Yde de Jong 04 Nov '05

04 Nov '05

Dear Robert, What I mean is that most entomologists will summarize a taxonomic treatment like: Eupogodon spinellus (C.Agardh 1827) Dasya spinella C.Agardh 1827 = Dasyopsis spinella (C.Agardh 1827) = Dasya cervicornis J.Agardh 1841 = Dasyopsis cervicornis (J.Agardh 1841) = Eupogodon cervicornis (J.Agardh 1841) = Gigartina flabellata Schousboe 1892 = Larnacea flabellata (Schousboe 1892) = Eupogodon flabellatus (Schousboe 1892) Dasya acanthophora Montagne 1840 Rodonema spinella Naccari 1828 Eupogonium spinellum Kützing 1879 -------- ....in either this way: Eupogodon Kützing 1845 = Dasyopsis Zanardini 1843 Eupogodon spinellus (C.Agardh 1827) - originally in Dasya = cervicornis J.Agardh 1841 - originally in Dasya = flabellata Schousboe 1892 - originally in Gigartina ....or this way: Eupogodon Kützing = Dasyopsis Zanardini Eupogodon spinellus (C.Agardh) Dasya spinella C.Agardh = Dasya cervicornis J.Agardh 1841 = Gigartina flabellata Schousboe 1892 And when some generic names are frequently associated with certain species-group names within a genus also: Eupogodon Kützing = Dasyopsis Zanardini = Gigartina auct. = Larnacea auct. Eupogodon spinellus (C.Agardh) Dasya spinella C.Agardh = Dasya cervicornis J.Agardh 1841 = Gigartina flabellata Schousboe 1892 Kind regards, Yde >Dear Yde, > >>I have to check if the TCS can deal with >>objective synonymy in a zoological sense. >>Species2000 for instance can't not deal either >>with objective synonymy nor with basionyms and >>is therefore missing a crucial part of >>information. > >Just asking: What exactly do you mean with 'objectice sysnonymy in >zoological sense' ? > >regards, >Robert Huber

1 0

Re: Topic 3: GUIDs for Taxon Names and Taxon Concepts - Maybe ...
by Sally Hinchcliffe 04 Nov '05

04 Nov '05

Jessie wrote: > > I agree that anyone should be able to assign GUIDs but for their "own" > Taxonomic_Concepts, (so for example a provider like say Mammal species > of the world (or Bergey's manual for bacteria) which has well described > concepts, could issue GUIDs for all of the concepts they recognise and > other users of concepts could use their GUID in their database to record > observations etc if they agreed with their concept. If they didn't agree > with the MSW concept they could publish their own Taxonomic_Concept and > GUID and relate it to some MSW Taxonomic_Concept GUID) BUT.... > Here's a friday afternoon, post-pub idea: we set up a concept bank like GenBank. You can publish (and ID) as many concepts as you like in your own databases but it would be good practice to voluntarily deposit your new concepts in some central repository of concepts and after a while nobody would take any paper seriously if it didn't have a bunch of concept bank ids at the bottom of it listing the new concepts formed. People could go in and mine the ConceptBank for concepts and do meta analyses or build up automated checklists out of small concepts culled from monographs. Anyone want to set one up? partially joking ... Sally *** Sally Hinchcliffe *** Computer section, Royal Botanic Gardens, Kew *** tel: +44 (0)20 8332 5708 *** S.Hinchcliffe(a)rbgkew.org.uk

1 0

AW: Topic 3: GUIDs for Taxon Names and Taxon Concepts
by Robert Huber 04 Nov '05

04 Nov '05

Dear Yde, > > I have to check if the TCS can deal with objective synonymy in a > zoological sense. Species2000 for instance can't not deal either with > objective synonymy nor with basionyms and is therefore missing a > crucial part of information. Just asking: What exactly do you mean with 'objectice sysnonymy in zoological sense' ? regards, Robert Huber

1 0

Re: Topic 3: GUIDs for Taxon Names and Taxon Concepts - Maybe ...
by Kennedy, Jessie 04 Nov '05

04 Nov '05

Hi Rich You definitely should be in bed!!! but not because of your input - amazes me how you manage to keep as clear as you do given the time .... > I did not mean to insinuate that *all* usages should be thought of as > concepts. Like you said -- for another discussion elsewhere. > Good... > > I agree with Sally that we should have Nomenclators provide GUIDs for > Taxon_Names but > > would be more strict and say that these names should have only one GUID > and that the GUID > > should always resolve to exactly the same name. So IPNI would be plant > names, Index > > fugorum fungi names, zoobank when available animal names etc. and that > we > should > > share the resource of fixing this rather than duplicating effort (if I > had > any > > resource to give;-) ) IPNI and IF wouldn't overlap in names. > > This is congruent with my thinking. But are you comfortable with these > different nomenclators having different definitions of a "name"? Might > make > it hard to pool cross-nomenclator data. > I'd prefer they used the same definitions of a name for exchanging data but don't especially mind how they represent it in their system....but that might cause other problems.... Good night.......... Jessie This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender. It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University.

1 0

Re: Topic 3: GUIDs for Taxon Names and Taxon Concepts
by Kevin Richards 04 Nov '05

04 Nov '05

Rich >> For practical reasons I think the starting point for assigning >> GUIDs should be basically nomenclatural. >I completely agree -- but again, what gets a "Name" GUID? (as opposed to a >"usage" GUID or a "concept" GUID) Only basionyms? (I hope!) Or also >different combinations? (I hope not!) Or also spelling variants? (I *really* >hope not!!) There is also a problem of how to deal with autonyms >(=nominotypical names in zoology). One GUID, or two? Logically, only one -- >but most people don't do it that way. I am trying to understand how you imagine a name guid system will work. When you say "what gets a name guid?", what data/database do you think will get the guid - a central name repository? Are you thinking that all records in various databases around the world that are referring to the "same" name will have the same "Name Guid"? For resolvable GUIDs this will mean the name will always resolve to the central repository data. Kevin ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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