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

Re: GUIDs for Taxon Names and Taxon Concepts
by Richard Pyle 14 Nov '05

14 Nov '05

Thanks, Roger. Yes, I was waiting for commentary on my use of "explicitly implied".... > "explicitly implied" is actually contradiction in terms: Agreed -- but I couldn't think of a different term to express what I meant. Rather than grasping for alternate expressions, let me explain it with an example. Suppose a book made clear and unambiguous references to "Ditrichum cornubicum Paton". And then, in the text account directly underneath, there is a paragraph that makes reference to "D. cornubicum". Because this has an abbreviated genus name, it is technically not the same character text-strings as "Ditrichum cornubicum". However, the contextual placement represents an "explicit implication" (oxymoron that it may be) that "D." is intended as an abbreviation of "Ditrichum". It is "explicit" in the sense that it is unambiguously following traditional taxonomic practice of genus abbreviation. It is "implied" in the sense that nowhere did the authors actually state that "D." is intended as an abbreviation for the genus name "Ditrichum". But the point is, even though "Ditrichum cornubicum" represents a different character string from "D. cornubicum", they would not constitute different "NameStrings", and hence would not warrant different NameUsage GUIDs. There are, of course, similarly "explicitly implied" abbreviations for trinomials. Another example would be if a documentation instance (e.g., a book) listed a species heading as "Aus (Xea) bus", where "Xea" is intended as a subgenus. If, in the body of the text underneath this heading, the name "Aus bus" or "A. bus" is used, it would be "explicitly implied" that these are intended as short-hand abbreviations for the "full" NameString, "Aus (Xea) bus". Thus, only one GUID for this documentation instance. There are other examples as well, and all introduce *some* degree of ambiguity -- but as I said before, NONE of the solutions are completely free of ambiguity. > I don't actually see a great deal of disagreement here. > We are debating between only two alternatives. Really?? Which two? I assume you mean "one kind of GUID" for taxon objects, vs. "two kinds of GUIDs". But earlier Rod Page had proposed three different "levels", with GUIDs for all three. Others seemed to like to three-level approach, but some slightly re-defined what the three levels ought to be. I pointed out at least 8 different "units" of a name, not all of which could be unambiguously pidgeonholed into either a "TaxonName" object or a "TaxonConcept" object. You advocate two kinds (levels? types? domains?) of GUID for taxon objects (i.e., Name & Concept). Personally, I think the ultimate goal should be as you describe: separate GUID domains/kinds/types for TaxonNames vs. TaxonConcepts. But Rod Page and others contributing to this thread have convinced me that this might be reaching for too much at this stage of the game. Thus, I am comfortable with the idea of establishing one domain/kind/type of GUID within the taxonomy realm, that is the most flexible and unambiguous of them all, and which can serve as a "stepping-stone" and/or surrogate to a future informatics world where we have an unambiguous distinction between a "TaxonName" object and a "TaxonConcept" object. Importantly, establishing GUIDs for usage instances now does not carry the risk that they will be rendered useless in the future, because I think there will always be value in identifying unique NameUsage instances. > Perhaps what we should do is each put together a page on the > wiki expounding either of the approaches. It will be easier > for some one coming along later to get up to speed on > the arguments and add to them. We then have both cases clearly > stated and we can see which one a consensus builds around. I agree with this, and took a hasty first stab at it with "Scenario 5" on the page you created: http://wiki.gbif.org/guidwiki/wikka.php?wakka=SeparateNamesAndConcepts If I can find time, I'd be happy to expand it on a dedicated page, using a real-world example (maybe a PDF excerpt of a representative documentation instance). I'd be happy to provide the PDF example, if you wish. > This way we can move on to other stuff without having > to make a decision on this one right now. I don't think anyone is being prevented from starting a new thread of discussion -- that can happen anytime independednt of this discussion. > I'll probably not get my page finished till later in the > week as I have other commitments - but certainly by Friday. O.K., if you pick a real-world PDF example that we can both model, I'll follow whatever template you create. Or, if you'd like me to provide a PDF real-world example, I can easily do that as well. 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: GUIDs for Taxon Names and Taxon Concepts
by Roger Hyam 14 Nov '05

14 Nov '05

