[tei-council] tei stemma model

[James Cummings]

David J Birnbaum wrote:
> Dear James (cc Council),
> 
>> However, I think the better solution has got to be the one which is more
>> consistent with the Guidelines as a whole.  
> I may have misunderstood, but since <eTree> is already part of the Graph
> chapter and already has the nesting structure I propose, I think we can
> already allow that nesting structure if we use the existing <eTree> to
> do it.

I was referring to the use of @xml:id instead of @n there.

> 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.)

> This sounds like the best way to incorporate group labels, especially
> because 1) it's already in place and 2) it doesn't conflict with labels
> for individual nodes (retrievable from @n or by dereferencing
> @key/@corresp/or something similar). In my own work I tend to refer to
> groups by the label on their parent (so that, for example, I would refer
> to the "beta branch of the tradition" to identify the subtree rooted at
> beta), but if one wishes to assign a different name to the group as a
> whole than to its root node in the stemma, <label> seems like a sensible
> place to record that name.

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)?

> As far as I can tell, the two approaches are informationally equivalent,
> but:
> 
> 1) As you note, allowing a single value keeps things straightforward, by
> which I mean easier to manage.

Agreed.

> 2) Making each instance of contamination a separate element records in
> an iconic way that each instance of contamination in the tradition is an
> independent event, separate from each other instance. There is no
> informational difference, but there is an intellectual one, to the
> extent that we would like our XML syntax to model our conceptualization
> of the reality we are encoding.

That argument persuades me more than reason 1, these are separate acts of
contamination that may entirely be wholly unrelated.  Furthermore at a
later juncture it might be decided that this contamination has actually
occurred from an intermediary and thus need to be changed.  Having them
separate probably makes this simpler to do (aka, reason 1.).

>> If one can use schematron to provide the necessary rules to validate that
>> an contaminates/@n attribute points only to a node or a node/@n points
>> only
>> to something in msDesc, then couldn't one do the same thing with @xml:id
>> and @targets, etc?
> I don't see why not.

Then that is more tempting, I feel.

> The only change to intellectual content is the addition of group labels,
> which may be useful and which my original model did not support at all.
> The change of @n to @xml:id and @corresp is, as you note, consistent
> with TEI practice elsewhere. 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>

?


> I appreciate that this additional cost may also seem worthwhile
> if it buys greater consistency with general TEI practice. I don't
> understand, though, how specifying multiple targets of contamination all
> on one <contaminates> element is more TEI-like than specifying each
> target in a separate <contaminates> element.

I wouldn't argue, I don't think that it necessarily is more TEI-like to do
that.  I've decided that I have no problems with multiple contaminates
elements.

-James

-- 
Dr James Cummings, Oxford Text Archive, University of Oxford
James dot Cummings at oucs dot ox dot ac dot uk