- tdwg-content - lists.tdwg.org

Re: Document vs. database
by Jim Croft 30 Nov '01

30 Nov '01

> Am I missing something, but why do we keep on talking about states? This > is the last thing I think is interesting (double entendre here...) States > are frosting, observations - measurements, photos - make up the cake itself. Is this a real issue or one of semantics? When I write "leaf shape ovate", does it mean I have observed the leaf and its shape most closely matches that of ovate, or that I have observed the shape character leaf and consider it to be in a state of ovateness? The end result is probably the same... But I think the issue is worth pondering... Perhaps Richard did not have it quite right and perhaps we should be recording zero or more observations which are made of a feature that has a certain character one of the attributes (rather than the state) of which is present/ absent/misinterpreted, etc. Maybe something like: <observation sequence="3" basis="specimen" refereence="Stevens in NGF67432"> <feature name="leaf"> <character name="margin" value="serrate" state="present"/> </feature> </observation> <observation sequence="4" basis="literature" reference="Stevens 1998a"> etc... or maybe it would be better to invert it and define a feature up front and make one or more observations about it: <feature name="leaf"> <character name="margin"> <observation value="serrate" modification="obscurely" state="present" basis="specimen" reference="Stevens in NGF67432"/> <observation ..... /> <observation ..... /> </character> </feature> There are numberous ways to moddel this sort of stuff, and has been repeatedly pointed out there is no right way to do it, there are only ways. The challenge is to find one that is functional, comprehensive, flexible, extensible, pragmatic and elegant. And one that we can all agree on... > Probably getting old. as are we all... and we have to get this damn thing working before our use-by dates are up... :) jim

1 0

Process: Forum software?
by Robert A. (Bob) Morris 29 Nov '01

29 Nov '01

DON'T REPLY TO THE LIST: As I mentioned in Sydney, we have now established an instance of the vBulletin web-based forum software (see www.vbulletin.com) and are prepared to host a forum here for the current discussions if there is any desire to do so. Forums provide better threading than email (it is not based solely on the Subject field) and also permit participants to consider things somwhat more at their own schedule and according to their own interests. The board administrators can set how long postings remain at the forefront, so that it is easier to understand what is current. vBulletin allows you to be notified briefly by mail when something of interest appeared on the forum. There are a few disadvantages to moving this discussion now: (a)Quite a bit has transpired and people might feel they need to restate things in the forum [that could be an advantage....]; (b)we are new to this software and might not administer it as seamlessly as a mail-based system. So as not to clutter the list. I would urge people to /privately/ reply to me with their sympathy for or against the issue. I'll summarize and post the results and then people can discuss it, if warranted. Send mail to ram(a)cs.umb.edu. Your "Reply" facility will likely send to the list. For a glimpse of how vBulletin forums operate, see those at http://vbulletin.com/forum/index.php http://forums.progresstalk.com/index.php http://www.linuxquestions.org/questions/ http://www.ntcompatible.com/vb/index.php http://www.webdevforums.com/ As far as I can tell, vBulletin is the software under the forum parts of sourceforge.net Bob Morris p.s. Forum software is aimed at community building, so vBuilder has lots of flashy features like smiley face annotations, personal avatars, polls about the quality of a thread, "buddy lists", etc. I don't expect that SDD forums would operate with that stuff in your face, especially as we gain administrative experience.

1 0

Re: Document vs. database
by Jim Croft 29 Nov '01

29 Nov '01

> In DELTA, Lucid etc we express alternate hierarchies in alternate documents. > Do we need to do better than this? Let's stop this line of thought right now... build one hierachy of characters that works first, THEN consider how to manage alternatives... maybe... jim

1 0

Re: Document vs. database
by Jim Croft 29 Nov '01

29 Nov '01

