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

Re: Topic 3: (Fauna Europaea and gender agreement) GUIDs for Taxon Names and Taxon Concepts
by Donald Hobern 07 Nov '05

07 Nov '05

Only because we do need to be able to generate binomials and trinomials correctly. Yde indicated that Fauna Europaea somehow does this. I agree that this does not stop us using the epithet as the primary unit, but I would like to know whether the epithet carries with it a set of dormant gender variants ready to be activated when it gets associated with a new genus - and should we really be tracking the gender of each genus as part of our data exchange model? To make this more relevant: If we chose (at least for zoology) to equate our nomenclatural objects with epithets rather than binomials, how do we expect applications to use these objects? Are there any special use cases that we need to consider? (Even if there are, they may not include any special GUID behaviour, in which case we can ignore them here.) Donald --------------------------------------------------------------- Donald Hobern (dhobern(a)gbif.org) Programme Officer for Data Access and Database Interoperability Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 --------------------------------------------------------------- -----Original Message----- From: Taxonomic Databases Working Group GUID Project [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU] On Behalf Of Richard Pyle Sent: 07 November 2005 10:04 To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU Subject: Re: Topic 3: (Fauna Europaea and gender agreement) GUIDs for Taxon Names and Taxon Concepts Hi Donald, You asked Yde: > Can you explain a little more about how you handle epithet agreement > ("gender unequivalencies") in this system? I realise this is tangential > from the main GUID discussion, but it does seem to be a complication > to the task of treating the epithet as the primary unit. My question to you: why would epithet gender agreement be a complication to the task of treating the epithet as the primary unit? I'm not sure if I follow. Aloha, Rich

1 0

Re: Various thoughts
by Donald Hobern 07 Nov '05

07 Nov '05

Rich, This is very useful, and your list of different levels ties in with some of the things I have been trying to think about in developing a central data index that will be flexible enough to guide users to relevant data based on a mapping between their request parameters and the variable name information that may be included in different data records. My guess is that many of the levels you describe will be handled by dynamic processing within different systems and will therefore not normally ever receive their own GUIDs. It will be the responsibility of projects such as uBio, Species 2000, ITIS and GBIF to develop algorithms that can cluster name strings in appropriate ways. I would say that the three levels that Rod identifies (raw name strings, nomenclatural records, taxon concepts) are the most important levels for us to refine and the ones on which we need to focus. The last of these is clearly the most contentious, but I believe that the TaxonConcept element as currently defined in TCS is an excellent compromise that should support a wide range of applications. Donald --------------------------------------------------------------- Donald Hobern (dhobern(a)gbif.org) Programme Officer for Data Access and Database Interoperability Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 --------------------------------------------------------------- -----Original Message----- From: Taxonomic Databases Working Group GUID Project [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU] On Behalf Of Richard Pyle Sent: 06 November 2005 11:18 To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU Subject: Re: Various thoughts 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: Topic 3: GUIDs for Taxon Names and Taxon Concepts
by Donald Hobern 07 Nov '05

07 Nov '05

