empty <rdg/> "should" rather than "may" be used

[ebeshero]

Per this discussion on the TEI Listserv , we should change the phrasing of the Guidelines 12.4 :
from:
"An omission in one witness may be encoded using an empty rdg"

to:

"An omission in one witness should be encoded using an empty rdg"

to help indicate that this is a practice we recommend.

[jamescummings]

I've got an issue #1175 to review modal verbs throughout. I got part way through just before last release. Happy to add this one to the list. (Though not yet convinced ... there are those who may not wish to encode absences in this way. I'll think about it and report back.)

[ebeshero]

@jamescummings What alternatives are you aware of? The listserv discussion linked here and Marjorie's tutorial (linked in the listserv discussion) covers some alternatives, but these are all basically signaled by the absence of the witness in the <app>. It seems a stronger and clearer signal to encode an empty <rdg/> instead, because that way the scholarly editor doesn't risk the possibility of forgetting to mention the missing witness. The discussion was about providing a clearer recommendation for Best Practice, which seems the right thing to do here.

[jamescummings]

@ebeshero I'm thinking primarily from the point of view of retrospective conversion. There are plenty of editions which signal omissions in a variety of other ways. (Notes inside the rdg for example). By changing this to should, we are saying that conversions which can't determine this are somehow now unstandard when they were before... but I've not had time to think about it yet really. Just offering to do so.

[ebeshero]

@jamescummings Good point...our conversation on the list is related to an update to collateX and certainly connected to recent developments on automated collation. They want to make sure they're following what TEI would recommend as best practice here, fwiw.

[lb42]

I share james reservations, I think. Didn't we just decide that the preferred way of indicating an empty content model was to use an explicit EMPTY element rather than simply offer an empty CONTENT element? Its not exactly the same thing, of course, but close enough to be confusing.

[hcayless]

I think I'm probably responsible for the "may", and I think I was wrong. The examples in that section need a revisit too. Also, we're not talking about changing content models here. If your practice was to indicate a witness omission with rdg/note, then that's still ok. I would argue strongly that do so isn't a best practice, but tightening up our recommendation isn't going to invalidate it.

[jamescummings]

@hcayless My worry is still mainly that all of the discussion about it seems to be thinking that people are hand-creating born-digital editions rather than doing retrospective conversion or legacy data migration where they may not be able to generate an empty <rdg/> for each witness for each <app>. It is the entire reason that silly location-referenced method exists. ;-) But there may be many many reasons an edition does not cite every witness in each critical apparatus note. For example only referencing significant variations because of a space limit imposed by print constraints. So they haven't included the variation in manuscript Z at that point because it just isn't interesting, but in other apparatus notes they have. I'm not saying this would be a good edition and don't have a good example to hand but I'm sure I've seen them. So in converting these we'd be putting an additional barrier in front of them. I realise there is always a way, given enough developer time, to extract data in better ways, but I'm just trying to make sure we're not raising that bar to entry without considering the other effects. If you had said that the change should be: "In born digital editions an omission in one witness should be encoded using an empty <rdg/> element." (or something better phrased) then I think I wouldn't be trying so hard to make sure we're clear about the side effects of the change.

[hcayless]

Ah, ok. I think that concern is orthogonal to the question of how you'd encode an omission. The editor is still entirely free to note or not note variation at any point, in markup or not. There is a wide range of practice in this area that has more to do with textual criticism than markup. I don't think an editor can or should ever be required to mark all variation in a digital edition. Possibly what we need then are some general remarks about editorial practice.

Possibly this was what was in my head when I wrote "may" (if it was me). But I still think that if you want to encode an omission, the right way to do it is with an empty rdg. If you don't want to, then you should do nothing at all.

[jamescummings]

Sure, if you are asking me how I'd encode an omission, then we are in complete agreement.
If you give me a stack of 10,000 critical editions from google books images and want me to generate TEI files for them, then I'd probably have different answer. I think that can be solved entirely by explaining the instances where one should do this and where one may choose (with proper understanding) to not do this. i.e. license the not doing of this where it is a significant barrier to using the TEI. Perhaps something like:

In the creation of digital editions an omission in one witness should be encoded using an empty <rdg/> element. While this is the general recommendation for most cases, it is not required and where it might cause difficulties (e.g. in retrospective conversion) then the choice not to do so should be documented in the <encodingDesc>.

(assuming encodingDesc is the right place to document that?)

[hcayless]

I have rewritten the sentence so as not to imply that all witness omissions need to be encoded:

An editor wishing to signal an omission in one witness
should encode the omission using an empty <gi>rdg</gi>, thus:

<egXML xmlns="http://www.tei-c.org/ns/Examples"><app xml:id="d1e372">
 <lem xml:id="d1e373" source="#Heyworth"><l n="18">Hypsipyle uacuo constitit in thalamo:</l></lem>
 <rdg xml:id="d1e376" wit="#J" cause="homeoarchon"/>
</app></egXML>

I think @jamescummings comment is right, and that further elaboration is needed on the relationship between editorial practice/theory and encoding practice. But I think that's a somewhat larger issue, and will end up being a paragraph or so of prose added to the TC chapter. I'm going to close this ticket and open one that addresses that task.