I have been watching the animated discussion on the revived SDD list and it is tood to see... too busy to comment, but still interested, and useful things are being said by others... :) > Existing data structures allow 2-level hierarchies e.g. > #1. Leaf shape/ > 1. ovate/ > 2. elliptic/ > #2. Flower colour/ > 1. blue/ > 2. red/ Is that really two levels of character is is it only one with a state attribure? Also, in our new model we also want to show more than just presence or absence of a state. Don't we want to show if it is present/rarely present/present by misinterpretation/rarely present by misisnterpretation, etc., and my favourites yet to be implemented as a character stae attribute: definitely absent, absent by misinterpretation, unknown, unscored > I'm simply suggesting allowing n levels: > <Leaves> > <shape> > <ovate> > <elliptic> > <Flowers> > <colour> > <blue> > <red> That is where we want to get to do, but echoing Bob's words, what we are after is the structure that allows us to get to that, giving people all the appearance of freedom to do what they like but not actually doing it and imposing a schematic straight jacket on the data. A schema for the data structure rather than the descriptive data itself. Like all freedoms, the descriptive data one too must be an illusion or we wil miss out on on all the creative potential that it offers as the free spirits among us do theri own thing. But that is another discussion... :) There has been a lot of talk about the feature/value paradigm and how this might be made to represent a biological description and even nested features in such descriptions... At the recent TDWG meeting Richard Pankhurst described something like a feature/character/value paradigm and at the time I made a note that this was probalably worth considering in more detail, but so far have not had the time. It probably would mean something like: <feature name="leaf" charecter="margin" value="serrate"/> or some equivalent using XML entities rather than attributes. Is there any merit in this approach above using a feature that is say "leaf margin" and another that is say "leaf tip" and yet another that is say "leaf base"? It would seem to give some structure to the character set data. On the surface it would also allow easy generation of more readable descriptions without excessive text processing: Leaf outline ovate, margin serrate, tip acute, base attenuate, etc. as opposed to: Leaf outline ovate, leaf margin serrate, leaf tip acute, leaf base attenuate, leaf... etc. Has anyone else considered this approach? jim

1 0

Re: Document vs. database
by Kevin Thiele 29 Nov '01

29 Nov '01

