Expression of continuing interest

[Bryan Heidorn]

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