#753 <app> is phrase-level
<app> is considered a phrase-level element, which is just plain WRONG and makes no sense whatsoever. <app> should be allowed to be at the very least paragraph-level. In fact, to reflect reality, <app> should have the same content model as <div>s, i.e. allowed to contain several paragraphs, or even divisions.
There are enough problems with the encoding of critical editions without shooting ourselves in the foot with this nonsensical, self-imposed constraint of the content model of <app>. This has been a plague to critical editors engaging with TEI for ages. I really couldn't care less if abolishing this constraint would make the processing of digital editions trickier. As it is, it makes the encoding of critical editions absurd, which is definitely a bigger problem for the TEI.
Please have mercy on editors and do something!
Diff:
I should add that, if the concern is about a possible increase in the issue of overlapping hierarchies, it has no ground.
1) even at phrase-level, there is a potential for overlapping, with <seg>s for instance, or even other <app>s.
2) if overlapping occurs, i.e. an omission of 1 paragraph and a half for instance, we can still encode that with 2 distinct apps and join then as best as we can.
3) but when a full section, or a full paragraph is omitted or variant in some witness(es), we MUST be given the option to encode that in a simple and straightforward manner.
In a nutshell, extending the content model of app will solve issues without bringing new ones.
I can't see any reason not to accept this request, though I think its going to be quite hard to implement, and will not work with existing tools. So its not an immediate silver bullet, I think.
I share Sebastian's concern that this is not as trivial a change as it may appear to be. As the name suggests, the <app> element was originally conceived of as a way of representing the critical apparatus found in a previously edited text, rather than as a vehicle for representing the analyses behind that annotation (I am aware that this contentious point for some) : hence it is perfectly reasonable for it to function as a phrase level element. To provide something fundamentally different, a bit more thought is needed.
Lou is right to note the tension between descriptive tagging of existing app crit text
(largely inline), and analytical structures for born-digital app crib (which is where I think MB is). This is such a fundamental issue in the TEI across the board (cf dictionaries) that we're not going to solve it here, are we? Which is why I incline to the weedy 80/20 solution of allowing <app> one level in the hierarchy. The alternative seems to be the long-waited fork of the TEI to create the prescriptive borndigitalTEI
(BDTEI).
I think the semantics of app change as soon as you allow to also appear in a model.divLike or model.pLike context and also allow the content model of lem and rdg to contain model.divLike or model.pLike objects. Something about the change of granularity between phrase like to larger chunks of texts including possible fragmentation of sections, etc. makes me think that this is a semantic change to app, and thus I'd rather have a new element than modify app to be allowed to do this. I'm similarly torn but would reluctantly agree with the repurposing of lem and rdg.
I don't, however, deny that there is a need for either some clear guidance (in using existing solutions) or a new element for block apparatus use. In creating that new element we should be very careful that its semantics and use are clear and mitigate those problems of overlap where possible. Inside this new element's rdgs there may well need to be structural duplication and I would argue for a solution which needed to duplicate some text/markup but where possible used the existing global attributes @copyOf @sameAs or similar to reduce this where possible.
I would vote against taking app and just modifying where it can appear.
<appStruct>, anyone?Here's my stab at what would have to be done to support this:
https://github.com/hcayless/TEI-Guidelines/commit/2a9c75743d5f809f47c72b4e3e27e4631a6cbe88#diff-6c109dbc7b2a94a982615c857f04759e
It's not too terrible...I don't agree that we need another new element for
this. What's needed is a change to the guidance for using app: I think now
that there is no (and there was never really intended to be) any legitimate
use of app/lem/rdg for encoding the appearance of an app. crit. in a
critical edition. It's for encoding the semantics of textual variance. And
texts vary at a variety of levels. The main difficulty I see is that this
increases the likelihood of nested apps, which are a pain to process, but
there are lots of things that are a pain to process and we still do them.
On Thu, May 21, 2015 at 5:39 AM, Sebastian Rahtz rahtz@users.sf.net wrote:
Related
Bugs: #753
Dears,
I am always unsettled by this omnipresent divide between apparatus "from print" and "born-digital". I really struggle to understand why there is supposedly such a stark difference.
A printed apparatus is not necessarily inline, of course. Paragraphs and chapters will be omitted or added, and the print apparatus will report that.
I don't think there is a real semantic change if we extend the content model of app. I really see the current situation as a bug, coming from a misunderstanding of what an apparatus is supposed to contain.
Of course it would be better to rethink the full critical apparatus module with a clean slate. But we've been postponing endlessly such corrections of maddening issues like this one, because we've been waiting for a new, cleaner module. But I believe it's really time to take action to correct what can be corrected.
I agree with Hugh, the main consequence will be an increase of nested apps. Not a big deal, really.
Somewhat surprisingly (for the TEI) there's a real confusion here between
what an apparatus does—record information about textual variance deriving
from sources like witnesses, editorial conjectures, and parallel texts—and
how an apparatus looks on the page—a set of (usually highly-compressed)
footnotes. TEI's critical apparatus is for encoding what the apparatus
does, not how it looks when printed. In print, we tend to focus on
small-to-medium-scale variation in the apparatus notes and handle
large-scale variation in other ways (e.g. by printing differing chunks side
by side in the text). TEI's "critical apparatus" tools should address
variation, period, whether micro or macro.
My own opinion is that while major revisions are needed, Marjorie and the
others who have made similar suggestions are right that we shouldn't delay
fixing things that are obviously wrong while we wait on a process that will
likely take years. I'm starting to think what we really need is a Digital
Critical Editions SIG, which would, among other things, be responsible for
the rewriting and ongoing maintenance of the Critical Apparatus chapter.
I'd be happy to help convene one, if folks think it's a good idea.
On Thu, May 21, 2015 at 12:08 PM, Marjorie Burghart mburghart@users.sf.net
wrote:
Related
Bugs: #753
just thinking aloud...
Many people will be familiar with the DiXiT project (Digital Scholarly
Edications Initial Training Network), and I wonder whether you
could ask that project to propose whether it could produce
a revision of the Crit App chapter? i bet someone within DiXiT
has this on their list of tasks anyway….
Sebastian Rahtz
Chief Data Architect
University of Oxford IT Services
+44 1865 283431
It's true that the purpose of <app> is to mark up what an apparatus does, rather than what it looks like on the printed page. However I think that there is or was an implicit assumption that marking up what it does should be expressible as a series of phrase level annotations, if only so that the markup could be "round-tripped" to a conventional printed form. Repurposing this markup to actually BE the variation concerned is not the same thing.
If we'd been going to do that, I think the TEI would have probably used something closer to Sperberg-McQueen's "rhine-delta" markup proposal.
But even "conventional" apparatus deal with chunks at least at the level of the whole verse line.
Related
Bugs: #753
Yes, of course. But they don't typically do it by embedding the whole of the verse line, chapter, etc. within the apparatus. They tend to use subterfuges like notes or comments instead.
In my experience apparatus abbreviate anything over a couple of words. Doesn't mean the app. crit. doesn't deal in chunks larger than the word or phrase.
Sent from my phone.
Related
Bugs: #753
You are right, Hugh, a print apparatus does deal in large chunks of texts.
If a sizeable chunk of text has been omitted, typically, the apparatus will quote as the lemma only a couple of words at the beginning, an ellipsis, and a couple of words at the end. Omissions are the most common examples of apparatus dealing with large portions of texts.
When real variants occur, i.e. when a poem can have two different endings, with two totally different stanza, for instance, then indeed if both versions are deemed interesting the editors will try to find solutions to represent them in the main edition, side by side for instance. But this is a way of visualising the variance, it does not mean that it's different.
This is the key point, surely. When we talk about this being a problem for processing, or posing difficulties in terms of ODD models, we're missing the point. I think encoders need to be able to encode any level of variance using the same markup.
Yes Martin! That's why we need (among other things) a block-level <app>.
Marjorie,
Council has concerns that what you're asking for amounts to altering the TEI Abstract Model, by, e.g., allowing
<p>inside<p>or sequences like<div/><p/><div/>. My own understanding is that a critical edition is a constructed text that provides evidence supporting the editor's argument for its construction and alternatives where they are deemed relevant. Therefore, any TEI critical edition would need to conform to TEI's Abstract Model and if you wanted to align sources where one has a paragraph and the other a chapter, you'd have to make it work (by, e.g., wrapping the paragraph in a div).The question is: are you asking for a mechanism for bypassing the TEI Abstract Model, or do you just want to be able to put larger structures in lem/rdg with the understanding that those structures should be parallel?
Put another way, should your document still be valid if the critical apparatus elements were removed from it?
Hi Hugh!
No, I'm not asking for a mechanism to bypass the TEI abstract model. What is really much needed is the possibility to put
<div>or<p>or<lg>or even<l>in a <lem> or <rdg>. In most cases that will be quite straightforward, and I can't think of examples of editions I know where a paragraph would happen within another paragraph. Besides, as you point out, editions are contructed by the editor, so extreme / borderline cases should be dealt with by adapting the structure of the edition (wrapping the paragraph in a div in your example).The main use of this correction will be, really, the ability to encode simply large omissions or additions, but especially to encode different versions of a text tradition, when for instance a "chanson de geste" has two different possible ending chapters, according to different families of manuscripts. The current situation is especially cumbersome when you are dealing with verse: my intial is precisely a Chanson de geste in verse with 2 possible endings. The ending sections are totally different, the number of stanza is different and they don't even have the same number of verses. Yet, in the present state, the TEI expects you to have <app> only with a verse, which philologically does not make any sense, because a verse in version 1 does not correspond directly to a verse in version 2. But if we can wrap each set of stanza in an <rdg>, then everybiody is happy: that's what philologists want, and the TEI abstract model is not the least abused.
Cheers,
Marjorie
Last edit: Hugh A. Cayless 2015-06-04