----- Original Message ----- From: "Eric Zurcher" <Eric.Zurcher(a)PI.CSIRO.AU> To: <TDWG-SDD(a)USOBI.ORG> Sent: Thursday, November 29, 2001 3:32 PM Subject: Document vs. database | At 02:15 PM 28-11-01 +1100, Kevin Thiele wrote: | >Issues | > | >I've taken the route of marking up a textual description, using a minimum of | >tags. It seems to me that a description comprises a series of features with | >values. I've used mixed markup because I wanted to have the mimimum tagging | >and make maximum use of the text. That is, in cases like: | > | ><Feature Name="Life form"><Value>shrub</Value></Feature> | > | >I've made use of the fact that "shrub" occurs in the text by enclosing it in | ><Value> tags. In cases like: | > | ><Feature><Name>Leaves</Name> | > | >I'm using a <Name> tag rather than a Name attribute | > | >This may make processing considerably more difficult, but it seems to me | >that there are some advantages. An alternative would be to first process the | >description into a DELTA-like structure then mark up that. I chose not to go | >that route because I still have the dream that one day we'll have a method | >of semi-automatically marking up the content of natural language into | >something like the above. The other advantage of this structure I believe is | >that it maintains all the complexity and nuance of the original natural | >language (which can be retrieved merely by removing all the tags). I prefer | >this to the DELTA-process (take a natural-language description -> atomise | >it -> reconstruct semi-natural-language by putting the atoms back together | >again in some fashion). | | My position on this is rather different, and I would prefer to see | characters defined a bit more rigorously. | | As an example, suppose that the description of one taxon is given as: | | <Feature Name="Life form"><Value>shrub</Value></Feature> | | A second as: | | <Feature Name="Life form"><Value>bush</Value></Feature> | | And a third as: | | <Feature Name="Life form"><Value>small woody plant</Value></Feature> | | And perhaps a fourth as: | | <Feature Name="Growth form"><Value>shrub</Value></Feature> | | Are these equivalent? There's certainly no obvious way to associate them, | aside from knowing that "bush" and "shrub" mean pretty much the same thing | in some dialects of English. I think the goal of trying to extract meaning | by inserting a few tags into existing textual descriptions relies too | heavily on a level of artificial intelligence that we're still unlikely to | see for a couple of decades. Good point, and there will clearly be a need for some type of processing somewhere along the line to catch and allow validation of these situations. But this is a processing issue, not a structural one. There's nothing in the DELTA data structure to prevent #1. Life form/ 1. shrub/ 2. bush/ 3. small woody plant/ #2. Growth form/ 1. shrub/ 2. smallish twiggy plant/ and I argue there should be nothing in the structure of the SDD standard to prevent it either. People simply need to be aware of the issue. But the SDD does, I agree, need to be structured in such a way that validation of these situations is made possible. The first-cut structure that I proposed does not allow much eyeball validation of this type - is this a problem? | But pondering on this made me think about why Kevin and I often disagree on | some of these issues. If I may greatly over-simplify our viewpoints, his | view is (I think) that a formal description ought to be a document from | which data can be extracted; whereas I tend of view a formal description | more as a database from which text can be generated. | | So what ARE we after: the free-flowing flexibility of a document, or the | rigour and precision of a database? Fortunately, there is a fair bit of | middle ground. It's worth noting that XML was developed as a markup | language for documents, but that it's primary usage to date has been as a | sort of portable and relatively light-weight data container. Still I think | that finding the right balance between flexibility and rigour is going to | be a major challenge in this exercise. My view I suppose is that part of the power of XML (something that has never been possible in the past) is that it allows precise retrieval of atomised data from a fairly free-form document. XML blurs the distinction between database and text. Before XML a text string like: Rigid, spreading shrub to c. 1m high and wide; stems glabrous. Leaves soon deciduous..... was highly intractable to computer processing. This intractability required us to manually and substantially restructure into e.g. a DELTA file before we could really do much with it. But there are problems I think with the DELTA process vis-a-vis natural language. In the relatively common case that we begin with a natural language description, the process is: natural language ----(1)-----> DELTA -------(2)-------->natural language (etc) where (1) is human processing and (2) is largely computer (CONFOR) processing. Two related problems here. Firstly, I often don't much like the output of CONFOR (some people say we humans should put up with the limitations computers force on us, but call me old-fashioned , I rebel at that {see also Asimov's Second Law of Robotics}). The second problem is that step 2 is unidirectional - if I edit the output natural language I break the process (the edits are volatile, next time I invoke CONFOR they get overwritten). So I'm trying to explore the new possibilities opened up by XML to produce a minimally restructured but highly parsable document. I'm happy to admit that I may be off-beam here. I just reckon we shouldn't discount the possibility. | >Features are nested: | > | ><Feature><Name>Leaves</Name> | > <Feature><Name>Shape</Name></Feature> | ></Feature> | > | >Is this allowable? In XML-Spy I can create a Schema OK for this document. | >It's also well-formed. | | It's certainly allowable in XML. Is it desirable in a description? | Possibly, but I think it relates to my question from yesterday about | hierarchies of characters ought to be expressed. Nesting is a very good way | to express a single hierarchy, but not for handling alternative | hierarchies. Which do people want? Existing data structures allow 2-level hierarchies e.g. #1. Leaf shape/ 1. ovate/ 2. elliptic/ #2. Flower colour/ 1. blue/ 2. red/ I'm simply suggesting allowing n levels: <Leaves> <shape> <ovate> <elliptic> <Flowers> <colour> <blue> <red> I can't decide if this a trivial or fundamental difference. | Nesting is a very good way | to express a single hierarchy, but not for handling alternative | hierarchies. In DELTA, Lucid etc we express alternate hierarchies in alternate documents. Do we need to do better than this? Cheers - k

1 0

Re: Taxonomic hierarchy in SDD
by Kevin Thiele 29 Nov '01

29 Nov '01

