- tdwg-content - lists.tdwg.org

TDWG99 (Harvard), Minutes of SDD meeting
by Gregor Hagedorn 25 Nov '99

25 Nov '99

Minutes of the Subgroup "Structure of descriptive data" workshop at TDWG 1999 in Harvard ---------------------- The subgroup convened on Sunday, 31.10.99 during the annual TDWG meeting at Harvard University. The following topics were discussed: 1. Diederich's "Basic properties" General agreement was reached that a direct application of the "structure-property-value" model would be too restrictive, applicable mainly to morphological descriptions. A more general model, including cultural/physiological and molecular descriptions should be developed. The term "feature" was proposed as a more general replacement for structure. 2. Standardization of schemas (character definitons), user defined metadata This was considered desirable in the long run, but, esp.considering the experiences made by Richard Pankhurst with plant descriptors, it should be considered a long term goal. The problems were shortly discussed. Agreement was reached that these topics are quite separate and should be discussed in separate discussion groups. 3. New interchange format for descriptors It was proposed that a new "Superset format", encompassing the functionality of the existing DELTA and NEXUS interchange formats, and with extensions to support the requirements of LucID, DeltaAccess, and possible further software packages should be developed. However, it was agreed that we should first step back to review the current use of descriptors. The new format should not be a simple superset with possible redundancy, but the principles of biological descriptions should be reevaluated to cover them with appropriate and general mechanisms. To achieve a clearer picture, a requirement analysis was proposed (see next point). A distinction was made between the data model and the metaformat. It was agreed that XML may be a good vehicle for a new standard. However, alternatives should be carefully evaluated. A decision for or against XML would have to be made only after the requirement analysis and information model had sufficiently far progressed. An important point was made that the standard should belong to TDWG, and should neither in name nor in the preparation of future versions be too intimately tied to any developer of a software application. The relationship to existing standards TDWG-DELTA or NEXUS should be clearly defined and mapping definitions provided. 4. Requirement analysis A requirement analysis is to be made, separately for general and application type specific requirements. The general requirements should be discussed according to a preliminary information model. 5. How to proceed The group agreed to communicate over an email listserver (which will be installed at the University of Kansas with the help of Jim Beach). It was agreed that the documents to be discussed should in simple cases be send directly as plain text in the body of an email, or in the case of longer, structured and formatted documents, in the form of HTML attachments. The use of PDF should be avoided, since it can not be directly read and is difficult to annotate and consolidate annotations. A web page will document the consolidated discussion papers and the emendations or criticisms regarding these papers. In addition, the list server will directly provide an unedited archive of the original discussion. Time frame: It was considered desirable to have a definite proposal by a years time. ---------------- Any additions or corrections from those present are welcome! Gregor ---------------------------------------------------------- Inst. for Plant Virology, Microbiology, and Biosafety Federal Research Center for Agriculture and Forestry (BBA) Gregor Hagedorn Net: G.Hagedorn(a)bba.de Koenigin-Luise-Str. 19 Tel: +49-30-8304-2220 14195 Berlin, Germany Fax: +49-30-8304-2203 Often wrong but never in doubt!

1 0

Nexus
by Gregor Hagedorn 25 Nov '99

25 Nov '99

