- tdwg-content - lists.tdwg.org

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 27 Nov '01

27 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

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

26 Nov '01

Surely there will be other hierarchies than classical taxonomy through which providers wish to offer inheritance. Phylogenetic hierarchies come to mind, for example. If the problem is inheritance, then the standard should provide for that, not for a special case. Success would be measured by the ability of the inheritance mechanisms to provide for the special cases. Bob Morris Steve Shattuck writes: > Date: Tue, 27 Nov 2001 13:35:31 +1100 > From: Steve Shattuck <Steve.Shattuck(a)csiro.au> > 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

Re: Morphological Data Representation
by Robert A. (Bob) Morris 26 Nov '01

26 Nov '01

Certainly end users need this and many kinds of information. We believe in integrated applications that discover or know where to find the answers to questions like this. See our toy demo http://www.cs.umb.edu/efg/xml1/DEVELOP/itis/demo.htm (This requires MSIE, but it is perfectly possible---and probably better---to support this kind of thing at the server. I subscribe to the belief that simplicity is superior to complexity, especially since much of the infrastructure now available to XML-based applications means that much of the programming to support gathering information from disparate sources is provided in the toolkits. To pick a field guide at random (or rather, what's at hand): the National Audubon Field Guide to Insects and Spiders has almost no taxonomy above Order (it does mention that the insects are in Class Insecta and Phylum Arthropoda; no mention of Subphylum, Subclass, Superorder, Suborder or other arcana easily found from ITIS). In my experience, field guide books may have a little nod toward taxonomy above Family (or Order if they are meant to be broad) but make no attempt to place the descriptive data in such taxonomy. Electronic descriptive pages vary widely, but those that embed taxonomy in their databases risk errors, excessive and often redundant data, and fragility in the face of taxonomic revisions. I say that if we are talking about descriptive data, we should just stick to descriptive data. Bob Morris Peter Rauch writes: > Date: Mon, 26 Nov 2001 11:22:45 -0800 > From: Peter Rauch <peterr(a)socrates.berkeley.edu> > To: TDWG-SDD(a)usobi.org > Subject: Re: Morphological Data Representation > > On Mon, 26 Nov 2001, Robert A. (Bob) Morris wrote: > > > My feeling is that taxonomic hierarchy is best got by web > > applications from services such as ITIS or other web > > services offering XML. There is a large community of > > descriptive data consumers, e.g. field naturalists, that > > find taxonomic hierarchy generally uninteresting. IMO, > > trying to integrate it with descriptive data actually > > addresses a small group of applications at a cost of added > > complexity. > > "There is a large community of descriptive data consumers, e.g. > field naturalists, that find taxonomic hierarchy generally > uninteresting." > > Bob, this comment needs a little bit more explanation / > discussion. > > Without arguing _where_ the field naturalist and other consumers > should get their taxonomic hierarchical information, I'd want to > argue that such information is (should be!) anything but > "uninteresting" to many (most?, all?) consumers, in their work > of understanding who is present in their study worlds and why. > > Having access to purported (evolutionary) relationships of their > study organisms focuses a special, valuable, most "interesting" > light on their studies. These users need to find these taxonomic > relationships handily, somewhere. In that context, your question > --Where?-- is probably a fair one to ask. > > Peter >

1 0

Forgot the bloody attachment
by Kevin Thiele 26 Nov '01

26 Nov '01

Forgot the bloody attachment - How many times does one have to put up a message before getting the message through? Oops. Steve Shattuck's pointed out, quite rightly, that we shouldn't fuss too much over the details of the challenge cases before actually taking the challenges. I think it's important to have a bit of an overview of the challenges for some distance ahead of us while working on one challenge in hand, rather than just taking steps one at a time, because it may be that solving one challenge may canalize us into a solution that makes a challenge down the road more difficult. So I suggest we keep a set of challenges in mind while working. But, of course, it'd be a disaster if we couldn't even agree on the challenges before starting to find the solutions! Cheers - k ----- Original Message ----- From: "Kevin Thiele" <kevin.thiele(a)BIGPOND.COM> To: <TDWG-SDD(a)USOBI.ORG> Sent: Sunday, November 25, 2001 9:27 PM Subject: Challenge Cases | Welcome back! | | I actually posted this message a week ago, but my email address has changed | slightly, and the list server rejected me. So here it is again. | | At the Sydney TDWG meeting we agreed that we would continue with the SDD | discussion on this list, but try to keep a tighter focus. The last active | period (about 12 months ago) was an important brainstorm session, but didn't | seem to be very effective at actually getting us to the goal of a workable | standard. | | We decided this time to try working through some challenge cases - real or | made-up instances of descriptive data that need to be accommodated in the | standard. By agreeing first on a +/- complete set of challenges, then | working through the challenge cases in order from simple to difficult, we | should be able to reasonably bound our problem while keeping an overview of | the territory while actually sinking out teeth into the nitty-gritty. | | Attached is my first attempt at a set of challenge cases, presented in +/- | this form to the Sydney meeting. The first challenge case has an exemplar, | the others have not yet. This document as it's worked up will be placed on | the TDWG web site for working reference. As the standard evolves, this will | also be put up on the site, possibly with progressive status indicators for | parts of the standard (e.g. working, proposed, normative - may we one day | get to normative) | | I suggest that we should first add to or modify the list of challenges. | Propose a challenge (with exemplar) to add to the list. Once we are happy | with an approximate list of challenges (keeping in mind that others will | become clear as we proceed, so there's no need to agonise over this step), | we'll start with challenge 1. We'll throw up the challenge, give a week or | so for contributors to propose data structures that can meet the challenge, | then compare and discuss alternate solutions. | | Gregor I think will shortly be posting a summary of the meeting discussions. | We agreed, I believe, that the goal is to provide a standard that can | adequately address the descriptive data requirements (ie be a superset) of | all existing programs (e.g. Lucid, DELTA, DELTA Access, Biolink) but not be | limited to existing programs. It should be able to function as an | interchange standard, but should not be limited to that. Bob Morris agreed | to provide shortly a discussion on interchange vs interoperability standards | and conflicts that may arise in trying to allow for both goals. We agreed | that XML will be the basis for the standard. | | May the force be with us! | | Cheers - k

1 0