[tei-council] tei stemma model

[James Cummings]

Dear David and Council,

Apologies in advance for a long rambling and incoherent post.  I sympathise
with many of the concerns that David expresses, especially those of the
character restrictions on @xml:id and the dangerous opportunities for
inconsistency.

The kind of proposal I'm sure could also be used for most stemmata I've
seen.  See for example one of the typical Chaucerian ones,
http://computerphilologie.uni-muenchen.de/jg03/robinson-abb07.gif used to
display variant frequency.

However, I think the better solution has got to be the one which is more
consistent with the Guidelines as a whole.  I'm also concerned that we are
just expressing the existing tree structure of the tree/root/iNode/leaf
elements in a different form.  Would it be better if this were revised to
allow the nesting structure similar to that which David suggests? (But this
would push it to P5 1.1 I'm assuming.)

The proposal as it stands has several problems.  As Conal has pointed out
the use of @n instead of @xml:id and @target(s).  While I understand
David's desire for simplicity since that is less error prone, I have to
agree with Conal.  I don't think that we should ever be using sigil as a
node identifier, to me it is a text-based label.  Hence, any restrictions
on @xml:id don't really apply. Anyone wanting to construct manuscript
stemmata will be happy to have a witList somewhere.  Thus I would be
recommending that any node being referred to have an @xml:id and use
@key/@corresp/or similar to itself refer to its own metadata (witList).

I think using <label> (which if memory serves eTree allows) to label groups
of nested eTree nodes might be useful.

I was curious about the decision to have contaminates only contain a single
target.  I understand that it keeps things straightforward, but what other
benefits are there, or conversely what drawbacks to having a single
contaminates point to multiple @xml:id's in a @targets attribute?

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?

For now following your advice (for now) to use eTree instead of node, and
assuming that there is a witList providing a sigil to which all of these
eTree elements point, but using @corresp/@xml:id/@targets does the
following do something similar to what you meant?

<eTree corresp="#msabc123" type="hypothetical">
  <eTree corresp="#msbeta" type="hypothetical">
    <eTree corresp="#msDusty" type="hypothetical">
	<label>Group Foo</label>
      <eTree corresp="'#msL" type="extant"/>
      <eTree corresp="#mst" type="lost"/>
    </eTree>
    <eTree corresp="#mseps" type="hypothetical">
	<label>Group Blort</label>
      <eTree corresp="#msR" type="extant"/>
      <eTree xml:id="nodeA" corresp="#msA" type="extant"/>
    </eTree>
  </eTree>
  <eTree corresp="msY" type="hypothetical">
	<label>Group Wibble</label>
    <contaminates targets="#nodeA"/>
    <eTree corresp="#msI" type="extant"/>
    <eTree corresp="#msX" type="extant"/>
  </eTree>
</eTree>

Aside from changing the @n attributes to references to spurious @xml:id
attributes, an my labelling of groups, is much intellectual content lost?

In having skimmed through some more of the trees and graphs section of the
Guidelines, I'd like to suggest that anything significantly more
complicated than David's proposal be held back until P5 1.1.  Moreover,
that when planning P5 1.1 that a significant re-examination of the current
graph/tree provision be undertaken.

-James

David J Birnbaum wrote:
> Dear Conal (cc Council),
> 
> For what it's worth, my reasoning was:
> 
> 1) Every <node> needs an identifier, to which @target can point.
> 
> 2) <node> elements might also want to be able to point to
> <msDescription> elements elsewhere, either in the same document or in a
> different document.
> 
> 3) Every <node> needs a label that can be rendered, and that cannot be
> subject to character restrictions.
> 
> 4) One could use a different attribute in each of these functions, but
> since they are all related (they are all essentially names of a
> manuscript represented by a node), using three attributes where one
> would do the job not only is inefficient, but also creates opportunities
> for inconsistency (i.e., error).
> 
> 5) In the schema I present, the one attribute that I use has all the
> desired properties of IDs, IDREFs, and plain text names simultaneously.
> There are no character restrictions on the name, it is guaranteed to be
> unique, and @target is guaranteed to point to the name of a <node>.
> 
> I'm not sure whether my reasoning was unclear or whether Council
> understands it but disagrees. In the former case, I hope the preceding
> elaboration is helpful (and if it is still unclear, please ask!). In the
> latter, if Council understands the reasoning but nonetheless believes we
> should use three attributes instead of one, so be it.
> 
> Best,
> 
> David
> 
> Conal Tuohy wrote:
>> I like it, but I have a question about the use of @n for reference.
>>
>> I'd have thought the standard practice here would be to have @target
>> be a URI reference to the @xml:id of a node. The node/@n could still
>> be used as a textual label.
>> Alternatively, instead of using URI reference, we could use @key and
>> @ident, as someone I think mentioned on the teleconference.
>>
>> C
>>
>>
>> -----Original Message-----
>> From: tei-council-bounces at lists.village.Virginia.EDU on behalf of
>> David J Birnbaum
>> Sent: Tue 17/07/07 13:09
>> To: TEI Council
>> Subject: [tei-council] tei stemma model
>>  
>> Dear Council,
>>
>> At our last conference call, Council charged Matthew and me with
>> coming up with a proposal for modeling stemmata codicum (a specific
>> type of acyclic directed graph) within a TEI framework. In
>> anticipation of tomorrow's conference call, a proposal along those
>> lines is now available at:
>>
>> http://clover.slavic.pitt.edu/~djb/private/article.html
>>
>> This is a temporary URL, but it will be valid at least through the call.
>>
>> I am still working on developing the XSLT needed to convert directly
>> from the descriptive model proposed in this article to SVG (an
>> indirect approach is already incorporated in the report), but that
>> won't be ready in time for tomorrow's call. Otherwise the report is
>> more or less complete, and, I hope, ready for discussion by Council.
>>
>> Best,
>>
>> David
>> _______________________________________________
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>>   
> 
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
> 


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