February 2000 - tdwg-content

Re: SDD Specifications Document
by Kevin Thiele 29 Feb '00

29 Feb '00

At 10:13 25/02/00 -0300, Mauro wrote: >I was about to suggest that a graphic model, perhaps using the UML >methodology, was in order, but Jean-Marc Vanel has already taken care of >that. His model is interesting, and deserves attention. I agree that a graphical representation of the model may be a good idea, but it's beyond me. Jean-Marc's work does indeed need appraisal by the group in relation to our goals. My understanding from a brief perusal of his site is that he's trying to establish a franework for creating a set (one day he hopes for a global set) of descriptions of plants on the web, the data structured in such a way as to be queryable as well as readable. So, has Jean-Marc already done all that this group set out to do and can we go home? Two likely differences between the present attempt and his may be 1. that we need to create something more flexible so that any botanist can capture any aspect of systematic data for any taxon - i.e. a Stipa can be described just as fully as a Taraxacum and a Nepenthes, with data ranging from morphology to anatomy, phytochemisty and gene sequences (the latter is the only easy one). Jean-Marc's thing seems to me to be of the fairly inflexible variety (see the earlier lexicon debate) i.e. systematic description is reduced to filling in the blank spaces on the form provided: Taxon name <fill in your taxon> Leaves <phyllotaxy>; margins <indentation>; venation <type>. I may be misrepresenting Jean-Marc's intentions here. Any comment? 2. Jean-Marc's model is directed towards capturing descriptions. We need to also allow for identification data for the range of key programs available and in the future. Thus, things like character sets, dependencies, allowing for misinterpretations etc may perhaps have little meaning in Jean-Marc's domain, but are critical in ours. Does anyone think we shold discontinue our attempt and run with Jean-Marc's instead? At the very least, we should make sure that they're compatible, perhaps seeing Jean-Marc's as a special-purpose subset of the general. -k

1 0

XML Schema
by Robert A. (Bob) Morris 28 Feb '00

28 Feb '00

Those who care may already know that on Feb 25 W3C released a working draft for public comment of XML-Schema, with a last call for review expected in March. Perhaps of more general interest is XML Schema Part 0: Primer at http://www.w3.org/TR/xmlschema-0/ >>>From the abstract: "XML Schema Part 0: Primer is a non-normative document intended to provide an easily readable description of the XML Schema facilities and is oriented towards quickly understanding how to create schemas using the XML Schema language."

1 0

Re: Progressive Revelation
by Mike Dallwitz 28 Feb '00

28 Feb '00

> From: Kevin Thiele <kevin.thiele(a)PI.CSIRO.AU> > To: TDWG - Structure of Descriptive Data <TDWG-SDD(a)USOBI.ORG> > Create a key to all grass species so you're working with a list of all > taxa at species level including all the Poa species. The character list > has two classes of characters - ones that are scored over all taxa (these > will be the easily generalised characters) and ones that are scored for > only a subset of taxa (the characters that are highly specific and/or not > easily generalisable). When the key program starts it splashes up the > generalised characters only. But if after answering some characters you > end up with only Poas, the program finds and adds to the character list > the Poa-specific characters. Characters are progressively revealed as you > proceed through the key, with as much depth as necessary - e.g. you may > come down to a species complex of alpine Poas and presto! some characters > appear that are just the ticket to separate them. Something like this, but less rigid, is achieved automatically by algorithms for finding 'best' characters. A 'best' algorithm typically has a penalty for characters which are unknown, inapplicable, or variable for some taxa, but it does not completely exclude them. The 'best' algorithm used in our programs Intkey (interactive identification) and Key (generation of conventional keys) has a natural penalty for such characters, arising from the goal of minimizing the average length of an identification. The algorithm also has a parameter, Varywt, which can be used to add an arbitrary penalty for such characters. However, this tends to increase the average length of an identification, so its use in Intkey is not recommended. A value of 0 for Varywt would have an effect similar to that proposed above by Kevin. If you try this in Intkey, note that a value of 0 is treated as 0.01, an ad hoc adjustment made specifically to _avoid_ the complete exclusion of the characters. In a data set with a substantial number of missing or inapplicable values (e.g. the sample data supplied with the DELTA programs), it is easy to observe how low values of Varywt cause characters with comparatively low separating power (and which therefore result in longer identifications) to move towards the top of the 'best' list. Varywt is primarily intended for use in Key, where the increased average length of an identification is offset by a reduction in the _printed_ length of the key. In Key, a value of 0 completely prevents the use of characters with intra-taxon variability. -- 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

Progressive Revelation
by Robert A. (Bob) Morris 28 Feb '00

28 Feb '00

