#480 Adding the @hand attribute to all (or most) text-containing elements
While the documentation of manucript hands in the header is currently well-supported, the assignment of these hands to individual stretches of text in the trasncription is much less so, as the @hand attribute is allowed only on a very limited number of elements, mostly limited to describing what could be called 'special cases' (att.transcriptional) or to specific editorial methods (att.textCritical). In addition, in the case of some of these elements, namely <gap> and <damage>, the @hand attribute does not really make sense in terms of the element itself but rather serves as a shorthand, implying the existence of an associated <del> element.
In order to be able to consistently indicate the hand responsible for every stretch of transcribed text, I would like to see the @hand attribute added (possibly via a new attribute class) to all text-containing elements on each level of the textual hierarchy. This would allow us to indicate the hands used in a document in a cascading fashion, indicating the principal scribe (if one exists) on the root <text> element and then indicating all deviations from this on the appropriate container element. This would mean that it would be trivial to determine the hand of any text node by simply finding the first ancestor that has the @hand attribute (and is not a <del> element*).
While the ideal, most consistent solution would be to provide the attribute on not only <text>, <div>, <p>, and <seg>, but also on all of their more specialised parallels, its provision on these basic elements and the relatively common <head>, <fw> and <note> elements would most likely cover the majoríty of cases. This would allow the @hand attribute to be used properly for the purpose which it was intended according to the guidelines, which sadly is currently not possible.
The <handShift/> element is not really a solution, since many of the textual items written in different hands (but still as a part of the original production process, excluding them from additions) are things like headings, forme work (folio numbers, signatures, catchwords), and notes, which are not a part of the textual flow and would make it very awkward to shift back and forth using the milestone element. Additionally, it does not allow for the cascaded indication of hand and would add unnecessary milestone elements where none are actually needed.
*) On the <del> element the attribute does not refer to the hand responsible for the textual content, but to the one responsible for the action indicated by the annotation, making <del> something of an anomaly; this could be seen as a reason for using a different attribute than @hand to indicate responsibility for a deletion. I would also very much like to see the @hand attribute removed from <gap> and <damage> elements in the favour of using a surrounding <del> element which not only is much more transparent semantically, but also allows the properties of the deletion and the ensuing damage or loss to be annotated separately.
Assigning to LB.
The Technical Council discussed this a bit 5 days ago and charged Lou with responding. I have also been pondering it a bit and want to make two brief notes:
a) I see that @hand is defined in a few attribute classes as well as individually on a few elements. If in the end we do not agree to implement this feature request, I think we should still create an attribute class to unite the various definitions of @hand in one place (though this attribute would still be available in the same places as it currently is).
b) During the Council meeting someone said that @hand is supposed to be handled like @xml:lang in that the value is assumed to be inherited from parent elements. I don't see where this is explained anywhere in the Guidelines regarding @hand. I think #PHHR would be the place to do that.
The Guidelines propose using <handShift> to indicate changes of hands rather than a @hand attribute structurally analogous to e.g. @xml:lang because information about hands belongs to a transcriptional view of the source rather than a logical one, and the supposition is that TEI markup will generally prefer to prioritize the latter to avoid overlap problems. It seems plausible to reconsider this supposition, now that (for example) we have <sourceDoc>. Making @hand global (or at least available on all elements which contain transcribed text) would be a fairly easy way to do this. We'd then need to decide whether there was still a need for <handShift> (we don't have <langShift> for example)
I thought there was an ingrained objection to making any more attributes global? Based on what happened on the @resp ticket, shouldn't there be a campaign to identify all the elements likely to need @hand, followed by the creation of a new class? I would suggest that @hand is far less worthy a candidate for a global attribute than @resp, because it can logically appear only on text-bearing elements which are descendants of
<text>or<sourceDoc>, whereas there are arguments for the use of @resp virtually everywhere.Caparisons are odorous. I did however explicitly suggest that @hand only makes sense on elements containing transcribed text. I am not sure that we currently have such a class, but it might be useful to define one. "text-bearing elements which are descendants of <text> or <sourceDoc>" means effectively, "non-header-elements" except that we currently allow all sorts of "text-bearing elements" inside the header as well : vide arguments about <p> in the header.
I'm also currently running into the issues described above. Is this something that might yet happen in P5, or should it be added to the P6-dev page?
LB to make a proposal for new attribute class and implement after running suggestions passed Council. The deletion of @hand from some elements should be made into a separate ticket. Raleigh F2F 2014-11-18.
@James: the decision is not clear. How far will hand be extended? I do not see a change in the last release.
Apologies: this is one of a few tickets that required more thinking about than was possible in time for them to get implemented at the last release. The difficulty here is deciding (a) exactly which elements should constitute the proposed new class (b) how to implement appropriate constraints. I hope to circulate a proposal in the next week or two.
For the moment, I propose to address only the question of extending availability of @hand by means of defining a new class for which I propose the name att.written.
Members of this class would be :
- existing members of att.transcriptional, att.textCritical, and (possibly) att.damaged
- text div p seg head fw label note
- zone line
- (possibly) <gap> and <unclear>
Note that this list doesn't include numbered <div>s though I suppose it should. Other suggestions are (grudgingly) welcome.
The Guidelines also need revision to clarify the following questions:
I will create a separate ticket for the deprecation/removal of @hand on <gap> <unclear> and from att.damaged; hence the "possibly"s above.
I'm unclear as to the logic behind what is included in the proposed att.written and what isn't?
Is it that elements which are merely providing annotation to existing text aren't in it because their parent containing element is? e.g. persName doesn't qualify because it is unlikely that just the persName was written by someone else?
If something like that is the case I would propose adding the following as things that might reasonably be written by another hand:
add (and all att.transcriptional as you note), ab, seg, hi, opener, closer, salute, signed, epigraph, lg,
Explaining why I'm wrong about some of those might clarify things for me. ;-)
I don't think that gap should have @hand.
-James
I'm a little confused too. I take it that @hand has hitherto been confined to 'scribal interventions' in a transcriptional context (which I take to include both the pure diplomatic transcription and the traditional TEI structural transcription). Hence its use, e.g. on add. And that the proposal is to extend it to all text-bearing elements in such a transcriptional context, as broadly conceived. Doesn't that make it something like a specialized form of @rend? And if so, should it not apply to a great many elements indeed? Anything that can be written can be ascribed to a particular hand, just as anything that can be written can be written in a particular rendering. So why p but not ab or l or item or cell? why div (or divx) but not lg? seg but not stage or note?