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, and remove its membership of att.source.
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".

SPEC REFERENCES

Change all instances of this:

<specDesc key="att.responsibility"

to this:

<specDesc key="att.global.responsibility"

and all instances of this:

<ident type="class">att.responsibility</ident>

to this:

<ident type="class">att.global.responsibility</ident>

PROSE

1. In att.global.responsibility.xml, change the definition from this:

     att.responsibility provides attributes indicating who is 
     responsible for something asserted by the markup and the 
     degree of certainty associated with it.

to this:

     att.responsibility provides attributes indicating the agency 
     responsible for some aspect of the text, the markup or 
     something asserted by the markup, and the degree of certainty 
     associated with it.

Add a note to this effect:

     Note that since a simple @resp pointing to a person or 
     organization is likely to be very ambiguous with regard 
     to the nature of the responsibility. For this reason, we 
     recommend that @resp be used to point not to an agent 
     (person or org) but to a respStmt, author, editor or similar 
     element which clarifies the exact role played by the agent. 
     Pointing to multiple respStmts allows the encoder to specify 
     clearly each of the roles played in part of a TEI file (creating, 
     transcribing, encoding, editing, proofing etc.).

2. In 3.4 (CO), update this paragraph:

     For most of the elements discussed here, some encoders 
     may wish to indicate both a responsibility, that is, a 
     code indicating the person or agency responsible for 
     making the editorial intervention in question, and also 
     an indication of the degree of certainty which the encoder 
     wishes to associate with the intervention. Because these 
     requirements are common to many of the elements discussed 
     in this section, they are provided by attribute classes, 
     specifically att.editLike, which itself inherits 
     attributes from three further classes called 
     att.responsibility, att.source, and att.dimensions 
     respectively. Any of the elements discussed here thus may 
     potentially carry any of the following optional attributes:

to this:

     For most of the elements discussed here, some encoders 
     may wish to indicate both a responsibility, that is, a 
     code indicating the person or agency responsible for 
     making the editorial intervention in question, and also 
     an indication of the degree of certainty which the encoder 
     wishes to associate with the intervention. These 
     requirements are served by the att.global.responsibility
     class, along with att.source and att.dimensions. Any of 
     the elements discussed here thus may potentially carry 
     any of the following optional attributes:

3. In 17.2 (AI), change this:

<p>These elements are all members of the class <ident type="class">att.interpLike</ident>, and thus share the following attributes: <specList><specDesc key="att.interpLike" atts="type inst"/> <specDesc key="att.responsibility" atts="cert resp"/></specList> </p>

to this:

<p>These elements are all members of the class <ident type="class">att.interpLike</ident>, and thus share the following attributes: <specList><specDesc key="att.interpLike" atts="type inst"/> They also inherit the following attributes from <ident type="class">att.global.responsibility</ident> <specDesc key="att.global.responsibility" atts="cert resp"/></specList> </p>

[more coming...]

SUPPORTED CUSTOMIZATIONS

[Check all customization ODDs and list any required changes here.]

BUILD TESTS

Add to the build process a couple of tests for the use of @resp and @cert in contexts where they were not previously allowed.

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.