No, this is not equivalent to dependencies, although at first sight it seems similar. It's a tree-topology rule: the rule "<states>s can have <characters>s as siblings" allows certain topologies for the data-representation trees that would be preluded by the rule "<states>s cannot have <characters>s as siblings". As I said, I don't know whether the rule's a good or necessary one or not.
But it is important that we sort it out... Dependency can be expressed in ways other than allowing the ultimate state to be a parent of a character, can't it? This would seem to be very messy and recursive and would probably break the clean hierarchical representation of data we seemed to be aiming towards.
Dependencies establish relationship rules between different parts of the tree. Sometimes these rules affect parent-sibling relationships as in the example, but sometimes not - that is, dependencies are more complex than can be handled by a topology rule.
I tend to agree with this...
In the key, if a user chooses a state marked * the character "Trap Structures" will disappear because of the dependencies. Note that the dependency on tree and shrub is not a logical one but a contextual one - it just happens that no trees or shrubs are carnivorous, so the dependency's useful but not logically necessary.
Well, this is important, isn't it? I think we have just established that our model must accomodate two kinds of dependency one based on logic andaracter tree topology, an the other based on content/context. In the former a character can not be present because to parent feature/character/organ is absent; in the latter it could conceivalbly be present, but just isn't. Up till now applications have just allowed scoring dependencies without making this distinction.
I don't think these dependency relationships can be expressed merely by the topology of the tree, as you suggest. We will need to deal with dependency rules as a separate issue.
I agree with this. We need to bear it in mind, but let's try and nail down a basic descriptive framework first...
jim