[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