head 1.7; access; symbols; locks; strict; comment @# @; 1.7 date 2009.11.25.03.14.38; author GarryJolleyRogers; state Exp; branches; next 1.6; 1.6 date 2009.11.20.02.45.31; author LeeBelbin; state Exp; branches; next 1.5; 1.5 date 2007.03.06.17.30.00; author TWikiGuest; state Exp; branches; next 1.4; 1.4 date 2006.04.25.08.30.15; author GregorHagedorn; state Exp; branches; next 1.3; 1.3 date 2003.11.17.15.08.18; author BobMorris; state Exp; branches; next 1.2; 1.2 date 2003.11.14.12.21.00; author GregorHagedorn; state Exp; branches; next 1.1; 1.1 date 2003.11.13.17.30.46; author BobMorris; state Exp; branches; next ; desc @none @ 1.7 log @none @ text @%META:TOPICINFO{author="GarryJolleyRogers" date="1259118878" format="1.1" version="1.7"}% %META:TOPICPARENT{name="StoredIdentificationKeys"}% ---+!! %TOPIC% Identification keys provide an explicit Reticulation element pointing into any node in the same or other stored identification keys. Indirectly, identification keys are thus Directed Acyclic Graphs. These reticulations within a key are occasionally used in conventional keys in biology to either provide for abnormal individuals, or to catch known misinterpretations by the user and lead them back to the main track. The Reticulation element is different from the Subkey element, pointing to entire identification keys. These should not be used to create cycles, although this requires external (non-w3c xml-schema) validation. The main cost is that machine traversal will require cycle detection. This is not very deep- cycle detection algorithms are in most algorithm texts-but it is a bit of a nuisance and in any case, should be clearly signalled in the annotation.
Example:
A1
B1
B2
C1
C2
A2
D1
D2
E1
E2
The KeyNode element provides for reticulations between arbitrary nodes of keys (rather than only pointers between entire subkeys as in the Subkey element). These reticulations within a key are occasionally used in conventional keys in biology to either provide for abnormal individuals, or to catch known misinterpretations by the user and lead them back to the main track.
A potential problem with the proposal is that hte current solution provides for arbitrary directed graphs and is not restricted to acyclical directed graphs. In theory it is possible when traversing the tree of the guided key to run in a loop.
Example:
A1
B1
B2
C1
C2
A2
D1
D2
E1
E2
If at question A a user trying to identify a atypical individual goes to A1 although most individual would be under A2, this problem can be caught later on, e.g. by pointing from C2 back to the A2 node. Similarly, if many such reticulations are build into the tree, it would be possible to catch another case at E2 and lead back to A1. This would then no longer be directed acyclical graph. In biology this would probably not be a problem, since the following question would be answered differently, so that a true cyclical behaviour is unlikely, at least in a well designed key.
What do we gain, if we restrict guided keys to acyclical graphs? Main.GregorHagedorn - 14 Nov 2003 The main cost is that machine traversal will require cycle detection. This is not very deep- cycle detection algorithms are in most algorithm texts-but it is a bit of a nuisance and in any case, should be clearly signalled in the annotation. d5 21 @ 1.2 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="GregorHagedorn" date="1068812460" format="1.0" version="1.2"}% d30 3 @ 1.1 log @none @ text @d1 1 a1 1 %META:TOPICINFO{author="BobMorris" date="1068744646" format="1.0" version="1.1"}% d9 21 @