-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
People names in teiHeader #242
Comments
I'll respond to this one in more detail (probably tomorrow), but before finalising the encoding, we really need to work out the kinds of responsibilities we wish to indicate in the files. See my notes in the EGD Leftovers doc, under the heading Authorship and responsibility |
A few more comments. On creating a reference list for responsibilities: this sounds like a very good idea and should in my opinion be implemented. On the structure of the responsibility statement: form A looks best to me, but I have a suspicion that form B has been suggested somewhere (was it perhaps in XML comments in one of our template files?). I dislike C, and D looks uninterpretable to me. (Are both persons understood to be responsible for both roles? Or if they are to be read respectively, then how do we record one person in more than one role?) And @michaelnmmeyer , I think you assigned the PIs and me to your original post with all the issues, but haven't assigned anyone to the separately created issues. I'm assigning myself as I look at each, but I feel it should be you who assigns the PIs to all of these issues. |
Thank you for the details. About the responsibilities list, I forgot to mention that we have a few uses of OK for using form A. I will do that automatically, no manual intervention is necessary. |
Thanks, but I think before making any global automated changes, we/you should wait until Arlo, and perhaps another PI or two, have had the opportunity to think about this and contribute. |
Thanks both of you. I have now gone through Dan's proposals in the EGD Leftovers doc, under Authorship and responsibility. I think I find myself in full agreement, but what is still lacking is a concrete suggestion for how to express the ideas in TEI. I suppose we will need to keep using Since the number of DHARMA_CritEd* files is enormously much smaller than the number of DHARMA_INS* files, if (as @michaelnmmeyer seems to imply) it is desirable to follow the same scheme in both contexts it will be easier to adjust the former to the latter (once we have our act together for how to encode |
For clarification, the "roles" I outline in the Leftovers are meant to correspond to responsibilities in the respStmt; responsibilities may be expressed simply by the role label or in a slightly more verbose form as we do now. Thus, for the roles that I feel pretty sure we need, we could go with: But there's still the whole blue section (blue meaning awaiting input and finalisation) on additional roles that we might want to consider, e.g. revision, ingestion from another corpus (=curation?), principal investigator of task force, TEI data manager, metadata collector, etc. |
Dear Dan, thanks for this. Let me below list the different types of editions I have so far encoded and see if I follow you correctly.
|
Dear @manufrancis , in the scheme I have proposed (which does not have to be implemented - I'll be the happiest if someone comes up with a better one and tells me to what write up for the EGD), your types would be as follows:
|
Thanks for these clarifications, dear Daniel!!! |
Most welcome. Do you have an opinion or preference for case 2 above? The "rules" are not finished and need to be discussed, so I'm happy to pick this up. |
For Vijayavenugopal's editions I would opt for 2.A, most of the time, when I consider that my amount of reviewing/correcting/improving is consequent. |
Thanks, that makes sense. Do you think that if there is an author and a curator, then the latter is by default also the encoder unless the encoder is explicitly named? Or should "the author and the curator" be the encoder by default, so that if the curator alone did the encoding, then this must be recorded explicitly? |
Sorry, I never had the chance to reply. We are not so far really trying to take into account the EGC model, so I am not sure we need to in the present discussion either. Anyhow, I am optimistic that whatever we decide in this discussion will be fairly easy to implement also in a future revision of EGC. |
Ah, now I see I did respond on that issue on 22 Dec. ... |
I guess there are many different cases. By "curator" do you mean also the "reviewer" (e.g. X is author and encoder, then Y review the edition for DHARMA)? In my view, at the risk to have a complex
As for display: Editor(s): AB (printed edition), CD (digital edition) |
No, "revision" is listed under "anticipated future roles" in a part of my recommendation that is just a sketch. Indeed there are many different cases and what we should be aiming for is a comprehensive framework that will cover all of those tolerably well, without the need to create specific rules for every possible scenario (which nobody would have the time to create, and which nobody would read and memorise). |
OK. |
The way I see it, the work of a "curator" is done prior to the creation of a DHARMA digital edition and uses as raw material a non-digital or non-DHARMA edition. Conversely, "reviewing" as I would define it is done at a later stage, taking an already existing DHARMA digital edition as raw material. |
Hmm ... You defined 2.C above as follows: But in that case considering the way you see that it does not seem to fit the fact that my curator's work was not done "prior to the creation of a DHARMA digital edition" but in the process of doing it (but whatever) and that I used as raw material either a printed edition by VVG (revised in the form of digital text file by VVG) or a digital text file by VVG (but whatever) ... In my view, at the risk of complexity, I think we should have slots for all kind of responsibilities in the Thus:
Further details could be made explicit if necessary in the epigraphical lemma. NB: link to |
Thanks for engaging with this. To be frank, I do not see the first part of your comment as productive; you seem to be finding fault with details of my wording instead of trying to get my point. By "prior to the creation of a DHARMA digital edition" I meant "not posterior to the creation". Normally, curation would of course take place in the process of a Dharma edition's creation. My purpose in saying "prior to" was to distinguish it from revision, which I would define as working to improve (or just check) an already existing Dharma edition, i.e. a posterior thing. I do not understand at all what fine distinction you are picking up (and then dismissing by "but whatever") when you say that your use of A) a printed edition by VVG (revised in the form of digital text file by VVG) or B) a digital text file by VVG does not fit my words "uses as raw material a non-digital or non-DHARMA edition". Neither A, nor B is a digital edition, and neither A nor B is a DHARMA edition. The second part of the comment, on the other hand, is just the kind of thing that I've been looking forward to. Almost anything is acceptable to me that the PIs can agree on. I have pasted your comment into the Leftovers doc. I think further discussion should take place there, where my current proposal is written out in detail and all the previous discussion is there. The copyright issue is I'm afraid more complicated than that; I am far from sure that someone who did nothing but encode a previous edition should share the copyright, and Arlo and I have long agreed that if a previous edition of an inscription exists, and you encoded it while collating with visual material, then copyright is yours alone, not shared with the previous editor. Please see the previous discussion in the Leftovers. Again, I'm not saying that it has to be the way I say, only that it has to be some way. |
Glad that at least a part of my comment seems to be useful ;-) |
To bounce about #299 So |
@manufrancis, thanks, I appreciate that, but that outline is not finished and not ready to be implemented. In particular, the bits in blue are incomplete and undecided, and definitely need input from you and @arlogriffiths before we can do anything about them. There's also the issue of differentiating more responsibilities (redundantly as the case may be), as suggested by you above. I'm not against that; we need to discuss. |
@danbalogh @michaelnmmeyer |
I have read carefully the leftovers on these issues and added my comments |
Thank you! |
Thanks to you, Daniel, in the first place. You have seen that I have mostly hesitation about resp for commentary div. |
There are no definite conventions for indicating people's roles. We have
<respStmt>
,<editor>
,<principal>
,<author>
, etc. depending on files.In particular, critical editions (DHARMA_CritEd*) do not follow the conventions
adopted in inscriptions (DHARMA_INS*).
I suggest we use a single notation for indicating people's roles. For instance,
to indicate editors, we could either use
<respStmt>
or<editor>
, but notboth, to avoid confusion.
Inscriptions generally use
<respStmt>
. However, the value ofrespStmt/resp
varies widely between files. Sometimes it contains phrases ("EpiDoc encoding",
etc.), sometimes full sentences, capitalized or not. People treat it as free
text (this is its purpose, according to the TEI documentation), so I cannot
process it mechanically. When people use several
<resp>
for a singleperson, it is also not clear how I should merge the values (separate them with
semicolons? with periods? capitalize or not? etc.)
The TEI documentation suggests to add an attribute
resp/@ref
to indicatepeople's role in a machine-readable way. See the note at
https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-resp.html. From what I
have seen so far, I see at least two distinctions that could be useful for
search and display:
from which this person is drawing. I mean the distinction between Salomé Pichon
and George Cœdès, for instance.
ideas, a collaborator, etc.
It would also be helpful to constrain the structure of
<respStmt>
in such a waythat the same notation is always used for representing the same data. Compare
the following. A, B and C represent the same data; D is a bit different but is
theoretically possible.
(A)
(B)
(C)
(D)
The text was updated successfully, but these errors were encountered: