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.
