The current code has rudimentary support for working with corrections to manuscripts, but this could be expanded in multiple ways useful for phylogenetic analysis. Presently, the --fill-correctors option assumes that correctors have been specified in a strictly linear order, with correctors defined with witness elements and placed following their first hand or preceding corrector in order in the listWit. But this can be problematic if the correctors do not follow a strict order. A series of hands with a known order (e.g., 424C1, 424C2) could be accompanied by a catch-all corrector witness (e.g., 424C) for corrections whose responsible hand is unclear. Likewise, the same witness could have correctors (424C1, 424C2) and also alternate readings or commentary readings (424K) that represent independent departures from the first hand's text.
A more robust approach would be for users to specify these relationships explicitly in the TEI XML collation. This can be done under the sourceDesc element in a listRelation element parallel to the listWit element. The relation elements in this listWit element can then be used to specify corrector relationships, along with known clade relationships, known ancestor-descendant relationships, and known exemplar-copy relationships among extant witnesses:
<listRelation type="witness">
<relation type="corrector" active="424C1" passive="424"/>
<relation type="corrector" active="424C2" passive="424C1"/>
<relation type="corrector" active="424C" passive="424"/>
<relation type="corrector" active="424K" passive="424"/>
<relation type="clade" mutual="6 424C1 1739 1881"/>
<relation type="parent" active="323" passive="322"/>
<relation type="ancestor" active="1845" passive="88 915"/>
</listRelation>(In principle, it would be advisable for users to continue specifying type attributes for witness elements in the listWit, in case this information needs to be used with filters or other conversion methods in the future.)
With access to such a list of witness relationships, the process of filling lacunae in correctors would amount to a simple loop through the relation elements with type="corrector" after the initial population of witnesses' reading sequences. It could even be expanded to fill the lacunae of extant copies and descendants based on their extant relatives. (Separate command-line options should be defined for such behavior.)
If witness relationships are specified in this way in a collation, teiphy could also use this information to define tree constraints for BEAST 3 XML outputs. The sampled-ancestors package's CladeConstraint class could be used with relation elements of type="clade", and its AncestryConstraint class could be used with relation elements of other types. This would result in more accurate trees and better-informed estimates of branch rates and transcriptional rates. The BEAST template and conversion code could be updated to incorporate witness relationships in this way.
Similarly, if the stemma software allows user specification of known ancestor-descendant relationships and independent corrector relationships, the to_stemma method could make use of specified witness relationships.
The current code has rudimentary support for working with corrections to manuscripts, but this could be expanded in multiple ways useful for phylogenetic analysis. Presently, the
--fill-correctorsoption assumes that correctors have been specified in a strictly linear order, with correctors defined withwitnesselements and placed following their first hand or preceding corrector in order in thelistWit. But this can be problematic if the correctors do not follow a strict order. A series of hands with a known order (e.g., 424C1, 424C2) could be accompanied by a catch-all corrector witness (e.g., 424C) for corrections whose responsible hand is unclear. Likewise, the same witness could have correctors (424C1, 424C2) and also alternate readings or commentary readings (424K) that represent independent departures from the first hand's text.A more robust approach would be for users to specify these relationships explicitly in the TEI XML collation. This can be done under the
sourceDescelement in alistRelationelement parallel to thelistWitelement. Therelationelements in thislistWitelement can then be used to specify corrector relationships, along with known clade relationships, known ancestor-descendant relationships, and known exemplar-copy relationships among extant witnesses:(In principle, it would be advisable for users to continue specifying
typeattributes forwitnesselements in thelistWit, in case this information needs to be used with filters or other conversion methods in the future.)With access to such a list of witness relationships, the process of filling lacunae in correctors would amount to a simple loop through the
relationelements withtype="corrector"after the initial population of witnesses' reading sequences. It could even be expanded to fill the lacunae of extant copies and descendants based on their extant relatives. (Separate command-line options should be defined for such behavior.)If witness relationships are specified in this way in a collation, teiphy could also use this information to define tree constraints for BEAST 3 XML outputs. The
sampled-ancestorspackage'sCladeConstraintclass could be used withrelationelements oftype="clade", and itsAncestryConstraintclass could be used withrelationelements of other types. This would result in more accurate trees and better-informed estimates of branch rates and transcriptional rates. The BEAST template and conversion code could be updated to incorporate witness relationships in this way.Similarly, if the
stemmasoftware allows user specification of known ancestor-descendant relationships and independent corrector relationships, theto_stemmamethod could make use of specified witness relationships.