Responsibility statement: to key or not to key

[danbalogh]

The discussion in the Roles, responsibilities... Google Doc was left unfinished in March 2025. We have basically agreed to follow my "Radical Proposal" which means in essence the following:

• we are only concerned with people who have actively contributed to the digital edition
• therefore the primary person(s) to be shown here are those who created the digital edition, even if this only means encoding a print edition without re-editing the text
• previous print editions are credited in the epigraphic lemma, but not in the responsibility statement
• when there is a need to distinguish between different degrees of contribution, we have a "creator" and a "contributor" level

So far so good. We have not, however, sorted out 1, precisely how this shall be encoded; 2, how this is to be displayed; and 3, what, if anything, to do with the existing files.

Currently in inscription editions we have the following framework:

            <respStmt>
               <resp>intellectual authorship of edition</resp>
               <persName ref="part:daba">
                  <forename>Dániel</forename>
                  <surname>Balogh</surname>
               </persName>
            </respStmt>

The contents of the <resp> element are free and the old EGD just says "follow the instructions in the template" - but no such instructions exist. The entire <respStmt> element may be iterated when several contributors contributed different things, e.g. when Fleet was the intellectual author and daba did only the encoding (which was to be shown separately in one of the former non-radical systems we used).

The current display for this seems to ignore the content of <resp> and simply show any and all names identified here as "Author(s) of digital edition", so for a file that's encoded with Fleet as intellectual author and daba as encoder, the display gives "Authors of digital edition: Dániel Balogh (daba), John Faithfull Fleet."

During the discussion last year, Michaël had proposed that we use @key on the <resp> instead of text content. Thus, instead of <resp>intellectual authorship of edition</resp> we would have for instance <resp key="creator"/>. I liked this suggestion and wrote it up in the GDoc, where it has been explicitly approved by Arlo, Manu and Annette. Analogously, for contributors we could use <resp key="contributor"/> instead of saying "contributor" or whatever in the content of the <resp>.
This has not been implemented, and the schema forbids @key on <resp>.

As a modification of the latter alternative, I had also suggested that we could use an empty <resp key="creator"/> for the creator(s) but <resp key="contributor">proofreader</resp> and suchlike for contributors, where the nature of the contribution could be clarified in the content. Manu, Michaël and Annette have agreed to this but Arlo was not enthusiastic about the whole contributor thing and expressed no opinion on this; his basic approach is that contributions can be clarified in the epigraphic lemma.

I now think this last alternative is too complicated to adopt at the last minute and devise display for. I do, however, think that the original alternative with @key should be adopted.
The following is what I think we should do.

• one <respStmt> containing <resp key="creator"/> is mandatory and should be pre-coded into the template
  • this must contain at least one, optionally more, <persName> elements encoded with ref to the participant list (nb. <resp> itself is not iterated)
  • as per the radical proposal, this is / these are the person(s) who were most instrumental to the creation of the digital edition, regardless of the calibre and kind of intellectual effort that this needed
  • therefore these persons will always have DHARMA part: identifiers
• a second <respStmt> containing <resp key="contributor"/> is optional and may be pre-coded into the template and commented out, or left to the encoder to create when necessary
  • when present, this must contain at least one, optionally more <persName> elements encoded with ref to the participant list when the person is a DHARMA member, but non-members may also be listed here, without ref (nb. <resp> itself is not iterated)
  • the nature of the contribution is not to be clarified here, but should preferably be clarified in the epigraphic lemma
• no additional <respStmt> elements beyond these two
• text content in <resp> is not forbidden by the schema (for legacy purposes), but is not encouraged in the EGD and ignored in processing
• display shall be "Author(s) of digital edition" [with automated plural] for the primary <respStmt> and "Contributor(s)" [with automated plural] for the secondary one
• the value "creator" should be understood as default for @key on <resp>, so that legacy files encoded without @key will continue to be displayed as they are now
• existing files could also be safely refactored in the following way
  • any <resp> elements which are children of the first <respStmt> in a <titleStmt> get tagged with @key="creator"
  • any <resp> elements which are children of a non-first <respStmt> in a <titleStmt> get tagged with @key="contributor"
  • this will probably produce correct results in the large majority of cases, and the incorrect results will not be any worse than the present display of "Authors of digital edition: Dániel Balogh (daba), John Faithfull Fleet."
• whether or not there has been batch refactoring, active encoders should be encouraged to check and update their existing files to this format
• I can volunteer to update a couple of dozen files by encoders who are no longer active, such as Jens Thomas and Natasja Bosma, but would not want to do hundreds

Please state below whether you agree with this or if not, exactly what should be done differently and how.

[AnneSchmiedchen]

I agree, of course, with Dániel's proposal on how to proceed.

[michaelnmmeyer]

I am fine with this.