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@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@tdwg.org +44 1578 722782 -------------------------------------