In my humble opinion, as many people have stated in this group, we need to put the actual content issues aside to establish the standard. In the end we only really care about sharing the content. The structure is just a means to enable sharing of content. The point that I was trying to make about "ovate" is not that the actual word "ovate" needs to be in the standard but that the descriptive mechanisms of the standard should allow data types such as "ovate" to exist as content and that the structure of the standard should be able to encode information about the content to allow people or computer programs to make decisions about the use of the content.

The particular XML-like syntax is only as means of how that kind of information could be encoded in the structure.

Maybe if I ground this in Kevin's document I'll have a little better luck trying to communicate.

------------------------------------- Character List {required unless an external lexicon resource has been specified above} [ Character Name3 Character ID Set membership {list of sets to which the character belongs; a character must be able to belong to more than one set} Attribution1 {reference to a contributor�s ID from the Contributors list} Source1 (reference to a source�s ID from the Sources list) Collated Character source {path name for another treatment that contains lower-level data for this character} Collation rule name {Name of a collation rule as defined in the Collation Rules list}2 Character type {ordered multistate, unordered multistate etc} Character dependencies (up) 4 Applies To list (or global/restricted type definition, then leave it to program to extract) 5 Character attachments [ attachment name attachment type attachment path/URL Public notes7 Private notes7 ] Private notes {internal notes for character}7 Character State List [ Character state name | Character state ID Character dependencies (down) Character state attachments . . . --------------- The authors of an Angiosperm treatment standard might want to use the document created by this group (BioSDD?) as a guideline for making their treatment definition. As part of their definition may wish to create a Character Name = "Leaf Shape", with a Character dependency of "Leaves". They will need to provide a Character State list for this Character. These states could take many forms. The BioSDD should provide guidance on this form. There should be a range of options of data types and processing to choose from (along of course with the options of using something not included in the BioSDD). I am arguing that the BioSDD should include data types and type qualifiers that are different from and addition to the "Character type" in Kevin's document

"Character type {ordered multistate, unordered multistate etc} "

So you might say that a particular character like "leaf shape" in the Angiosperm might have Character States that are assigned by "text", "collation rule" or "Fourier descriptor". The Angiosperm standard authors might further specify that vocabulary for character states of the text based state descriptions. They might include "ovate", "oblong" and "round" in that list. (This list would not be included in the BioSDD. The BioSDD would just say that if you have a unordered unistate text field that you can provide a list to the authors or leave the state values open to any text.) An author of a treatment then might decide by ungrounded opinion that the leaves of the Waga oni plant are "ovate". The author would record "ovate" and that it is of type "text" so that not computer program will read it and try to treat it like a Fourier descriptor.

I am sorry that I am having difficulty making this clear.

I might be way off base. There seem to be two issues related to this problem. Should we allow a standard that flags these kinds of data and how can we represent this type of functionality in the structure of the BioSDD guidelines so that Angiosperm standard authors can easily use them.

now I need to get some work done.

Bryan