Since theology has arisen, how's this: Object oriented databases are better for this stuff than either hierarchical or relational, precisely for the reasons you outline below. [By the way, hoping this is not a forbidden commercialism but at least reveals my conflict of interest: we operate the university program for eXcelon, Inc. (formerly Object Design) by which universities can get Object Store, eXcelon [a native XML store], and most other eXcelon products for a total of $650/year. See our web site at www.cs.umb.edu/~serl/odiedu. This is a pretty good way to get into OODB's if you are a university. The program applies in most of the world.] Bob Morris Kevin Thiele writes: > Date: Mon, 28 Feb 2000 09:47:10 +1100 > From: Kevin Thiele <kevin.thiele(a)PI.CSIRO.AU> > To: TDWG-SDD(a)usobi.org > Subject: Progressive Revelation > > At 15:30 24/02/00 +1100, Eric Zurcher wrote: > > >6) I'm intrigued by the notion of a "Progressive Revelation model" > >(footnote 5). It sounds terribly theological - or perhaps that's > >Thiele-logical? (my apologies to Kevin, but I really can't resist bad puns). > > I'm often accused of teleology, but rarely of theology. > > Progressive Revelation is perhaps a new way of handling holes in data > matrices for random-access keys. The background is this: > > The simplest data structure for a random-access key is a fully populated > matrix i.e. all taxa are scored for all characters/states. Works well > sometimes, especially if the taxa are highly comparable e.g. the species of > a genus or the genera of a family. > > This structure is problematic sometimes though, for two reasons. Firstly and > most simply, you may not have data for all taxa, and need to leave holes in > the matrix. Solution is simple - fill the holes with ?s and allow for this > in the key program. But it often also happens that some characters are > simply inapplicable to some taxa, or (worse) are non-ambiguous for some taxa > but ambiguous for others. For instance, stipules don't occur in monocots, > stipule-like structures sometimes do but if you try scoring stipule > characters as defined for dicots against monocots you run into all sorts of > strife because of ambiguity of context. LucID can handle this to some extent > using the "present by misinterpretation" score, but the problem is in the > character definition, not the score. > >...

1 0

Re: <XML> Abstract Data Model for Taxonomy
by Kevin Thiele 28 Feb '00

28 Feb '00

>>>From Jean-Marc >Leigh Dodds a écrit : > >> 1. Firstly is it possible to express items like >> "Feature often present by mis-identification" > >Sorry, my english is too weak. Does this mean a character value that is >often reported by confusion with another taxon ? Leigh is presumably referring to the "Feature present (by misinterpretation)" score (see LucID). This is a score applicable to a state for a taxon so that, for instance, if a taxon lacks petals but has petal-like pseudopetals, you can score that petals are absent (the truth) but also present (by misinterpretation). This pre-empts likely user errors in an interactive key, while allowing the treatment builder to maintain data integrity. If there is no such score, the only way of pre-empting the mistake is to deliberately introduce errors into the data.

1 0

Progressive Revelation
by Kevin Thiele 28 Feb '00

28 Feb '00

At 15:30 24/02/00 +1100, Eric Zurcher wrote: >6) I'm intrigued by the notion of a "Progressive Revelation model" >(footnote 5). It sounds terribly theological - or perhaps that's >Thiele-logical? (my apologies to Kevin, but I really can't resist bad puns). I'm often accused of teleology, but rarely of theology. Progressive Revelation is perhaps a new way of handling holes in data matrices for random-access keys. The background is this: The simplest data structure for a random-access key is a fully populated matrix i.e. all taxa are scored for all characters/states. Works well sometimes, especially if the taxa are highly comparable e.g. the species of a genus or the genera of a family. This structure is problematic sometimes though, for two reasons. Firstly and most simply, you may not have data for all taxa, and need to leave holes in the matrix. Solution is simple - fill the holes with ?s and allow for this in the key program. But it often also happens that some characters are simply inapplicable to some taxa, or (worse) are non-ambiguous for some taxa but ambiguous for others. For instance, stipules don't occur in monocots, stipule-like structures sometimes do but if you try scoring stipule characters as defined for dicots against monocots you run into all sorts of strife because of ambiguity of context. LucID can handle this to some extent using the "present by misinterpretation" score, but the problem is in the character definition, not the score. Sometimes a better way to handle such circumstances using LucID is to break the key up into a hierarchically nested set of keys & subkeys. For instance, you want to create a key to grass species of Australia but there are many special characters needed for identifying Poa species that are either inapplicable to or ambiguous with respect to the remaining grasses. So put Poa as a genus in the top-level key and attach to it a subkey to Poa species in which you can optimise your character definitions for the Poas. There are some disadvantages to this but often the advantages (in having an optimised rather than generalised and suboptimal character list) outweigh the disdvantages. But there may be another solution - Progressive Revelation. As far as I know no-one's done this yet, but I think it has merit. It would work like this. Create a key to all grass species so you're working with a list of all taxa at species level including all the Poa species. The character list has two classes of characters - ones that are scored over all taxa (these will be the easily generalised characters) and ones that are scored for only a subset of taxa (the characters that are highly specific and/or not easily generalisable). When the key program starts it splashes up the generalised characters only. But if after answering some characters you end up with only Poas, the program finds and adds to the character list the Poa-specific characters. Characters are progressively revealed as you proceed through the key, with as much depth as necessary - e.g. you may come down to a species complex of alpine Poas and presto! some characters appear that are just the ticket to separate them. Might work. This seems to me to be a more natural way of approaching both the building and running of a key. In some ways it's like a hybrid between a traditional random-access key and a traditional nested hard-copy key, but it has more flexibility than either. In the context of natural-language descriptions (and more controversially) it would also provide a challenge to what to me is the Universalist furphy that all descriptions should be strictly comparable! I've included these ideas into the SDD Specification because I think this may be one for the future. Cheers - k ps Eric - if you incorporate these ideas into DELTA we'll need to make an arrangement regarding due acknowledgement and royalties :-)

