Skip to content
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

<del>: meaning, display, and wrapping it around more than one <gap> #304

Closed
arlogriffiths opened this issue May 18, 2024 · 7 comments
Closed
Assignees
Labels
invalid This doesn't seem right

Comments

@arlogriffiths
Copy link
Collaborator

EGD 4.4.1 define <del> as follows:

  • text that was deleted in premodern time (without adding a corresponding correction) should be wrapped in the element <del>
  • in our project, this element will by default be understood to represent text rendered illegible through erasure by means of chiselling a stone surface, hammering copper flat, or rubbing the surface smooth

No allusion is made to the notion of "scribe" and when the deletion was made vis-à-vis the initial engraving of the line.

I have these two lines of code for a case of intentional erasure presumably postdating the orignal engraving by some years, decades or even centuries:

<lb break="no" n="B3"/>ma</surplus> suparṇa<unclear>vā</unclear>haṇa tguh uttuṅgadeva, <unclear>Um</unclear>iṅ<unclear>so</unclear>r· I  rakryān· kanuruhan· pu dharmmamūrtti <unclear>naro</unclear>ttama dānaśūra <unclear>k</unclear>umo<unclear>nak</unclear>ǝ<unclear>n</unclear> i<unclear>kana</unclear>ṁ ri pucaṅan·, Iṁ barahǝm·, Iṁ bapuri, lmaḥniṁ varggāpi<unclear>ṅhe</unclear> <del><gap quantity="8" reason="lost" unit="character"/>
<lb n="B4"/> <gap quantity="32" reason="lost" unit="character"/></del>  susukǝn·, mapaknā pa<unclear>ṅ</unclear>adǝganani dharmma karṣyan· śrī mahārāja,</p> <p>sambandha, A<supplied reason="lost">n·</supplied>
Capture d’écran 2024-05-18 à 09 05 10

In the display, I see the notion of "scribal deletion" which appears to me more narrow than what we iontended in EGD 4.4.1. Notably, it would seem inappropriate for the case I a dealing with. So should I encode differently or should the display be modified?

Capture d’écran 2024-05-18 à 09 06 36 Capture d’écran 2024-05-18 à 09 06 58

Finally, it seems that the system does not pick up on the fact that the deletion stretches across the <lb> for which reason I have had to encode two <gap>s wrapped in a single <del>. Only for the first <gap> does the system recognize the connection between lacune and deletion.

All in all, I might have preferred the tooltip at the start of <del> to indicate "Deletion | 8 lost characters | 32 lost characters" or something like that.

@arlogriffiths arlogriffiths added the invalid This doesn't seem right label May 18, 2024
@michaelnmmeyer
Copy link
Member

I picked the "Scribal deletion" tooltip from the old editorial conventions table. No problem changing it to something else.

