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

Re: Basic requirements for a basic GUID infrastructure
by Richard Pyle 15 Nov '05

15 Nov '05

Hi Ricardo, > I also think that the specimen group has a similar concern about how > many "kinds" of GUIDs we have. For example, we can issue GUIDs to a > survey or collecting event, a lot, an individual, parts of an > individual, tissues, etc. However, Donald suggested a neat solution to > break down the problem into smaller manageable pieces, which is to > develop a shared ontology and relate each record in our specimen network > to the classes in the ontology. So in the end, we only have one kind of > GUID and many metadata services laying on top of that doing the various > mappings. This sounds almost *exactly* like what I am thinking for taxonomic data. The one unit that is shared by all consumers of taxonomic data is the NameUsage instance. It lies at the heart of indexing efforts, spelling variant documentation, basionym creation, new combination creation, and concept definitions (among others). How these fundamental units of taxonomy are used and cross-linked can be determined by overlying metadata services, via a shared ontology. > In my opinion, this kind of solution lay down a number of > requirements for an underlying GUID infrastructure: > > 1) Identifiers deliver you to objects (where feasible). > 2) Identifiers deliver you to object metadata. > 3) Each object should wear its own identifier (desirable). > 4) Identifiers are issued in a descentralized manner, i.e., by > independent agents. > 5) Ids identify digital objects, not physical ones. > 6) Other requirements I missed? > > Then I pose the question, would the above assumptions fulfill the > requirements of the candidate solutions laid out in the previous taxon > concepts and names discussion? I *think* so, but I would need clarification on some of the vocabulary: - What is an "object" in the context of taxonomy, and how is it different from object metadata? Is it necessarily a physical object? Or might it be an abstract object, such as a Code-compliant taxon name (independent of how or where that name is used or appears within some form of documentation)? - What does "wear" mean in #3? - I understand the need for #4, but how, then, are GUIDs re-used by multiple data providers? For example, the NameUsage instance of "Aus bus" in the publication "Smith 1995" might be replicated as a data record in many different data providers. Would each provider automatically create its own GUID for this same NameUsage instance? Or would GBIF establish tools to help locate and re-use a GUID that has already been established by another data provider for this NameUsage instance? - I assume that #5 also applies to abstract objects (like the notion of a TaxonName independent of its involvement with any particular NameUsage instance), such that the identifier refers to the digital record established for the physical/abstract object. Does this sound correct? - Also related to #5 (and your next paragraph), there is a much tighter connection between a physical object and its digital representation in the realm of specimens, than there is in the realm of taxonomy. It is unlikely that Bishop Museum will assign large numbers of GUIDs for digital records representing physical specimens housed at the Smithsonian. On the other hand, it is VERY likely that Bishop Museum and Smithsonian will share MANY taxon names and NameUsage instances across their two datasets. > You might argue that the current taxon names and concepts discussion > would require a centralized ID issuing authority I would not argue that taxonomy GUIDs should necessarily be centralized. But I *would* argue that tools be established to encourage re-use of existing GUIDs, rather than encourage proliferation of multiple GUIDs for multiple digital objects that refer to the identical physical/abstract object. Aloha, Rich

1 0

Re: GUIDs for Taxon Names and Taxon Concepts
by Nozomi Ytow 15 Nov '05

15 Nov '05

Hi Rich, > > "Any data object reprsenting an occurrence of a NameString as it > > appears, or, interpreted as explicit by the data provider, > > within some form of static documentation." > Fine by me! May be obvious, intead of explict, for clarity. Explicit is clearer than obviuos, but it may be too restrictive. Usability of data strongly depends on data provider's good will. For wider concept coverage, we shoudn't enforce/require/assume too much to potential providers. > Similarly, we are generally thinking > in terms of one "kind" of GUID for Documentation instances. As ISBN, DOI etc. are expected: they are an abstraction of physical printed matters, just like a taxon conceps is an abstraction of physical specimens in front of a taxonomist. > Therefore, I think there should be only one "kind" of GUID for taxon objects > as well -- and the only one that I know of that can broadly accomodate all > sorts of subtypes is the generic "NameUsage" instance. Taxon data object or taxon physical object? If you mean taxon data object, NameUsage (sensu Rich/James, not sensu Jessie) is the most general kind. "Name as concept" principle behind TCS assures that a data object representing a name usage convays at least one concept. It does not exclude subtypes of the kind. > If the question of "How many 'kinds' [domains] of taxon GUIDs should there > be?" is beyond the scope of this discussion, then frankly I'm not clear on > what sorts of topics fall *within* the scope of this discussion (other than > the trusty LSID vs. DOI vs. whatever debate). It if four (or five) in our system. Publication-ish, Author/Agent-ish, NameString-ish, TaxonCocnept-ish (and Specimen/Observation-ish if it shouldn't be treated as a taxon cocnept containing only one specimen/event: they are singleton taxon cocnept. Note that here I use formal concept, i.e. a pair of intent and extent, rather than Roger seems using only intent). It is only explaining an implementation of taxon concept oriented database. I need to read previous discussions for its implecation in this context. Cheers, JMS

1 0

Re: GUIDs for Taxon Names and Taxon Concepts
by Nozomi Ytow 15 Nov '05

15 Nov '05

Rich, > > "explicitly implied" is actually contradiction in terms: > Agreed -- but I couldn't think of a different term to express what I meant. As one of NameUasage camp, I would rephrase as: "Any data object reprsenting an occurrence of a NameString as it appears, or, interpreted as explicit by the data provider, within some form of static documentation." I suspect we may slipping off from data object identification to how to when one should create a data objects. I'm very sorry that my real life prevents to contribute, or even to read the on-going important discussion on GUID... Cheers, James

1 0

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

14 Nov '05

Hi Rich, If I call the GUID for 8 I presume I get back a data object of some kind that contains: 1. A literature ref field that contains a string representation of a citation of Pyle 2005 and or a GUID that points off to get more information about the publication. 2. A GUID that points to the data object containing data about Xea ba (Smith 1995) Jones 2000 - as depicted here (by Pyle 2005) - i.e. the GUID for 9 3. A GUID that points to the data object containing stuff about Aus bus Smith 1995 - as depicted here (by Pyle 2005) - i.e. the GUID for 10. 4. A GUID that points to the data object containing stuff about Aus cus Smith 1995 - as depicted here (by Pyle 2005) - i.e. the GUID for 11. This data structure is beginning to look a lot like a TaxonConcept to me but then I see the world through TCS glasses :) Is this wrong? What would I get back that would be materially different to this? All the best, Roger Richard Pyle wrote: > 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 > > -- ------------------------------------- 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 Yde de Jong 14 Nov '05

14 Nov '05

Dear Roger, Thanks you for clear reply and Richard for his additions. My problem in understanding your GUID system is that -if I am right- it aims to integrate two functional properties for names, namely (1) cross-referencing for nomenclatural mapping and (2) definite identification of all name objects in the linked systems, which also function as an input of user-cases. The Semantic Web Applications for knowledge-based systems I know always try's to separate those functions. The benefit of splitting is that the functional constraints on (in our case) name objects will be restricted depending their use on either the critical cross-referencing or the usage context. When you merge both functions you induce conflicting constraint on your name object and I think that is what happens in your current discussion with Richard: For the cross-referencing property you need nomenclatural exactness; for the usage (modelling) context you would like to have a maximum of flexibility and freedom to treat name objects. Of course both methods have their pros and cons. A problem of explicit cross-referencing is that it is an awful lot of work in the beginning and you need to have certain standards, but once established it's probably the best system. Merging cross-referencing and user-cases has the benefit of having a quick start, however, conflicting constraints on your data (=name) objects, a lot of complex algorithmic modelling, and always the uncertainty of ending with an sub-optimal system. If I am right the GBIF attempt is not 'either-or', but a kind of hybrid system. Since I am not an expert in this informatics area I realise that some of the answers probably can be found in recent GBIF documents on this issues and your wiki page. So time to do some homework. Kind regards, Yde >Hi Yde, > >TaxonNames > >Yes it is ambiguous as to whether a nomenclator may wish to issue a >TaxonName GUID for 4 and/or 5. What I would do if I were a >nomenclator is issue a TaxonName GUID for both. The GUID of the >wrongly spelled one would return an object which included the GUID >of the correctly spelled one. This is just what I would do not what >a nomenclator may choose to do. > >TaxonConcepts > >TaxonConcepts depend on intention. From just a list of words it is >usually impossible to say whether they represent something that >should have a TaxonConcept GUID or not. > >If this list was entitled "Moths I have caught in my moth trap" I >would argue strongly that you should not treat them as concepts. >They are an attempt by some one to say which taxa they have found >not an attempt to re-define taxa. The authors want to reference >existing taxa not give objects an identity. The items on the list >may get GUIDs from some recording scheme system though. > >If the exact same list was entitled "A treatment of Zus from Far >Away Land" then it seems to me that they are all meant to be >concepts (possibly with bad nomenclature). The authors want to >tag/label these taxa so that other people can reference them when >they go bird watching in Far Away Land - or whatever animal a Zus >is... > >An Analogy > >I have in front of me a book called Everyman's Dictionary of First >Names. Here are some names from the book. > >Milli >Mills >Milly - see Milli >Milo >Milson >Milton >The question: "Should we issue National Insurance numbers for these >people?" is not a good one. They are not people they are just names! >But we only know that because I told you where I got them from. The >people who compiled the book probably had a database with IDs on. >They could try and set up a global system for names with GUIDs. This >system would clearly be completely separate from a global system for >identifying people by number for tax purposes although the tax >system may refer to the name system and a credit reference agency >might provide a service for getting an NI number from a person's >name plus some other disambiguation data. > >So we can argue about the correct spelling of Milly and the register >can have its own pointers to 'correct' spelling but Milly Smith >still gets a tax bill because when she was born they gave her a >number. > >(Incidentally I believe Denmark actual has this system. It has a >national list of acceptable names for children and it has a system >of issuing ID numbers to everyone at birth. The UK just gets >confused with NI numbers and NHS numbers etc) > >Hope this helps, > >All the best, > >Roger > >[BTW I had the name book to hand because the children are choosing a >name for our new cat. Milo is the favourite but we are open to >suggestions. He is a ginger tom with a sister called Motlie]. > > > > >>Re: GUIDs for Taxon Names and Taxon Concepts >>Dear Roger, >> >>One puzzling thing for me to be explained in more detail is the following: >> >>Extending the example of Richard: >> >>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 >>6. Xea bus (Smith 1995) Jones 2000 as it appears in Pyle 2005 >> = Xea ba (Smith 1995) Jones 2000 >> >>I agree with Richard that it is ambiguous whether nos 4 & 5 should >>get TaxonName >>GUIDs or TaxonConcept GUIDs, but I believe this is a matter of >>defintion we can solve. >> >>However, how to discriminate between the TaxonConcept of no. 4 and >>the TaxonConcept of no. 6 which includes subjective synonymy? I >>assume you need a GUID for each documentable usage instance? >> >>Kind regards, >> >>Yde >> >> >> >> >> >>>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>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>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 >>> >>> >>> >>>>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 14 Nov '05

14 Nov '05