Susan Farmer wrote: > I (initially) put all of my data into > DELTA and then converted it to Nexus. The Nexus file has been heavily > modified (and many of my character and state names truncated in the > bargin). Until very recently, there was no way to take *this* file > back into DELTA. But more than that; all of the continuous data > in the original file (aka measurements) are now gone and will have to > be added back into the DELTA data set by hand. :-( We had several comments on NEXUS so far. I agree with Kevin (and Leigh), that "users of NEXUS are more than happy with their format". However, I don't think they should be, exactly because the situation Susan is commenting on. NEXUS is by far more specialized and that much information is lost when restricting a data set to NEXUS. If NEXUS does not change, it would sooner or later become a one-way format, and would not be used for data storage any more. That does not mean that NEXUS is not a good format, but I believe we do need a format that is covering all the common ground. We should try to learn from NEXUS as we should try to learn from DELTA. >Given this, and other similar comments on the list, I'd suggest that an >additional requirement of any new format (if thats the way things go) >is that it provides backwards-compatibility, as far as possible with >other formats. I believe this backward compatibility will be possible, at least in a one- way situation. With this I mean that a simple XML program (given the new program is based on XML) will be able to provide DELTA or NEXUS formatted, that can be read by older programs. However, if the new format is really a redesign and not just a superset of competing directives, some information may be lost, and some information may have to be mapped in a way that will usually provide the best results. > Why not extend the current standards that if there are data types that > their particular application doesn't recognize, they stay around -- just > ignored. MacClade does that even with Nexus data (maybe the newest one > doesn't); but if I save my file from within MacClade, if I want to run > PAUP again, there are commands that I must reinter into the file > because MacClade has removed them because it didn't understand them. I believe that a new format is more desirable than blowing up existing formats beyond their design specifications. I think the latter is the main problem that I have with the proposals for "New Delta": The discussion and proposals correctly identify many shortcomings, which I consider very valuable work. However, resolving these issue in the context of the existing DELTA format structures, and especially in close context to the way the CSIRO DELTA programs currently work, has lead to many solutions which I consider undesirable. Gregor ---------------------------------------------------------- Inst. for Plant Virology, Microbiology, and Biosafety Federal Research Center for Agriculture and Forestry (BBA) Gregor Hagedorn Net: G.Hagedorn(a)bba.de Koenigin-Luise-Str. 19 Tel: +49-30-8304-2220 14195 Berlin, Germany Fax: +49-30-8304-2203 Often wrong but never in doubt!

1 0

Welcome
by Gregor Hagedorn 25 Nov '99

25 Nov '99