I agree with all this Eric :-) | While canalization is a risk, there certainly is also merit in trying to | retain the best features of "prior art". The DELTA format has persisted for | over 20 years, which is nearly an eternity in the IT field. It must have | been doing one or two things right. There's no need to follow it too | closely, but certainly we can learn quite a bit from DELTA about what works | well and what doesn't. No-one has suggested ignoring prior art, be it DELTA or any of the other programs. I think we have agreed several times to start with +/- a blank slate, learning as you say quite a bit from DELTA, Lucid etc about what works and what doesn't along the way. | >2. Of all the descriptions in the world, 99.9999999% of them are not in | >DELTA. Probably 99.999% of them are textual (natural language) descriptions. | >Surely this should form the basis of our first challenge, methinks. | | I think that's actually a rather harsh assessment of DELTA's uptake. Let's | say there are about 4x10^6 known species. We'd like descriptions for them | all, along with descriptions of higher taxonomic levels (genera, families). | So the magnitude of total number of descriptions is about 10^7. I'd guess | that the number of taxa with DELTA descriptions is of the magnitude of | 10^5. So that means roughly 1% of all taxa already have a DELTA description. I didn't stop to consider the maths, for which my apologies. My point was simply that a vast minority of decriptions are in any type of standardised format at the present. If your estimations are correct (and I can't judge that) then there are still 99 non-DELTA descriptions for every DELTA one, or any other. | >3. Related to 2 above, many (though by no means all) DELTA datasets are | >already abstractions from the source (a set of natural language | >descriptions). We should start with the source. | | The source? Surely the ultimate source is observations made on individual | specimens. If we wish to start with the source, the first thing that needs | to be done is to make sure that we have a system which can adequately | describe a specimen in hand. Yes, you're right about the ultimate source, but there are chains of sources, of course. The reason why I'm interested in the vast legacy of textual descriptions as source material is that I think that effective semi-automated processing of these descriptions along the lines of Pankhurst and Taylor is not too far off (some processing is here already, if course). We should make this easier rather than harder, if at all possible. Capturing the truly ultimate direct observations is something that any Builder program supporting the new standard will have to be good at, of course. | (Sorry if I get too defensive about DELTA. I just can't help myself...) Please don't think that I'm too dismissive of DELTA. I just think we should be assuming that we can do a fair bit better. Cheers - k

1 0

Document vs. database
by Eric Zurcher 29 Nov '01

29 Nov '01

At 02:15 PM 28-11-01 +1100, Kevin Thiele wrote: >Issues > >I've taken the route of marking up a textual description, using a minimum of >tags. It seems to me that a description comprises a series of features with >values. I've used mixed markup because I wanted to have the mimimum tagging >and make maximum use of the text. That is, in cases like: > ><Feature Name="Life form"><Value>shrub</Value></Feature> > >I've made use of the fact that "shrub" occurs in the text by enclosing it in ><Value> tags. In cases like: > ><Feature><Name>Leaves</Name> > >I'm using a <Name> tag rather than a Name attribute > >This may make processing considerably more difficult, but it seems to me >that there are some advantages. An alternative would be to first process the >description into a DELTA-like structure then mark up that. I chose not to go >that route because I still have the dream that one day we'll have a method >of semi-automatically marking up the content of natural language into >something like the above. The other advantage of this structure I believe is >that it maintains all the complexity and nuance of the original natural >language (which can be retrieved merely by removing all the tags). I prefer >this to the DELTA-process (take a natural-language description -> atomise >it -> reconstruct semi-natural-language by putting the atoms back together >again in some fashion). My position on this is rather different, and I would prefer to see characters defined a bit more rigorously. As an example, suppose that the description of one taxon is given as: <Feature Name="Life form"><Value>shrub</Value></Feature> A second as: <Feature Name="Life form"><Value>bush</Value></Feature> And a third as: <Feature Name="Life form"><Value>small woody plant</Value></Feature> And perhaps a fourth as: <Feature Name="Growth form"><Value>shrub</Value></Feature> Are these equivalent? There's certainly no obvious way to associate them, aside from knowing that "bush" and "shrub" mean pretty much the same thing in some dialects of English. I think the goal of trying to extract meaning by inserting a few tags into existing textual descriptions relies too heavily on a level of artificial intelligence that we're still unlikely to see for a couple of decades. But pondering on this made me think about why Kevin and I often disagree on some of these issues. If I may greatly over-simplify our viewpoints, his view is (I think) that a formal description ought to be a document from which data can be extracted; whereas I tend of view a formal description more as a database from which text can be generated. So what ARE we after: the free-flowing flexibility of a document, or the rigour and precision of a database? Fortunately, there is a fair bit of middle ground. It's worth noting that XML was developed as a markup language for documents, but that it's primary usage to date has been as a sort of portable and relatively light-weight data container. Still I think that finding the right balance between flexibility and rigour is going to be a major challenge in this exercise. >Features are nested: > ><Feature><Name>Leaves</Name> > <Feature><Name>Shape</Name></Feature> ></Feature> > >Is this allowable? In XML-Spy I can create a Schema OK for this document. >It's also well-formed. It's certainly allowable in XML. Is it desirable in a description? Possibly, but I think it relates to my question from yesterday about hierarchies of characters ought to be expressed. Nesting is a very good way to express a single hierarchy, but not for handling alternative hierarchies. Which do people want? Eric Zurcher CSIRO Livestock Industries Canberra, ACT Australia E-mail: Eric.Zurcher(a)pi.csiro.au

1 0

Re: Taxonomic hierarchy in SDD
by Eric Zurcher 29 Nov '01

29 Nov '01

At 12:38 PM 28-11-01 +1100, Kevin Thiele wrote: >Concerning Steve's exemplar drawn from a DELTA butterfly treatment: I've >added a few challenges to the challenge cases (number 9 in the attached) >specifically designed to address representation of DELTA datasets in the new >standard. Personally, I don't think we should start with a DELTA data set as >our first challenge, for several reasons: > >1. We have agreed several times that it's important not to be canalized by >DELTA or any other existing representation, but to keep the existing >representations in mind while working. Starting with XDELTA seems to me to >increase the risk of canalization While canalization is a risk, there certainly is also merit in trying to retain the best features of "prior art". The DELTA format has persisted for over 20 years, which is nearly an eternity in the IT field. It must have been doing one or two things right. There's no need to follow it too closely, but certainly we can learn quite a bit from DELTA about what works well and what doesn't. >2. Of all the descriptions in the world, 99.9999999% of them are not in >DELTA. Probably 99.999% of them are textual (natural language) descriptions. >Surely this should form the basis of our first challenge, methinks. I think that's actually a rather harsh assessment of DELTA's uptake. Let's say there are about 4x10^6 known species. We'd like descriptions for them all, along with descriptions of higher taxonomic levels (genera, families). So the magnitude of total number of descriptions is about 10^7. I'd guess that the number of taxa with DELTA descriptions is of the magnitude of 10^5. So that means roughly 1% of all taxa already have a DELTA description. >3. Related to 2 above, many (though by no means all) DELTA datasets are >already abstractions from the source (a set of natural language >descriptions). We should start with the source. The source? Surely the ultimate source is observations made on individual specimens. If we wish to start with the source, the first thing that needs to be done is to make sure that we have a system which can adequately describe a specimen in hand. (Sorry if I get too defensive about DELTA. I just can't help myself...) Eric Zurcher CSIRO Livestock Industries Canberra, ACT Australia E-mail: Eric.Zurcher(a)pi.csiro.au