1 0

Re: SDD Specifications Document
by Kevin Thiele 28 Feb '00

28 Feb '00

At 15:30 24/02/00 +1100, Eric Zurcher wrote: >1) One "pattern" that recurs in the document in the use of "attachments" to >entities. These consist of a name, type, path, public notes, and private >notes. Presumably one could define some sort of generic "attachment" object >and avoid the multiple (4) redefinitions currently given in the outline. >This would shorten the outline appreciably. This sounds sensible. Should someone edit the document to reflect this, or should we just leave efficiency dividends like this to Leigh or whoever creates the final thing? Two comments though. Firstly, most of these attachment objects will be unique - presumably it won't often happen that one attachment will be used for two taxa, or for a taxon and a character state. So do you gain much? Secondly, ease of reading the text treatment should be a consideration. If all the information re the attachment stays with the taxon/state etc entry, this may make the treatment more navigable. >2) ID numbers crop up in a number of places. But it's not obvious how >"unique" these various IDs need to be. For example, must character IDs be >unique only with the context of the set of all character IDs, or of all IDs >used anywhere within the treatment? Or perhaps they are intended be used >across treatments (to facilitate merging, etc.), and must be unique (but >consistent) in an even broader sense? (But perhaps this is an area this is >best left deliberately ambiguous for now.) I'd say that IDs need to be unique within their context eg at the character level. Super-uniqueness beyond the treatment is the lexicon issue and doesn't need to be addressed here, I think. We should construct the standard in such a way that lexica can grow, but without a requirement for them. For instance, there should be no requirement that character IDs form a contiguous integer set. >3) Character (and taxon) sets - these should probably be defined >hierarchically, so that sets would be able contain other sets, as well as >the base elements (characters or taxa). Note that there seems to be another >"up vs. down" problem here - is it better to define a set by listing the >members within it, or for the each of the members to list the sets to which >it belongs? What do people think? Does the idea of allowing nested sets overlap and merge the boundary with the nested character structure, and perhaps become redundant. For instance, I envisage the characters being nested (as discussed earlier in the list): Plant leaves orientation venation prominence reticulation flowers petals colour number .........etc Sets are perhaps a shortcut across all this. If they were heirarchically structured, would you just be repeating much of the above without the lowest level? >4) I'm rather confused by footnote 3, regarding the nesting of character >names, and the restriction of "properties" to only the lowest level. What >it the reason for this restriction? But certainly there seems to be merit >in separating the "properties" of a character from it's textual >representation. This is almost essential when attempting to generate >natural-language descriptions in multiple languages. Similarly, different >wordings may be appropriate in different application contexts >(natural-language vs. interactive keys vs. conventional keys, or keys of >the layman vs. the specialist). There are many things in the document that I haven't thought through properly, but I decided to get it out for comment before labouring further. I think what I meant was that the higher-level structures in the character names list do not have any representation in the data "matrix", only the lowest level. Consider some data represented in the LucID way (as a taxon-state matrix) (you can do the same thing for a DELTA representation in which cells of the matrix hold taxon-character scores): 123456789 Taxon1 010101000 Taxon2 111010101 Taxon3 000101001 Columns 1-9 represent character states. Columns 1-3 may be the states of character 1, 4-5 the states of character 2, 6-9 the states of character 3. Now characters 1&2 may both belong to a higher-level structure, but the properties of this higher-level thing are not equivalent to the properties of the state (for instance, it can't have a score). But perhaps there are properties in common? >5) This draft allows for a "score" only within the context of a "state >name". It is not obvious how characters with non-discrete values (e.g. >numeric values) would be handled. Just as for Leigh's original XDELTA. >7) For purposes of natural-language generation (and perhaps other >applications), it is desirable to have some sort of "connection operator" >between states within a character (e.g., "flowers blue or violet" vs. >"flowers blue and violet" vs. "flowers blue to violet" all carry slightly >different meanings). This and other requirements of generating >natural-language descriptions might be an argument for generally preferring >a "characters within taxa" representation to "taxa within characters". Again, I think Leigh's XDELTA covers this, using nested scores.

1 0

Re: SDD Specifications Document
by Kevin Thiele 28 Feb '00

28 Feb '00

Bob Morris surely something like this - working out data requirements - needs to be done whether the final product has a DTD, RDF or XML-Schema base. I'm not qualified to argue the implications or advantages, so how about those of us like me argue about the data, and you mob argue about the rest. Maybe we can get to resolutions at the same time! Cheers - k

