Global @resp attribute

IMPLEMENTATION PLAN

Council agreed to go ahead with this 2014-11-18. What follows is an implementation plan.

SPECS

1. Rename att.responsibility.xml to att.global.responsibility.xml.
2. Add the class to att.global.xml.
3. Replace att.responsibility everywhere it occurs with att.source (to preserve @source where it is now allowed).
4. Change the definition of @cert in certainty.xml to mode="change".
5. Change the definition of @resp in space.xml to mode="change".

PREVIOUS CONTENT

Proposal for a Global @resp attribute

This page summarizes the discussions of LB, HC and MH on request 443.

THE PROBLEM PART 1: @resp

Many, many users want to use @resp all over the place; but the current meaning of @resp is already confusingly dependent on its context:

@resp: "(responsible party) indicates the agency responsible for the intervention or interpretation, for example an editor or transcriber."

In the Glines, we have examples of @resp use to express responsibility for:

• editorial interventions such as <corr>, <ex>, <supplied>
• specifying a <spanGrp> or <interpGrp>
• writing a <note>
• identifying a <persName> as such
• specifying the place and date of someone's birth (<event>)
• counting the populations of red and grey squirrels between specific dates (<population>)
• providing supplementary info about a witness (<witDetail>)
• writing an abstract (<abstract>)
• describing the origin of a MS (<origin>)
• the entire act of transcribing and encoding a passage (<respons>)

and many more things. Sometimes @resp refers to manipulating text in an editorial capacity; sometimes to making judgements and applying markup; and sometimes to providing information or explanation.

There is clearly a need to allow people to use @resp globally. Since our own Glines show examples of it to describe the complete act of transcribing and encoding, it makes no sense to limit its context such that it could not be used for any of the component elements of an encoded text; and since we already have examples of its use in the header, there is no reason to exclude that either. Since there are examples of its use to specify responsibility for the selection and application of a TEI tag, there is no reason to prevent a user from assigning responsibility for the application of any TEI tag; ergo the attribute should be global.

The problem of what @resp refers to in any specific context remains, but the examples from the <respons> spec provide a straightforward solution: rather than pointing directly to an agent, @resp should point to a <respStmt>, in which the nature of the responsibility is clear in the <resp>(s).

THE PROBLEM PART 2: @cert

att.responsibility also contains @cert. Should this also be global?

Given that whenever we assign responsibility for something to an agent, there is always the possibility that we are not certain about it, then there is no context in which @resp could be used without the possible need for @cert. Therefore @cert should also be global.

The solution:

1. Promote att.responsibility to att.global.responsibility, and make it a member of att.global.
2. Add a note to @resp recommending that wherever possible it point not directly to an agent but to a <respStmt>.
3. Add several examples to the att.responsibility specification showing a variety of uses of @resp pointing to <respStmt>.
4. Update all references to att.responsibility in the Glines prose (e.g. in Names and Dates, we have "Some members of the att.naming class are also members of the att.responsibility class, from which they inherit the following attributes..."
5. Look at all chapter sections which address the use of att.[global.]responsibility attributes and make any required changes, including suggesting that @resp point at <respStmt> where this is appropriate. This includes Chapters 3, 13, and 17.
6. Expand 21.3 (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/CE.html#CERESP), "Attribution of responsibility", so that it also mentions the use of @resp as a simpler alternative to a full <respons> element.

PERIPHERAL ISSUE: @source

We have had some discussions about whether it makes sense for @source to be global along with @resp and @cert. This is based on the notion that, if you're assigning responsibility to someone for something, and expressing some uncertainty about it, you may well wish to say on what source you're basing the assertion. We disagree about the need for this.

HC contends that in any place one might want to indicate an intellectual contribution by an editor/encoder of the document, one might equally well want to cite an external authority for that contribution. HC also feels @source has a stronger argument for universality than @cert.

MH is also close to being convinced of this. Since it involves a different attribute class, though, we could deal with it in a separate ticket.