Dear Colleagues I welcome all the new members of the list! Currently 96 people have subscribed, that is considerably more than I expected. However, only few people from the NEXUS community have subscribed. As it should be, the discussion is already in full flow. If those people who have signed up late want to catch up, please can go to the web archive (http://usobi.org/archives/tdwg-sdd.html) Perhaps we should try to add some more structure (Kevin already made some suggestions), but in any case just keep posting everything you think relevant. Regarding the general purpose of this list and the manager (Mauro's question), I post the welcome message below. Most of you have already received this, but some early subscribers did not or received an earlier version. Separate postings with minutes and a provisional outline will follow. ---------------------------------------- TDWG-SDD, Discussion List on the Structure of Descriptive Data To post a message to the list, send email to tdwg-sdd(a)usobi.org from your subscribed email address. Include a meaningful Subject line. In general, use only plain text in the main body of your message, and put HTML or other formatted text/graphics in attachments. This will make it easier for other subscribers to read the message, and very importantly, it will allow the LISTSERVer to create useful search terms from you message's main body. TDWG is the Taxonomic Databases Working Group. The mission of TDWG can be found at http://www.tdwg.org/. The subgroup "Structure of Descriptive Data" was started 1998 at the TDWG meeting in Reading. At the TDWG meeting in Harvard in Oct 1999 it was agreed that the subgroup should attempt to analyze the requirements for a new standard for descriptive data. The metaformat for the standard will probably be based on XML or related formats. It is hoped that this standard will reach universal recognition to become at some point a successor to existing standards like DELTA, NEXUS, or XDF. The purpose of this discussion list is to foster communication and collaboration among those involved in the creation of a new standard. The new standard should be carefully drafted and agreed upon by consensus. The discussion list provides an email- and www-accessible archive (available at http://usobi.org/archives/tdwg-sdd.html) so that the discussion is adequately documented. The list is expected to produce some traffic, including attached formatted documents (HTML + graphics). If you are concerned about too many emails flooding in, please consider whether your email client offers an automatic filter function to directly copy all mails originating from the list into a separate folder. To unsubscribe from the list you should send an email to LISTSERV(a)USOBI.ORG with the message: UNSUBSCRIBE TDWG-SDD If you have any question about the TDWG-SDD list, write to the list owners at the generic address: TDWG-SDD-Request(a)USOBI.ORG ---------- If you have any suggestion or additions please send them to me! ---------------------------------------------------------- Inst. for Plant Virology, Microbiology, and Biosafety Federal Research Center for Agriculture and Forestry (BBA) Gregor Hagedorn Net: G.Hagedorn(a)bba.de Koenigin-Luise-Str. 19 Tel: +49-30-8304-2220 14195 Berlin, Germany Fax: +49-30-8304-2203 Often wrong but never in doubt!

1 0

Re: Types of data
by Gregor Hagedorn 25 Nov '99

25 Nov '99

> > I too would argue that what we seek is a system that distinguishes between > > "observations", measured in some sense (either directly using > > some device), or perhaps "mapped" using known or widely used conventions and > > higher level abstractions that often pass as qualitative "data", (ie leaf > > "ovate" or state "relatively derived" or "1"). > > Would it be too simplistic to simply allow the format to express > the source (qualitative/quantitative, or a more detailed description) > or a particular data set? I believe that original measurement data should be part of the data set, together with rules how to map them unto categorical data (DELTA: "Keystate directive"). Knowing that categorical states for, e.g. length-to-width-ratio of a leaf have been measured rather than just guessed, solves only a small part of the problem. > > Deciding which sources you trust, value, or otherwise wish to > manipulate is an option you then have at the application level. > > i.e. "I wish only direct measures of leaf shape, and not > a description such as 'ovate'. but ovate is rather difficult to parameterize. It may be possible to get ellipsoidal parameters, but width and length are clearly insufficient. Does anybody know about good parameterization of shapes, so they can be stored in more objective forms? Gregor ---------------------------------------------------------- Inst. for Plant Virology, Microbiology, and Biosafety Federal Research Center for Agriculture and Forestry (BBA) Gregor Hagedorn Net: G.Hagedorn(a)bba.de Koenigin-Luise-Str. 19 Tel: +49-30-8304-2220 14195 Berlin, Germany Fax: +49-30-8304-2203 Often wrong but never in doubt!

1 0

A comparison of formats for descriptive data
by Mike Dallwitz 25 Nov '99

25 Nov '99

> From: Jim Croft > To: TDWG-SDD > enunciate/tabulate exactly what it is we are trying to achieve and the > shortcomings/limitations of exiting formats in reaching this goal No sooner said than done :-). See A comparison of formats for descriptive data http://biodiversity.uno.edu/delta/www/compdata.htm Actually, I've been working on this for a few days, but have been hampered by some administrative work (a review of our project). The document is rather sketchy at the moment, and I will correct and add to it as time permits. There may be quite a few errors in the information on Nexus/Paup/MacClade. Also, I haven't yet had time to incorporate some of the suggestions made on this list. The paper I presented at the recent TDWG meeting is also available: Introduction to data requirements for natural-language descriptions and identification. http://biodiversity.uno.edu/delta/www/descdata.htm -- Mike Dallwitz CSIRO Entomology, GPO Box 1700, Canberra ACT 2601, Australia Phone: +61 2 6246 4075 Fax: +61 2 6246 4000 Email: md(a)ento.csiro.au Internet: biodiversity.uno.edu/delta/

1 0

Types of data
by Kevin Thiele 25 Nov '99

25 Nov '99