1 0

Re: SDD Specifications Document
by Neil Caithness 25 Feb '00

25 Feb '00

> From: "Mauro J. Cavalcanti" <maurobio(a)ACD.UFRJ.BR> > > I was also curious about this notion. Maybe it is one of the latest > "revelations" of Religious Cladism - its practitioners are fond of such > theological terminology. Mauro, are you serious, or was this just a through-away comment? This is the sort of pseudo-criticism that comes from people who understand nothing. "Religious Cladism" means what, and "its practitioners" refers to whom? Neil Caithness

1 0

Re: SDD Specifications Document
by Mauro J. Cavalcanti 25 Feb '00

25 Feb '00

Eric Zurcher escreveu: > 6) I'm intrigued by the notion of a "Progressive Revelation model" > (footnote 5). It sounds terribly theological - or perhaps that's > Thiele-logical? (my apologies to Kevin, but I really can't resist bad puns). I was also curious about this notion. Maybe it is one of the latest "revelations" of Religious Cladism - its practitioners are fond of such theological terminology. Otherwise, I essentially agree with all the points raised by Eric Z. I was about to suggest that a graphic model, perhaps using the UML methodology, was in order, but Jean-Marc Vanel has already taken care of that. His model is interesting, and deserves attention. Cheers, -- + - - - - - - - - - - - - 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: SDD Specifications Document
by Eric Zurcher 24 Feb '00

24 Feb '00

At 16:02 23/02/2000 +1100, Kevin Thiele wrote: >Dear list_eners > >attached find SDDspecs.rtf. This is my attempt to formalise the discussion >so far into a set of specifications for a new descriptive data standard. > and requested comments his proposal. I've not had time to think this through in detail, but I'd nonetheless like to offer a few scattered observations. 1) One "pattern" that recurs in the document in the use of "attachments" to entities. These consist of a name, type, path, public notes, and private notes. Presumably one could define some sort of generic "attachment" object and avoid the multiple (4) redefinitions currently given in the outline. This would shorten the outline appreciably. 2) ID numbers crop up in a number of places. But it's not obvious how "unique" these various IDs need to be. For example, must character IDs be unique only with the context of the set of all character IDs, or of all IDs used anywhere within the treatment? Or perhaps they are intended be used across treatments (to facilitate merging, etc.), and must be unique (but consistent) in an even broader sense? (But perhaps this is an area this is best left deliberately ambiguous for now.) 3) Character (and taxon) sets - these should probably be defined hierarchically, so that sets would be able contain other sets, as well as the base elements (characters or taxa). Note that there seems to be another "up vs. down" problem here - is it better to define a set by listing the members within it, or for the each of the members to list the sets to which it belongs? 4) I'm rather confused by footnote 3, regarding the nesting of character names, and the restriction of "properties" to only the lowest level. What it the reason for this restriction? But certainly there seems to be merit in separating the "properties" of a character from it's textual representation. This is almost essential when attempting to generate natural-language descriptions in multiple languages. Similarly, different wordings may be appropriate in different application contexts (natural-language vs. interactive keys vs. conventional keys, or keys of the layman vs. the specialist). 5) This draft allows for a "score" only within the context of a "state name". It is not obvious how characters with non-discrete values (e.g. numeric values) would be handled. 6) I'm intrigued by the notion of a "Progressive Revelation model" (footnote 5). It sounds terribly theological - or perhaps that's Thiele-logical? (my apologies to Kevin, but I really can't resist bad puns). 7) For purposes of natural-language generation (and perhaps other applications), it is desirable to have some sort of "connection operator" between states within a character (e.g., "flowers blue or violet" vs. "flowers blue and violet" vs. "flowers blue to violet" all carry slightly different meanings). This and other requirements of generating natural-language descriptions might be an argument for generally preferring a "characters within taxa" representation to "taxa within characters". Cheers, Eric Zurcher CSIRO Division of Entomology Canberra, Australia E-mail: ericz(a)ento.csiro.au

1 0

Re: <XML> Abstract Data Model for Taxonomy
by Jean-Marc Vanel 24 Feb '00

24 Feb '00