Rich, Thanks for this. I fully agree that we need to separate the core plan for infrastructure from the different subdomain matters. Reading what you have said, I would like to suggest a way for us to keep our focus in these discussions. I want us to achieve something workable at the end of this, and we need to avoid getting tied up in different issues that are certainly important to TDWG and to GBIF, but which will over-extend us right now. I think that it IS really important for us to discuss what the key objects in nomenclature and taxonomy are that would need GUIDs (names, epithets, concepts as published uses, concepts as delineations of sets of organisms, etc.). These discussions will help us to understand how GUIDs are likely to be used. We need to make enough progress on these points to feel sure that we will be able to support the various ways that GUIDs could possibly be used in our domain. However we do not need to solve all of the debates as part of this GUID project. We need to agree on one or more GUID models and associated infrastructure that would be sufficient to support the range of possible uses we identify. The specific application of this GUID model to the different sub-domains is another issue. I think that TDWG must work through all of these questions, but it should be done as part of the different working groups (Biological Collections Data, Taxonomic Names, Structured Descriptive Data, Images, etc.). I think therefore that we should focus on getting the following outputs from the GUID discussions: 1. A list of use cases for identifiers that we should be able to support if we are to meet expectations. We should be sure that there is no major use case that cannot be supported by our proposed implementation. This includes our understanding anything that would be essential for a system of name management based entirely on epithets, as well as one based on binomials (and all of the possible layers that Rich listed from a plain text string up to a fully documented concept). We may finally decide that from a GUID management standpoint all of these classes of data need exactly the same behaviour, but we need a good range of examples if we are to be confident on this point. 2. A specification of the format and expected behaviour for one of our GUIDs independently of the exact type of data being identified, along with a plan to implement any associated infrastructure. 3. A set of guidelines or rules for the TDWG working groups or others to apply to make use of these GUIDs to support their own objects. I believe that the actual decisions here need to be made by those who are developing the different exchange standards. For example, Yde's suggestions about fundamentally different expectations among zoologists and botanists need to be addressed in the TCS group. As another example (taken from one of Sally's posts), the TCS group could recommend a set of organisations to be responsible for GUIDs for names within different taxonomic groups (IPNI, ZooBank, Index Fungorum, etc.). The GUID specification should clearly explain the implications of adopting GUIDs for any particular class of data, as well as any infrastructure work that is required (e.g. registration of the data class in some ontology). One way of looking at this is that I support Rod's point that we are developing an infrastructure on top of which appropriate mappings can be performed. It's up to different subcommunities to work out the most appropriate way to use that infrastructure to make their data linkages as robust as possible. This is all a bit wordy, but I don't have time to make it shorter right now. Thanks, Donald --------------------------------------------------------------- Donald Hobern (dhobern(a)gbif.org) Programme Officer for Data Access and Database Interoperability Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 --------------------------------------------------------------- -----Original Message----- From: Taxonomic Databases Working Group GUID Project [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU] On Behalf Of Richard Pyle Sent: 04 November 2005 03:53 To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU Subject: Re: Topic 3: GUIDs for Taxon Names and Taxon Concepts Hi Kevin, > 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. I think that would be WONDERFUL -- and might even be feasible for zoological names once ZooBank is up and running. But that's tangential to my main point -- which is that TDWG Standards should establish a clear definition for what a "Name" is. At the very basic level, we need to be able to understand the difference between, say, a Specimen GUID vs. a Publication GUID vs. a Taxon Name GUID. Granted, the resolution service should take care of this distinction (a GUID is, after all, a *G*UID), in which case we would't really need to distinguish between these domains. We really need only one GUID system for all object domains (specimens, publications, names, concepts, etc.). But Donald's question of 29 October and the TDWG GUID Wiki, imply that there are different issues to consider for different GUID domains (e.g., "GUIDsForCollectionsAndSpecimens" vs. "GUIDsForTaxonNamesAndTaxonConcepts"). So, *IF* we are partitioning GUID domains (rather than letting the resolution service determine the difference between a specimen and, say, a publication), and *IF* we are thinking about "GUIDsForTaxonNamesAndTaxonConcepts", then I believe it is critical to come up with clear definitions for what the scope of a "Name" is. If TDWG does not impose some standards of this sort, then cross-walking different datasets will be every bit as much a nightmare as it currently is. I would see that as a most unfortunate outcome for the broader goal of global biological data exchange. Maybe I misunderstood your question? Aloha, Rich

1 0

Topic 3: (Fauna Europaea and gender agreement) GUIDs for Taxon Names and Taxon Concepts
by Donald Hobern 07 Nov '05

07 Nov '05

Dear Yde, Just catching up. There is one small practical point I'd like to understand about Fauna Europaea. You wrote the following: How is Fauna Europaea organised? - Basically we have a list of 'naked' taxon names (from the infraspecific level to Kingdom) including full authorship for at least the generic and (infra)specific levels. All those taxon names (read: name elements) have unique id's. - All epithets are linked to their original genus, so original combinations can be reconstructed. This is nearly, but not completely similar to basionyms in botany because gender unequivalencies are not necessarily corrected. - Species names are created by recursively linking species-group names to genus-group names. Genus names are parents of specific epithets, and specific epithets are parents of infraspecific epithets. - Subjective synonyms are specific epithets recursively linked as childs to 'accepted' specific epithets. For objective synonymy genus names synonyms are recursively linked as childs to 'accepted' genus names. - Conclusion: Names (=naked name element/author/year plus original genus for epithets) are for eternity. Species names (so your taxon names) are temporary concepts (if they are not basionyms) which don't have identifiers and which are not kept in the database after taxonomic changes else then by version control. - However, an unique species name id can be easily artificially created by merging both generic and epithet id's (a trick we also use for Species2000). - Taxon concepts are not explicitly covered. Can you explain a little more about how you handle epithet agreement ("gender unequivalencies") in this system? I realise this is tangential from the main GUID discussion, but it does seem to be a complication to the task of treating the epithet as the primary unit. Thanks, Donald --------------------------------------------------------------- Donald Hobern ( <mailto:dhobern@gbif.org> dhobern(a)gbif.org) Programme Officer for Data Access and Database Interoperability Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 ---------------------------------------------------------------

