wiki-archive/twiki/data/SDD/Primer/SddDependencies.txt,v

head	1.11;
access;
symbols;
locks; strict;


1.11
date	2007.07.27.13.08.52;	author HeleneFradin;	state Exp;
branches;
next	1.10;

1.10
date	2007.07.27.11.03.15;	author HeleneFradin;	state Exp;
branches;
next	1.9;

1.9
date	2007.05.07.14.41.26;	author GregorHagedorn;	state Exp;
branches;
next	1.8;

1.8
date	2006.09.07.01.57.41;	author DonovanSharp;	state Exp;
branches;
next	1.7;

1.7
date	2006.08.30.01.47.27;	author DonovanSharp;	state Exp;
branches;
next	1.6;

1.6
date	2006.07.20.01.40.57;	author DonovanSharp;	state Exp;
branches;
next	1.5;

1.5
date	2006.07.06.05.54.36;	author DonovanSharp;	state Exp;
branches;
next	1.4;

1.4
date	2006.07.05.04.46.13;	author DonovanSharp;	state Exp;
branches;
next	1.3;

1.3
date	2006.06.07.04.52.25;	author DonovanSharp;	state Exp;
branches;
next	1.2;

1.2
date	2006.06.02.07.38.36;	author DonovanSharp;	state Exp;
branches;
next	1.1;

1.1
date	2006.06.01.06.08.35;	author DonovanSharp;	state Exp;
branches;
next	;


desc
@@


1.11
log
@none
@
text
@%META:TOPICINFO{author="HeleneFradin" date="1185541732" format="1.1" version="1.11"}%
%META:TOPICPARENT{name="SddContents"}%
---++SDD Part 0: Introduction and Primer to the SDD Standard 

---+++3.11 Dependencies in SDD
  
Dependencies are logical relationships between characters such that a state of one character controls the presence (or absence) of another feature in interactive keys.

Consider, for example, the following features:

%ATTACHURL%/depend.jpg
 
Wing colour and Wing shape only have meaning when wings are present – if wings are absent, they are logically inappropriate in the key. Relationships of this kind are generally accomodated within interactive identification applications by the use of dependencies. For the above example a negative dependency may be set such that if a user chooses the state Wings: absent, then the characters Wing Colour and Wing Shape will be removed from characters Available. Alternatively, some applications allow a positive dependency to be set so for example Wing Colour and Wing Shape are initially hidden and only appear if a user chooses the state Wings: present. Dependencies can help to keep the character list cleaner and less cluttered, and help make some features work better.

In SDD dependencies are defined by <DependencyRules> within the <CharacterTree> element.

A simple SDD code instance representing dependency definition has the basic structure shown below and in Example 3.11.1.

%ATTACHURL%/chartreenodeseq.gif

---++++Example 3.11.1 - Negative dependencies in SDD.

<table bgcolor="#ddddff" border="0" width="100%" cellpadding="5" cellspacing="5" style="border-collapse: collapse" bordercolor="#111111">

<tr>
<td>
  
<verbatim>
        <Nodes>
          <CharNode>
            <DependencyRules>
              <InapplicableIf>
                <State ref="s13"/>
              </InapplicableIf>
            </DependencyRules>
            <Character ref="c1"/>
          </CharNode>
          <CharNode>
            <DependencyRules>
              <InapplicableIf>
                <State ref="s4"/>
                <State ref="s13"/>
              </InapplicableIf>
            </DependencyRules>
            <Character ref="c2"/>
          </CharNode>

		  ... etc.
		  
        </Nodes> 
</verbatim>
	
</td>
</tr>

</table>

Positive dependencies are expressed in the same fashion with the &lt;InapplicableIf&gt; tag. Applicable-If and Inapplicable-If statements are in principle convertible, but 

---+++Discussion

It is currently unknown how applications which enforce referential integrity between scored data and dependencies will manage data imported from applications which do not enforce referential integrity. -- Main.DonovanSharp - 01 Jun 2006

Does Lucid have problems with this? <nop>DeltaAccess/DiversityDescriptions does maintain referential integrity between applicability rules and terminology, and between terminology and data, but not between applicability rules and data. The main reason for not doing this is that it would prevent creating a desirable applicability rule before all violating data (which may be hundreds) have been removed first. Instead, DiversityDescriptions allows violation of dependency rules, but warns the user, enabling him or her to fix the violations as time goes by. It is thus an application-level integrity, not a database-level one. -- Main.GregorHagedorn, 2007-05-07.

