New case of <space/> imposed by physical necessity §4.3.5 EGD

[amandinebricout]

@danbalogh @arlogriffiths @ajaniak During the reading of Khalimpur Plate BC88, I have encountered a situation for spaces imposed by physical necessity that, unless I am mistaken, is not reported in the Guide. Indeed the three first lines are interrupted by a long space due to the attachment point of the seal (see the attached photo). I suggest to encode the new type of space by something like <space type=“sealattachmentpoint” unit=“character” quantity=“18”/> but this proposition is maybe a bit too much long. Do you have any other suggestion? Can we add this case in the guide? Thank you in advance for your help, Amandine

[danbalogh]

Thanks, Amandine, for the nice illustration. There is also an earlier proposal of mine in an EGD comment, about possibly introducing a <space type="deco"/>, which is somewhat similar. On the other hand, we don't want to over-complicate these spaces. I now propose the following:

1. To our already existing list of permitted types of space, we add "feature", covering engraved art (e.g. on a CP or a flat stone), relief art (e.g. on a sculpture base) and seals attached directly to a plate such as Amandine's example. The difference between "feature" and "defect" would be that a feature is a deliberately created artificial thing, whereas a defect is accidental or natural.
2. We explicitly forbid the use of @quantity and @unit for all spaces imposed by physical necessity, since our purpose in encoding such spaces is merely to record a disturbance that may have influenced the writing process; the number of characters that were impossible to write there is irrelevant. (At present, attributes are forbidden for binding holes and ascenders/descenders, but permitted for defects.) This would moreover allow me to simplify and shorten the section on imposed spaces, since there would be no need to discuss each type in detail, just to give the general instructions and list the permitted types with definitions.

[danbalogh]

Incidentally, forbidding quantity and unit for imposed spaces would leave the door open in case we wanted to switch the encoding of imposed spaces from <space/> to <milestone/> - the idea of using <space/> in such cases has met with some objections on the mailing lists for Indic texts and for EpiDoc.

[amandinebricout]

Dear Dániel, Thank for you reply. Sorry I don't think to read the comments before opening this issue, but it shows that the case has to be considered because it is not unique. Your proposal seems to me relevant in that it distinguishes between an accidental, non-chosen physical constraint and a constraint due to the manufacture of the object (engraving, seal, sculpture). But in that case, maybe, the case "binding hole" could also be included in the manufacturing constraints (what you name "feature"), isn't it? In any case, this distinction "natural constraint/manufacturing constraints" seems clear enough to me to be easily applied. As for the mention of the length of the space, I don't know to what extent it is useful to give it or not. Giving the number of aksaras can possibly allow to evaluate the average number of aksaras per line, which can help in the case of a damaged plate...I confess I have no settled opinion on this point and maybe not enough experience in epigraphy to evaluate the relevance to mention or not these details.

[danbalogh]

Thanks for your thoughts on this. Indeed, perhaps "binding_hole" could be integrated into "feature", though because it is such a salient thing in almost all CPs, it is better kept separate. I think anyone who wants to count the number of akṣaras per line and use that as a basis for further deductions (e.g. number of characters lost to damage) will always look at a facsimile to do so and not rely on just an edition. Let's see what Arlo thinks.

[arlogriffiths]

I have no profound thoughts at this time. But Amandine's example reminds me of Bengal dedication inscriptions with a complex layout on their support (general, stone/metal statues) due to the complex morphology of the latter. In such cases, I suppose most encoders may feel it most natural to insert <milestone> tags into their lines of edition.

Yes, let's keep "binding_hole" (or was it "binding-hole"?) separate.

I am not very happy with "feature" (as a defect is also a feature) but I have no better alternative to offer.

[danbalogh]

@arlogriffiths, a complex layout involving more than one surface should certainly be encoded with milestones, gridlike or pagelike as the case may be. In that case, we use <milestone/> to identify where a particular surface begins vis-à-vis the text (just like the specialised milestones <lb/> and <pb/> are used to encode where a particular unit begins vis-à-vis the text. Text from one such milestone to the next is in the original written on the surface (or part thereof, i.e. line) specified in the milestone. What we are talking about here are single surfaces where the text has a discontinuity for some reason. In these cases we currently use <space/> to encode the interruption itself, and not a particular surface (or part thereof) demarcated by the interruption. Thus, e.g. if you have text on two faces of a stela, you encode surface A at the beginning of each line and surface B at the point where each line runs across to the next face. This is different from the case of CP holes, ascenders, descenders, defects and, if we follow through with this, artificial features. In that case, if you have an interruption in a line, you don't create two tags (one to mark the beginning of the section of the text before the interruption, and another to mark the beginning of the text after the interruption), but only a single one (to mark the interruption itself).

Leaving that matter aside and coming back to the current point: you have not replied explicitly pro or con to the suggestions I made above. It seems to me that you tacitly agree with introducing a new @type of imposed space. Is that right? Do you also agree that we can make do with a single new type and do not need two (or more) new types for "artwork interrupting the text" and "seal attachment interrupting the text"? Can you also accept forbidding @quantity and @unit on all imposed spaces, thereby simplifying our encoding?

If it's "no" to any of the above, then let's continue the discussion and figure out a solution. If it's "yes" to all, I'll revise the EG accordingly. I'll try to think of a better token than "feature", but I don't have one at the moment and don't think anyone will have trouble with a little bit of ambiguity in that term when it is contrasted with "defect" (reminding me of "bug versus feature" in IT), so I guess it'll stay. Alternatively, we could decide to scrap "defect" and just use "feature" in the future, regardless of whether we are talking about an unintentional or intentional feature of the surface. But I would rather keep this distinction: it makes intuitive sense even if I can't think of any particular purpose why we would want it.

[arlogriffiths]

It's "yes" to all. I am now revising the XML file initially encoded by Amandine in which context the issue arose, and am appklyon @type="feature".

[arlogriffiths]

@ajaniak : could you update the schema to allow this @type on <space>?

[danbalogh]

OK, thanks. Will update the EGD.

[ajaniak]

I have updated the schema

[danbalogh]

Thanks. I think we can consider this resolved.