LinneanCoreTcsNameExamples

GregorHagedorn - Mon May 08 2006 - Version 1.14
Parent topic: LinneanCoreExampleNames

-- Main.TrevorPaterson - 30 Nov 2004 after UBIF.LinneanCoreExampleNames -- Main.SallyHinchcliffe -- 03 Nov 2004 -- PaulKirk and Main.GregorHagedorn -- 8 Nov 2004

i Family:

1 Acmopyleaceae (Pilg.) A. P. Melikyan & A.V.Bobrov - in Proc. Internat. Conf. Pl. Anat. & Morphology, St. Petersburg, 1997: 93 (1997): basionym: Acmopyleaceae subfam. Acmopyleoideae APPROACH: needs two _Original_ Concepts with a relation 'has basionym' between them. The Concept for the basionym merely contains the NameSimple string 'Acmopyleaceae subfam. Acmopyleoideae', and is of Rank 'subfamily'. We are a bit confused about this name - as we had been led to believe that it would be represented by the string 'Acmopyleoideae', (which could be related to the parent family 'Acmopyleaceae' by creating a further concept and a classification relationship). * I think the name of the subfamily alone is canonical, adding the name of the family is redundant but common. As usual I am confused about the TCS concept types. If the basionym record does not contain anything more than the name string (i.e. not even a publication) than why is it Original type rather than incomplete or nominal type? -- Gregor, 10.12.2004 * Touche - in this case the information to make a meaningful original concept for the basionym is missing - so it should be flagged as of type 'incomplete' ( if we had a bit more information we could make the original concept - i.e. the according to ) -- Main.TrevorPaterson - 13 Dec 2004 2 Alzateaceae S.A.Graham - Ann. Missouri Bot. Gard. 71 (3): 775 (1984 publ. 1985). APPROACH: only problem seems to be representing the two publication dates ? maybe solved by a better Publication structure ? AlexandriaCore * Current AlexandriaCore support both the year on publication and true publication date. However, it is valid criticism of LC whether this would not have to be duplicated inside LC to avoid too much of a dependency. I have no clear view whether the decoupling or avoiding redundancy is more important. -- Gregor, 10.12.2004 3 Argophyllaceae (Engler) A.Takhtadzhyan - Sistema Magnoliofitov (Systema Magnoliophytorum): 208 (1987) basionym: Saxifragaceae trib. Argophylleae APPROACH: similar to first example. 4 Asteraceae Martinov - Tekhno-Bot. Slovar 55. 1820 remarks: nom. alt.: Compositae. APPROACH: similar to first example: but relationship is 'has replaced synonym' or similar...

ii Infra familial: (all examples taken from Orchidaceae)

1 subtrib. Anthogoniinae S. C. Chen , Z. H. Tsi & G. H. Zhu - in Acta Phytotax. Sin., 37(2): 116 (1999). 2 trib. Bletieae Benth. - Fl. Austral. 6: 270, 302. 1873 [23 Sep 1873] remarks: as "Bletideae" 3 subfam. Codonorchidoideae (P. J. Cribb) M.A.Clem. & D.L.Jones - Orchadian 13(10): 439 (30 Jan. 2002). basionym: Orchidaceae trib. Codonorchideae P. J. Cribb - in Lindleyana, 15(3): 169 (2000).

iii Genera:

* Would the relationship to a family according to IPNI have to be "sec. IPNI"? And would IPNI have to deliver two record for each name, one sec. original author, one revision to express the family? -- Gregor, 10.12.2004 * I think IPNI could decide what they are representing: are they creating original concepts as defined by the original authors of those concepts and then putting them into IPNIs classification (then we have (A) original concept AccordingTo oldguy, RelationshipAssertion 'is child of' taxonconcept, AccordingTo IPNI, where the parent concept may be IPNIs or someone else's.) Or IPNI could deliver revision concepts which include the clasfication relationships as part of the concpt definition; and yes in this case they would probably be delivering two concepts (1) the original (2) IPNIs revision which refers to the original, bur now includes classification information. -- Main.TrevorPaterson - 13 Dec 2004 * speaking for IPNI - our family classifications are rather 'accidental' and don't express anything that coherent. It could code one of two things - either what family was considered correct according to the institution entering the data at the time -OR it could indicate which family the author had put the genus in. The former is IPNI's classification, the latter, part of the original author's classification. Either way it doesn't belong in LC, and the canonical name (and the label) should NOT include it. (nor for Infrafamilial as well) -- Main.SallyHinchcliffe - 14 Dec 2004

1 Cuenotia Rizzini - Dusenia 7: 303. 1956 family (acc. to IPNI) Acanthaceae APPROACH: In our [[http://www.prometheusdb.org/download/Cuenotia.xml XML(ABCD)]] (or [[http://www.prometheusdb.org/download/Cuenotia_LC.xml XML(LC)]]) for this example we have chosen to represent Rizzini's original concept for Cuenotia, and an original concept authored by IPNI for the family Acanthaceae. We have related the concepts in two (alternative) ways (i) by including the relationship 'has 'child' Cuenotia in the definiton of Acanthaceae, or (ii) by a 'third party' taxonomic assertion that Cuenotia is a child of Acanthaceae. 2 x Carruanthophyllum G. D.Rowley - Name that Succulent: 200 (1980). family (acc. to IPNI) Aizoaceae. Hybrid Parentage: Aizoaceae Machairophyllum × Aizoaceae Carruanthus Schwantes ex N.E.Br. in Journ. Bot., Lond. lxvi. 325 (1928); vide Ingram in Baileya, xvi. 141 (1969). Our approach to representing hybrids is tied to the ABCD Name structure. Each parent Genus is represented as an original concept, and the hybrid genus has relationships 'is hybrid child of' to each of those. We are not represnting classification of all of these as members of the Aizoaceae family. We are not sure what it means biologically to have a hybrid genus? Our attempted [[http://www.prometheusdb.org/download/hybridGenus.xml XML(ABCD)]] and [[http://www.prometheusdb.org/download/hybridGenus_LC.xml XML(LC)]] is shown. * To my knowledge, a hybrid genus is simply a hybrid of individuals from species from two different genera. THe biology of a hybrid species and a species in a hybrid genus is not really different, it is a question of opinion or phylogeny whether to distantly related species are in the same or different genera. However, the special hybrid genus name form is introduced to highlight this unusual case of hybridization across genera. -- Gregor, 10.12.2004

3 Caesia Vell. - Fl. Flum. 107 (1825); iii. t. 23 (1827). family acc.to IPNI: Rhamnaceae APPROACH: seems to be a similar example to 1. 4 Caesia R.Br. - Prodromus Florae Novae Hollandiae 1810 family acc. to IPNI Liliaceae, or Anthericaceae, depending on what record you select ... APPROACH: again seems to be a similar example to 1, but now with some confusion in the taxonomic relationships captured. these can be 'resolved' by relating the concept to separate concepts for both Liliaceae and Anthericaceae (which may be related to each other by some kind of synonymy assertion. 5 Calanticaria (B. L. Rob. & Greenm.) E. E. Schill. & Panero - Bot. J. Linn. Soc. 140(1): 73 (2002). family acc. to IPNI: Compositae (or Asteraceae if you prefer). basionym: Compositae Gymnolomia subgen. Calanticaria B.L.Rob. & Greenm. APPROACH: similar example to iii.1, but now with basionym relationship as well (as in i.1). Again unsure of representing the name in the basionym concept: can hold full string for the basionym name 'Compositae Gymnolomia subgen. Calanticaria B.L.Rob. & Greenm.' of rank subgenus - but should it be simply 'Calanticaria B.L.Rob. & Greenm.' of rank subgenus?

iv Infrageneric: 1 Caesia sect. Crinagrostis F.Muell. - Fragmenta Phytographiae Australiae 10 1877. Family acc. to IPNI Liliaceae, so this is presumably a child of Caesia R.Br. and not Caesia Vell. This would seem to be a classification not nomenclatural issue. To represent the first use and definition of the name 'Crinagrostis F.Muell.' an original concept would be created with the Name 'Crinagrostis F.Muell.', AccordingTo 'F.Muell (1877)', of Rank 'section', possibly with a parent relationship to some genus concept named Caesia. (Again we are not sure about representing multiple Monomial strings such as 'Caesia sect. Cringrostis F.Muell.' as the Name of a single concept - though TCS could handle this if it is a correct interpretation.) * Any infrageneric/supraspecific taxa need the genus as part of their canonical name, else you would not have identity. Not sure that is what you are asking??? But the genus is name identity, as well as classification. See my attempt to discuss this in LinneanCoreDisentangle -- Gregor, 10.12.2004 * OK i missed some of the implications in this. The original concept resembles a species binomial: to represent the first use and definition of the name 'Caesia sect. Crinagrostis F.Muell.' an original concept would be created with the Name 'Caesia sect. Crinagrostis F.Muell.', AccordingTo 'F.Muell (1877)', of Rank 'section', (possibly with a parent relationship to some genus concept named Caesia). The rule seems to be for anything below Genus represent the whole name including Genus - is this true - are Suprageneric Genus' different? -- Main.TrevorPaterson - 13 Dec 2004 * Not sure if this has been disentangled but my idea in putting in the comment 'Family acc. to IPNI Liliaceae, so this is presumably a child of Caesia R.Br. and not Caesia Vell.' was NOT to suggest that we include the family (i.e. to put in classification information) but to illustrate the problem of homonyms in the hope that any LC schema we came up with would handle it. In my opinion linking a child (Crinagrostis F.Muell) to the correct parent (Caesia R.Br. and not Caesia Vell.) is the job of the nomenclator and should be handled within LC by using a reference to the correct genus rather than just filling in the (ambiguous) genus name -- Main.SallyHinchcliffe - 14 Dec 2004 2 Cajanus sect. Cantharospermum (Wight & Arn.) Benth. - Plantae Junghuhnianae enumeratio plantarum 1852 family (acc. to IPNI)Fabaceae. basionym:Cantharospermum Wight & Arn. - Prodromus Florae Peninsulae Indiae Orientalis 1 1834 No new issues here: classification as member of Fabaceae is a TCS issue; classification as a section of Cajanus in the Name String is unresolved. 3 Calamagrostis ser. Muticae Keng ex Keng f. - in Bull. Bot. Res. North-East. Forest. Inst., 4(3): 195 (1984). family (acc. to IPNI): Gramineae, or Poaceae if you prefer. same issues * ... this was a slightly mischeivous example from me. Gramineae is a conserved name for Poaceae (or Poaceae is another way of saying Gramineae). It is one example where the same concept (those grassy things) has two names: Gramineae if you are old fashioned, and Poaceae if you like your family names to be consistent. As far as I know the differences between Gramineae and Poaceae are purely terminological, but a real botanist, taxonomist or nomenclaturalist may wish to differ. -- Main.SallyHinchcliffe - 14 Dec 2004 * I agree, for 8 vascular plant familes (Apiaceae/Umbelliferae, Arecaceae/Palmae, Asteraceae/Compositae, Brassicaceae/Cruciferae, Clusiaceae/Guttiferae, Fabaceae/Leguminosae, Lamiaceae/Labiatae, Poaceae/Gramineae) the code allows concurrent synonyms, none is preferred and usage differs widely. It is an exceptional case in the code - but extremely common in usage. In my mind this case is easier treated if the information model behind accepts that a "name object" or TCS concept may be related to multiple name-string variants. As far as I understand, TCS proposes to treat "Poa alpina L." and "Poa alpina Linne" and "Poa alpina Linné" and "Poa alpina Linneaeus" as separate records with separate ID, and then map relationships between them. My confusion is that I do not see how this scales, if we have several hundreds circumscription concepts (this number is my estimate for monographs and floras, not including checklists or ecological involving the species). Rather than only defining the relationships between the circumscription concepts, we have to multiply them out with the name variants, and draw relationships between them. -- Main.GregorHagedorn - 14 Dec 2004

4 Calamagrostis subgen. Calamagrostis Adans. - Feddes Repertorium Specierum Novarum Regni Vegetabilis 63 1961 remarks: This is an autonym, which APNI includes, but the other parts of IPNI does not. Should we be dealing with them as well? The name has clearly been introduced in an original publication, probably with a definition (even if implicitly just 'not Calamagrostis subgenus xyz') so can be validly represented with a TCS original concept.

v Species: 1 Caesia spinosa Vell. - Fl. Flum. 107 (1825); iii. t. 23 (1827). Family (acc. to IPNI): Rhamnaceae, so presumably a child of Caesia Vell., not Caesia R.Br. again this seems to be only an issue of classification not nomenclature. The TCS schema probably needs a further 'relationship' type to capture a classification between any hierarchichal levels. i.e. species Y.z. 'is placed in' family X; otherwise we require to make the recursive relationships species Y.z. 'is child of' genus Y 'is child of' Family X. This relationship is obviously taxonomic not nomenclatural, alternative names for this relationship might be 'is member of', 'is child of (with incertae sedis)', 'is included in' (but we already use this for set-based relationships sensu Koperski et al.). 2 Caesia spiralis Endl. - Plantae Preissianae 2(1) 1848 Family acc. to IPNI Liliaceae, so this is presumably a child of Caesia R.Br. and not Caesia Vell. again this seems to be only an issue of classification not nomenclature * I disagree, the issue Sally is mentioning is which genus the species has been published in. This is not retrievable from the name string (genus authors are lacking, so genus has no identity), but is a question of nomenclature. Only one genus can be zoology.available = botany.valid, so whether the species has which status depends on the answer. Knowing this is essential to determine which is the correct name for an accepted character circumscription concept. -- Gregor, 10.12.2004 * Yes this was exactly my point (see my rather more longwinded explanation above -- Main.SallyHinchcliffe - 14 Dec 2004 * OK IPNI seems to include the concept Caesia Vell. from IndexKew. for completeness - to allow it to be noted as a replaced synonym for Cormonema. The original concept for Caesia Vell. is judged by the 'rules' to be invalid because the name has already been used for a different concept Caesi R.Br. This can be recorded as a relationship assertion: concept named Caesia Vell. is invalid name for Concept named Cormonema ( or as in IPNI, the reverse relationship 'Cormonema has synonym Caesia Vell.'): Because IPNI save the relationship in one direction, the Caesia Vell. concept is a dead end - only used as a synonym link - why would there be confusion about whether to use it or Caesia R.Br. - the original concept for Caesia R.Br. does not have an invalid assertion associated with it, and has been included in IPNIs classification. i.e. Caesia spiralis is a child of Caesi R.Br., similarly Caesia spinosa Vell. is only used as a dead end synonym record for Cormonema spinosum. (IPNI has also classified Caesia Vell. and Caesia spinosa Vell. into Rhamnaceae.) The difficulties are obviously in trying to build the nomenclatural history from the modern standpoint - it may be easier for IPNI to include the 'invalid' relationship in their representation of Caesia Vell. - but then it really isnt the original concept they are representing - but a modern, IPNI concept.......TCS just treats the Name "Caesia spiralis Endl." as string, the classification information for this concept is stored as relationships. We dont think you should store and try and retreive classification information in the string - of course because of this horrible binomial system the name was generated from the classification...hence the source of all confusion. TCS tries to disambiguate the meaning of the string as used in a concept by use of definitions and relationships, rather than by dissecting semantics in the string. If you want to know which genus or family a species is classified in - look up the classification relationships. -- Main.TrevorPaterson 13 Dec 2004 * ...well, IPNI includes both Caesia Vell. and Caesia spinosa Vell. because they were published even though they oughtn't to have been (I believe in 1825 IPNI was not online so Vell. may not have been aware that R.Br. had got there first with his genus name) Both are invalid but they're out there and need to be recorded in IPNI so there's somewhere for us to say that the later homonym is invalid & for people to look at the names and not keep making the mistake. Somehow either LC or TCS has to handle the issue of the children of homonyms NOT by my implied method of looking at the family and guessing, but explicitly by reference to the id of the parent record the child is in. -- Main.SallyHinchcliffe - 14 Dec 2004 3 Daboecia cantabrica (Huds.) K.Koch - Dendrologie 2(1): 13 (1872). family (acc. to IPNI): Ericaceae basionym: Ericaceae Vaccinium cantabricum Huds. Fl. Angl. ed. I. 143. isonym: Ericaceae Daboecia cantabrica (Huds.) Britten & Rendle List Brit. Seed.-Pl. Ferns 18 (1907). This is straight forward to represent using three original concepts; Huds.'s is recorded as the basionym for Koch's; Britten and Rendle's is marked as a later Homonym of Huds.'s. (We dont have the relationship 'Isonym' or 'homotypic homonym' in our schema - but could add it if required). Note, to more accurately reflect the original concepts as (implicitly) defined when they were originally defined, Koch's can relate to the (earlier) basionym, but not the later isonym, so this relationship is stored in the isonym. A database system could traverse relations ineither direction, or implement this in a number of ways. Example [[http://www.prometheusdb.org/download/Isonym.xml XML(ABCD)]] or [[http://www.prometheusdb.org/download/Isonym_LC.xml XML(LC)]]. 4 Daboecia cantabrica (Huds.) Britten & Rendle - List Brit. Seed.-Pl. Ferns 18 (1907). family (acc. to IPNI): Ericaceae basionym: Ericaceae Vaccinium cantabricum Huds. Fl. Angl. ed. I. 143. Because we have created these concepts for the previous example, creating the basionym relationship is simple. In the [[http://www.prometheusdb.org/download/Isonym.xml XML(ABCD)]] or [[http://www.prometheusdb.org/download/Isonym_LC.xml XML(LC)]] example I have included this as part of the definition of Britten and Rendle's concept. 5 Vaccinium cantabricum Huds. - Fl. Angl. ed. I. 143. family (acc. to IPNI): Ericaceae This is a classification not a Name: would need to relate the concept for V.c. to one for Ericaceae. 6 Daboecia × scotica D.McClintock - in Garden, 103(3): 116 (1978). family (acc. to IPNI): Ericaceae Remarks: Cultivation. (D. azoria x cantabrica) My interpretation is that this is a hybrid, therefore would be represented by creating an original concept having this Name, AccordingTo/referenced McClintock, and with two 'is hybrid child of' relationships to concepts representing the parents species. The family relationship would also be stored by a relationship to an 'Ericaceae' concept. 7 Dacryodes belemensis Cuatrec. - Trop. Woods no. 106: 58. 1957 family (acc. to IPNI): Burseraceae No new issues? Family: Buseraceae is a classification 8 Dacryodes peruviana (Loes.) Lam. - Ann. Jard. Bot. Buitenzorg 42: 202. 1932 family (acc. to IPNI): Burseraceae Basionym: Burseraceae Pachylobus peruvianus Loes. Bot. Jahrb. Syst. 37: 569. 1906 No new issues? but Burseraceae is not part of the name of the basionym - must be a classification too. 9 x Carruanthophyllum hybridum (Haw.) G.D.Rowley - in Cact. Succ. J. Gr. Brit., 44(1): 2 (1982):. family (acc. to IPNI) Aizoaceae basionym: Aizoaceae Mesembryanthemum hybridum No new issues? but Aizoaceae is not part of the name of the basionym - must be a classification too.

vi Infraspecific:

* Would TCS not want to deal with the classification issue here? How shall a machine reason whether a subspecies belongs to which species (e.g. in the case of homonyms)? -- Gregor, 10.12.2004 * Machines can only 'reason' by applying algorithms to stored data. we store the data in relationships not in the name string. Do you want to store the information in a name string - in which case you are right - you will never know whether you have the genus Caesia Vell. or Caesia R.Br. in a binomial string -- Main.TrevorPaterson - 13 Dec 2004 * I am not suggesting to derive it from the name string, but pointing out that TCS somewhat incorrectly treats this ONLY has an issue of hierarchy, and not also of the name. I can change many things in the hierarchy without changing the name, but if I change those parts of the hierarchy also embedded in the canonical name identity, without changing the name, I produce nonsense. -- Gregor, 10.12.2004 * OK - I've checked the latest version of LC & the genus element within the CanonicalName element has a string (e.g. Caesia) and a property which is a reference (e.g. thisCaesia and not thatCaesia - or Caesia Vell. and not Caesia R.Br.). We put this in from the start to handle homonyms, and that's why I included lots of Homonym examples in my data, to try and bring this debate out. So the question is, are we sneaking some Concepts into our names by doing this? Or are we simply providing an unambiguous way of providing nomenclatural information that makes explicit what the binomial fails to do? My opinion is the latter ... -- Main.SallyHinchcliffe - 14 Dec 2004 * OK - we missed the significance of these 'ref' attributes for Genus and SpeciesEpithet- as they are not commented. It isn't clear what they reference....other instances of LC objects ie a Genus record, or a species record? would the only use of the SpeciesEpithet 'ref' be for subspecies?? TCS view is that this really is an issue of classification, the concept with the name Caesia spinosa Vell. would have the relationship 'is child of' a concept for the genus with the name Caesia Vell. --Main.TrevorPaterson 16 Dec 2004

1 Dacryodes peruviana (Loes.) Lam. var. caroniensis Cuatrec. - Trop. Woods no. 106: 61. 1957 * Note these are non-canonical name strings. The canonical equivalent for above would be "Dacryodes peruviana var. caroniensis Cuatrec". If TCS wants to use the original name as used in the publication, where does the canonical name occur in TCS? Or reversely, if the database editors apply canonicalization rules to the name string as used in the publication, different editors may apply different rules (less in the redundant authorship example above than in grammatical corrections). I think TCS needs to define the expected behaviour. -- Gregor, 10.12.2004 * TCS is not 'using' names: it is an exchange schema to represent and transfer stored information as represented by the originators of the information. A schema can't/shouldn't try to automatically standardize information to some view according to a A.Scrutineer, unless the information then becomes 'accrding to A.Scrutineer'. It can be used to record A.Scrutineer's opinion on what a standard/valid name for an earlier concept 'should' be.....people can then use this standard scrutinized concept as the source of the name in their work. If different scrutineers provide alternative representations relating back to the same original concept - we can then pick our favourite - ie the one according to our favourite scrutineer - or make an aggregate concept 'all of X,Y and Z' -- Main.TrevorPaterson 13Dec2004.

2 Daboecia cantabrica (Huds.) K.Koch subsp. azorica (Tutin & E.F.Warburg) McClintock - Bot. J. Linn. Soc. 101(3): 280 (1989):. family (acc. to IPNI): Ericaceae basionym: Ericaceae Daboecia azorica Tutin & E.F.Warb. in Journ. Bot. 1932, lxx. 12. 3 Daboecia cantabrica (Huds.) K.Koch nothosubsp. scotica (D. C. McClint.) E.C.Nelson - in New Plantsman, 3(2): 84 (1996):. family (acc. to IPNI): Ericaceae basionym: Ericaceae Daboecia × scotica. (D. C. McClint.) * Note that this is a subspecific nothotaxon without information about the parents. I do not know myself whether there should be a "x" here or not... -- Gregor, 10.12.2004 4 Poa alpina L. subsp. stefanovii Fiserova - in Preslia, 46(3): 223 (1974). family (acc. to IPNI): Gramineae, or Poaceae if you prefer.

Fungi

A few 'unusual' nomenclatural acts to mull over: from -- Paul Kirk (through Gregor Hagedorn) -- 8 Nov 2004

1 Opegrapha endoleuca Nyl., (1855)
Replaced synonym: Opegrapha enteroleuca Fée, 1827; Competing synonym: non Opegrapha enteroleuca Ach., 1814. This is a basic nom. nov. to replace a homonym (IF ref). * TCS can represent this by creation of three original concepts. The last concept (AccordingTo Nyl.) has as part of its definition a relationship 'is Nom.Nov.' to the concept of Fee. When Fee made his erroneous homonym concept - he presumably did not know or was ignoring that of Ach.; therefore Fee's concept has no relationships recorded about Ach or the later Nyl. concept. However we can record assertions linking (i) Fee 'is a later homonym of' Ach. and (ii) Fee 'has Nom.Nov.' Nyl. - these RelationshipAssertions are AccordingTo Nyl. see our TCS conformant [[http://www.prometheusdb.org/download/FungiNomNov.xml XML(ABCD)]] or [[http://www.prometheusdb.org/download/FungiNomNov_LC.xml XML(LC)]] * The distinction between original relationships and relationship assertion is good, but somewhat problematic in practice, in that I would guess most data providers do not know this. For some relationships this can be assumed (like basionym), if explicit knowledge is required by the code. The rest would go into assertions. Contrary to what you say however I see little chance to have the assertion according to Nyl. This is not a critique of TCS, but TCS has to discuss this and how to react as a provider. -- Gregor, 10.12.2004 * yes - i suspect that actually it will be simpler if the assertions would belong /be made by the database provider, so that in the case of ITIS all the classification hierarchy relationships are according to ITIS, and all the synonym assertions pointing out to concepts not in 'their' classification are also according to ITIS. Correctly ascribing assertion relationships is proably only feasible (and worthwhil?) for new taxonomic work - where it is possible for the author to do this themeselves - it is proably not something that database aggregators would be interested in doing.-- Trevor

2 [3] Cortinarius luteobrunneus Peintner & M.M. Moser, Mycotaxon 81: 180 (2002)
Replaced synonym: [1] Thaxterogaster leoninus E. Horak, 1973; Competing synonym: non [2] Cortinarius leoninus (Velen.) G. Garnier, 1991. A basic nom. nov. to prevent creation of a homonym (IF ref). I think that this is esssentially the same as the previous example: three concepts are created 1,2 & 3 - the definition of 3 includes 'is Nom.Nov. of' 1. The assertion "1 'has Nom.Nov.' 3" can be recorded AccordingTo Peinter & Moser; but in this case 1 & 2 are not homonyms. I am not sure what if any relationship is needed to capture the fact that the existence of 2 blocks moving the epithet of 1 to 3. On reflection we probably need a relation 'Name is blocked by' in the TCS schema which would be part of the definition of concept 3: i.e. concept 3 - Name = Cortinarius luteobrunneus Peintner & M.M. Moser; AccordingTo Peintner & M.M. Moser (2002) (+ref); relationship 'is Nom.Nov. for' concept 1; relationship 'Name is blocked by' concept 2. 3 Nectria mauritiicola (Henn.) Seifert & Samuels, in Seifert, Stud. Mycol. 27: 160 (1985)
Basionym: Corallomyces mauritiicola Henn., 1904; Unavailable basionym and competing synonym: Corallomyces elegans Berk. & M.A. Curtis, 1853 non Nectria elegans Y. Yamam. & Maeda, 1957; Anamorph: Rhizostilbella hibisci (Pat.) Seifert 1985. A combination using a later synonym because the one which has priority cannot be used because the combination would create a homonym (IF ref). A Possible TCS representation would be : * CONCEPT 1: Corallomyces elegans Berk. & M.A. Curtis, 1853 (sec. Berk. & M.A. Curtis, 1853) * CONCEPT 2: Corallomyces mauritiicola Henn., 1904 (sec. Henn. 1904) * CONCEPT 3: Nectria elegans Y. Yamam. & Maeda, 1957 (sec. Yamam & Maeda, 1957) * CONCEPT 4: Rhizostilbella hibisci (Pat.) Seifert 1985. 'is Anamorph of' [5] (sec. Seifert, 1985) * CONCEPT 5: Nectria mauritiicola (Henn.) Seifert & Samuels, in Seifert. ' is Comb.Nov. for' [1]; 'has basionym' [2]; 'Name is blocked by' [3]; 'is teleomorph of' [4] (sec. Seifert, 1985) * RELATIONSHIP 1: [2] 'is later homonym of' [1] (sec. Seifert, 1985)

NOTE: this uses two relations not (yet) in TCS: (i) 'is Comb.Nov. for' [we have 'is recombination of' which is probably equivalent ??)(ii) 'Name is blocked by' 4 Entoloma amplifolium Hesler, (1967)
Replaced synonym: Pleuropus entoloma Murrill, 1945; Competing synonym: Entoloma entoloma; ("tautonym prevention"). A nom. nov. to prevent a tautonym (note GH: tautonyms like "Bufo bufo" are ok in Zoology, but not in Botany). (IF ref). A Possible TCS representation would be : * CONCEPT 1: Pleuropus entoloma Murrill, 1945(sec. Murrill, 1945) * CONCEPT 2: Entoloma entoloma 'has basionym' [1]; (sec. Hesler, 1967 ??) * CONCEPT 3: Entoloma amplifolium Hesler, (1967) 'has rejected name' [2]; 'is Comb.Nov. for' [1]; 'is nom.nov. for' [1]; (sec. Hesler, 1967)

NOTE: is concept 2 like a dummy concept? - i.e. never really created other than to record the fact that it would have been a name if not a tautonym. Or would there be no need ever to represent this invalid and unused name? The name of [3] seems to be both a new name and a new combination - are these both recorded? 5 Ceriomyces albus var. richonii Sacc., (1888)
Replaced synonym: Ptychogaster albus Richon; Competing synonym: Ceriomyces albus var. albus; ("autonym creation prevention"). A nom. nov. to prevent creation of a homotypic autonym (IF ref). A Possible TCS representation would be : * CONCEPT 1: Ptychogaster albus Richon (sec. Richon) * CONCEPT 2: Ceriomyces albus var. albus; (sec. Hesler, 1967 ??) * CONCEPT 3: Ceriomyces albus var. richonii Sacc., (1888) 'is comb.nov. for' [1]; 'is nom.nov. for' [1]; 'Name is blocked by' [2](sec. Sacc., 1888)

NOTE: is concept 2 like a dummy concept? - i.e. never really created other than to record the fact that it would have been a name if not a tautonym. Or - further confusion for me - I read elsewhere (UBIF.LCNameAuthorshipConventions) that creating a variety in a species automatically creates an autonym variety - i.e. Ceriomyces albus var. albus: so is this actually (or implicitly) created by the creation of Ceriomyces albus var. richonii Sacc., (1888)? And presumably there needs to be something captured in the definition of Ceriomyces albus var. albus about its relationships to other concepts (e.g. Ceriomyces albus).

Some other complex authorship examples (double ex, sanctioning and ex):from -- Main.GregorHagedorn - 15 Nov 2004

* I think you overlook that both the ":" and the "ex" express a relationship between concepts and name publications... How do you model the botany.invalid name which later is validated or sanctioned in TCS? -- Gregor, 10.12.2004 * the later concept has a name (Aus bus Smith ex Jones) and a relationship ('is valid name for' or 'sanctions') - to another concept - which may be incomplete? or have the definition of their use of the name, and which has the original authors name (Aus bus Smith). 1 Candida vini (J.N. Vallot ex Desm.) Uden & H.R. Buckley ex S.A. Mey. & Ahearn in Lodder 2 Chlorociboria aeruginosa (Pers. : Fr.) Seaver ex Ramamurthi, Korf & L. R. Batra 3 Oudemansiella longipes (P. Kumm. : Fr.) Boursier in Moser in Gams For some reason I picked this name to scrutinize to see if I could understand why double ins occured. The cited reference is actually co-authored by Moser and Gams, so why is it not longipes (P. Kumm. : Fr.) Boursier in Moser, Gams and Fischer. ( Index Fungorum Record: Oudemansiella longipes (P. Kumm.) Boursier, in Moser in Gams, Kleine Kryptogamenflora, Edn 2 (Stuttgart) IIb: 88 (1955); actual publication: Kleine Kryptogamenflora. Bd. 2 b. Basidiomyceten?T. 2. Die Röhrlinge, Blätter- und Bauchpilze (Agaricales und Gastromycetales). [Bearb.] von Meinhard Moser von Meinhard Moser, Helmut Gams, G. Fischer (1955) ). Maybe the 'double in' is a typo? Anway they are so rare according to Gregor's statistics that maybe they don't matter. * G. Fischer is the publisher, so not an author. The German "[Bearb.]" means that this part of the flora has been done by Moser alone, while the entire flora is edited by the team. I am not an advocate of double "in", I would simplify to the last and independent publication, but there is contention here. Rich prefers keeping double in. And we all agree it is a rare issue... -- Gregor, 10.12.2004 4 Luttrellia monoceras (Drechsler) Khokhr. in Azbukina et al. (eds) in Gornostai This is interesting because it was originally published with spelling as 'Lutrellia', and so there is a problem whether this is corrected as a mistake in the original concept (and keep the original orthography as an attribute), or whether we have two concepts - the original and the corrected. If people have used/referred to the original spelling that would imply we needed a concept for each spelling (with a relationship link between the two). * This is the point where I think the TCS philosophy becomes impractical by bloating the number of concepts into a realm that is very difficult to manage. These are not different concepts in terms of hirarchy-concept, type-concept, and character circumscription concept. Biology is so rife with misspellings and orthographical or grammatical corrections and typos, that requiring to relate all these strings with the rich relationship system becomes very hard. What would the relationship between "Luttrellia monoceras" and "Lutrellia monoceras" be according to TCS? I would actually need to know whether the spelling correction (which needs not be published under the bot. code, just used, but without any interest in priority) has been published or not, and whether it does change other aspects of the concept or not. -- Gregor, 10.12.2004 * You would not necessarily have to make a new concept with the corrected name for each 'wrong' concept, as traversal of relationships could be done at look up time. The problem is obviously worst when it applies to the genus in a binomial. In 'name only' world it is dificult to see a relationship between "Luttrellia monoceras" and "Lutrellia monoceras", other than "Luttrellia monoceras" orthographical correction "Lutrellia monoceras", classifying them as belonging to the genus "Luttrellia" gets round the problem - and if a genus with a wrong name is created/used, a single correction relationship solves the problem if resolved at look up. Undoubtedly there is baggage/explosion by tracking as concepts and not 'correcting' records. I guess we see benefits as well as disadvantages in using separate concepts rather than versioning/alterring a single concept (which may lead to equally confusing problems of 'who meant what?'). There probably has to be a practical cut off where minor typos can be corrected, but substantive differences are new concepts.

5 Gelasinospora pseudocalospora Udagawa in Udagawa, Furuya & Horie in Kobayasi et al. * (here citation contains "et al." rather than list of authors) 6 Chrysomyxa ledi de Bary var. cassandrae (Peck et Clinton) Savile * (just a random infraspecific name where the redundant species authors are cited) I thought that including the species authors here was 'wrong' and that LC was concerned with representing 'correct' names. If the name was originally published like this would you include it as 'original orthography'? * Replace "correct" with "canonical" and I agree. The name above is a correct name, albeit not canonical. It is permissible under the code, and frequently used such. The question is how does TCS deal with these multiple spellings? -- Gregor, 10.12.2004

Summary Points from Consideration of Botanical and Fungal Name Examples.

-- Main.TrevorPaterson - 02 Dec 2004

Nomenclatural information that can be represented as relationships between concepts

We think that the TCS will only work satisfactorily as a 'wrapper' for LinneanCore name information if the concept relationships are not reproduced as part of the name elements. We think that TCS should be able to represent all the nomenclatural relationships as relationships between concepts. In the above examples we used the following relatioships.

* 'has basionym' * 'has parent' : the basic relationship for classification * but it is necessary to represnt membership of higher taxa at arbirary rank, not just direct parent e.g member of Family or Order; suggested relationship names * 'has parent (with incertae sedis)' seems quite an obscure terminology * I so far never understood this term as meaning classification in tax. hierarchy. I think the terms below are better. -- Gregor * 'is member of' * 'is placed in' * 'included in' confusion with set relationships between concepts?? - i.e not specifically rank based membership * 'has replaced synonym' is more explicit/directional than 'has synonym' * 'is hybrid of' * 'is later homonym of' again has explicit directionality, probably would not be used by an original concept author who should not use a homonym! * 'is nomen novum for' -- lacking * 'has isonym' / 'has homotypic homonym' : could be made more explicit by 'has earlier homonym' * 'Name is blocked by' if it is useful/meaningful to record this * 'is combination novum of' we were using 'has recombination' (erroneously?) for this * what is the difference between this and has basionym?

Separating Classification from Nomenclatural Information

We think that the TCS will only work satisfactorily as a 'wrapper' for LinneanCore name information if the concept relationships are not reproduced as part of the name elements. In particular we view taxonomic classification as only meaningful between concepts as used by taxonomists. Unfortunately the rules of nomenclature mean that naming is governed by clasification...

• representing classification in names:
  • binomials and trinomials inherently contain classification information (i.e. Genus species subspecies), which is why names change as classifications change
  • compounding monomials would do something similar - but these are not code compliant and we dont think should be used as Name strings. Rather, these classifications should be represented concept relationships. e.g.:
    • Acmopyleaceae subfam. Acmopyleoideae
    • Saxifragaceae trib. Argophylleae
    • Compositae Gymnolomia subgen. Calanticaria B.L.Rob. & Greenm.
    • Cajanus sect. Cantharospermum (Wight & Arn.) Benth.
      

• disambiguating the genus in binomials:
  Reading Sally's comments makes it clear that a major aim from the nomenclators view point is to provide a means to identify the correct genus in a binomial - where there is a choice amongst several possible identical genus strings. This comes about because the genus author name is not given in a binomial (nor is the species epithet author given in a trinomial). LinneanCore currently has a referencing mechanism to point to the correct parent name in these cases. From the TCS standpoint this is a classification issue, and can be expressed by relating one concept (e.g. with a binomial name) to the parent genus concept. So we consider that this requirement can be adequately provided in the TCS wrapper and does not need to be reproduced in the LC.