As a use case example, the XPer2 software deals with character dependencies using an inapplicability rules and a set of exclusion modes. However, the displaying in the identification interface relates more to the positive approach: characters are displayed to the user only once a mode or several modes (distinct from the exclusion(s) mode(s)) has(have) been selected. -- Main.HeleneFradin - 27 Jul 2007

As SDD dependencies are defined in a &lt;CharacterTree&gt; element, I think I would need an example that includes a character hierarchy to understand better if the character under the rule of applicability has to be hierarchically dependent from the character that displays the &lt;InapplicableIf&gt; state (my understanding is that it is not necessary) and to distinguish clearly the character that is attached to the &lt;CharNode&gt; element and the potential parent character. I tried to build an example from the schema above about Wings characters. Is it correct ?

<table bgcolor="#ddddff" border="0" width="100%" cellpadding="5" cellspacing="5" style="border-collapse: collapse" bordercolor="#111111">

<tr>
<td>
  
<verbatim>
        <Characters>
          <CategoricalCharacter id="c1">
            <Representation>
              <Label>Presence</Label>
            </Representation>
            <States>
              <StateDefinition id="s1">
                <Representation>
                  <Label>present</Label>
                </Representation>
              </StateDefinition>
              <StateDefinition id="s2">
                <Representation>
                  <Label>absent</Label>
                </Representation>
              </StateDefinition>
            </States>
          <CategoricalCharacter id="c2">
            <Representation>
              <Label>Colour</Label>
            </Representation>
            <States>
              <StateDefinition id="s3">
                <Representation>
                  <Label>blue</Label>
                </Representation>
              </StateDefinition>
              <StateDefinition id="s4">
                <Representation>
                  <Label>yellow</Label>
                </Representation>
              </StateDefinition>
            </States>

        ...

        </Characters>

        <DescriptiveConcepts>
          <DescriptiveConcept id="dc1">
            <Representation>
              <Label>Wings</Label>
            </Representation>
      	  </DescriptiveConcept>
        </DescriptiveConcepts>

        ... etc (for more detail see the topic <DescriptiveConcepts>)

        <CharacterTrees>
	  <CharacterTree id="ct1">
            <Representation>
              <Label>Default Feature Tree</Label>
            </Representation>
            <DesignedFor>
              <Role>InteractiveIdentification</Role>
	    </DesignedFor>
            <Nodes>
              <Node id="cn1">
                <DescriptiveConcept ref="dc1"/>
              </Node>
              <CharNode>
	        <Parent ref="cn1"/>
            	<Character ref="c1"/>
	      </CharNode>
              <CharNode>
	        <DependencyRules>
                  <InapplicableIf>
                    <State ref="s2"/>
    	          </InapplicableIf>
         	</DependencyRules>
                <Parent ref="cn1"/>
            	<Character ref="c2"/>
              </CharNode>

        ...

            </Nodes>
          </CharacterTree>
        </CharacterTrees>
</verbatim>
	
</td>
</tr>

</table>
-- Main.HeleneFradin - 27 Jul 2007

%META:FILEATTACHMENT{name="chartreenodeseq.gif" attr="" autoattached="1" comment="" date="1157594120" path="chartreenodeseq.gif" size="9635" user="Main.DonovanSharp" version="2"}%
%META:FILEATTACHMENT{name="depend.jpg" attr="" autoattached="1" comment="" date="1149233772" path="depend.jpg" size="9363" user="Main.DonovanSharp" version="1"}%
@


1.10
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="HeleneFradin" date="1185534195" format="1.1" version="1.10"}%
d68 95
@


1.9
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1178548886" format="1.1" version="1.9"}%
d66 2
@


1.8
log
@@
text
@d1 1
a1 1
%META:TOPICINFO{author="DonovanSharp" date="1157594261" format="1.1" reprev="1.8" version="1.8"}%
d58 1
a58 1
Positive dependencies are expressed in the same fashion with the &lt;InapplicableIf&gt; tag
d60 1
a60 1
It is currently unknown how applications which enforce referential integrity between scored data and dependencies will manage data imported from applications which do not enforce referential integrity.
d62 1
d64 1
a64 3


