#443 @resp should be a member of att.global

GREEN
closed-fixed
6
2014-12-10
2013-03-11
No

This suggestion was originally raised in 2005, and closed because the discussion stalled: http://purl.org/tei/fr/1173968. The idea came up again on the Council list here:

http://lists.village.virginia.edu/pipermail/tei-council/2013/017238.html

I think there are strong arguments for the use of @resp in a wide range of different contexts. As Gaby says, " I can't imagine any element that I would not want to be able to say either who is responsible for the decisions it represents, or from what publication the information so tagged comes."

Related

Feature Requests: #443
Feature Requests: #536

Discussion

  • Laurent Romary

    Laurent Romary - 2013-03-11

    Excellent idea. I feel like@source could be given a similar thought and correlated with @resp so that encoders are provided with guidance as to which to use when.

     
  • Martin Holmes

    Martin Holmes - 2013-03-26

    I keep coming across more people who would like to see this. Another email today: "It's reassuring to know I'm not the only one struggling with... assigning editorial responsibility to a variety of tags".

     
  • Lou Burnard

    Lou Burnard - 2013-03-30

    The last timne this was discussed (and rejected) I made the point that simply making @resp global won't help with the desire to represent multiple possible structurings. "You can't say the div starts here according to x" at the same time as saying "the div starts here according to Y" simply by using @resp on the <div> -- you need to use <milestone>s or similar, which already have @resp. I haven't heard any new evidence to make me change my mind. We have a mechanism for marking certainty and responsibility in a stand off way which works for all known cases. Why add yet another one which doesn't?

     
    Last edit: Lou Burnard 2013-03-30
    • Martin Holmes

      Martin Holmes - 2013-03-30

      @Lou: the fact that this proposal won't help with the specific problem you outline (representing multiple possible structurings) is a minor one, surely; it WILL help with a wide range of simple requirements that we face every day. I can't remember ever needing to express the fact that one editor believes a div should start here and another that it should start there, but every day I have to say that X is responsible for this transcribed <seg>, or Y is responsible for this definition.

       
      Last edit: Martin Holmes 2013-03-30
  • Lou Burnard

    Lou Burnard - 2013-03-30
    • milestone: --> AMBER
     
  • Lou Burnard

    Lou Burnard - 2013-03-30

    Of course, but my point is that we should not make something global
    unless we can think of a good use case for its presence globally. If we
    can identify some elements for which it would make no sense to use this
    attribute (and I would argue that this is the case here) then it should
    not be global, and it is up to those who want to extend its use to
    specify where it does make sense.

    By the way, I am guessing that if you're talking about transcription,
    you probably want to add this to att.transcriptional ?

    On 30/03/13 16:49, Martin Holmes wrote:

    @Lou: the fact that this proposal won't help with the specific
    problem you outline (representing multiple possible structurings) is
    a minor one, surely; it WILL help with a wide range of simple
    requirements that we face every day. I can't remember ever needing to
    express the fact that one editor believes a div should start here and
    another that it should start there, but every day I have to say that
    X is responsible for this transcribed , or Y is responsible for this
    definition.


     
  • Martin Holmes

    Martin Holmes - 2013-03-31

    "If we can identify some elements for which it would make no sense to use this
    attribute (and I would argue that this is the case here) then it should
    not be global..."

    I've never heard this argument and I don't think it's legitimate. If we put our minds to it, we can perfectly well think of elements for which we cannot conceive of any need for @xml:id or @xml:lang, to take two examples. When would you need @xml:lang on <pb/>, for instance, or @xml:id on <lb/>? You make something global when the places where it's required cover a sufficiently wide and diverse range of contexts that it's not practical or sensible to capture them in an attribute class.

    For the record, in one small project, I need it on <pron>, <seg>, <def>, <phr>, <quote>, <cit>, <persName>, <placeName>, <name> and potentially many other elements.

     
    Last edit: Martin Holmes 2013-03-31
  • Lou Burnard

    Lou Burnard - 2013-03-31

    The fact that you haven't heard an argument before does not, I hope, ipso facto make it illegitimate! Moreover, as it happens I know of one or two projects which do specify xml:id on <lb/> though I agree that the application of xml:lang to an empty element seems a bit odd.
    And while I'm nit picking, saying something is global does imply that it's captured in an attribute class! I think there's a good case to be made for some kind of
    att.pervasive class, but stand by my position that we should not hand people a pointed stick such as global @resps that cannot be used meaningfully in all contexts, especially
    since we already have a perfectly adequate mechanism in the shape of <respons> ... looking forward to discussing further in providence.

    BTW I (and presumably others) cannot see your list of proposed element beneficiaries without doing "view source" in my mailer, so here they are again:

    <pron>, <seg>, <def>, <phr>, <quote>, <cit>, <persName>, <placeName>, <name>

     
    Last edit: BODARD Gabriel 2013-06-27
  • BODARD Gabriel

    BODARD Gabriel - 2013-04-11

    In discussion, we felt that a more concrete proposal, with specific use-cases, for what elements or classes of elements need @resp, so that this ticket can be discussed with more focussed and limited proposals.

    (It turns out that most of my use-cases are really a desire for the @source attribute, so I'm less help to Martin here than we thought I would be. :-) )

     
  • BODARD Gabriel

    BODARD Gabriel - 2013-05-31

    In discussion among TEI Council, it was decided that we should (a) propose expansions to the use of both @resp and @source in tandem, since they are both "talking about attribution of different kinds", and (b) use this ticket to collect concrete and documented use-cases for each (starting with Martin's suggestions of dictionary and naming elements above), with a view to developing a clear proposal for the expansion of these attributes, perhaps in a new class att.attribution.

    To get started, several EpiDoc projects have expressed a desire to be able to indicate where various descriptive and historical information about a MS come from, for example, the description of the support is drawn from (but not technically quoted) a particular publication, then <supportDesc> or <support> or perhaps even <objectType> and <material> would be given an @source pointing to the xml:id of the bibl describing that reference. Ditto <history>, <origin>, <provenance>, etc.

     
  • Martin Holmes

    Martin Holmes - 2013-05-31
    • assigned_to: Martin Holmes
     
  • Martin Holmes

    Martin Holmes - 2013-05-31

    Jennifer Drouin has a case for <castList>, in which "the list of characters in the play is not included in the manuscript given to me by the author, but we thought that the published version of the play should have a list of characters nonetheless (as is, in fact, the case of most of Shakespeare's plays in which the dramatis personae list is an invention of the editor, not found in the original text)."

    She also notes that she has had to correct some stage directions, and would like to use @resp on <stage>.

     
    Last edit: Martin Holmes 2013-05-31
  • Martin Holmes

    Martin Holmes - 2013-05-31

    Expanding on my previous post: in our Nxaʔamxcín dictionary project, we need to ascribe responsibility for:

    • Individual pronunciations of an item (<pron>)
    • Transcriptions of those pronunciations made in the field (for which we use <seg> inside <pron>)
    • Transcriptions which are later narrow versions of phonemic field transcriptions, or phonemic versions of narrow field transcriptions (<seg>)
    • Definitions for words and phrases provided by informants in the field and later (<sense>, <def>)
    • Example phrases and sentences provided by informants, as well as their definitions, in-the-field transcriptions, and derived transcriptions (<cit>, <quote>, <seg>)
    • Division of a form into individual morphemes (<hyph>, <m>)
    • Identification of a component of a definition as a suitable short gloss for the entry (<gloss>)
    • Assignment of feature structure information to an entry (<fs>)

    This may seem excessively pernickety, but this is a project with a 50-year history, and takes place in a cultural context in which appropriate acknowledgement and attribution of contributions, elder authority, etc. are profoundly important.

     
  • Laurent Romary

    Laurent Romary - 2013-05-31

    What Martin says should be true for any serious dictionary project with more than one editing person. It is very important to maintain a source document that traces back contributions.

     
  • Laura Estill

    Laura Estill - 2013-06-09

    I would like to be able to use @resp on \<label>. For instance, I have a seventeenth-century manuscript with some labels from the 17th C and some from the 19th C. Some could also be added by archivists.

     
  • Lou Burnard

    Lou Burnard - 2013-06-10

    Are these labels or seals or stamps? Anyway, are you describing them as
    part of your <msDesc> or are you actually planning to transcribe them
    as part of the text?

     
    Last edit: BODARD Gabriel 2013-06-27
    • Laura Estill

      Laura Estill - 2013-06-11

      I'm transcribing them as part of the text (though also mentioning them in the header). They are not seals or stamps.

       
  • Scott Vanderbilt

    I have many, many instances in RIB where various items of metadata, as well as transcriptions, translations, notes, and entries in bibliography and apparatus where @source would be immensely useful in attributing additions and modifications thereto. @resp is not ideal, not only because it is one level of indirection away from the actual authority (usu. a bibliographical item), but also because it is not sufficiently granular when there may be multiple bibl. entries from the same author/editor; @resp alone won't unambiguously point to the actual authoritative reference.

    While I have no stand on the global vs. non-global argument, I would very much like to see @source on the following (at the very least): <objectType>, <material>, <dimensions>, <condition>, <layout>, <handnote>, <decoNote>, <provenance>, <location>, <rdg>, and <bibl>.

     
  • Martin Holmes

    Martin Holmes - 2013-06-19

    Thanks Scott. I would say that wherever there's an argument for @source, the argument can also be applied to @resp, because wherever attribution is being assigned to a bibliographical item, it might perfectly well be assigned to an individual editor who made a decision not based on antecedent authority.

     
  • BODARD Gabriel

    BODARD Gabriel - 2013-06-27

    I think I would like to start by, (1) pretty much right now adding @source to att.responsibility, so that it is available everywhere that @resp is, which I believe is pretty uncontroversial (I at least am completely convinced by Martin's arguments to this effect); and then, (2) more luxuriously gradually adding that class to more elements/classes as argued elsewhere in this ticket. The former would have the benefit of making @source available on <rdg> etc., which would be incredibly useful, and it wouldn't prejudice the ongoing discussion of the latter.

    Incidentally: why do <respons> and <space> have @resp defined separately, rather than membership of att.responsibility? Is it just so that they don't inherit @cert? We have a better way to do this now, don't we? (I ask because I think I'd want them both to inherit @source as well...)

     
  • Martin Holmes

    Martin Holmes - 2013-06-27

    @Gaby: re your second question, I see that respons/@resp is only a single pointer, whereas att.responsibility/@resp is multiple pointers. In addition, the definitions are subtly different, although the similarity of the descs suggests this is accidental:

    respons/@resp:
    (responsible party) identifies the individual or agency responsible for the indicated aspect of the electronic text.

    a pointer to one of the identifiers typically but not necessarily declared in the current document header, associated with a person asserted as responsible for some aspect of the text's creation, transcription, editing, or encoding

    att.responsibility/@resp:
    responsible party) indicates the agency responsible for the intervention or interpretation, for example an editor or transcriber.

    A pointer to an element typically, but not necessarily, in the document header that is associated with a person asserted as responsible for some aspect of the text's creation, transcription, editing, or encoding.

    I think it would be useful to bring these into alignment anyway, allowing multiple values in respons/@resp, and one obvious way of doing that is to bring respons and space into the class.

     
    • BODARD Gabriel

      BODARD Gabriel - 2013-06-27

      Do you think we should break these off into three separate FRs then, to make it easier for us to enact one or two of them even while still debating the third?

      1. add <respons> and <space> to att.responsibility (perhaps with @cert deleted, if people care)
      2. add @source to att.responsibility
      3. make @resp and @source more globally available (i.e. this ticket)
       
  • James Cummings

    James Cummings - 2013-07-09

    I'm of the opinion that we should resist with an iron will making anything that is not truly global att.global.*

    I have not been convinced that @resp and @source are truly global.

    I agree with suggestion 1 and 2 above by Gabby. I also think there are a large number of elements which may be suitable candidates for membership in att.responsibility.... But I don't want att.responsibility to be global.

    -James

     
  • Thomas A. Carlson

    Two use cases have come up for Syriaca.org's Syriac Gazetteer in which @source on <desc> and <note> would have been useful: I wanted to include (1) descriptions of a place taken verbatim from a print source, but a print source which is not in general being encoded in this TEI, and (2) notes about a place taken from a print source, etc. For case (1), I embedded the <desc> element within the <place> element, but since <desc> cannot take a @source attribute, I had to wrap the description text within a <quote> within the <desc>, putting @source on the <quote> element. For case (2), I could have wrapped a <quote> within a <note>, but instead I gave up and used <desc>/<quote> instead, since <note> cannot take a @source attribute.

    We would also like to use, parallel to our <desc> element taken from a print source, a <desc> element generated for our project by an editor. This would require adding @resp to <desc> or perhaps to <quote>, but I don't think having <desc>/<quote>/@resp makes sense for our project, since if the description is created de novo it is not quoting some other authority outside of the text.

    Thank you all for discussing these issues!

     
  • Martin Holmes

    Martin Holmes - 2013-07-09

    From Sylvia N. Stoyanova:

    "I am encoding the transcription of a manuscript with thousands of internal references, some of which are specific, others less so and some have mistakes by the author. Working with various editors on identifying the most precise destination of links, I need to add the feature of "resp" to attribute proper responsibility for the suggested links, but "resp" cannot be currently contained within a "ref" element or any link describing element that I know of. I also need to add "resp" to marginal notes and other editorial markings (it has worked for dates so far)."

     
  • Martin Holmes

    Martin Holmes - 2013-07-09

    @James: what is the basis of your objection? It sounds simply dogmatic to me. We have a bunch of global attributes already, some very useful, some not. @resp and @source are needed all over the place, and it's difficult to imagine an element where there is no use-case for one or other of them. Do you imagine simply expanding the att.responsibility class steadily over years until it eventually includes virtually all the elements in the schema?

     
  • Sebastian Rahtz

    Sebastian Rahtz - 2013-07-10

    On 9 Jul 2013, at 23:56, Martin Holmes martindholmes@users.sf.net wrote:

    @James: what is the basis of your objection? It sounds simply dogmatic to me. We have a bunch of global attributes already, some very useful, some not. @resp and @source are needed all over the place, and it's difficult to imagine an element where there is no use-case for one or other of them. Do you imagine simply expanding the att.responsibility class steadily over years until it eventually includes virtually all the elements in the schema?

    I'm with Martin. The global attributes already have loads of mad things in linking which get very little use. if @resp and @source were in a module,
    they'd be easy to turn on and off.
    --
    Sebastian Rahtz
    Director (Research) of Academic IT
    University of Oxford IT Services
    13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431

     
  • James Cummings

    James Cummings - 2013-07-10

    Sebastian: existing bad decisions are not an argument

    Martin: it is slightly dogmatic on principle because I think any global attribute additions should be strongly resisted and only implemented if truly necessary because making global attributes that aren't really needed globally is a bad idea.

    I feel that in some cases, say publicationStmt and various other metadata, we have ways to say the source or the resp (such as sourceDesc).

    I'm not saying that you can't come up with examples... just that doing it this way might not be what we want to recommend in all cases. And if I have this unease then I think devil's advocates should step forward... just in case we are making a mistake because global attributes are/should be hard to change!

     
  • BODARD Gabriel

    BODARD Gabriel - 2013-07-10

    I don't have very strong feeling about whether att.resposibility should become part of global or just be very prevalent, so long as it's available in all the places we need it.

    I do feel more strongly about the need for symmetry between @resp and @source (I'm already doing things that I couldn't do without @source on <lem> and <rdg>, for example). I'm going to create tickets for (1) and (2), above, and I'll link to them from here when I've done so.

     
    • BODARD Gabriel

      BODARD Gabriel - 2013-07-10

      Tickets added as Bug 589 and FR 465.

      (We can now focus in this ticket on arguing about how global or otherwise att.responsibility should be. ;-) )

       
  • Lou Burnard

    Lou Burnard - 2013-07-10

    On 10/07/13 10:12, James Cummings wrote:

    Sebastian: existing bad decisions are not an argument

    Entirely agree. Sebastian, if there are global attributes which you
    think should not be in that class, please explainwhy. Though that is not
    relevant to the current discussion.

    Martin: it is slightly dogmatic on principle because I think any
    global attribute additions should be strongly resisted and only
    implemented if truly necessary because making global attributes that
    aren't really needed globally is a bad idea.

    This is a good dogma.

    I feel that in some cases, say publicationStmt and various other
    metadata, we have ways to say the source or the resp (such as sourceDesc).

    This is the real problem here. We have several overlapping mechanisms
    (@resp, @source, @ed, specific elements like <sourceDesc>) and we should
    be clearer about when to use one rather than another. @resp, for
    example, is specifically about " something asserted by the markup", and
    should not assert anything about responsibility for the content of an
    element. If we do decide to make this change I'd like to see a section
    explaining the semantics of the attribute, bringing together and
    discussing some of the examples currently scattered through the text and
    bringing out the usages envisaged.

     
    Last edit: BODARD Gabriel 2013-11-20
  • Martin Holmes

    Martin Holmes - 2013-07-10

    @Sebastian:

    @resp, for
    example, is specifically about " something asserted by the markup", and
    should not assert anything about responsibility for the content of an
    element.

    This is a meaningless distinction, surely. A text() node is markup just as much as an element is. There's no clear border between the encoding and the content.

     
  • Lou Burnard

    Lou Burnard - 2013-07-10

    Sorry Martin, but you are completely misunderstanding my (not
    Sebastian's) point here.

    <add resp="#X">text</add>

    does NOT mean #X added "text" to the source being transcribed. It means #X asserts that "text" is an addition.

    <del resp="#X">text</del>

    does NOT mean #X deleted the text. It means #X thinks there is a
    deletion here.

    In other words, @resp is talking about the tagging itself, not the thing
    tagged.

     
    Last edit: Kevin Hawkins 2013-11-11
  • Lou Burnard

    Lou Burnard - 2013-07-10

    Sigh. Make that:

    Sorry Martin, but you are completely misunderstanding my (not
    Sebastian's) point here.

    <add resp="#X">text</add>

    does NOT mean #X added "text" to the source being transcribed. It means #X asserts that "text" is an addition.

    <del resp="#X">text</del>

    does NOT mean #X deleted the text. It means #X thinks there is a
    deletion here.

    In other words, @resp is talking about the tagging itself, not the thing
    tagged.

     
    Last edit: Kevin Hawkins 2013-11-11
  • Martin Holmes

    Martin Holmes - 2013-07-10

    @Lou:

    @resp: "A pointer to an element typically, but not necessarily, in the document header that is associated with a person asserted as responsible for some aspect of the text's creation, transcription, editing, or encoding."

    If @resp can be someone "responsible for some aspect of the text's creation", then <add resp="#x"> can obviously mean that x is responsible for the addition. I think your view of the meaning of @resp is at variance with the Guidelines definition.

     
  • Martin Holmes

    Martin Holmes - 2013-07-10

    @Lou: in that case, the Guidelines chapter text is at variance with the attribute definition in the Spec. I choose the Spec, and you choose the chapter text. Pistols at dawn.

    (Could you not quote the preceding discussion in your replies? It makes the ticket a bit hard to follow.)

     
  • Ville Marttila

    Ville Marttila - 2013-10-29

    Having always understood @resp in the way described by Lou, and @hand as the proper way of ascribing responsibility for textual content (although the distinction between transcription and annotation is admittedly an artificial one), I would like to point out that one element which has not been mentioned so far but I think should have @resp is <damage>. While the existence of damage in the source text may in most cases be seen as an objective fact, its representation in annotation is extremely subjective, involving editorial conjecture about its degree, agent etc. for which I would like to assign responsibility to the person annotating it. Would this be entirely unreasonable and beyond the scope of the attribute?

     
  • James Cummings

    James Cummings - 2013-11-19

    Oxford 2013-11 face-to-face decided that MH and LB to agree on clarification to Guidelines to say that @resp means different things in different contexts: responsibility for markup and content except when the element in question is a transcriptional element, in which case the content of the element is marked as coming from the source. The idea of having @resp global is rejected.

     
  • BODARD Gabriel

    BODARD Gabriel - 2013-11-20

    In addition to the very useful suggestion above to clarify the definition of @resp in the Guidelines, I think this feature request still needs some concrete proposal for which elements people would like to make (the newly expanded [see FR 465]) att.responsibility to. To summarize, the following groups of elements have been suggested so far:

    1. Martin (supported by Laurent) suggested several dictionary elements, including: seg, pron, def, phr, quote, cit, persName, placeName, name, hyph, m, gloss, fs

    2. Scott Vanderbilt (supported by me, on behalf of several EpiDoc users) suggested several msDesc-related elements, such as: support, supportDesc, objectType, material, history, origin, origDate, origPlace, provenance, dimensions, condition, handNote, decoNote, location, bibl

    3. Jennifer Druin suggested castList, stage

    4. Laura Estil suggested label

    5. Thomas Carlson suggested desc, note

    6. Sylvia Stoyanova suggested ref

    7. Ville Marttila suggested damage.

    (I could imagine a more complete list under (2) above including most if not all of msdescription and namesdates.)

    Any suggestions for how to organize this into a coherent proposal?

     
  • Elena Pierazzo

    Elena Pierazzo - 2014-05-22

    I add <pc> as an element for which @resp would be very useful, not only to be able to distinguish a punctuation mark introduced by the editor from one originally in the source, but also to compare different punctuation marks form different editions or different hands.

     
    Last edit: Elena Pierazzo 2014-05-22
  • Elena Pierazzo

    Elena Pierazzo - 2014-05-22

    For what it counts, I agree with the statement on the top by Gabby: I cannot think of any element for which @resp would not be useful. But if I had to choose, I'd say it should be present in all transcriptional elements at very least, considering "transcriptional" in loosest sense (for instance I'd like @resp on <hi> and <emph). And of course on <pc>, that strictly speaking is not transcriptional, but it is used by many in transcriptions.

     
  • Martin Holmes

    Martin Holmes - 2014-07-01

    Council discussed this 2014-06-30 and decided that MH, LB, and HC will collaborate on a position paper, Council can then decide who will be on the subgroup to write up a recommendation.

    The issues raised:

    @resp has two distinct meanings; sometimes it can mean responsibility for the content of an element, and sometimes for the decision to encode in a particular way (i.e. responsibilty for the markup). This ambiguity is potentially worse if @resp becomes global. However, we might recommend that a global @resp could point to respStmt elements instead of to individuals, thus removing all ambiguity about what it means; the same @resp could point to two respStmts in which different individuals or groups are assigned responsibility for different aspects of the element which bears it. A global @resp might be more acceptable in this scenario.

    The objection that making things global is in itself a bad thing was raised but strenuously opposed; there is nothing intrinsically bad about global attributes.

    If @resp were global under the scenario detailed above, there would be a strong argument for @source also being global, through membership of the same class.

     
  • Martin Holmes

    Martin Holmes - 2014-11-18

    Council decision 2014-11-18:

    • Rename att.responsibility (including @cert) att.global.responsibility; make att.global inherit it.
    • Change the prose and examples in the Guidelines to as best practice pointing from @resp to a <respStmt>.
    • Raise a ticket to consider modifying @resp to have schematron rule that it should point to a respStmt and warn when this isn’t the case, to be considered one year from now.

    Action on MH to implement the changes.

    Action on HC to raise a ticket relating to @source.

     
  • Martin Holmes

    Martin Holmes - 2014-11-18
    • Group: AMBER --> GREEN
    • Priority: 5 --> 1(low)
     
  • Martin Holmes

    Martin Holmes - 2014-11-20
    • Priority: 1(low) --> 6
     
  • Martin Holmes

    Martin Holmes - 2014-12-10

    In rev 13092 I committed a set of changes detailed in the implementation plan here:

    http://wiki.tei-c.org/index.php/Global_@resp_attribute

    Waiting to see what Mr Jenkins makes of it.

     
  • Martin Holmes

    Martin Holmes - 2014-12-10
    • status: open --> closed-fixed
     
  • Martin Holmes

    Martin Holmes - 2014-12-10

    The build appears to have gone well, and I've proofed the resulting changes; added one tweak in rev 13093. I'm now closing this ticket.