Leigh Dodds a écrit : > 1. Firstly is it possible to express items like > "Feature often present by mis-identification" Sorry, my english is too weak. Does this mean a character value that is often reported by confusion with another taxon ? > I note you've already highlighted seasonal variations as a problem. My solution: the default for a Property is to record the state for: - middle of active season - adult specimen Otherwise, create a new Property. Note that beside the specified sub-elements of tax:Property (appliesTo, appliesToClasses, name), it is possible to add extra information like, say, <bio:season>spring</bio:season>. This is a property (rdf:Property) about a property (tax:Property). > To that I'd add geographical, My (simple) solution: if anything is different in some region, create a lower level tax:TaxonomicClass, containing just the differing Features; according to model, other Features will be inherited. > 2. It seems to presuppose a Linnean viewpoint i.e. Kingdom, > Phylum, etc. I didn't write that, in fact this model is so generic that it could almost be applied to car models! > Gregor has previously pointed out that the > reality is much more complex. Multiple hierarchies > can be produced. For example, how would the model be used to express > DNA/Protein data? Physiological versus Molecular hierarchies? And belonging to phytosociological associations, also. Although I didn't think of that, this is no problem. You just have to publish on the Web a Schema with, say, a ProteinClass and a ProteinSubClass, declaring that both are rdfs:subClassOf of tax:TaxonomicClass, and connecting them using tax:lowerClasses and tax:upperClass, etc. And hoping that many will connect to your Schema... Well, this is the freedom of the Web, but I hope that a standard will be found. But I wanted to show that extendibility is perfectly possible, with the possibility that the new semantic is declared as such, so that tools can understand the new semantic. > 3. I assume that the list of Feature/Properties will not be > fixed, but can be extended at will? Yes > However I'm concerned that the presence of items like 'TaxonomicClass' in > the model doesn't > capture the range of flexibility that Kevin, Gregor and the others > have stated as a requirement. Is this requirement like the Molecular hierarchies, or something else ? Cheers Jean-Marc -- <person> <first_name>Jean-Marc</first_name> <name>Vanel</name> <project>Worlwide Botanical Knowledge Base - making botany available on Internet <a href="http://wwbota.free.fr/" >site</a> </project> <homePage>http://jmvanel.free.fr/</homePage> <a href="mailto:jmvanel@free.fr">mail (eventually put "wwbota" in subject to route your mail in relevant folder)</a> </person>

1 0

Re: <XML> Abstract Data Model for Taxonomy
by Leigh Dodds 24 Feb '00

24 Feb '00

