Kerry wrote:

First, I am stuck trying to adequately model the structure and dependencies of the leaf apex characters "apex obtuse or minutely mucronate within an apical notch". I am parsing this out as: Apex shape obtuse notched Apex projection immucronate mucronate within notch (dependent on 'Apex shape - notched') The model has an attribute for 'dependent on' under the character element. Does the proper solution of this problem require a 'dependent on' attribute as part of the //character/state element as well? Am I parsing the data correctly?

Maybe... but is there a correct answer to this in the absence of context? Without knowing what the other taxa in the application are, you could get away with:

Apex shape obtuse minutely mucronate in an apical notch Or even, trivially: Apex shape obtuse or minutely mucronate in an apical notch

It maybe that there are only two character states in this group of taxa - the bluntish ones with obtuse/mucronate tips and the sharp ones with acute/attenuate tips. In this case building a line of dependency might not only be unnecessary, but might it also be misleading?

But I do not this that was the real issue, was it? The challenge was, if you had a dependency, how would you deal with it...

The first problem led me to the second problem, which is: how do we identify the character or state another character depends on? This is not a problem when working with DELTA format data which has unique identifiers already, but text descriptions do not. Is an Xpath description adequate or do we need to be able to have a structure that allows us to uniquely identify what a character state describes?

Is there any harm in requiring a unique id for each node? Most descritpive applications probably do this already to manage their data matrices. DELTA lets you see them which is considered mabye useful, Lucid doesn't which is considered healthy... :)

    I originally thought a  unique identifier was needed to identify

missing data not explicitly encoded in the description and to provide a pointer to characters or states that are other characters of states depend on. Now that I see how complex this may be to implement, I'm wondering if another way would be better.

Is our structure/Schema/DTD is right, it would be nice to think that it was self referenceing and that we did not have to worry about internal ids and pointers, wouldn't it...

Thinking further about Kevin's two types of dependency, context and content (or whatever the terminology was), isn't the former an artifact of the character set we have decided to use and the latter an artifact of the taxa we are covering? The former is just not possible, the latter might be possible but is just not there. If this really is the case and one sort of dependency arises from the character state and another arises from the taxa being considered, then it is very likely that they should be modelled in slightly or completely different ways.

    I originally included an attribute called 'describes' under the

//character/state element. I thought that this could be used for two purposes: (1) to add descriptive text to the character state and (2) to help build a unique identifier for a character state. The first use is no problem; this structure allows an author to easily add "high' to the value for the character state describing height for example. The structure is less useful for building an identifier for what the character state describes.

//character/state is not always going to be unique is it? The tip mucronate, obtuse, acute condition could exist in scales, bracts, leaves, petals, sepals, anthers, etc. A more complete path is going to have to be specified which could get pretty nasty... but hey, computers are good at nasty...

    I thought I could build a unique identifier by combining the

character name and the 'describes' attribute. So for

    <Character>
            <CharName>Leaf</Charname>
            <State describes="PlaneShape" modifier="+/-">oblong</State>
    </Character>

The identifier 'LeafPlaneShape' identifies what the state describes. This allows you to recognize that even when there are multiple states (ie. 'ovate', 'round', etc.) they are all describing one aspect of the leaf. If nested characters are recognized, the identifier must get longer. 'ApexShape' or 'ApexProjection' wouldn't work, it would have to be 'LeafApexShape' or 'LeafApexProjection'. If the nesting gets deep, this gets awkward pretty fast. It would work, though.

but not very elegantly... Dependency is the act of a state/value controlling the applicability or otherwise of a character/feature or as Kevin has pointed out a taxon controlling a character feature (in the identification process this get s bit circular as you have to hav an idea what a taxon is before you can decide if a character is inapplicable, but such knowledge can be built into the data in various ways). Thus the model will have to accommodate that a certain character/feature is unavailable if a certain state/value exists, perhaps in a totally different branch of the character/feature tree - and the obligate reciprocal relationship between controlling state/values and controlled characters/feataures. Unique ids, even arbitrary sequential numeric ones a la DELTA, might be the best (or an adequate) way to do this.

How about:

<feature id="123"> <feateName>leaf</featureName> <character id="6" nullcharacter="3" nullstate="4"> <characterName>leaf shape</characterName> <state modifier="+/-" value="present">oblong</State> <state value="rarely">ovate</State> <state value="rarely">obovate</State> </character> </feature>

... just doodling... maybe this needs to be specified in a separate characterlist up front, rather than in the guts of the descriptive data.

Actually we have not even decided that yet have we? Should the list of characters/states and the lists of taxa be described as separate blocks, or should they be implied from the content and structure of the standard data file. I prefer the former and both DELTA and Lucid do this... but have we decided that this is the way to go?

    Do others think that having an identifier is necessary and, if so,

has anyone been able to come up with a better way to handle it? Is Xpath adequate to our needs?

I always have problems with Xpath - it is supposed to work, but I always manage to get lost in the hierarchy... need more practice... :)

jim