[DDI-SRG] Note on bug 122

Joachim Wackerow joachim.wackerow at gesis.org
Thu Jan 31 09:49:28 EST 2008


I like the systematic list or requirements and the related use cases.

  1 - adding items to non-hierachies
  2 - adding items and levels to extremes and encapsulating
  3 - adding items and levels within exisiting structure
  4 - adding subset of items

In contrast to the suggested solutions by adding the element 
'insertBefore' and the attribute 'parentLevel' I see an alternative.

'insertBefore' is actually a "insert above", above one level higher in 
the hierarchy. 'parentLevel' defines the relationship between two 
levels. CodeValue newLevelNumber and newIsDiscrete are definitions of 
changes of the attributes of a level after "editing" the levels.

The definitions 'insertBefore' and 'parentLevel' are additions to the 
current approach of representing a hierarchy by nesting. This is another 
level of complexity for an application.

I see an alternative in an expansion of using the current principle of 
representing a hierarchy by nesting.

When the existing CodeSchemeReference is also possible below 'Code' the 
requirements from above (2-4, 1 is already possible anyway) seem to be 
solvable. Details see at the bottom.


Some remarks on excerpts of earlier emails from Wendy.

 > According to CodeSchemeReferenceType the full CodeScheme is referenced
 > and there is no option for limiting inclusion. The option for using only
 > parts of a coding scheme is found in Variable/CodeRepresentation which
 > is extended by CodeSubsetInfo. This includes the IncludedLevel,
 > IncludedCodeRerference, etc.
(this is from Wendy's email Januar 25th)

IncludedLevel and IncludedCodeReference are possible as sub-elements of 
CodeSchemeReference, both are optional and repeatable. This way an 
desired part of a referenced CodeScheme can be included (for comfort the 
definition of a range of codes is probably missing).


 > Clarification of LevelNumber:
 >
 > It is just an identifier. The suggested use is to make it incremental
 > but this is not a requirement. The documentation should be clarified
 > here.
(this is from Wendy's email Januar 24th)

When levelNumber is just an identifier then it should a string (not an 
integer as now). This way any level definitions would be possible, it is 
just a name. Structural level definitions like "1.1" would be possible.

Background: the hierarchy of codes is expressed by nesting not by the 
level definition. This has only informational character for the level.



EXAMPLE 2A:

Total level=1
         Male level=2 (discrete) ADD LEVEL
         Female level=2 (discrete) ADD LEVEL

<l:CodeScheme>
   <Identifier type="r:MaintanableIDType"><r:ID>TotalSex</r:ID></Identifier>
   <r:Label>Sex</r:Label>
   <r:Description>Recoded Sex adding total</r:Description>
   <l:CategorySchemeReference 
type="r:ReferenceType"></r:ID>Cat_TOTAL</r:ID></l:CategorySchemeReference>
   <l:Hierarchy>Regular</l:Hierarchy>
   <l:Level levelNumber="1">
     <l:Name>Total</l:Name>
     <l:Relationship>Nominal</l:Relationship>
   </l:Level>
   <l:Level levelNumber="2">
     <l:Name>Level 1 Members</l:Name>
     <l:Relationship>Nominal</l:Relationship>
   </l:Level>
   <l:Code isDiscrete="false" levelNumber="1" insertBefore="1">
     <l:CategoryReference 
type="r:ReferenceType"><r:ID>Cat_TOTAL_1</r:ID></l:CategoryReference>
     <l:Value>3</l:Value>
     <l:CodeSchemeReference type="r:ReferenceType" 
levelNumber="2"></r:ID>ORIG_SEX</r:ID></l:CodeSchemeReference>
   </l:Code>
<l:CodeScheme>


Example 3:

         Iron level=1
            Bar and Cast Iron level = 2 NEW ITEM
               Bar Iron level=3 (discrete) LEVEL SHIFT
               Cast Iron level=3 (discrete) LEVEL SHIFT
            Pig Iron level = 2 (discrete)
            Iron not elsewhere classified level = 2 (discrete)

The existing codes would be included by CodeSchemeReference with a 
limiting inclusion. The CodeSchemeReference must be applied here twice. 
Once for 'Iron' and once for the codes from 'Bar Iron' to 'Iron not .. 
'. The new level specification would be done similar to the suggested 
solution in bug 122. But the attributes should stay be attributes of 
IncludedCodeReference  or IncludedLevel .

Achim




More information about the DDI-SRG mailing list