[tei-council] tei stemma model

[Lou Burnard]

Unless I'm mistaken, when this investigation of how to represent ms 
stemma was first proposed, it was mostly as an exercise to see how 
applicable the existing TEI model for trees and graphs is. I may be 
inventing this, but my recollection is that the conversation went 
something like
x: we've got this lovely way of representing graphs and networks and stuff
y: why would anyone ever want to use such a thing
x: well you could use it represent, err, airplane networks, or family 
trees, or um,
y: or MANUSCRIPT TRADITIONS! wow that's really innerestink

So the exercise intended for David was really to test the capabilities 
of the existing TEI model, which I think his work does rather well.

I don't have anything to add to what James has already said about
labels and the use of existing TEI styles for identification and 
linkage. I do however wish to confess to a feeling of unease about 
contamination.

As I understand it, this is a way of saying that a given node has one or 
more parent-nodes *other* than the one it's actually attached to -- 
which  of course means that you're not looking at a tree any more, but a 
directed acyclic graph. So it cannot be represented using <tree> or 
<eTree> -- you need to use the more general <graph>.

I would be interested to see how David's example would play as a <graph>

Lou



the discussion about
z: David J Birnbaum wrote:
> 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
> 
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>