
----- Original Message ----- From: "Steve Shattuck" <Steve.Shattuck@CSIRO.AU> To: <TDWG-SDD@USOBI.ORG> Sent: Tuesday, December 04, 2001 11:31 AM Subject: It's How the Data will be Used that Counts | A couple of points: | | Kevin suggests a rule "<states>s cannot have <characters>s as siblings". | But this is what DELTA calls Dependencies, it represents the state that | controls a character. This would seem to be a good thing (and may be very | important). 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. 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. In dependencies, there may be several controlling states for a character, and these may or may not occur on nodes antecedent to the node in question. An example (from a key of mine): the character: Trap structures (on carnivorous plants) submerged or underground bladder-traps pitcher-traps sticky hairs irritable leaf-blade segments has controlling states in several other characters, viz: Nutritional strategy carnivorous parasitic* neither carnivorous nor parasitic* Habit tree* shrub* terrestrial herb aquatic herb 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. 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. Cheers - k