The bug you mention will be addressed in the 'major overhaul' I mentioned in our mail exchanges. There are many cases like that (among which #305, as you observed).

@michaelnmmeyer
Copy link
Member

michaelnmmeyer commented May 21, 2024

To be noted that we use "Scribal addition ..." for <add>. Should I also change this?

@arlogriffiths
Copy link
Collaborator Author

I was at first sight inclined to think we want to keep "Scribal" there. But plain "Addition" would also not be wrong and would allow for accommodating any (thus far unforeseen and probably rather hypothetical) cases of addition to a text by an engraver who was active after the original scribe. Another reason for removing any allusions to the notion of a 'scribe' is the fundamental problem we face in most epigraphic documents, namely that we have only limited understanding, or no understanding at all, of the division of labor between various types of artisans:

  1. writing on a preliminary (perishable) support: done by a scribe proper
  2. engraving a redacted text into the permanent support: done by an engraver, not necessarily the same person as the scribe

michaelnmmeyer added a commit to michaelnmmeyer/dharma that referenced this issue May 21, 2024
@danbalogh
Copy link
Collaborator

Regarding the term "scribe", we've already had some discussion, as a consequence of which the introductory part of EGD §4.4 (Premodern scribal intervention) now says:
most premodern corrections presumably took place shortly after the full text was first engraved and were carried out by the original scribe/engraver, though some may have happened at a later time and/or may have been executed by a different person
Implicitly, we thus define scribe as something like "anyone who deliberately interacted with the engraved text in premodern times with the intention of creating or altering its meaning". If you wish, we can make this explicit in the next EGD. Improvements to this definition are welcome in that case.
So your encoding with <del> is correct.

As for the tooltip, in my opinion tooltips are meant to be brief and can never be expected to be pedantically accurate in all cases. When the tooltip says "Scribal deletion", the above definition of scribe should apply, but this cannot be explained in the tooltip, and there will be very few cases where the meaning of "scribe" is not straightforward. Of course, your suggestion of simple "Deletion" is even briefer and not pedantic, but as Michaël's above comment implies, it increases ambiguity. Although the proper technical term for editorial deletion (e.g. of dittography) is "suppression", this is in my opinion not immediately straightforward (hence even the EGD §6.2.3. title is "Editorial deletion (suppression)"), so if the tooltip were just "deletion", then I think the potential for readers to misunderstand this as editorial deletion has much more impact than the potential for readers to misunderstand "scribal" in a narrower sense of "scribe". The problem is more conspicuous in the case of addition and correction. There is a terminological consistency in the EGD, so indeed: we should certainly not change "Scribal addition" to just "Addition", and if we don't do that, then changing "Scribal deletion" to "Deletion" introduces an inconsistency. In that connection, I think it is worth recalling that you once observed in an EGD comment (21 June 2021), "in the context of drafting the EGC, distinghuishing ‘editorial’ from ’scribal’ interventions has proven quite important, so I’d prefer imposing the distinction also in EGD"
So, I would much prefer to keep the tooltips (and the EGD section heads) involving "scribal" just as they are now.
If you find that really objectionable, then tooltips (and perhaps headings) along the lines of "Premodern deletion" or "Deletion in the received text" could be considered.

And finally, on the encoding of deletion across a line break. I do not see this as a bug; in fact, since the line break is not (and cannot be) deleted, I see it as an encoding error. It's a case of overlapping hierarchies: even if a deletion perceived as a single feature extends across a line break, it must be encoded as two separate features because the hierarchy of extrinsic structure intervenes in it. See EGD §8.2 and especially §8.2.5, "Tier 5, phrase-level elements". Although scribal intervention is not explicitly listed here as a phrase-level element, it certainly is one (and none of the lists of examples for the hierarchical tiers are complete). According to our rules formulated early on, such elements must "in case of conflict give way to elements of tier 4 and above" (where <lb/> elements belong to tier 3). For a partial analogy, think about deletions extending across the lines of a stanza: in that case it would be technically impossible to encode a single <del> element, because the ordered hierarchy of content objects would prevent it. Since line beginnings (as well as all milestone-like elements such as page breaks and milestones) are conceived of as constituting a virtual alternative hierarchy (the "contents" of a line are thought of as the text extending from one <lb/> element to the next or to the end of the division), there should never be phrase-level elements whose start tag is in one line but the end tag is in the next. This, by the way, applies equally to <surplus> in #305.
So on this count, I would very, very emphatically urge you to change your encoding and split the <del> tag across the line break. The schema should in my opinion flag as an error the occurrence of any milestone-like element within any phrase-level element, with the possible exception of semantic tags (although in the EGD 8.2.5 we actually do explicitly list semantic tags among those that have to be split across line breaks). The desired display could, I believe, still be achieved by making the algorithm that generates the tooltip look beyond the milestone-like element that is immediately adjacent to a phrase-level tag to see if a phrase-level tag of the same kind follows directly, and implementing this check may not be more complicated than what Michaël suggests above.

@arlogriffiths
Copy link
Collaborator Author

Thanks for exposing all of this so clearly.

  • I'd be happy if our notion of "scribe" as something like "anyone who deliberately interacted with the engraved text in premodern times with the intention of creating or altering its meaning" could be made this explicit in the next EGD
  • happy to accept your preference on tooltips
  • thanks for pointing out the error in my encoding

I leave the reast to Michael.

michaelnmmeyer added a commit to michaelnmmeyer/dharma that referenced this issue May 21, 2024
@danbalogh
Copy link
Collaborator

A minor update as I'm just catching up on my task list: issue #307, newly formulated by Michaël, is relevant to why we want to treat line breaks (and other milestone-like elements) like a virtual hierarchy.

I've noted the explicit definition of scribe for the EGD.

@michaelnmmeyer
Copy link
Member

Our current schema infrastructure cannot flag encoding issues like these. I have a more expressive one in preparation, but it will likely not be completed before more than a year.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
invalid This doesn't seem right
Projects
None yet
Development

No branches or pull requests

3 participants