1 0

Re: AW: Topic 3: GUIDs for Taxon Names and Taxon Concepts
by Richard Pyle 06 Nov '05

06 Nov '05

Hi Roger, I'm not sure what you're specifically asking, but there is definitely a difference between ICBN and ICZN Codes in terms of what constitutes a nomenclatural act. Under the ICBN code, combining a species epithet with a different genus name (i.e., creating a new combination) is a Code-governed act. Under ICZN, it is not. There are some ICZN rules that affect subsequent combinations (e.g., gender agreement, secondary homonyms, etc.), but the point is, ICZN-governed "names" are limited to what more or less corresponds to botanical basionyms. These differences between the two Codes have led to the different perspectives of: Botanical -- subsequent genus combination constitutes a new name, and thus genus combination is an attribute of a name object. Zoological -- genus combination (other than original genus combination) considered an attribute of *usage* of a name; therefore not creating a "new" name object. The difference is also reflected in the different styles of attributing authorship of names. As I said in a previous post, it all boils down to whether genus combination is an attribute of a name object (botanical), or of a name-usage instance (zoological). Maybe you're asking about something altogether different, in which case I apologize for adding mud to the water.... Aloha, Rich > -----Original Message----- > From: Taxonomic Databases Working Group GUID Project > [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU]On Behalf Of Roger Hyam > Sent: Monday, November 07, 2005 12:29 AM > To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU > Subject: Re: AW: Topic 3: GUIDs for Taxon Names and Taxon Concepts > > > Yde, > > Could you say which articles in the code (http://www.iczn.org/iczn/) > support the usage examples you are giving here. > > My understanding of this is that it is a matter of presentation within > publications and not a matter of different use of the nomenclatural > codes. The authors are simply assuming that the specific epithets are > well enough known (in combination with the author string) for them not > to have to quote the genus part of the binomial. It seems to me to be > merely a presentation convention like abbreviating the genus name to a > single letter. > > If it is significantly different way of treating names (and therefore > relevant to the GUID debate) why isn't in the code? Perhaps we should > approach the ICZN 2000 editorial committee for their comments? But this > would definitely be outside the scope of GUIDs and should perhaps be > moved to a different list. > > Quoting article numbers nearly always clarifies these debates. > > Hope this helps, > > Roger > > > > On Fri, 4 Nov 2005 15:31:19 +0100, Yde de Jong > <yjong(a)SCIENCE.UVA.NL> wrote: > > >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 > > > > > -- > > ------------------------------------- > Roger Hyam > Technical Architect > Taxonomic Databases Working Group > ------------------------------------- > http://www.tdwg.org > roger(a)tdwg.org > +44 1578 722782 > -------------------------------------

1 0

Re: Topic 3: (Fauna Europaea and gender agreement) GUIDs for Taxon Names and Taxon Concepts
by Richard Pyle 06 Nov '05

06 Nov '05

> and should we really be tracking the gender of each genus as part of > our data exchange model? Good question. The Catalog of Fishes does, and I have found it to be EXTREMELY useful. The other parameter necessary for algorithmic gender-matching of species epithets to genus names is whether the species epithet is proposed as a noun, or as an adjective (not always obvious or self-evident). Only adjectives change to match the gender of the genus -- nouns preserve original orthography. At least that's how it works in ICZN-land. > To make this more relevant: If we chose (at least for zoology) to > equate our > nomenclatural objects with epithets rather than binomials, how do > we expect > applications to use these objects? Appilcations would use them only in the context of a usage instance (wherein the rank, parent name(s), and orthography are indicated as attributes of the usage instance). As stand-alone objects, they would default to their original usage instance (i.e., original genus, original orthography, original rank). Authorship (and certain other Code-governed properties) would be preserved as attributes of the Name object, and the rest would be stacked on the usage instance. This fits in nicely with Jessie's campaign within TCS to encourage using names only in the context of a "SEC" (concept definition usage) -- and not as stand-alone "nominal concepts" -- whenever possible. > Are there any special use > cases that we need to consider? I'm not entirely clear on what you mean by "use cases", but autonyms/nominotypical names (i.e., same epithet, same rank-group, different rank) certainly need to be dealt with as "special case" -- but I think that is true regardless of whether coming at it from the botanical or zoological perspective. Rich

