Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

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

GREEN
closed-fixed
Martin Holmes
6
2014-12-10
2013-03-11
Martin Holmes
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

<< < 1 2 (Page 2 of 2)
  • 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?

     
  • 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.

     
  • Lou Burnard
    Lou Burnard
    2013-07-10

    I refer you to the (fairly extensive) discussion at
    http://www.tei-c.org/release/doc/tei-p5-doc/en/html/PH.html#PHHR

    On 11/07/13 00:06, Martin Holmes wrote:

    @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.


    [feature-requests:#443]
    http://sourceforge.net/p/tei/feature-requests/443/ @resp should be a
    member of att.global

    Status: open
    Labels: TEI: New or Changed Class
    Created: Mon Mar 11, 2013 12:42 AM UTC by Martin Holmes
    Last Updated: Wed Jul 10, 2013 06:16 PM UTC
    Owner: Martin Holmes

    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."


    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/tei/feature-requests/443/

    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/subscriptions/

     

    Related

    Feature Requests: #443

  • 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.

     
<< < 1 2 (Page 2 of 2)