Hi Rich, So you define a NameUsage as: "Any occurrence of a NameString as it appears or is explicitly implied within some form of static documentation." Let us explore this definition! Picking a volume almost at random (I like the cover) I chose Porley & Hodgett (2005) /Mosses & Liverworts./ http://www.tdwg.hyam.net/images/bryo_01.jpg and picking a page at random - in this case 136 http://www.tdwg.hyam.net/images/bryo_02.jpg So we have a 'static' document and it is chuck full of NameStrings. I have circled some of them. We have /Ditrichum cornubicum/ (a red data book moss). It is mentioned, with a picture on the previous page and at the top of this page it is mentioned a few more times. Further down this page we have /Buxbaumia aphylla/ which is also mentioned twice. There is a picture of it on the next page. So how many name usages do we have here? There seem to be loads. * Does each mention of the name on the page count as a usage? - would seem to be a silly thing to do. * Does mentioning the name on different pages mean different usages? - would also be silly but we don't have anyway to judge (different pages within a journal or combined work for example?) * How about same page but different context? The picture may be of a different moss to the one that they mention in the text. * If a subspecies is mentioned does that count as a usage of the specific name (it has been used) and likewise a binomial implies a usage of the genus name. * There are around 1100 species mentioned in this publication. They are probably mentioned on average 3 times each (a guess) so that is 3300 new name usages. Plus they are all binomials or subspecific names so double that for the different usages or genera etc. So 6,600 name usages in this volume. I wonder how many publications like this come out a year globally? I really can't see how one would apply your definition. Perhaps if you restricted it to taxonomic works but then you have to define a taxonomic work and you are still limited to how it has to be stated to act as a 'usage'. It certainly isn't clear to me. We can easily define what a TaxonConcept is because it implies *intent*. If I want to create an object that I want you to refer to as a definition of a taxon then I am creating a TaxonConcept and should issue a GUID to make it easy for you to refer to it. If not then I shouldn't bother. If I want to use the services of a nomenclator to define the publication and typification of the name I am using then I can use a TaxonName GUID within my definition - but I don't have to. I can't see how that can be any simpler than that. Porley & Hodgetts (2005) have no intension whatsoever of 'committing' nomenclatural acts or of defining any taxa that people will later refer to. They are simple *referring *to existing concepts. Yet by your definition they have created over 6k name usages that a diligent publisher might issue GUIDs for. Have I completely misinterpreted you definition? If so could you define it a little tighter? If you imply that the author has to have meant to describe something then you are just creating the TaxonConcept definition I am working with here. How else can you subset all the times names appear in print? This is all great fun but we do need to nail it down and move on. All the best, Roger Richard Pyle wrote: > Hi Roger, > > >> Could you attempt a concise definition of a >> UsageInstance we can all agree on then :) >> > > Sure: Any occurrence of a NameString as it appears or is explicitly implied > within some form of static documentation. > > "NameString" refers to a string of textual characters meant to represent a > name of biological organisms. This can be defined more restrictively to > "ScientificNameString" (names that conform to one of a designated set of > nomenclatural Codes), or more broadly to include vernacular NameStrings. > > "static documentation" can be defined broadly, to include publications, > databases, and any other form of documented medium of human communication. > The "static" part means that it must represent a snapshot in time. In the > case of dynamic databases, this would require a "date stamp" for each > UsageInstance -- either for an individual record, or for a snapshot of the > entire dataset. > > The "explicitly implied" part addresses zoological-style nomenclatural > listings along the lines of what Yde has sent to this list, where a genus is > listed once as a header, and species epithets are enumerated below, > explicitly implying a series of binomials, even if they are not actually > printed on papaer as such. > > The point is, the definition is highly flexible, yet mostly unambiguous > (assuming sufficient metadata for identifying a documentation instance). > > I think it only makes informatic sense to distinguish two "kinds" of GUID > for taxonomic objects if the distinction between the objects is unambiguous. > Given these NameStrings: > > 1. Aus Smith 1995 > 2. Xea Jones 2000 > 3. Aus bus Smith 1995 > 4. Xea bus (Smith 1995) Jones 2000 > 5. Xea ba (Smith 1995) Jones 2000 > > It is ambiguous whether there are three, four, or five distinct NameObjects > represented (i.e., it is ambiguous whether #s 4 & 5 should get TaxonName > GUIDs, or TaxonConcept GUIDs via SEC instances). > > However, given this list: > > 1. "Aus" as it appears in Smith 1995 > 2. "Xea" as it appears in Jones 2000 > 3. "Aus bus" as it appears in Smith 1995 > 4. "Xea bus" as it appears in Jones 2000 > 5. "Xea" as it appears in Pyle 2005 > 6. "Xea ba" as it appears in Pyle 2005 > 7. "Xea" as it appears in ITIS Nov. 11, 2005 snapshot dataset > 8. "Xea bus" as it appears in ITIS Nov. 11, 2005 snapshot dataset > 9. "Xea ba" as it appears in ITIS Nov. 11, 2005 snapshot dataset > > There is very little ambiguity that each item in this list gets its own > GUID. Until a universal definition of a "NameObject" emerges, certain usage > instances can serve as surrogates for basionyms (1, 2, 3), or botanical new > combinations (4), or TaxonConcepts (1-6) -- in whatever way that a data > manager needs or wishes to establish linkages among GUIDs (e.g., linking #s > 4, 6, 8 & 9 to #3 via "is basionym of"; or linking #s 4, 6, 8 & 9 to #2 via > "is combined with"; or linking #5 to #6, #2 to #4, and #1 to #3 via > "contains"). > > Several people have expressed a desire for "simple" and "flexible", and I > think this approach maximizes both. > > Aloha, > Rich > > -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