1 0

Re: Topic 3: GUIDs for Taxon Names and Taxon Concepts
by Richard Pyle 06 Nov '05

06 Nov '05

Understood, and thanks! We do seem to be arriving at some sort of consensus, which is refreshing! Aloha, Rich > -----Original Message----- > From: Taxonomic Databases Working Group GUID Project > [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU]On Behalf Of Donald Hobern > Sent: Sunday, November 06, 2005 11:48 PM > To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU > Subject: Re: Topic 3: GUIDs for Taxon Names and Taxon Concepts > > > Rich, > > I never meant my post to come across as a criticism of your level > of detail > (or anyone else's). I believe that all of the messages that have > been sent > contribute to an understanding of the problem space that a GUID solution > must address. I just wanted to limit expectations as to what we > could hope > to solve within these discussions. > > Best wishes, > > Donald > > --------------------------------------------------------------- > Donald Hobern (dhobern(a)gbif.org) > Programme Officer for Data Access and Database Interoperability > Global Biodiversity Information Facility Secretariat > Universitetsparken 15, DK-2100 Copenhagen, Denmark > Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 > --------------------------------------------------------------- > > > -----Original Message----- > From: Taxonomic Databases Working Group GUID Project > [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU] On Behalf Of Richard Pyle > Sent: 07 November 2005 10:37 > To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU > Subject: Re: Topic 3: GUIDs for Taxon Names and Taxon Concepts > > Thanks, Donald -- and my apologies for interpreting too much > detail in your > request. The question of whether concepts need their own GUIDs, vs. being > represented by Name-GUID+Publication-GUID, as posed in your > original Post on > this "Topic 3", seemed to me a more specific question than the > issue of what > a "Name" object is or should be -- so I had calibrated my level of > specificity in my response too precisely. > > I understand and agree that the focus should be broader at this > stage, and I > will re-calibrate the level of specificity of my comments accordingly. > > > For example, Yde's suggestions about > > fundamentally different expectations among zoologists and > > botanists need to be addressed in the TCS group. > > It was discussed among the TCS group -- at GREAT length. There seems no > easy answer, other than "different solutions for different Codes", which > seems to me to be the genesis of a terrible future legacy.... > > It all boils down to the distinction of which attributes apply to a Name > object, vs. which apply to usage instances. The botanical approach stacks > more attributes on the Name object, whereas the zoological > approach tends to > put them more on the usage instances. But as you suggest, this > is something > best saved for a Taxonomy GUID subgroup discussion. > > In any case, thanks for your clarification of the focus. > > Aloha, > Rich > > Richard L. Pyle, PhD > Database Coordinator for Natural Sciences > 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: Topic 3: GUIDs for Taxon Names and Taxon Concepts
by Richard Pyle 06 Nov '05

06 Nov '05

Thanks, Donald -- and my apologies for interpreting too much detail in your request. The question of whether concepts need their own GUIDs, vs. being represented by Name-GUID+Publication-GUID, as posed in your original Post on this "Topic 3", seemed to me a more specific question than the issue of what a "Name" object is or should be -- so I had calibrated my level of specificity in my response too precisely. I understand and agree that the focus should be broader at this stage, and I will re-calibrate the level of specificity of my comments accordingly. > For example, Yde's suggestions about > fundamentally different expectations among zoologists and > botanists need to be addressed in the TCS group. It was discussed among the TCS group -- at GREAT length. There seems no easy answer, other than "different solutions for different Codes", which seems to me to be the genesis of a terrible future legacy.... It all boils down to the distinction of which attributes apply to a Name object, vs. which apply to usage instances. The botanical approach stacks more attributes on the Name object, whereas the zoological approach tends to put them more on the usage instances. But as you suggest, this is something best saved for a Taxonomy GUID subgroup discussion. In any case, thanks for your clarification of the focus. Aloha, Rich Richard L. Pyle, PhD Database Coordinator for Natural Sciences 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: Topic 3: (Fauna Europaea and gender agreement) GUIDs for Taxon Names and Taxon Concepts
by Richard Pyle 06 Nov '05

06 Nov '05

Hi Donald, You asked Yde: > Can you explain a little more about how you handle epithet agreement > ("gender unequivalencies") in this system? I realise this is tangential > from the main GUID discussion, but it does seem to be a complication > to the task of treating the epithet as the primary unit. My question to you: why would epithet gender agreement be a complication to the task of treating the epithet as the primary unit? I'm not sure if I follow. Aloha, Rich

1 0

Re: Various thoughts
by Kennedy, Jessie 06 Nov '05

06 Nov '05

Good discussion Rod.... > > 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 I would agree here with Rod's 3 levels. Richard has gone into much more detail on what a name might be but I think that Rod's is good enough for our purposes. (1)Name strings that supposedly refer to some concept but don't adhere to any of the biological codes of nomenclature, (2)names that were published correctly according to a biological code of nomenclature (and have by definition a type specimen) and concepts (a name + publication where the name may be (1) or (2) depending on the "quality "of the concept ). Many of Richards name types could be sub-types of 1,2, or 3 as he suggests I think. > > So, one could imagine that a nomenclatural database could link its > names to namestring GUIDs, I couldn't honestly imagine a nomenclatural database linking to name strings GUIDs but I could maybe imagine a name search facility linking to nomenclatural or concept databases... >and a concept database could link to > nomenclatural GUIDs. Yes this is what SEEK would want to do... (for its prototype - we're not seeing ourselves being the long term concept bank (yet...) ) > From the user's perspective, they can choose what > kind of entity they want to refer to. Agree here but they really need to understand the problem if they are to make good use of these services. If a user doesn't understand the fact that a scientific name will not uniquely identify what kind or organism they are referring to and thereby that their data will be unambiguous (probably now and more likely in the future thereby lowering it's value) then we're doing them a disservice. > > 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). Yes I agree we need to accommodate different levels of uncertainty I guess this is where I've been promoting nominal concepts when you know the name but don't know the meaning, rather than using a name - basically to express more explicitly we don't know the meaning of the name. > > 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. These are more like concepts to me than name string GUIDs - except that the concepts don't have code approved names.... but if we're really only storing name strings and giving them a GUID then that's more like what I thought the name string GUIDs you were originally proposing were. > > I think we get some benefits from this: > > 1. Everybody is explicit about what they provide Yes > > 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. Chuck could correct me here about TROPICOS but I guess they don't just suggest what names to use they describe concepts and part of that is assigning the appropriate code compliant name to them....i.e. they have a clear meaning for each of the names they use. But some other database might have just as valid but different meaning for the same name as them, possibly because of geography. > > 3. Users decide what level is appropriate for them. They may just link > to a name, they may link to a concept. Yes - but as long as they know if they link to a name they're not being clear about what they mean - it is possible to link to concepts of different degrees of accuracy (genus, sp, sub sp etc)which is different from linking to a name which has a degree of ambiguity and possibly the granularity issue too(except for the implicit inclusion of type specimens in meaning of names). Hope that made sense... > > 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). Yes if done correctly... > > 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). No we in SEEK have been looking at this problem from an ecologist's point of view. I few are to integrate biodiversity data spanning spatial and temporal ranges and we know different parts of the globe use different meaning for the same taxa and that this has also changed across time then integrating data on names will give inaccurate results for analysis. Now genomic work is more recent but even it is starting to suffer I believe from this same problem. So we should try and educate people now and look to the future as well as the past data. > > 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. Yes but it might also add more confidence to the error! So a name is linked to a meaning but it's not what the author meant! The author should decide....and we should provide tools to help them do so. > 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). Agreed if we don't find a good way of doing it. But I still believe people need to be educated on this. > > 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. I agree but I don't think we should pull the wool over people eyes about the problem... > > 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). But why will you use/have the same sequence? - because you've sequenced it yourself and you get the same sequence? or because you thought it was Aus bus or whatever, looked it up in Genbank and copied the sequence??? Again highlighting the importance of being clear what we mean when we use a name - or sequence.... > 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. Yes this would be useful for some things....but definitely limited because of the existing problems in use of names..... > > 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. I agree we need to think big, I agree we need automation - but automation of what - tool sot help people get their meaningful names right would be the best thing. Getting people etc accept error is one thing - making sure they realise the error they are incorporating into their valuable research is just as important. (if they want to share with others they haven't planned to beforehand) 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