November 2001 - tdwg-content

Re: Taxonomic hierarchy in SDD
by unknown＠example.com 27 Nov '01

27 Nov '01

Sounds fine, store the hierarchy but keep it separate from the items. No worries. The idea of supporting multiple hierarchies for different inheritances is interesting and I can see its potential importance. I'll need to test it out here in "biology land" to see if it makes sense in practice. I believe that the classification is tied very closely to taxon concepts, and that descriptions are certainly tied to concepts. If you change the concept you almost always change the description, and so knowing the classification can be important in understanding what the author is up to. Steve

1 0

Re: Taxonomic hierarchy in SDD
by Tim Jones 27 Nov '01

27 Nov '01

I am not sure I follow here but I do agree it is definately wise to understand the thoughts of a taxononomist <grin>... I am not an expert in this area by any means but it it would seem to me that whether you choose to accept or reject someones description and whether you want to accept their taxonomic classification are two different things (albeit closely related). Could it be that they should be modelled seperately? That way it is possble to store a description without having to adopt the classification structure in the data. Or is it that these two concepts are just so tightly coupled that it is not needed? Just a thought... not of a taxonomist Cheers -----Original Message----- From: Steve Shattuck [mailto:Steve.Shattuck@CSIRO.AU] Sent: Tuesday, 27 November 2001 2:08 PM To: TDWG-SDD(a)USOBI.ORG Subject: Re: Taxonomic hierarchy in SDD If a dataset includes the descriptions of two families and 4 genera but doesn't tell you which genera belong to which family you will be forced to get this information from someplace else (e.g. ITIS). If the dataset is based on a different arrangement from ITIS you don't know this because the dataset didn't tell you because it's not part of the standard. In this case the data won't make sense because the family descriptions need to be a superset of the genera which belong to them. I think this is a pretty basic problem if we want to support hierarchical data (taxa at different taxonomic ranks). Again, if you don't want to follow the author of the dataset then you are free to ignore the suggested classification - but I would strongly suggest that you better know what the author is thinking and ignore all of her data if you don't agree with it, not accept the descriptions while rejecting the classification. Steve

1 0

Re: Taxonomic hierarchy in SDD
by unknown＠example.com 27 Nov '01

27 Nov '01

If a dataset includes the descriptions of two families and 4 genera but doesn't tell you which genera belong to which family you will be forced to get this information from someplace else (e.g. ITIS). If the dataset is based on a different arrangement from ITIS you don't know this because the dataset didn't tell you because it's not part of the standard. In this case the data won't make sense because the family descriptions need to be a superset of the genera which belong to them. I think this is a pretty basic problem if we want to support hierarchical data (taxa at different taxonomic ranks). Again, if you don't want to follow the author of the dataset then you are free to ignore the suggested classification - but I would strongly suggest that you better know what the author is thinking and ignore all of her data if you don't agree with it, not accept the descriptions while rejecting the classification. Steve

1 0

Re: Taxonomic hierarchy in SDD
by Lander, Nicholas 27 Nov '01

27 Nov '01

This raises the old argument for scoring _data_ in our databases rather than information derived from those data. This is to say that your system should at least allow of scoring descriptive data at specimen level rather than at the conceptual level of species (or other taxa). Thus the descriptions of taxa could be derived "just in time", ie on the fly when required. Redetermination of a given suite of specimens would result in all the relevant descriptions, keys, and other products being, in effect, dynamic. This will be vital for projects which are institutional or international in scope. Nicholas Lander WA Herbarium (PERTH) -----Original Message----- From: Steve Shattuck [mailto:Steve.Shattuck@CSIRO.AU] Sent: Tuesday, November 27, 2001 1:51 PM To: TDWG-SDD(a)USOBI.ORG Subject: Re: Taxonomic hierarchy in SDD Sounds fine, store the hierarchy but keep it separate from the items. No worries. The idea of supporting multiple hierarchies for different inheritances is interesting and I can see its potential importance. I'll need to test it out here in "biology land" to see if it makes sense in practice. I believe that the classification is tied very closely to taxon concepts, and that descriptions are certainly tied to concepts. If you change the concept you almost always change the description, and so knowing the classification can be important in understanding what the author is up to. Steve

1 0

Re: Taxonomic hierarchy in SDD
by Tim Jones 27 Nov '01

27 Nov '01