1 0

Re: [tdwg-tapir] Errors in the protocol schema
by "Döring, Markus" 14 Nov '05

14 Nov '05

Javi, I changed the unknownOutputModel flag, but I cant find the other problems you mentioned. Are they still there? markus -----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces(a)lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Javier privat Gesendet: Montag, 14. November 2005 12:20 An: tdwg-tapir(a)lists.tdwg.org Betreff: [tdwg-tapir] Errors in the protocol schema Hi all, Before I forget, here are some problems that I have with the actual schema. I did not want to change things directly because I still consider Markus to be our editor ;) -The search tag in the capabilities still requieres the "acceptUnknownOutputModels" attribute, this should be removed (Now this is indicated below in customOutputModels). -The type of the datasourceName environmental variable is not correctly set. -add, not & lessThanOrEquals seems to have the same problem under operators. I think that's all for now... Javi. _______________________________________________ tdwg-tapir mailing list tdwg-tapir(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org

1 0

Re: [tdwg-tapir] {Definitely Spam?} Modification in the Inventoryresponse
by "Döring, Markus" 14 Nov '05

14 Nov '05

I like the idea. It will make the inventory a little bit more "customizable" similar to the searches. Are there any objections or other preferred names for the new attribute? Could be for example elementName, responseElement, responseName, tag, tagname, name, renamed. I think I quite like tag. And I think it should be optional and default to the <value> tag if not supplied. Markus -----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces(a)lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Javier privat Gesendet: Dienstag, 25. Oktober 2005 12:41 An: tdwg-tapir(a)lists.tdwg.org Betreff: [tdwg-tapir] {Definitely Spam?} Modification in the Inventoryresponse Dear all, Samy Gaiji, from IPGRI, sent us yesterday an email with comments about TAPIR. He consider the response format of the inventory operation inconvenient. For those not remembering an inventory operation looks like this: Request: ------------ <?xml version='1.0' encoding='UTF-8'?> <request> <header /> <inventory count='true' start='0' limit='50' xmlns:dwc='http://digir.net/schema/conceptual/darwin/2003/1.0'> <concepts> <concept path='dwc:/Country' /> <concept path='dwc:/Genus' /> </concepts> </inventory> </request> ---- Response ------------- <?xml version="1.0" encoding="UTF-8"?> <response> <header></header> <inventory> <record> <value>AUSTRALIA</value> <value>Calicium</Genus> </record> <summary start="0" totalReturned="50" totalMatched="73" next="50" /> </inventory> </response> -------------- He find hards to parse after that all concepts are named 'value' and having to trust on that the elements are returned in the same order as they were request. I don't know, for me this does not look like a big issue, but in any case here is a proposal that makes possible to assign names to the elements that are responded. Request: ----------------------------------- <?xml version='1.0' encoding='UTF-8'?> <request> <header /> <inventory count='true' start='0' limit='50' xmlns:dwc='http://digir.net/schema/conceptual/darwin/2003/1.0'> <concepts> <concept path='dwc:/Country' elementName='Country' /> <concept path='dwc:/Genus' elementName='Genus' /> </concepts> </inventory> </request> ------------------------------- Response: ------------------------------- <?xml version="1.0" encoding="UTF-8"?> <response> <header></header> <inventory> <record> <Country>AUSTRALIA</Country> <Genus>Calicium</Genus> </record> <summary start="0" totalReturned="50" totalMatched="73" next="50" /> </inventory> </response> ------------------------ You can find attached a modification of the latest protocol schema that includes this. What are your thoughts on this?

5 4

[tdwg-tapir] serialised tapir filters
by "Döring, Markus" 14 Nov '05

14 Nov '05