1 0

Challenge Case 1
by Barringer, Kerry 28 Nov '01

28 Nov '01

Attached are the files for a partial solution to the first Challenge case. I have deliberately left out the XSLT code that capitalizes the first letter in a sentence and eliminates the comma before the period. The stuff I have written is awkward and embarassing and I will try to come up with a more elegant way that can be used for general formatting of the nodes. This DTD corrects some of the typos in the DTD posted yesterday. The XML file should validate against this DTD. I commented out the DOCTYPE line in the XML because the Xalan parser is fussy about how the file location is cited and I wanted one file to test with all the parsers. The XSLT code runs correctly using Microsoft, Sablotron, Saxon, and Xalan parsers in XMLCooktop. The resulting html file is also attached. I had to do this because the code does not run properly under MS Internet Explorer 5.5. This could be a namespace problem. I will look into it. Unfortunately, I did this coding before I saw Kevin Thiele's Nov 27 posting. That posting contains some good ideas about markup that I want to incorporate in this DTD. I especially like his handling of 'shrub' as a character state, not a name. Like Kevin, I nest characters. There are many small differences in the two approaches. The most notable is the handling of numeric characters and ranges. My approach may be too simple for anything but natural language output. As a side challenge, I would like to try to develop code that would produce a tabular description from this markup. The table should have blank cells for missing data. This will help determine if it is necessary to code missing characters as part of the description, or if we can get by with only coding the character we know. I think the later approach is most practical. This will also help determine if nested characters can be used. 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

Challenge 1
by Kevin Thiele 28 Nov '01

28 Nov '01

