It's How the Data will be Used that Counts

Jim Croft jrc at ANBG.GOV.AU
Wed Dec 5 08:08:27 CET 2001

> 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...


More information about the tdwg-content mailing list