Dear all, in Madrid we were trying to allow all operations also to be alternatively invoked via pure http-get requests. For this we needed to agree on a way to serialise complex filters. We proposed the following syntax: http://ww3.bgbm.org/protocolwiki/GetInvokedOperations To test these kind of filters I have created a parser that tranlates them into PyWrapper filter objects: http://ww3.bgbm.org/tapirwrapper/utilities/filterdecoder.cgi The new "concept aliasing" is not yet implemented as is the new cocnept binding syntax inspired by RDF: http://ww3.bgbm.org/protocolwiki/ConceptAlias The simple decoder service is meant to play and test with serialised filters and the operator precedences. Its not heavily tested so dont expect it to be 100% bug free. thanks, Markus PS: to read more about the madrid meeting results take a look at the protocol wiki: http://ww3.bgbm.org/protocolwiki/MadridResults2005 ... but be aware that the wiki pages are currently under heavy changes and not all results have been properly documented yet.

1 0

Re: GUIDs for Taxon Names and Taxon Concepts
by Richard Pyle 14 Nov '05

14 Nov '05

Thanks, Yde -- I should have included the junior synonym example in my original list, so I'm glad you raised it. Let me slightly modify your list (I've stripped the name authorships to make it less cluttered -- we assume no homonyms here -- and "ba" is the feminine form of "bus"): 1. Aus, as it appears in Smith 1995 2. Aus bus, as it appears in Smith 1995 3. Aus cus, as it appears in Smith 1995 4. Xea, as it appears in Jones 2000 5. Xea ba, as it appears in Jones 2000 6. Aus, as it appears in Pyle 2005 7. Xea, as it appears in Pyle 2005 8. Xea bus, as it appears in Pyle 2005 9. = Xea ba (Smith 1995) Jones 2000 10. = Aus bus Smith 1995 11. = Aus cus Smith 1995 The last 3 are "as they appear in Pyle 2005"). Among the three implied junior synonyms (#s 9, 10 & 11), there are several types: - #9 is the same basionym, same combination, different epithet spelling. - #10 is the same basionym, same epithet spelling, different combination. - #11 is a different basionym. I see these as three different classes of "synonyms", and I do not believe that we need to enumerate these (and other) classes of synonyms before we can implement a GUID system for taxon objects. Applying the NameUsage instance paradigm as I have described it to this case, #s 1-7 would each get a distinct GUID. As for 8-11, because there are four distinct NameStrings within one documentation instance (Pyle 2005) -- four GUIDs would be assigned. There are various degrees of ambiguity as to what nomenclatural and Concept links could/would/should be established among these nine GUID-represented objects (some are obvious, and some may not be obvious), but at least there is no ambiguity about what objects should have a GUID assigned to them. Aloha, Rich

1 0

Re: GUIDs for Taxon Names and Taxon Concepts
by Richard Pyle 14 Nov '05

14 Nov '05

Hi Roger, Sorry, I wasn't clear enough. I think the simplest way to clarify is to answer your questions directly: > So we have a 'static' document and it is chuck full of NameStrings. I have circled some of them. > > We have Ditrichum cornubicum (a red data book moss). It is mentioned, with a picture on the > previous page and at the top of this page it is mentioned a few more times. Further down this > page we have Buxbaumia aphylla which is also mentioned twice. There is a picture of it on > the next page. > > So how many name usages do we have here? One. A "NameString" is defined as a string of textual characters meant to represent a name of biological organisms. That there may be many replicate copies of the *same* NameString within one documentation instance does not mean there are many NameStrings (keeping in mind the "or is explicitly implied" part of the definition). > Does each mention of the name on the page count as a usage? No, because they are replicate copies of the same NameString; not different NameStrings. > - would seem to be a silly thing to do. Yes, it would. > Does mentioning the name on different pages mean different usages? Not if those different pages are within the same scope of the documentation instance. Sometimes, however, what seems like a single documentation instance may be subdivided into several documentation instances (e.g., chapters in a book), so it depends on what the scope of the documentation instance is. Please note that this realm of ambiguity exists completely independently of the problems we're discussing about GUID "units" in taxonomy, and thus applies equally to all solutions to the question of what object(s) should receive a taxon GUID. > - would also be silly but we don't have anyway to judge > (different pages within a journal or combined work for example?) We judge based on the defined scope of the documentation instance (hence my parenthetical comment, "assuming sufficient metadata for identifying a documentation instance"). > How about same page but different context? The picture may be of a > different moss to the one that they mention in the text. A picture is not a NameString. Multiple replicates of the same literal or explicitly implied NameString within the same defined documentation instance do not constitute multiple NameStrings, and hence do not represent multiple usage instances. > If a subspecies is mentioned does that count as a usage of > the specific name (it has been used) Yes, of course. True even for autonyms, such as "Pseudanthias ventralis ventralis", being a separate NameString from "Pseudanthias ventralis" (the former consisting of 32 textual characters (including the spaces), and the latter consisting of 22 textual characters (including the space). > and likewise a binomial implies a usage of the genus name. Yes, that is correct. Just as trinomial implies usage of a species name as well as a genus name. Part of "explicitly implied". > There are around 1100 species mentioned in this publication. > They are probably mentioned on average 3 times each (a guess) > so that is 3300 new name usages. No, it is 1100 NameString usages that include spaces as part of the NameString (i.e., species-group names), plus an additional 300 NameString usages at the genus level (a guess), plus whatever NameStrings at higher ranks. Again, a NameString is identified as a string of textual characters meant to represent a name of biological organisms. Multiple copies of the same NameString meant to represent the same name of the same biological organisms within a defined documentation instance do not constitute multiple NameStrings, and hence do not represent multiple NameUsage instances. The "meant to represent a name of biological organisms" part of the definition is necessary to address the fact that homonyms are meant to refer to different names, even though they share the same NameString. Thus, the appearance of two separate homonymous NameStrings intended to represent two separate names, constitute two separate NameUsage instances (in need to two separate GUIDs). > I really can't see how one would apply your definition. How about now, after I have clarified the definition? > Perhaps if you restricted it to taxonomic works That is a question of the scope of documentation instances; not the scope of NameUsage instances. I would suggest leaving the definition flexible and broad. > It certainly isn't clear to me. Is it any more clear now? If not, please let me know what parts don't make sense. > We can easily define what a TaxonConcept is because it implies intent. > If I want to create an object that I want you to refer to as a definition > of a taxon then I am creating a TaxonConcept and should issue a GUID to > make it easy for you to refer to it. If not then I shouldn't bother. > If I want to use the services of a nomenclator to define the publication > and typification of the name I am using then I can use a TaxonName GUID > within my definition - but I don't have to. I can't see how that can > be any simpler than that. Evidently we have different ideas about the definition of the word "simpler"... ;-) > Porley & Hodgetts (2005) have no intension whatsoever of 'committing' > nomenclatural acts or of defining any taxa that people will later refer > to. They are simple referring to existing concepts. Really? Who makes that decision? You? Porley & Hodgetts (2005)? SEEK? GBIF? There is an almost perfectly smooth transition gradient in published literature (let alone unpublished documentation sources) between name-only usages and full-blown highly-defined TaxonConcepts. If you advocate two "kinds" of GUIDs (one for TaxonNames, and one for TaxonConcepts), then an arbitrary line needs to be drawn between those that are TaxonName objects, and those that should be treated as TaxonConcept objects. This discussion thread has made clear that this arbitrary line would be drawn in different places by different people. Why not start a GUID system from the simplest and most flexible approach (which also happens to be the most objective in terms of identifying objects to which GUIDs should be assigned), and condense as much of the subjectivity as possible into the second-tier informatics task of establishing links among GUID-represented objects? That second-tier task is already rife with subjectivity and ambiguity no matter how many "kinds" of taxon GUIDs are established. > Yet by your definition they have created over 6k name usages > that a diligent publisher might issue GUIDs for. Well....probably more like 1.5K Name usages. And who is the "publisher" in this case? The publisher of the book? Is that who we expect will assign the GUIDs? Or do you mean the publisher more generically -- as a publisher of GUID assignments (like a data provider)? > Have I completely misinterpreted you definition? Well...."completely" might be too strong of a word. The word "mostly" seems like a more appropriate adverb in this case. > If so could you define it a little tighter? I thought I had....let me know if this message does not clarify the definition. > If you imply that the author has to have meant to describe something then you are just > creating the TaxonConcept definition I am working with here. How else can you subset > all the times names appear in print? Well....there minimally has to be sufficient evidence that the author intended a given NameString to represent biological organisms -- so that we can at least classify the NameString as a "name" (as distinguished from the large quantities of other non-name words that might appear within a documentation instance). But whether or not the described "something" rises to the level of a TaxonConcept, or is merely intended as a reference to a pre-existing TaxonConcept (or something else entirely), is an ambiguity that I do not think should clutter the discussion about GUIDs for taxonomic objects. > This is all great fun but we do need to nail it down and move on. I agree 100%. Unfortunately, the level of disagreement (not just from me) as expressed in this discussion makes it clear that we have not yet nailed it down. Finally, let me know if you want me to clarify what I mean by "explicitly implied" in my one-sentence definition. This is where I expected some argument, because it is the one area where there is ambiguity in my approach (other than the documentation instance thing -- the ambiguity of which applies equally to all of the proposed taxon GUID solutions). I don't believe that any solution is completely free of ambiguity -- but I believe that NameString Usage instances are (by far) the least ambiguous of objects, and can flexibly serve as "handles" to both TaxonName objects (by any definition) and TaxonConcept objects (in the sense that we all seem to accept that "Aus bus Smith 1995 SEC Jones 2000" can serve as a "handle" to a TaxonConcept instance). 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: GUIDs for Taxon Names and Taxon Concepts
by Richard Pyle 13 Nov '05

13 Nov '05

Hi Roger, > Could you attempt a concise definition of a > UsageInstance we can all agree on then :) Sure: Any occurrence of a NameString as it appears or is explicitly implied within some form of static documentation. "NameString" refers to a string of textual characters meant to represent a name of biological organisms. This can be defined more restrictively to "ScientificNameString" (names that conform to one of a designated set of nomenclatural Codes), or more broadly to include vernacular NameStrings. "static documentation" can be defined broadly, to include publications, databases, and any other form of documented medium of human communication. The "static" part means that it must represent a snapshot in time. In the case of dynamic databases, this would require a "date stamp" for each UsageInstance -- either for an individual record, or for a snapshot of the entire dataset. The "explicitly implied" part addresses zoological-style nomenclatural listings along the lines of what Yde has sent to this list, where a genus is listed once as a header, and species epithets are enumerated below, explicitly implying a series of binomials, even if they are not actually printed on papaer as such. The point is, the definition is highly flexible, yet mostly unambiguous (assuming sufficient metadata for identifying a documentation instance). I think it only makes informatic sense to distinguish two "kinds" of GUID for taxonomic objects if the distinction between the objects is unambiguous. Given these NameStrings: 1. Aus Smith 1995 2. Xea Jones 2000 3. Aus bus Smith 1995 4. Xea bus (Smith 1995) Jones 2000 5. Xea ba (Smith 1995) Jones 2000 It is ambiguous whether there are three, four, or five distinct NameObjects represented (i.e., it is ambiguous whether #s 4 & 5 should get TaxonName GUIDs, or TaxonConcept GUIDs via SEC instances). However, given this list: 1. "Aus" as it appears in Smith 1995 2. "Xea" as it appears in Jones 2000 3. "Aus bus" as it appears in Smith 1995 4. "Xea bus" as it appears in Jones 2000 5. "Xea" as it appears in Pyle 2005 6. "Xea ba" as it appears in Pyle 2005 7. "Xea" as it appears in ITIS Nov. 11, 2005 snapshot dataset 8. "Xea bus" as it appears in ITIS Nov. 11, 2005 snapshot dataset 9. "Xea ba" as it appears in ITIS Nov. 11, 2005 snapshot dataset There is very little ambiguity that each item in this list gets its own GUID. Until a universal definition of a "NameObject" emerges, certain usage instances can serve as surrogates for basionyms (1, 2, 3), or botanical new combinations (4), or TaxonConcepts (1-6) -- in whatever way that a data manager needs or wishes to establish linkages among GUIDs (e.g., linking #s 4, 6, 8 & 9 to #3 via "is basionym of"; or linking #s 4, 6, 8 & 9 to #2 via "is combined with"; or linking #5 to #6, #2 to #4, and #1 to #3 via "contains"). Several people have expressed a desire for "simple" and "flexible", and I think this approach maximizes both. Aloha, Rich

1 0

Re: GUIDs for Taxon Names and Taxon Concepts
by Roger Hyam 13 Nov '05

13 Nov '05

Hi Rich, "But we probably can agree on what a usage instance is." Could you attempt a concise definition of a UsageInstance we can all agree on then :) All the best, Roger Richard Pyle wrote: > Hi Roger, > > Many thanks! This is helpful. > > >> I think you are wrong in your conclusions that we do not need >> GUIDs for TaxonNames and TaxonObjects >> > > You are mistaken if you believe that I don't think we need GUIDs for > TaxonName objects. I *do* think we need them. I just believe that we will > do more harm than good if we encourage a proliferation of separate > Name-GUIDs and Concept-GUIDs, when there is not a clear distinction between > them. If we recognize two distinct "kinds" of GUIDs, with the realization > that the same informational object (e.g., a new combination) would be > represented by one data provider as one "kind" of GUID, and by another data > provider as the other "kind" of GUID, then I think we are setting ourselves > up for some really thorny data management issues down the road. > > >> I need to do diagrams >> to illustrate the case so have created a wiki page here: >> >> http://wiki.gbif.org/guidwiki/wikka.php?wakka=SeparateNamesAndConcepts >> > > This is excellent and I will expand upon it in the Wiki to reflect the point > I am trying to make as soon as I have time. > > >>> Yes, you could certainly force-treat zoological names as though they >>> > were > >>> botanical names (treating new combinations as "new names"), just as you >>> could easily force-treat botanical names as though they were zoological >>> names (assigning TaxonName GUIDs only to basionyms, and representing new >>> combincations via Usage/TaxonConcept GUIDs). I just believe that we >>> > will > >>> come to regret it if we leave the distinction "fuzzy". >>> >> I am not suggesting we leave it fuzzy I am suggesting we leave it up to >> the nomenclators and that it isn't a GUID issue. >> > > It is a GUID issue if there are two different "kinds" of GUID established, > without a clear distinction between them. And I think the current > distinction between whether a data provider sould establish a TaxonConcept > GUID or a TaxonName GUID for a given data record is "fuzzy". > > >> Just because we are not solving the problem here does not mean that >> we are not going to get the problem solved. >> > > Yes, but we may be creating a new problem, or exacerbating an existing > problem, by introducing different kinds of GUIDs without a clear > understanding of which types of GUIDs apply to which kinds of data objects. > > >> Then don't refer to the TaxonName GUIDs issued by nomenclators when you >> issue your TaxonConcepts. Just ignore the nomenclator bit. If you are >> correct then everyone will follow your lead. A two GUID system will just >> degrade to a one GUID system if the names thing is wrong. >> > > It's not about "right" or "wrong" -- it's about optimizing the efficiency > and effectiveness of information exchange. Encouraging the creation of > ill-defined GUIDs carries with it a risk of impeding information exchange, > because of ambiguities about mapping records in one dataset to records in > another dataset. > > >> Here is a definition of the two types of GUID: >> >> A TaxonName GUID resolves to a data object that only contains >> information about nomenclature. The provider does not intend >> anyone to be able to identify a specimen to this GUID. >> >> TaxonConcept GUIDs resolves to a data object that contains information >> about the delimitation/circumscription/relationships of a taxon. >> The provider intends people to be able to identify or otherwise >> related data to this GUID. >> > > As a vocal and long-standing commentator on the difference between a > taxonomic "name" and a taxonomic "concept", I feel I have a strong grasp of > this distinction. What concerns me on this GUID discussion is that I > believe that ill-defined GUID "domains" ("kinds") have the potential of > doing more harm than good. We don't all agree on what a "name" is. We > don't all agree on what a "concept" is. But we probably can agree on what a > usage instance is. This is why I now advocate focusing on this broadest, > most flexible, and unambiguous of taxonomic entities to start with in > applying TDWG-standard GUIDs to, because ALL datasets can conform to it > (especially if the "SEC" part of the usage instance can be set to "Nobody in > particular"). > > I'll try to articulare this more effectively on the Wiki page you started. > > Aloha, > Rich > > -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