Here's my first go at representing Challenge 1. The challenge: Rigid, spreading shrub to c. 1m high and wide; stems glabrous. Leaves soon deciduous (particularly on older plants), +/- oblong, (4-)6-10(-15) mm long, 2-3 mm wide, apex obtuse or minutely mucronate within an apical notch, glabrous or a few hairs present near tip; stipules dark reddish-brown, c. 1 mm long, often shallowly joined around the node; spines stout, 1.5-4 cm long. Discaria nitida Slender shrub, to 5 m high; stems glabrous. Leaves persistent (rarely deciduous), elliptic to obovate, (8-)10-20(-30) mm long, 3-7 mm wide, glabrous, shining; spines not developed at each node, to c. 1 cm long. The representation: <Document> <Description Name="Discaria pubescens"> <Feature Name="Habit">Rigid, spreading <Feature Name="Life form"><Value>shrub</Value></Feature><Feature Name="Height"> to c. <Value MinValue="0"/><MaxValue>1</MaxValue><Units>m</Units> high and wide</Feature></Feature>; <Feature Name="Stem indumentum">stems <Value>glabrous</Value></Feature>. <Feature><Name>Leaves</Name><Feature Name="Longevity">soon <Value>deciduous</Value>(particularly on older plants)</Feature>, <Feature Name="Shape">+/- <Value>oblong</Value></Feature>, <Feature Name="Length">(<OutMinValue>4</OutMinValue>-)<MinValue>6</MinValue>-<MaxValu e>10</MaxValue>(-<OutMaxValue>15</OutMaxValue>)<Units> mm</Units> long</Feature>, <Feature Name="Width"><MinValue>2</MinValue>-<MaxValue>3</MaxValue><Units> mm</Units> wide</Feature>, <Feature Name="Apex shape"><Value>obtuse</Value> or minutely <Value>mucronate within an apical notch</Value></Feature>, <Feature Name="indumentum" Value="hairy">surfaces <Value>glabrous</Value> or a few hairs present near tip</Feature>;<Feature><Name>stipules</Name><Feature Name="Colour"><Value Value="Brown"/><Value Value="Red"/>dark reddish-brown</Feature>, c. 1 mm long, <Feature Name="Arrangement">often shallowly <Value>joined around the node</Value></Feature></Feature></Feature> <Feature><Name> spines</Name><Feature Name="Robustness"><Value>stout</Value></Feature>, <Feature Name="Length"><MinValue>1.5</MinValue>-<MaxValue>4</MaxValue><Units>cm</Unit s> long</Feature></Feature>. </Description> <Description Name="Discaria nitida"> <Feature Name="Habit">Slender <Feature Name="Life form"><Value>shrub</Value></Feature><Feature Name="Height"> to <Value MinValue="0"/><MaxValue>5</MaxValue><Units>m</Units>hig</Feature></Feature>; <Feature Name="Stem indumentum">stems <Value>glabrous</Value></Feature>. <Feature><Name>Leaves</Name><Feature Name="Longevity"><Value>persistent</Value>(rarely<Value Qualifier="rarely">deciduous</Value>)</Feature>, <Feature Name="Shape"><Value>elliptic</Value> to <Value>obovate</Value></Feature>, <Feature Name="Length">(<OutMinValue>8</OutMinValue>-)<MinValue>10</MinValue>-<MaxVal ue>20</MaxValue>(-<OutMaxValue>30</OutMaxValue>)<Units> mm</Units> long</Feature>, <Feature Name="Width"><MinValue>3</MinValue>-<MaxValue>7</MaxValue><Units> mm</Units> wide</Feature>, <Feature Name="indumentum" ><Value>glabrous</Value></Feature> shining; </Feature><Feature><Name>spines</Name>, not developing at each node, <Feature Name="Length" MinValue="0">to c. <MaxValue>1</MaxValue><Units>cm</Units> long</Feature></Feature> </Description> </Document> or, if you prefer <Document> <Description Name="Discaria pubescens"> <Feature Name="Habit">Rigid, spreading <Feature Name="Life form"><Value>shrub</Value></Feature> <Feature Name="Height"> to c. <Value MinValue="0"/><MaxValue>1</MaxValue><Units>m</Units> high and wide</Feature> </Feature>; <Feature Name="Stem indumentum">stems <Value>glabrous</Value></Feature>. <Feature><Name>Leaves</Name> <Feature Name="Longevity">soon <Value>deciduous</Value>(particularly on older plants)</Feature>, <Feature Name="Shape">+/- <Value>oblong</Value></Feature>, <Feature Name="Length">(<OutMinValue>4</OutMinValue>-)<MinValue>6</MinValue>-<MaxValu e>10</MaxValue>(-<OutMaxValue>15</OutMaxValue>)<Units> mm</Units> long</Feature>, <Feature Name="Width"><MinValue>2</MinValue>-<MaxValue>3</MaxValue><Units> mm</Units> wide</Feature>, <Feature Name="Apex shape"><Value>obtuse</Value> or minutely <Value>mucronate within an apical notch</Value></Feature>, <Feature Name="indumentum" Value="hairy">surfaces <Value>glabrous</Value> or a few hairs present near tip</Feature>; <Feature><Name>stipules</Name> <Feature Name="Colour"><Value Value="Brown"/><Value Value="Red"/>dark reddish-brown</Feature>, c. 1 mm long, <Feature Name="Arrangement">often shallowly <Value>joined around the node</Value></Feature> </Feature> </Feature> <Feature><Name> spines</Name> <Feature Name="Robustness"><Value>stout</Value></Feature>, <Feature Name="Length"><MinValue>1.5</MinValue>-<MaxValue>4</MaxValue><Units>cm</Unit s> long</Feature> </Feature>. </Description> <Description Name="Discaria nitida"> <Feature Name="Habit">Slender <Feature Name="Life form"><Value>shrub</Value></Feature> <Feature Name="Height"> to <Value MinValue="0"/><MaxValue>5</MaxValue><Units>m</Units>high</Feature> </Feature>; <Feature Name="Stem indumentum">stems <Value>glabrous</Value></Feature>. <Feature><Name>Leaves</Name> <Feature Name="Longevity"><Value>persistent</Value>(rarely<Value Qualifier="rarely">deciduous</Value>)</Feature>, <Feature Name="Shape"><Value>elliptic</Value> to <Value>obovate</Value></Feature>, <Feature Name="Length">(<OutMinValue>8</OutMinValue>-)<MinValue>10</MinValue>-<MaxVal ue>20</MaxValue>(-<OutMaxValue>30</OutMaxValue>)<Units> mm</Units> long</Feature>, <Feature Name="Width"><MinValue>3</MinValue>-<MaxValue>7</MaxValue><Units> mm</Units> wide</Feature>, <Feature Name="indumentum" ><Value>glabrous</Value></Feature> shining; </Feature> <Feature><Name>spines</Name>, not developing at each node, <Feature Name="Length" MinValue="0">to c. <MaxValue>1</MaxValue><Units>cm</Units> long</Feature> </Feature> </Description> </Document> Issues I've taken the route of marking up a textual description, using a minimum of tags. It seems to me that a description comprises a series of features with values. I've used mixed markup because I wanted to have the mimimum tagging and make maximum use of the text. That is, in cases like: <Feature Name="Life form"><Value>shrub</Value></Feature> I've made use of the fact that "shrub" occurs in the text by enclosing it in <Value> tags. In cases like: <Feature><Name>Leaves</Name> I'm using a <Name> tag rather than a Name attribute This may make processing considerably more difficult, but it seems to me that there are some advantages. An alternative would be to first process the description into a DELTA-like structure then mark up that. I chose not to go that route because I still have the dream that one day we'll have a method of semi-automatically marking up the content of natural language into something like the above. The other advantage of this structure I believe is that it maintains all the complexity and nuance of the original natural language (which can be retrieved merely by removing all the tags). I prefer this to the DELTA-process (take a natural-language description -> atomise it -> reconstruct semi-natural-language by putting the atoms back together again in some fashion). Features are nested: <Feature><Name>Leaves</Name> <Feature><Name>Shape</Name></Feature> </Feature> Is this allowable? In XML-Spy I can create a Schema OK for this document. It's also well-formed. In this example, there is not a 1:1 correspondence between the descriptions - e.g. the description for D. pubescens has <Feature Name="Apex shape"> while that for D. nitida does not. This is anathema to most of us, but is a real world case. We'll have to deal with it. In this example there is no character list against which character names etc can be validated (to e.g. pick up the above problem). This is something we need to deal with. Be gentle with me. Your mission, should you choose to accept it, is to show that I'm crazy and do better than this. This email will self-destruct in 5 seconds Cheers - k

1 0