Hi, > The spring is coming, the crocuses are in bloom, it's time to come up > with a formal model. Some questions: 1. Firstly is it possible to express items like "Feature often present by mis-identification" (I came across this somewhere, but can't recall the posting/webpage) I note you've already highlighted seasonal variations as a problem. To that I'd add geographical, and developmental (i.e. age of item). 2. It seems to presuppose a Linnean viewpoint i.e. Kingdom, Phylum, etc. Gregor has previously pointed out that the reality is much more complex. Multiple hierarchies can be produced. For example, how would the model be used to express DNA/Protein data? Physiological versus Molecular hierarchies? [See (RQT) Character and item hierarchy from Gregor posted on 1/12/99 - I'd include a URL, but the ListServ archive seems to require a username/password] 3. I assume that the list of Feature/Properties will not be fixed, but can be extended at will? Apologies if this seems overly critical, I'm just trying to get my head around things. Fundamentally I think that an RDF (or even Groves) model of the data will be extremely useful. However I'm concerned that the presence of items like 'TaxonomicClass' in the model doesn't capture the range of flexibility that Kevin, Gregor and the others have stated as a requirement. I'd welcome some further discussion/information of your model. Cheers, L.

1 0

<XML> Abstract Data Model for Taxonomy
by Jean-Marc Vanel 24 Feb '00

24 Feb '00

Hello dear group The spring is coming, the crocuses are in bloom, it's time to come up with a formal model. Look at http://wwbota.free.fr/UML_diagrams.htm -- <person> <first_name>Jean-Marc</first_name> <name>Vanel</name> <project>Worlwide Botanical Knowledge Base - making botany available on Internet <a href="http://wwbota.free.fr/" >site</a> </project> <a href="mailto:jmvanel@free.fr">mail (eventually put "wwbota" in subject to route your mail in relevant folder)</a> </person>

1 0

Re: SDD Specifications Document
by Jean-Marc Vanel 24 Feb '00

24 Feb '00

Dear contributors It's good to see a new debate begining! Undefined terms in SDD Specifications Document: * "Progressive Revelation model" * Treatment * score It seems that this Specification mixes data and Specification of processing to be done on this data by an application. Processing is a very interesting subject (see transforms), but good design is layered design, and processing seems an upper and distinct layer. Eric Zurcher a écrit : > 1) One "pattern" that recurs in the document in the use of "attachments" to > entities. .... > 2) ID numbers crop up in a number of places. But it's not obvious how > "unique" these various IDs need to be. I agree. > some sort of "connection operator" > between states within a character (e.g., "flowers blue or violet" vs. > "flowers blue and violet" vs. "flowers blue to violet" "flowers blue and violet" will have to be covered by my proposed "Abstract Data Model for Taxonomy". <person> <first_name>Jean-Marc</first_name> <name>Vanel</name> <project>Worlwide Botanical Knowledge Base - making botany available on Internet <a href="http://wwbota.free.fr/" >site</a> </project> <a href="mailto:jmvanel@free.fr">mail (eventually put "wwbota" in subject to route your mail in relevant folder)</a> </person>

1 0

Re: SDD Specifications Document
by Jean-Marc Vanel 24 Feb '00

24 Feb '00

Bob Morris a écrit : > (a).On theoretical and practical grounds, DTD's > are now understood to be a weak way to describe the schemata > > (b). Mixed content (a mixture of text and elements) is a really > bad idea, Yes and yes; DTD is an old technology from SGML, if we want a standard for at least 10 years, it's better to avoid it. -- <person> <first_name>Jean-Marc</first_name> <name>Vanel</name> <project>Worlwide Botanical Knowledge Base - making botany available on Internet <a href="http://wwbota.free.fr/" >site</a> </project> <a href="mailto:jmvanel@free.fr">mail (eventually put "wwbota" in subject to route your mail in relevant folder)</a> </person>

1 0

Re: SDD Specifications Document
by Leigh Dodds 24 Feb '00

24 Feb '00

> (a).On theoretical and practical grounds, DTD's > are now understood to be a weak way to describe the schemata > (small 'S') of XML documents. The specialists should argue > about whether RDF or XML-Schema's (uppercase 'S') work > better (or try each on for size) and if there is a compelling > reason to have a DTD then derive one from the Schema. I agree, and will use the W3C XML-Schema syntax to produce an XML interpretation of Kevins document. I'll refrain from using any complicated Schema features so at to not detract from the core discussion. The debate in the developer community concerning Schemas is currently something of a hot topic [1]. I hope to be able to present something shortly. Cheers, L. [1]. http://www.xml.com/pub/2000/02/23/xmldeviant/index.html

1 0

Re: SDD Specifications Document
by Leigh Dodds 24 Feb '00

24 Feb '00

Hi, Just to respond to the following mentioned by Bob: > (b). Mixed content (a mixture of text and elements) is a really > bad idea, as is well known in the SGML community. Our own > limited experience has been that dealing with it in display code > necessitates to code obscurely. I can't tell whether anything > in the proposal would lead this way. Maybe some pseudo-code > XML-like examples would enlighten. Mixed content can certainly be difficult to manage, although people are using it on a daily basis when they write HTML, so it can't all be bad! Seriously though, I had been thinking that the 'notes' and other free text sections in the format would use XHTML derived tags to describe its presentation. Perhaps its worth exploring this further. Firstly, for non-markup people. Mixed content is markup which contains free text interspersed with additional tags. e.g. <notes>This is mixed content</notes> An (trivial) example using XDELTA syntax: <character number="2"> <description>main colour of inner part of front wing</description> <image num="2" mime="image/jpeg" href="lepc02.jpg" /> <multi type="unordered"> ...states removed... </multi> <notes>I should stress here that there may be other wings colours yet to be determined</notes> </character> Where denotes emphasised text. This facilitates the production of a nicely formatted display, at least for HTML. An alternative which removes mixed content (I'll just reproduce the notes tag for clarity: <notes> <text>I should stress here that there </text> may be <text>other wings colours yet to be determined</text> </notes> I believe this is less readable, and involves more markup effort from the user. Of course I might be barking up the wrong tree, and this kind of markup isn't a requirement. The issue is related to how the textual content in the data is to be presented to the user, and isn't something we've explored yet. The main problem with mixed content is it makes life difficult for parser and tool writers. It does make some things easier for the user, like readability. Cheers, L.

1 0

Re: <XML> Abstract Data Model for Taxonomy
by Noel Cross 24 Feb '00

24 Feb '00

On Thu, 24 Feb 2000, Jean-Marc Vanel wrote: > > > 2. It seems to presuppose a Linnean viewpoint i.e. Kingdom, > > Phylum, etc. > > I didn't write that, in fact this model is so generic that it could almost > be applied to car models! > This is puzzling. In that case why would a TaxonomicClass need to have a member named "botanicalAuthor" as in your UML diagram? -Noel

1 0

SDD Specifications Document
by Kevin Thiele 23 Feb '00

23 Feb '00

Dear list_eners attached find SDDspecs.rtf. This is my attempt to formalise the discussion so far into a set of specifications for a new descriptive data standard. Leigh has explained that his XDELTA is a first-cut approach to such a standard, done more to show what's possible than as a serious suggestion for a final cut. He has offered to revisit and rework "XDELTA" in light of the list's discussions. To make his job easier, I think it wold be a good idea for those of us still out there to work up a structured specification document for Leigh to work his magic on. If it works OK, the attached may be the first step to this specification. Again, this is a first cut. It incorporates my ideas, and those I've been able to trawl from the list that have made sense to me. I may have got things all wrong, and it will almost certainly not be exhaustive, but I think at this stage it's better for the authors of other ideas to work on this directly rather than for me to try to understand what they were saying. I hope the document's self-explanatory - if not, ask me to explain. Any suggestions as to the best way to work up the document? If we all edit bits and repost we'll end up with diverging versions. Anyway, see if this makes sense to you. Cheers - k

1 0

Re: SDD Specifications Document
by Bob Morris 22 Feb '00

22 Feb '00

Kevin Thiele wrote: > Dear list_eners > <XML data modeling spec proposal>... I'm not competent to address the proposal, but I would like to try to influence the directions that may emerge from it in several ways: (a).On theoretical and practical grounds, DTD's are now understood to be a weak way to describe the schemata (small 'S') of XML documents. The specialists should argue about whether RDF or XML-Schema's (uppercase 'S') work better (or try each on for size) and if there is a compelling reason to have a DTD then derive one from the Schema. Aside from (or perhaps actually because of) the lack of typing, inheritance, and ordering mechanisms, DTDs add restrictions on the kinds of schema inference that can be made from particular XML documents that might be a query result, and because of that make it less straightforward to mediate between the answers to queries on two different databases. These issues are explored in the book "Data on the Web" by Abitoul et al., and in the literature behind it. (b). Mixed content (a mixture of text and elements) is a really bad idea, as is well known in the SGML community. Our own limited experience has been that dealing with it in display code necessitates to code obscurely. I can't tell whether anything in the proposal would lead this way. Maybe some pseudo-code XML-like examples would enlighten. (c). One should keep in mind that queries can be constructed by software, not just by people. The latter are far better than the former at resolving ambiguity and supplying reasonable defaults. So for example, we should always ask at the end if we have given enough to formulate queries and interpret their answers in a non-interactive fashion. Put another way, data exchange is a minor reason to adopt XML compared to its utility for the construction of queries and the interpretation of their answers. (Here's a trivial example, soon to be easily fixed: the data returned by the experimental XML facility at ITIS*ca conforms to a DTD in all but one case: that where there is no data matching the query. In that case, it returns the same HTML "sorry no answer" page that the html interface does, thereby requiring an XML application to have special knowledge of this case---which would not bother a human at all but sure startled our little application.) Bob Morris

1 0

XHTML
by Susan B. Farmer 12 Feb '00

12 Feb '00

>>>From the HTML Writers Guild Newsletter ---------- Begin INcluded Taxt 1. XHTML: Bridging the Gap between HTML and XML (Kynn Bartlett, HWG President, kynn(a)hwg.org) On 26 January 2000, the World Wide Web Consortium released the newest flavor of HTML -- XHTML. The HTML Writers Guild is proud to have played a role in the development of this specification, and we would like to thank Ann Navarro and Frank Boumphrey for their dedication and hard work in the W3C's HTML Working Group. But what _is_ XHTML, and what does it mean to members of the Guild? WHAT IS XHTML? To understand that, first we need to review what HTML is. Hypertext Markup Language was created as an "application" of SGML (Standard Generalized Markup Language), which is a "meta-language" for describing other markup languages. Extensible Hypertext Markup Language (XHTML) is simply a version of HTML but defined as an application of XML (Extensible Markup Language). XML was developed as another "meta-language", not as complex as SGML but powerful enough for use in web environments. WHY XHTML? Why an XML-based HTML, if we already have "normal" HTML? By using XHTML, we have access to the strengths of XML -- extensibility and interoperability. Developers can extend XHTML through modules, DTDs, schemas, and incorporation of other XML-based languages. XSLT (Extensible Stylesheet Language Transformations), which allow XML documents to be easily changed from one representation to another, will make it easy to adapt XHTML pages for a wide variety of browsers and user agents. WHAT IS XHTML LIKE? If you're already familiar with HTML 4.01, you'll find that XHTML 1.0 offers the same features and abilities you've always had. (Future versions of XHTML will expand beyond simply "translating" the HTML specification into XML.) There are some differences in syntax, however; the most notable ones include: * Documents must be "well formed" -- an XML term meaning that tags must match and be nested properly * Element and attribute names must be in lower case * For non-empty elements, end tags are required -- no more optional or </LI> tags * Attribute values must always be enclosed in quotes * Empty elements must either have an end tag, or the start tag must end with /> If you're like at least half of the web designers out there, the second bullet point above might stand out and you may be asking: WHY LOWER CASE? In HTML, tags and attributes are not case sensitive. This means that <BODY>, <body>, <Body>, and even <bOdY> refer to the same thing; you can have your opening tag be <body> and your closing tag </BODY>, and it all works fine. XML, the language used to build XHTML, is case sensitive. <Body> is considered a different tag from <BODY>, <body>, or <bOdY>, in XML. Because of this, a standard for XHTML tags had to be set -- and the most likely choices were "all uppercase" (such as <BODY>), or "all lowercase" (such as <body>). In the end, lowercase won out, although it really could have gone either way; a semi-arbitrary choice had to be made. DO CURRENT BROWSERS SUPPORT XHTML? No and yes. Current browser releases do not speak XHTML, they speak HTML. However, it is possible to write XHTML in a way that is compatible with HTML, and will not break on existing HTML-based browsers. These are described in Appendix C of the XHTML specification. As an example, the "hr" (horizontal rule) tag must be closed, and would normally be written in XHTML as either <hr/> or <hr></hr>. However, this will confuse many existing HTML-based browsers; instead, you can write the tag as <hr /> -- note the space. This is legitimate XHTML and is compatible with HTML browsers. HOW CAN I LEARN MORE ABOUT XHTML? The complete spec for XHTML 1.0 is available via the web from the W3C's web site: http://www.w3.org/TR/xhtml1/ For a chance to experience XHTML and XML first-hand -- or perhaps just view the source of some web pages written in XHTML -- read on to the next article! --------- End Included Text Susan Susan Farmer sfarmer(a)goldsword.com Botany Department, University of Tennessee http://www.goldsword.com/sfarmer/Trillium

1 0

(GEN) Maize ontology & interoperable ontologies
by Vincent, Leszek 11 Feb '00

11 Feb '00

Dear subscribers to TDWG-SDD On Jan. 31, 2000 I sent an email to you (copy below) about developing a containment hierarchy for Maize & expanding this to include the rest of the Poaceae and hopefully subsequently the rest of the monocots & dicots (via interoperable ontologies). I'm presenting some of this work at the next Maize Genetics Conference (March) [http://www.agron.missouri.edu/Coop/Conf/2000.html] & include a copy of the abstract below F.Y.I. -------------- Conference abstract: Developing systematic descriptors and containment hierarchies for maize The Systematic Descriptors component of the Missouri Maize Project is aiming to provide descriptors in appropriate 'containment hierarchies' (biological terms, their relationships and associations) for maize. We wish to design a structure that has wide contribution from scientists studying maize and many other plant species. Databases comprising all sorts of information on monocots and dicots will need to be increasingly interoperable to facilitate future concurrent searches of these databases and so be helpful to a wide range of end-users. Developing systematic descriptors in containment hierarchies which accommodate maize data is a challenge on its own. But developing a structure that can accommodate present and future data from other monocot and dicot taxa, is another very relevant and stimulating challenge. An overview has been developed and the framework is forming. We are seeking feedback on the framework and content. NSF award 9872655. ----------------------- For further info. on this project please access: http://www.agron.missouri.edu/mnl/74/89vincent.html - a publication in the Maize News Letter. Should you have any comments, suggestions... about the development of containment hierarchies for maize (in a formal ontology) and the subsequent development of interoperable ontologies, I'd love to hear from you. Thanks for your time. Sincerely, - Leszek Vincent ======================== Text of email of Jan. 31: Dear subscribers to TDWG I've been 'listening' to the contributions on Lexicons, XML etc. for a while now and thought I should seek your comments because your contributions have sparked several developments in my thinking. I'm wrestling with the development of a hierarchy (containment hierarchies) of systematic descriptors for corn/maize/ Zea mays for the Missouri Maize Project (see URLs below). While this is challenging for maize/corn on its own, an added challenge is my desire to develop containment hierarchies which are compatible with databases for other grass crops e.g. rice (Oryza). To add to the challenge I have the ideal of trying to accommodate the 'interests' of similar databases for various DICOT crops e.g. soybean, cotton. While I do appreciate that such an all encompassing approach is maybe impossible to achieve I thought that it would still be good to get some other folks opinions on this. Having some kind of 'generic' structure which accommodates monocots & dicots should greatly facilitate the interoperability of these databases. It's the interoperability scenario which really got me on to thinking about this issue. Conducting simultaneous searches of dicot & monocot databases for morphological data down to molecular (e.g. sequence) data is not too far fetched. But I'm battling to find info. which addresses/refers to such 'generic' standards. I'd be grateful to have your thoughts on the above. ======================== xoxoxoxoxoxoxoxoxoxoxoxoxoxoxox P. Leszek D. Vincent Ph.D., FLS Plant Science Unit, Dept. of Agronomy, 209 Curtis Hall, University of Missouri-Columbia, MO 65211-7020, USA. Ph: (573) 884-3716 (Agronomy), (573) Fax:(573) 884-7850; Ph/Fax (Home): (573) 441-1228; Email: Leszek(a)missouri.edu Plant Systematist on the Missouri Maize Project - NSF award 9872655 - (http://www.cafnr.missouri.edu/mmp/ and http://www.agron.missouri.edu/) xoxoxoxoxoxoxoxoxoxoxoxoxoxoxox

1 0

Re: (LEX) Containment Hierarchies
by P. F. Stevens 01 Feb '00

01 Feb '00

When one starts to "spread" morphological databases in botany one runs into innumerable problems, as I think I mentioned some time ago. In this case, thinking of monocots and "dicots", will we allow monocots to have stipules? What do we do with the intravaginal squamules of many Alismatales which, as far as I can see, are colleters under another name? But why should they not have a different name, since they are likely of independent origin from colleters in dicots? But, if one takes that tack, can we use the terms haplostemony and diplostemony in monocots, as Ronse Decraene questioned in a monocot symposium volume about four years ago? Indeed, do monocots ever have sepals or petals? Why should "hypogeal" and "epigeal" mean different things for monocot and dicot seedlings? These are not insoluble problems, but I have seen no recent discussions on how to clarify botanical terminology, although I think that this is definitely needed - and it needs to be an international effort, not least because we can have the same botanical term meaning different things in different languages (I think "crassinucellate" is an example). Peter S.

1 0