-- Main.DonovanSharp - 01 Jun 2006
@


1.7
log
@@
text
@d1 1
a1 1
%META:TOPICINFO{author="DonovanSharp" date="1156902447" format="1.1" version="1.7"}%
d29 22
a50 13
          <Node id="cn3">
            <Parent ref="cn1"/>
            <InheritableDefinitions>
              <DependencyRules>
                <OnlyApplicableIf>
                  <State ref="s1"/>
                </OnlyApplicableIf>
              </DependencyRules>
            </InheritableDefinitions>
          </Node>
          <Char ref="c2">
            <Parent ref="cn3"/>
          </Char>
d67 1
a67 1
%META:FILEATTACHMENT{name="chartreenodeseq.gif" attr="" autoattached="1" comment="" date="1153359447" path="chartreenodeseq.gif" size="11536" user="Main.DonovanSharp" version="1"}%
@


1.6
log
@@
text
@d1 1
a1 1
%META:TOPICINFO{author="DonovanSharp" date="1153359657" format="1.1" reprev="1.6" version="1.6"}%
d5 1
a5 1
---+++3.10 Dependencies in SDD
d17 1
a17 1
A simple SDD code instance representing dependency definition has the basic structure shown below and in Example 3.10.1.
d21 1
a21 1
---++++Example 3.10.1 - Negative dependencies in SDD.
@


1.5
log
@@
text
@d1 1
a1 1
%META:TOPICINFO{author="DonovanSharp" date="1152165276" format="1.1" version="1.5"}%
d15 1
a15 1
In SDD dependencies are defined by &lt;DependencyRules&gt; within the &lt'CharacterTree&gt; element.
d17 1
a17 1
%ATTACHURL%/chartreenodeseq.jpg
d19 2
d58 1
a58 1
%META:FILEATTACHMENT{name="chartreenodeseq.jpg" attr="" autoattached="1" comment="" date="1152074683" path="chartreenodeseq.jpg" size="26281" user="Main.DonovanSharp" version="3"}%
@


1.4
log
@@
text
@d1 1
a1 1
%META:TOPICINFO{author="DonovanSharp" date="1152074773" format="1.1" reprev="1.4" version="1.4"}%
d21 5
a25 1
    
d42 4
@


1.3
log
@@
text
@d1 1
a1 1
%META:TOPICINFO{author="DonovanSharp" date="1149655945" format="1.1" reprev="1.3" version="1.3"}%
d15 1
a15 1
In SDD dependencies are defined by DependencyRules within the CharacterTree element.
d41 1
a41 1
It is currently unknown how applications which anforce referential integrity between scored data and dependencies will manage data imported from applications which do not enforce referential integrity.
d48 1
a48 1
%META:FILEATTACHMENT{name="chartreenodeseq.jpg" attachment="chartreenodeseq.jpg" attr="" comment="" date="1149655942" path="chartreenodeseq.jpg" size="28312" stream="chartreenodeseq.jpg" user="Main.DonovanSharp" version="2"}%
@


1.2
log
@@
text
@d1 1
a1 1
%META:TOPICINFO{author="DonovanSharp" date="1149233916" format="1.1" reprev="1.2" version="1.2"}%
d15 1
a15 1
In SDD dependencies are defined by DependencyRules within the CharacterTree element as part of the CharacterHierarchies.
d17 2
d48 2
a49 1
%META:FILEATTACHMENT{name="depend.jpg" attachment="depend.jpg" attr="" comment="" date="1149233771" path="depend.jpg" size="9363" stream="depend.jpg" user="Main.DonovanSharp" version="1"}%
@


1.1
log
@@
text
@d1 1
a1 1
%META:TOPICINFO{author="DonovanSharp" date="1149142115" format="1.1" version="1.1"}%
d3 1
d5 1
a5 3
SDD Part 0: Introduction and Primer to the SDD Standard 

3.10 Dependencies in SDD
d11 1
d15 1
a15 1
In SDD dependencies are defined by <DependencyRules> within the <CharacterTree> element as part of the character hierarchy.
d17 1
a17 1
Example 3.10.1 - Negative dependencies in SDD.
d20 1
a20 1
d34 1
a34 1
d37 1
a37 1
Positive dependencies are expressed in the same fashion with the <InapplicableIf> tag
d45 3
@