On the taxonomic heirarchy thread - I agree wholeheartedly that the heirarchy should not be part of the description. Could it rather be a recommended link to a classification? We often come across the situation where one person has a diferent view of the hierarchy to another. If the heirarchy is not part of the descriptive data but can be refered to from an alternative source then would it be possible to use one (or another) source depending on your point of view. That way you could follow say the ITIS calssification if it suits or if the framework is published any other hierarchy that supports the framework interface. Tim --------------------------------------------------------- Database Manager Centre for Research on Introduced Marine Pests GPO Box 1538, Hobart Tas 7000, Australia. Phone : (03) 62325222 (switch), (03) 62325213 (direct) Mobile: 0411 560057 Fax : (03) 62325485 E-mail: tim.jones(a)marine.csiro.au --------------------------------------------------------- -----Original Message----- From: Steve Shattuck [mailto:Steve.Shattuck@CSIRO.AU] Sent: Tuesday, 27 November 2001 1:36 PM To: TDWG-SDD(a)USOBI.ORG Subject: Taxonomic hierarchy in SDD The full taxonomic hierarchy of the included taxa/items certainly must be supported by the standard (and it will be addressed after we deal with simple characters, states and items). If the creator of the dataset doesn't think it's important then they can choose to leave it out; if the user of the data doesn't think it's important then they can ignore it. This will be especially important if we intend to support inheritance and compilation up and down the classification (as has been suggested by several of us). Jumping the gun a bit, I would think these relationships would be stored either as a separate nested set of elements with ID's linking to specific items, or the items themselves would be nested with parent items containing their children. Steve Shattuck CSIRO Entomology biolink(a)ento.csiro.au

1 0

Taxonomic hierarchy in SDD
by unknown＠example.com 27 Nov '01

27 Nov '01

The full taxonomic hierarchy of the included taxa/items certainly must be supported by the standard (and it will be addressed after we deal with simple characters, states and items). If the creator of the dataset doesn't think it's important then they can choose to leave it out; if the user of the data doesn't think it's important then they can ignore it. This will be especially important if we intend to support inheritance and compilation up and down the classification (as has been suggested by several of us). Jumping the gun a bit, I would think these relationships would be stored either as a separate nested set of elements with ID's linking to specific items, or the items themselves would be nested with parent items containing their children. Steve Shattuck CSIRO Entomology biolink(a)ento.csiro.au

1 0

Re: Taxonomic hierarchy in SDD
by Peter Stevens 27 Nov '01

27 Nov '01