Rich, OK - so I didn't get all the stuff about a NameString occurring many times within a multi page document (perhaps spanning chapters and or contributions from other authors or not as the case may be) and the nature of documentation etc. I'd still like you to sharpen up the definition though. "Any occurrence of a NameString as it appears or is explicitly implied within some form of static documentation." "explicitly implied" is actually contradiction in terms: explicitly = "Fully and clearly expressed; leaving nothing implied." (http://dictionary.reference.com/search?q=explicitly) implied = "not directly or specifically made known" (http://dictionary.reference.com/search?q=implied) My formal logic is self taught and very shaky but I believe that from a statement containing a paradox one can argue almost anything. Check out wikipedia (http://en.wikipedia.org/wiki/Contradiction#A_paradox_involving_contradiction). This may explain why you can logic things out of your definition that I don't see as following. "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." I don't actually see a great deal of disagreement here. We are debating between only two alternatives. It could be much worse. There could be 5 alternatives and 12 people chipping in and disagreeing about what they mean by each alternative - then it would be much harder to reach consensus. 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. If we do this we will then be able to move forward with other issues and for each issue we will be able to look at the implications of going with either of our two ways forward. I guess we will soon get bored of one choice and it will die a natural death or something will come along to replace them both. This way we can move on to other stuff without having to make a decision on this one right now. If all else fails we can flip a coin in February next year (just kidding on that one). I'll probably not get my page finished till later in the week as I have other commitments - but certainly by Friday. All the best, Roger Richard Pyle wrote: > 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 > > -- ------------------------------------- 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 Roger Hyam 14 Nov '05

14 Nov '05

Hi Yde, TaxonNames Yes it is ambiguous as to whether a nomenclator may wish to issue a TaxonName GUID for 4 and/or 5. What I would do if I were a nomenclator is issue a TaxonName GUID for both. The GUID of the wrongly spelled one would return an object which included the GUID of the correctly spelled one. This is just what I would do not what a nomenclator may choose to do. TaxonConcepts TaxonConcepts depend on intention. From just a list of words it is usually impossible to say whether they represent something that should have a TaxonConcept GUID or not. If this list was entitled "/Moths I have caught in my moth trap/" I would argue strongly that you should not treat them as concepts. They are an attempt by some one to say which taxa they have found not an attempt to re-define taxa. *The authors want to reference existing taxa *not give objects an identity. The items on the list may get GUIDs from some recording scheme system though. If the exact same list was entitled "/A treatment of Zus from Far Away Land/" then it seems to me that they are all meant to be concepts (possibly with bad nomenclature). *The authors want to tag/label these taxa* so that other people can reference them when they go bird watching in Far Away Land - or whatever animal a /Zus /is... An Analogy I have in front of me a book called /Everyman's Dictionary of First Names/. Here are some names from the book. * Milli * Mills * Milly - see Milli * Milo * Milson * Milton The question: "Should we issue National Insurance numbers for these people?" is not a good one. They are not people they are just names! But we only know that because I told you where I got them from. The people who compiled the book probably had a database with IDs on. They could try and set up a global system for names with GUIDs. This system would clearly be completely separate from a global system for identifying people by number for tax purposes although the tax system may refer to the name system and a credit reference agency might provide a service for getting an NI number from a person's name plus some other disambiguation data. So we can argue about the correct spelling of Milly and the register can have its own pointers to 'correct' spelling but Milly Smith still gets a tax bill because when she was born they gave her a number. (Incidentally I believe Denmark actual has this system. It has a national list of acceptable names for children and it has a system of issuing ID numbers to everyone at birth. The UK just gets confused with NI numbers and NHS numbers etc) Hope this helps, All the best, Roger [BTW I had the name book to hand because the children are choosing a name for our new cat. Milo is the favourite but we are open to suggestions. He is a ginger tom with a sister called Motlie]. Yde de Jong wrote: > Dear Roger, > > One puzzling thing for me to be explained in more detail is the following: > > Extending the example of Richard: > > 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 > 6. Xea bus (Smith 1995) Jones 2000 as it appears in Pyle 2005 > = Xea ba (Smith 1995) Jones 2000 > > I agree with Richard that it is ambiguous whether nos 4 & 5 should get > TaxonName > GUIDs or TaxonConcept GUIDs, but I believe this is a matter of > defintion we can solve. > > However, how to discriminate between the TaxonConcept of no. 4 and the > TaxonConcept of no. 6 which includes subjective synonymy? I assume you > need a GUID for each documentable usage instance? > > Kind regards, > > Yde > > > ------------------------------------------------------------------------ > > >> 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 >> ------------------------------------------------------------------------ >> >>> 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: GUIDs for Taxon Names and Taxon Concepts
by Yde de Jong 14 Nov '05

14 Nov '05

Dear Roger, One puzzling thing for me to be explained in more detail is the following: Extending the example of Richard: 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 6. Xea bus (Smith 1995) Jones 2000 as it appears in Pyle 2005 = Xea ba (Smith 1995) Jones 2000 I agree with Richard that it is ambiguous whether nos 4 & 5 should get TaxonName GUIDs or TaxonConcept GUIDs, but I believe this is a matter of defintion we can solve. However, how to discriminate between the TaxonConcept of no. 4 and the TaxonConcept of no. 6 which includes subjective synonymy? I assume you need a GUID for each documentable usage instance? Kind regards, Yde >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>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>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 > > > >>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 Richard Pyle 14 Nov '05

14 Nov '05

Hi James, > As one of NameUasage camp, I would rephrase as: > > "Any data object reprsenting an occurrence of a NameString as it > appears, or, interpreted as explicit by the data provider, > within some form of static documentation." Fine by me! > I suspect we may slipping off from data object identification > to how to when one should create a data objects. Yes, but I think there is at least *one* relavent point to this that is more directly related to GUIDs for taxon objects: one kind? two kinds? three kinds? more? I think we generally assume that there is only one "kind" of GUID for specimens (i.e., we aren't speaking in terms of one "kind" of GUID for whole specimens, and another separate "kind" of GUID for specimen parts, and yet another separate "kind" of GUID for multi-part "specimens" like multi-taxon fossil specimens...etc.). Similarly, we are generally thinking in terms of one "kind" of GUID for Documentation instances (not separate "kinds" for journal articles vs. books; or even published vs. unpublushed). Therefore, I think there should be only one "kind" of GUID for taxon objects as well -- and the only one that I know of that can broadly accomodate all sorts of subtypes is the generic "NameUsage" instance. If the question of "How many 'kinds' [domains] of taxon GUIDs should there be?" is beyond the scope of this discussion, then frankly I'm not clear on what sorts of topics fall *within* the scope of this discussion (other than the trusty LSID vs. DOI vs. whatever debate). > I'm very sorry that my real life prevents to contribute, or even to > read the on-going important discussion on GUID... Likewise, my apologies to the list if my rantings are not relevant to (or are external to) what is supposed to be discussed on this forum. Aloha, Rich

1 0

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

14 Nov '05

What you get back depends on who you call, what you ask for, and how much linking has already been established. Minimally, the "data" for GUID 8 would include the NameString "Xea bus", and either textual citation metadata or a ref-GUID pointing to the documentation instance of "Pyle 2005" (i.e., #1 in your list below). Ideally, it would also include locater information (e.g., page numbers) for finding where, within the documentation instance "Pyle 2005", you can find the appearance(s) of the NameString "Xea bus" (or its "explicitly implied" equivalent of "X. bus"). There may be various other bits and pieces of direct data and/or metadata attached directly to GUID 8, depending on whether the data provider recognizes it as a surrogate representation of a basionym, new combination, TaxonConcept, whatever -- but the "true" definition of GUID 8 is simply the appearance of the NameString "Xea bus" within the documentation instance of "Pyle 2005". If the data provider that you called for GUID 8 had established full INTRA-documentation nomenclatural cross-links, then you might also get: - A Link of nomenclatrual type "is combined with" to GUID 7. - Links of nomenclatural type "is senior synonym of" to GUIDs 9, 10 & 11. If the data provider that you called for GUID 8 had established INTER-documentation nomenclatural cross-links, then you might also get: - A link of nomenclatural type "has basionym" to GUID 2. - If a plant, also a link of nomnclatural type "is authored combination" to GUID 5. If the data provider that you called for GUID 8 also dealt in concepts, you might also have: - Links of Concept type "includes" to GUIDs 9, 10 & 11. - Links of Concept type "includes" to GUIDs 2, 3 & 5. - A Link of Concept Type "is included in" to GUID 7 (maybe?? or would this be "is child of"?) And there may be other intra-GUID cross-links established as well. But the point is, the data attached directly to GUID 8 only intrinsically represents the NameString (along with its "explicitly implied" equivalents), and a reference to a documentation instance, and perhaps some other attributes tied directly to the appearance of that name within that documentation instance (e.g. page numbers). All the rest is secondary contextual linking among other GUID-bearing NameUsage instances, as established by various data providers. The structure is appealing because it *can* fit nicely into TCS (e.g., distinguishing nomenclatual links that would be embedded within a TCS <TaxonName> instance, vs. concept links that would be enumerated within TaxonConcept/TaxonRelationships) -- however, it is broader than simply assigning GUIDs to TaxonConcept instances, because not all Usage instances rise to the level of "defined concept" (sensu Jessie). Rather, a *subset* of NameUsage instances would represent TaxonConcept instances -- just as a subset of TaxonConcept instances would represent "Original Concepts" (=original descriptions, =basionyms & New Combinations). I agree that it is suboptimal to use these sorts of surrogate GUIDs -- but it seems we had already begun to embrace the "[TaxonName] SEC [Publication]" interesection as a surrogate identifier ("handle") to a TaxonConcept -- so I'm only taking the same idea one step further. Let me know how else I might clarify. 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 14, 2005 1:19 PM To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU Subject: Re: GUIDs for Taxon Names and Taxon Concepts Hi Rich, If I call the GUID for 8 I presume I get back a data object of some kind that contains: 1. A literature ref field that contains a string representation of a citation of Pyle 2005 and or a GUID that points off to get more information about the publication. 2. A GUID that points to the data object containing data about Xea ba (Smith 1995) Jones 2000 - as depicted here (by Pyle 2005) - i.e. the GUID for 9 3. A GUID that points to the data object containing stuff about Aus bus Smith 1995 - as depicted here (by Pyle 2005) - i.e. the GUID for 10. 4. A GUID that points to the data object containing stuff about Aus cus Smith 1995 - as depicted here (by Pyle 2005) - i.e. the GUID for 11. This data structure is beginning to look a lot like a TaxonConcept to me but then I see the world through TCS glasses :) Is this wrong? What would I get back that would be materially different to this? All the best, Roger Richard Pyle wrote: 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 -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

1 0