(RQT) Character Dependency rules

[Gregor Hagedorn]

> You've probably considered these already,

No, I think this is a new idea... :-)

> example 1.  Say you want to allow a more or less accurate state for a
> "time of year" character.  In that case the month would be dependent on a
> year, and the day would be dependent on the month.
>
> example 2.  You want your user to be able to choose more or less accurate
> geographical locations.
>
> Whether these examples would ever really occur is a question, but I'm not
> sure we need to proscribe the use of state dependencies.

OK, what I see here is the question to introduce an implicit "data
present" dependency. Only if a character is used in an item, be it
with categorical states, numerical measurements, or text, other
characters would become visible.

I think this would be useful. For numerical chars there would be a
work-around (see below, mapping from -1e308 to +1e308 or whatever is
the computers idea of inifinity...), but this would not work for
text. It could also help eliminating some "data present" characters
that are occasionally found in Delta data sets just to define a
dependency.

What do the DELTA cracks think about this?

The symbol to define such dependencies could be the "*" used commonly
for "any value".

---
For the sake of completeness: If other states shall depend on certain
values, this is not a problem, since one would define a character
state mapping (DELTA: KEYSTATES) say:
  Char 1: Seed size, length (numeric) [µm]
  Char 2: Seed size, class
   state 1: Char1 < 2 mm
   state 1: Char1 >= 2 mm
Some characters that can only be observed in larger seeds could then
be made dependent on 2,2

Gregor
----------------------------------------------------------
Gregor Hagedorn                 G.Hagedorn at bba.de
Institute for Plant Virology, Microbiology, and Biosafety
Federal Research Center for Agriculture and Forestry (BBA)
Koenigin-Luise-Str. 19          Tel: +49-30-8304-2220
14195 Berlin, Germany           Fax: +49-30-8304-2203

Often wrong but never in doubt!