Leigh Dodds writes: >> I too would argue that what we seek is a system that distinguishes between >> "observations", measured in some sense (either directly using >> some device), or perhaps "mapped" using known or widely used conventions >and >> higher level abstractions that often pass as qualitative "data", (ie leaf >> "ovate" or state "relatively derived" or "1"). > >Would it be too simplistic to simply allow the format to express >the source (qualitative/quantitative, or a more detailed description) >or a particular data set? Too simplistic, I think. There will surely be many cases where in one data set some characters will be "real" (i.e. low-level) observations while others will be abstractions. For instance, sometimes it will be viewed as worthwhile for the taxonomist to capture real data (leaf shapes are fairly easy to do), other times anything other than abstraction is practically impossible (try working out how to capture indumentum characteristics quantitatively). More on the entity/property/value model. Don wrote: >Can character definitions be constrained without making too tight a >straight-jacket for oneself? Might it be possible to represent taxon >character descriptors by for example an entity/property/value (eg. >leaf/shape/ovate) based schema? >This on the face of it would seem to map onto an XML element/attribute/value >schema pretty well. Would that help define more closely how we construct >characters and maybe even prove universally applicable for all character >types? > >Could one constrain further by expressing within the schema the hierarchical >relationships between the elements(eg 'blade' and 'petiole' as child >elements of leaf') or would the introduction of terminology into the >'standard' be a step too far? This worries me. Is the entity/property/value schema restricted to 3 levels? (ditto for XMLs element/attribute/value). If so, it seems too much of a straightjacket, especially if we want to express a hierarchy of elements like this. What to do about leaf/lamina/abaxial_surface/vein_islands/indumentum/density. I agree that a hierarchically structured schema may be wonderful, but in a biological context I wouldn't like to see it constrained at 3 levels just because that's what existing computer formats do. Cheers - k

1 0

Re: Types of data
by Don Kirkup 25 Nov '99

25 Nov '99

Kevin Thiele wrote; > This worries me. Is the entity/property/value schema restricted to 3 > levels? (ditto for XMLs element/attribute/value). If so, it seems too much > of a straightjacket, especially if we want to express a hierarchy of > elements like this. No not at all, theoretically you can have as many levels in the hierarchy you like; element/element/...nth element/attribute/value > What to do about > leaf/lamina/abaxial_surface/vein_islands/indumentum/density. One (RDF centric) way to model this would be to treat leaf, lamina, abaxial_surface, vein_islands, indumentum as nested elements, and an attribute called density which will have a value (let's say "sparse"); <My_description> <leaf> <lamina> <vein_islands> <indumentum density="sparse"/> </vein_islands> </lamina> </leaf> </My_description> or more in line with the conventional (DELTA, NEXUS) approach, simply as a single element with an attribute (called density) and a value; <My_description> <leaf_lamina_abaxial_surface vein_islands_indumentum density="sparse"/> </My_description> In the latter case you've lost a lot of contextual information, but the approach (elements have properties that have values) might still offer improved consistency in definition of descriptors . Many of us, probably quite naturally, end up defining characters in this way, but there are may examples to the contrary, and none of the existing formats seem either expect or enforce this discipline. don

1 0

Re: Types of data
by Don Kirkup 25 Nov '99

25 Nov '99

Aren't observations made by looking at specimens and measurements taken from 'organs' (or whatever constituent parts of specimen)? The taxonomic philosophers might well argue that all characters are abstractions, that the concept that a leaf has shape is an abstraction. In terms of the 'reality' of statement you might make about the shape of a leaf, it doesn't really matter whether you describe shape using standard terms or as set of coordinates or as an elliptic fourier coefficient. Surely the way you measure an attribute depends on what you are going to use the measurements for, ultimately that's a question of precision. If there is a possibility that there will be a variety of uses (reuse) for the data, then an indictation of the degree of precision of the measurement would be highly desirable. Isn't it also important to distinguish whether the description refers to an actual leaf (ie. that leaf there, on that specimen is ovate) or whether you are making a generalisation about a taxon (ie leaves ovate to obovate)? A taxon cannot have a leaf shape, only leaves can, and an actual leaf does not usually vary in shape except through time. So if the reality is; "I looked at two specimens; from specimen x I measured 3 leaves and their shapes were ovate, ovate and obovate; from specimen y I measured 2 leaves, the first was ovate, the second obovate" Then why not say so? <my_taxon_description> <specimen> <leaf shape="ovate"/> <leaf shape="ovate"/> <leaf shape="obovate"/> </specimen> <specimen> <leaf shape="ovate"/> <leaf shape="obovate"/> </specimen> </my_taxon_description> For a generalised statement about my taxon, all I need is an aggregate function for the listed values of leaf shape. It seems that very few 'real' observations are formally recorded but we have a lot of generalisations. "leaves ovate to obovate, 5--31 mm long" What can be deduced about the relationship between leaf shape and leaf length? At what point in the exercise or recording observations should the decision be made that this information either is or is not important? <my_taxon_description> <specimen> <leaf shape="ovate" length_mm="10"/> <leaf shape="ovate" length_mm="8"/> <leaf shape="obovate" length_mm="25"/> </specimen> <specimen> <leaf shape="ovate" length_mm="5"/> <leaf shape="obovate" length_mm="31"/> </specimen> </my_taxon_description> Maybe the ovate leaves are all immature, or there's some enivironmental factor. Maybe I don't want to know, but maybe I do. don > Leigh Dodds writes: > > >> I too would argue that what we seek is a system that > distinguishes between > >> "observations", measured in some sense (either directly using > >> some device), or perhaps "mapped" using known or widely used > conventions > >and > >> higher level abstractions that often pass as qualitative > "data", (ie leaf > >> "ovate" or state "relatively derived" or "1"). > > > >Would it be too simplistic to simply allow the format to express > >the source (qualitative/quantitative, or a more detailed description) > >or a particular data set? Kevin Thiele wrote; > Too simplistic, I think. There will surely be many cases where in one data > set some characters will be "real" (i.e. low-level) observations while > others will be abstractions. For instance, sometimes it will be viewed as > worthwhile for the taxonomist to capture real data (leaf shapes are fairly > easy to do), other times anything other than abstraction is practically > impossible (try working out how to capture indumentum characteristics > quantitatively).

1 0

Looking for the list manager
by Mauro J. Cavalcanti 25 Nov '99

25 Nov '99

Dear Colleagues... I am in need of contacting directly the administrator of this discussion list. Could anyone kindly point her/his name and e-mail address to me? Thanks in advance for any assistance you can provide. Regards, -- + - - - - - - - - - - - - Mauro J. Cavalcanti - - - - - - - - - - - - + | Setor de Paleovertebrados, Departamento de Geologia e Paleontologia | | Museu Nacional do Rio de Janeiro | | Quinta da Boa Vista, 20940-040, Rio de Janeiro, RJ, BRASIL | | E-mail: maurobio(a)acd.ufrj.br | | Home Page: http://read.at/digitax/personal.html | + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + "Life is complex. It consists of real and imaginary parts."

1 0

Re: so far ...
by Jim Croft 25 Nov '99

25 Nov '99

> This is typical of the level of malpractice of those who seem to be taking the > running with this discussion. Can you imagine being so clumsy and foolhardly > with hard-won data? I despair of this debate. Patience Nick - new lists take a while to settle down as participants try and establish a common agenda, and people strut personal favorite products and ideologies. Like Bernie, I am waiting for the discussion to focus itself. I had initially thought we were looking at a common and comprehensive (interchange?) format for biological descriptive data, perhaps involving an information model of the topic we are dealing with, and importantly, its boundaries. But all too quickly we have got to the level of all things to all people end-products, software and a degree of daunting complexity that we could probably do without at this stage. Approaching things from an 'if it aint broke dont fix it' point of view, is someone in a position to enunciate/tabulate exactly what it is we are trying to achieve and the shortcomings/limitations of exiting formats in reaching this goal? Having done this we might be better able to partition things into managable and achievable lumps. I was not at the Harvard meeting so I'm a bit reluctant to stick an oar in, but since when has ignorance been a reason not to have an opinion... :) All the suggestions of 'do it this way using this', while interesting and educational, are tending to obscure rather than clarify what it is we are tring to achieve. Well, I am getting a bit lost, and I love this data stuff... jim

1 0