Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Adding the @hand attribute to all (or most) text-containing elements #481

Closed
TEITechnicalCouncil opened this issue Oct 29, 2013 · 20 comments
Closed

Adding the @hand attribute to all (or most) text-containing elements #481

TEITechnicalCouncil opened this issue Oct 29, 2013 · 20 comments
Assignees
@lb42
Labels
sf-automigrated Status: Go TEI: Schema Type: FeatureRequest
Milestone
Guidelines-3.0.0

Comments

@TEITechnicalCouncil
Copy link

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.

Original comment by: sf_user_vmarttil
@TEITechnicalCouncil
Copy link
Author

  • assigned_to: Lou Burnard

Original comment by: @jamescummings

@TEITechnicalCouncil
Copy link
Author

Assigning to LB.

Original comment by: @jamescummings

@TEITechnicalCouncil
Copy link
Author

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.

Original comment by: @kshawkin

@TEITechnicalCouncil
Copy link
Author

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)

Original comment by: @lb42

@TEITechnicalCouncil
Copy link
Author

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.

Original comment by: @martindholmes

@TEITechnicalCouncil
Copy link
Author

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.

Original comment by: @lb42

@TEITechnicalCouncil
Copy link
Author

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?

Original comment by: adunning

@TEITechnicalCouncil
Copy link
Author

  • Group: AMBER --> GREEN

Original comment by: @jamescummings

@TEITechnicalCouncil
Copy link
Author

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.

Original comment by: @jamescummings

@TEITechnicalCouncil
Copy link
Author

@James: the decision is not clear. How far will hand be extended? I do not see a change in the last release.

Original comment by: @laurentromary

@TEITechnicalCouncil
Copy link
Author

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.

Original comment by: @lb42

@TEITechnicalCouncil
Copy link
Author

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:

  • when to use <handShift> rather than @hand
  • what does it mean if both are used (is it an error?)
  • what exactly is the difference between @resp and @hand

I will create a separate ticket for the deprecation/removal of @hand on <gap> <unclear> and from att.damaged; hence the "possibly"s above.

Original comment by: @lb42

@TEITechnicalCouncil
Copy link
Author

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

Original comment by: @jamescummings

@TEITechnicalCouncil
Copy link
Author

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?

Original comment by: @PFSchaffner

@TEITechnicalCouncil
Copy link
Author

This issue was originally assigned to SF user: louburnard
Current user is: lb42

@sydb
Copy link
Member

sydb commented Nov 10, 2015

We should perhaps also add <signed> to the group of elements in att.written. After all, it is usually handwriting. (Suggested by Martha Gardener at a workshop.)

@lb42
Copy link
Member

lb42 commented Feb 20, 2016

@jamescummings : what is your reason for thinking <gap> shouldnt have @hand? Removing it would break Birnbaum, and the use case cited in the spec seems plausible to me. Would you also remove it from <unclear?
@sydb : yes, seems plausible; adding <signed> to the list

@lb42
Copy link
Member

lb42 commented Feb 20, 2016

Have now re-read this ticket more carefully, and see that removing @hand from gap and unclear forms part of the original proposal. This would risk making existing documents invalid, so should be handled as a deprecation in the first instance.

So, I am now planning to implement the new class with the following members

  • existing members of att.transcriptional, att.textCritical, and (possibly) att.damaged
  • text div p ab note lg
  • seg head fw label hi
  • opener, closer, salute, signed
  • zone line

Local definitions will of course be removed where needed, except that I propose to retain the local definition for @hand on <gap> and <unclear> to facilitate deprecation. The attributes will be removed on 2017-08-01.

lb42 added a commit that referenced this issue Feb 20, 2016
@lb42
add new class att.written per issue #481
9d3c4b8
@lb42
Copy link
Member

lb42 commented Feb 20, 2016

Implemented at commit 9d3c4b8

@lb42 lb42 closed this as completed Feb 20, 2016
@hcayless hcayless added this to the Guidelines-3.0.0 milestone Feb 23, 2016
sydb added a commit that referenced this issue May 19, 2016
@sydb
Added <signed> to 'att.written' as per issue #481
b169c03
@sydb
Copy link
Member

sydb commented May 19, 2016

Just noticed that <signed> had not, in fact, been added to list. Added to att.written in b169c03.

sydb added a commit that referenced this issue Aug 7, 2017
@sydb
Remove @hand from <gap> and <unclear>
33e8a19 
The deprecation period has expired (ended a week ago), so removing this attribute. This finishes up a closed issue, #481, I think.
@gerritbruening gerritbruening mentioned this issue Jul 9, 2018
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lb42 lb42

Labels
sf-automigrated Status: Go TEI: Schema Type: FeatureRequest
Projects
None yet
Milestone
Guidelines-3.0.0
Development

No branches or pull requests
5 participants
@hcayless @sydb @raffazizzi @lb42 @TEITechnicalCouncil