>This raises the old argument for scoring _data_ in our databases rather >than information derived from those data. This is to say that your >system should at least allow of scoring descriptive data at specimen >level rather than at the conceptual level of species (or other taxa). >Thus the descriptions of taxa could be derived "just in time", ie on the >fly when required. Redetermination of a given suite of specimens would >result in all the relevant descriptions, keys, and other products being, >in effect, dynamic. This will be vital for projects which are >institutional or international in scope. > <bold>I think that if databases are to be anything other than local, this seems to be the issue</bold>. One can in theory at least go from measurement to shape terms and still keep the basic data intact. At the risk of overkill, below are some important (I think) points to be borne in mind. Note that these measurements and images I talkk about (sorry, this is edited from some notes which may turn into a paper or a lecture for next term's class) are really the metadata that ground the data of the description of an animal or plant or the character states of a phylogenetic analysis. Although the comments below are couched in terms of phylogenetic analysis, the metadata assembled would be useful for a variety of purposes. <fontfamily><param>Times</param><bigger><bigger><bigger>Access to individual observations linked to individual specimens is the ideal towards which we should strive. Photographs, drawings, images in general and measurements as well as bibliographic references are the proper metadata of morphological-phylogenetic data; they ground those data. Having such metadata readily accessible has several advantages. 1. We should be able to revisit earlier decisions that there were states by examining the observations available to the authors who made those decisions. 2. The same character may be quite properly divided in different ways for different taxa within a larger group. When studying the larger group, we need to combine all the raw data from which the states were separately abstracted in the smaller studies. Combining raw data may destroy states, looking at a subset of the raw data may suggest additional states. 3. There is no knowing how future morphological observations will relate to a gap that currently separates two states (this is unlike the normal situation for molecular data). Similarly, data based on misidentified specimens or taxa assigned to the wrong higher taxon should be in a form that allows them to be easily placed in their correct contexts, at the same time evaluating any effects this may have on state delimitation. 4. Gap coding is not universally accepted, and there are at present no sound reasons for preferring one method of coding over another. There are few studies that code the same variation in different ways and compare the results. Absent such reasons, studies and comparisons, metadata will enable observations to be used by a variety of coding practices. 5. If the states scored for a taxon are those believed to be basal in it (Nandi et al. 1998; Doyle and Endress 2000), details of the variation within the taxon need to be accessible. This is particularly necessary given that our knowledge of taxa presumed to be "basal" in a lineage and so sometimes (but largely incorrectly) emphasized when assigning states is in a state of flux. The general direction we should go is clear. Genbank is more reliable than Vernon Heywood's shoebox in which we often place our data (Heywood, 19). The shoebox may be discarded when we move, and our heirs and assignees may well consign it to the recycling pile or bonfire on our deaths. Unless our observations can be stored somewhere, phylogenetic hypotheses will not cumulate. Information on each character should be stored as individual measurements and images as far as is possible, and linked to specimens and place of publication. If we are serious about morphology, we need an equivalent to GenBank, a MorphBank. </bigger></bigger></bigger></fontfamily>

1 0

DTD for Description
by Barringer, Kerry 27 Nov '01

27 Nov '01

Attached is an attempt at a usuable DTD for taxonomic descriptions. It is modified from a Taxonomic Document Markup based largely on DELTA format data. I modified the original based on the mailing list contributions of Steve Shattuck, L. Dodds, and G. Rousse. The most visible difference is use of attributes to hold information without real-world meaning. This is based on current modelling techniques and is explained by Rouse in his posting of Nov. 23 much more clearly than I could explain it. There are also many attributes derived from the DELTA format which may not be applicable. I would like to omit the attribute for order from the standard. If each taxon/specimen, character, and state is uniquely identified, then ordering is more flexibly handled in XSL. This would allow those who want to order based on alphabet, a character state (as in field guides), inferred relationships, etc. to do as they please without changing the data. Because of the nature of XML, each description will be part of a higher element, usually either a specimen or a taxon. It is these entities that are ordered, not the descriptions themselves. Within a description, the ordering and selection of characters is easiest with XSL or other processing. This allow the author (or compiler) of the document to arrange characters in a way that makes sense for the treatment. The summary outline is also included in the DTD. Description Heading Character CharName codedCharName textCharName State Connector Qualifier codedStateName textStateName Comment Comment Character For those still looking for XML/XSL tools, I recommend XML Cooktop for Windows http://www.xmleverywhere.com as a good general editor, it handles DTD's and Schema' as text files for editing, but otherwise is good and the XSL editing and testing is excellent. I apologize for using DTDs instead of Schemas. It is the language I know and have been using for a while now. For me, they are a little clearer and easier to understand, even if they are not quite as flexible. If the group wants only Schemas, I will learn that next. There is a good utility for converting DTDs to Schemas at http://puvogel.informatik.med.uni-giessen.de/dtd2xs/ In the next few days, I will send in some markup of challenge cases and XSL routines. Kerry ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Kerry Barringer (Curator of the Herbarium) Herbarium 718-623-7318 (office) Brooklyn Botanic Garden 718-941-4774 (fax) 1000 Washington Avenue 718-623-7312 (herbarium) Brooklyn, NY 11225-1099 U.S.A. kbarringer(a)bbg.org http://www.bbg.org/ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

1 0

Re: Taxonomic hierarchy in SDD
by Douglas Trainor 26 Nov '01

26 Nov '01

Taxonomic disagreements aside, I have run into programming "gotchas" in the past because I did not know about generic homonyms and thus my code was ignorant of homonyms. I was surprised then to find both a corticioid fungus and a marine sponge with the same genus name (Corticium is in both Carticiaceae and Plakinidae). Also a surprise to find both a fungus and a plant with the same genus name (Virgaria). Then a taxonomic guru told me about the genus Erica for insects/plants. There are probably two dozen others... douglas Steve Shattuck wrote: > If a dataset includes the descriptions of two families and 4 genera but > doesn't tell you which genera belong to which family you will be forced to > get this information from someplace else (e.g. ITIS). If the dataset is > based on a different arrangement from ITIS you don't know this because the > dataset didn't tell you because it's not part of the standard. In this case > the data won't make sense because the family descriptions need to be a > superset of the genera which belong to them. I think this is a pretty basic > problem if we want to support hierarchical data (taxa at different taxonomic > ranks). > > Again, if you don't want to follow the author of the dataset then you are > free to ignore the suggested classification - but I would strongly suggest > that you better know what the author is thinking and ignore all of her data > if you don't agree with it, not accept the descriptions while rejecting the > classification. > > Steve

1 0

Re: Taxonomic hierarchy in SDD
by Robert A. (Bob) Morris 26 Nov '01

26 Nov '01

We may not be arguing here. I don't dispute the need for this, only argue that there should not be a standard for taxonomy, but rather a standard for how to specify taxonomy. Or any other hierarchy for that matter. Doing this would allow you to get the hiearchy from /any/ suitable source, including but not limited to the data source itself. To me it seems that the least brittle thing for data inheritance is to use the same model as for datatype inheritance, i.e. a separate "schema" to which reference is made, as Tim Jones argued. Bob Steve Shattuck writes: > Date: Tue, 27 Nov 2001 14:07:35 +1100 > From: Steve Shattuck <Steve.Shattuck(a)csiro.au> > To: TDWG-SDD(a)usobi.org > Subject: Re: Taxonomic hierarchy in SDD > > If a dataset includes the descriptions of two families and 4 genera but > doesn't tell you which genera belong to which family you will be forced to > get this information from someplace else (e.g. ITIS). If the dataset is > based on a different arrangement from ITIS you don't know this because the > dataset didn't tell you because it's not part of the standard. In this case > the data won't make sense because the family descriptions need to be a > superset of the genera which belong to them. I think this is a pretty basic > problem if we want to support hierarchical data (taxa at different taxonomic > ranks). > > Again, if you don't want to follow the author of the dataset then you are > free to ignore the suggested classification - but I would strongly suggest > that you better know what the author is thinking and ignore all of her data > if you don't agree with it, not accept the descriptions while rejecting the > classification. > > Steve >

1 0