1 0

Re: GUIDs for Taxon Names and Taxon Concepts
by Richard Pyle 12 Nov '05

12 Nov '05

Hi Roger et al., I have done my best to illustrate my "one kind of GUID" proposal via Scenario 5: http://wiki.gbif.org/guidwiki/wikka.php?wakka=SeparateNamesAndConcepts I also added the main concern I have regarding Scenario 4, which is that Name instances may not be directly comparable, and therefore not directly mappable. Let me re-emphazise that I have a long track record of championing the distinction between taxon names and taxon concepts, so I understand the importance of recognizing them as distinct entities. My concern at this point is to find the "least common denominator" that can serve as the root currency exchange of taxonomic information, and allow the greatest flexibility in application at this early stage of TDWG-GUID standarization. I put this together hastily, so I apologize if I was not clear. Aloha, Rich -----Original Message----- From: Taxonomic Databases Working Group GUID Project [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU]On Behalf Of Roger Hyam Sent: Friday, November 11, 2005 3:26 AM To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU Subject: Re: GUIDs for Taxon Names and Taxon Concepts Hi Rich, I think you are wrong in your conclusions that we do not need GUIDs for TaxonNames and TaxonObjects but I need to do diagrams to illustrate the case so have created a wiki page here: http://wiki.gbif.org/guidwiki/wikka.php?wakka=SeparateNamesAndConcepts I also intersperse some comments below. Richard Pyle wrote: Hi Roger, Rich - yes. I think you sum up the difference between new combinations in ICZN and ICBN well. But... just because the ICZN does not consider the usage of a name in a different genus as a nomenclatural act does not stop us creating a data object (TaxonName object) to represent what that name looks like in the new genus - perhaps with its new ending and possibly different author string (ICZN Recommendation 51G). I agree that nothing is stopping us, but I forsee headaches down the road as a result of doing so. In your next message, you wrote: "1. We have two kinds of GUID (one for TaxonNames and one for TaxonConcepts)." >>>From this I interpret that TaxonName GUIDs are different with TaxonConcept GUIDs -- is that correct? If so, the problem is that a botanist would assign a new TaxonName GUID to a new combination, and a zoologist would assign a TaxonConcept GUID to the same entity, because "genus combination" is a property of a name in botany, and a properyy of a usage (~concept) in zoology. Yes, you could certainly force-treat zoological names as though they were botanical names (treating new combinations as "new names"), just as you could easily force-treat botanical names as though they were zoological names (assigning TaxonName GUIDs only to basionyms, and representing new combincations via Usage/TaxonConcept GUIDs). I just believe that we will come to regret it if we leave the distinction "fuzzy". I am not suggesting we leave it fuzzy I am suggesting we leave it up to the nomenclators and that it isn't a GUID issue. I don't leave the maintenance of the brakes on my car fuzzy by not fixing them myself - I delegate it to a mechanic. Just because we are not solving the problem here does not mean that we are not going to get the problem solved. My point has always been, and continues to be, that *IF* you have separate "kinds of GUID" for TaxonNames and TaxonConcepts, the line between the two should be unambigious (and ideally be consistent for both botany and zoology). After thinking about it some more, in the context of what has been written on this thread, I find myself coming back to that first "IF". Given that there seems to be a need and a desire to leave the definition of a "name unit" (to which a GUID is assigned) loose and flexible, then perhaps it would be premature to establish a GUID system for Name-Objects at all. Instead, I think we can both simplify *and* disambiguate taxonomic objects if there is only *ONE* GUID system -- which represents a Name-Usage instance. Then don't refer to the TaxonName GUIDs issued by nomenclators when you issue your TaxonConcepts. Just ignore the nomenclator bit. If you are correct then everyone will follow your lead. A two GUID system will just degrade to a one GUID system if the names thing is wrong. In the case of datasets consisting of only namestrings, with no specific implied concept objects, the names can be interpreted as "NameString SEC Nobody" (=Nominal TaxonConcept in TCS). Nomenclators could use whichever subset of these Name-usage GUIDs that they wish to refer to their own version of a name-object. For example, ZooBank can concern itself only with those GUIDs attached to original basionym usage instances, and IPNI can manage both basionyms usage instances and new-combination usage instances. ConceptBank could expand the scope of GUIDs to all those usage instances that represent defined concepts. Name indexers could use the broadest set of GUIDs (effectively all name-usage instances). I think you are mixing issues here. The name string probably represents a TaxonConcept sec the dataset - depending on your intent. If you have had people scoring observations to a checklist for an area for a number of years then it would be convenient to treat the names as concepts so that you can reason about how they may be related to other better defined concepts. They are concepts sec your list. If they are just words you found in some books then they are just words till you intend to do something with them. A nomenclator should not be publishing data other than nomenclatural data (debatable what this is I know but no circumscription data anyway). ConceptBank sounds like any indexer (like GBIF) that crawls the people who are defining concepts of taxa and tries to provide sensible query expansion on the basis of the GUIDs or however else it links the objects together. So, in summary, my feeling is that if we are to think of "two kinds of GUID" for taxon objects, then we need an unambiguous (and cross-Code) distinction between the two. If such a distinction is too cumbersome to draw (as it seems to be, based on the current thread), then we should only go with one kind of GUID -- and by default it should be the one kind that is most flexible (=usage instance). See the wiki page for why I think this is an erroneous conclusion. Here is a definition of the two types of GUID: A TaxonName GUID resolves to a data object that only contains information about nomenclature. The provider does not intend anyone to be able to identify a specimen to this GUID. TaxonConcept GUIDs resolves to a data object that contains information about the delimitation/circumscription/relationships of a taxon. The provider intends people to be able to identify or otherwise related data to this GUID. I think the notion of the intension of the provider is very important as it answers many questions. "Should I attach a GUID to object X?" depends on what you want other people to do with it. I don't think this is very cumbersome definition? There is no 'natural' distinction between these two things. It is a pragmatic split so we produce a series of 'rooted' directed graphs of 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