[tei-council] tei stemma model

David J Birnbaum djbpitt+tei at pitt.edu
Wed Jul 18 10:59:35 EDT 2007


Dear James (cc Council),

>> The only
>> substantial structural feature not currently present is a way of
>> representing contamination, but adding another element should not
>> inflict any damage on the existing graphing model (i.e., could be
>> undertaken easily and without substantial delay).
>>     
>
> Yes, I have no problem with adding the <contamination/> element.  (Though I
> suppose the concept provided by the element name is a bit specialised to
> this use, I have no better suggestions at the moment.)
>   

For what it's worth, I chose "contaminates" (verb) rather than 
"contamination" because I thought the former made the directionality 
clear. That is, if a parent contains a <contaminates> element, it 
suggests that the parent is the contaminator. If it contains a 
<contamination> element, it leaves open whether it is the contaminator 
or the contaminatee. This isn't a major problem (the @target attribute 
disambiguates in any case), but I tend to forget the names I assign to 
objects, so I try to make them as mnemonic and self-explanatory as I can.

> Should then eTree leaf nodes also have their own <label> elements if the
> user is not pointing back with @corresp to some msDescription (or similar)?
>   

What I liked about your use of <label> is that we may want to label a 
node both individually and as a branch in the tradition. As I wrote 
earlier, I tend to use the same term for both, but one might reasonably 
want to refer to, say, beta as the "northern branch" of the tradition 
and gamma as the "southern branch," so that ones need to label a node 
both "beta" and "northern branch." In this case one could dereference a 
@corresp (or use an @n in just this limited function; it is, after all, 
a global TEI attribute, although its use in this textual function might 
represent an unacceptable retreat from the War on Attributes) to get the 
siglum but use <label> for something prosier and more usefully 
descriptive. I don't see any particular need for <label> elements on 
leaf nodes as long as we can get their identifiers by dereferencing 
@corresp or through @n, but I see no reason to prohibit it. If I 
remember correctly, <eTree> can always contain <label>. We should 
probably advise users on how they should distinguish among all these 
labeling mechanisms, though, so that we don't up leaving people 
uncertain about which strategy they should use to map a name to a node.

>> One possible additional cost (on top of
>> general parsimony and reduced opportunity for error with my model, which
>> I mentioned earlier) is that users may need to draw a stemma where they
>> do not have corresponding <msDescription> elements elsewhere. Since your
>> model doesn't record the sigla in the stemma itself, it requires that
>> users record them elsewhere, even when an <msDescription> (or witness
>> list or something similar) may otherwise not be needed, so that the
>> indirection and additional markup may be required not by the
>> informational goals of the author, but by the construction of the
>> schema.
>>     
>
> What if they nest <label> element for those?  So:
>
> <eTree corresp="#msabc123" type="hypothetical">
> (...)
>   <eTree corresp="msY" type="hypothetical">
>     <label>Group Wibble</label>
>     <contaminates targets="#nodeA"/>
>     <eTree corresp="#msI" type="extant"><label>Manuscript I</label></eTree>
>     <eTree corresp="#msX" type="extant"><label>Manuscript X</label></eTree>
>   </eTree>
> </eTree>
>
> ?
>
>   

This should work, although it may cause confusion about how one labels 
an intermediary node that has both its own name and the name of a branch 
of the tradition. I've been advocating @n, but, of course, that means 
putting character data into an attribute value, which is something that 
we try not to do.

Cheers,

David




More information about the tei-council mailing list