Critical Apparatus - Revision history

Malte at 08:31, 6 August 2010

2010-08-06T08:31:28Z

Stuartyeates at 19:48, 4 August 2010

2010-08-04T19:48:45Z

Stuartyeates at 19:40, 4 August 2010

2010-08-04T19:40:25Z

Gailey at 16:38, 4 August 2010

2010-08-04T16:38:01Z

Gailey: New page: category:Critical Apparatus ==Notes== The following is a collection of responses to our query about what TEI users would like to be able to do with the Apparatus module. ==From Gab...

2010-08-04T16:36:31Z

New page: category:Critical Apparatus ==Notes== The following is a collection of responses to our query about what TEI users would like to be able to do with the Apparatus module. ==From Gab...

New page

[[category:Critical Apparatus]]

==Notes==

The following is a collection of responses to our query about what TEI users would like to be able to do with the Apparatus module.

==From Gabriel Bodard==

I would approach this question differently. I don't think redesigning the Apparatus module of TEI is a question of saying what is wrong with the existing module, but of looking at the problem from the ground up and asking, what would we like the Apparatus module to do?

For my part, everything that I want to be able to do with the critical apparatus, I can (now) do, having made some proposals a couple of years ago which led to some tweaking of the content model. One might argue some of this is a bit tortuous, perhaps (e.g. rdg is now optional in app), but it works.

In the kinds of digital texts I work with apparatus can contain the following distinct kinds of content:

*(1) a variant reading, either from a parallel text, or a supplement from a more complete copy of the text;
*(1a) a difference in opinion between editors (e.g. restoring lost text or expanding an abbreviation);
*(2) a comment on or description of a specific word or sequence of characters, describing damage or uncertainty, for example;
*(3) a comment on the text as a whole, the condition of the surface or support, say; i.e. a note not requiring a pointer to location;
*(4) a pointer to a particular markup construction in the text transcription itself, e.g. choice or app or subst, which contains more information than can be represented in the standard conventions (e.g. Leiden) of display; the "hidden" information can be automatically called in and represented in the apparatus.

We tend not in my field to have much need for Lachmannian or genetic apparatus, so I've never worried about those.

When James and I discussed rebooting the Apparatus module a year or two ago, we thought not of picking at the TEI module with a bunch of markup experts and seeing if we could improve it, but rather of starting with a conversation completely outside of the TEI world with a bunch of textual scholars (the Apparatus Criticus YahooGroup was identified as a promising venue) to discuss what a brand-new Apparatus module would look like. (We never got around to getting this off the ground, but that doesn't mean we couldn't still.)

==From James Cummings==

We tend not in my field to have much need for Lachmannian or genetic apparatus, so I've never worried about those.

Others are more expert than I in this, but I suspect those are certainly some of the areas where critapp might need improvement. I don't know how useful an apparatus might be in relating different

One of the things I noticed, which is probably more an indication of poor editorial workflow than problems with , when editing a series of witnesses into a single parallel-segmentation model was that it was quite difficult for me to pre-determine an adequate level of granularity. So each time a new witness was added, the borders of the <app> would often expand or contract depending on the nature of the variation. So in the following example:
<source>
<p> The <app>
<rdg wit="#A #B">cat</rdg>
<rdg wit="#C">dog</rdg>
</app> sat <app>
<rdg wit="#A #C">on the mat</rdg>
<rdg wit="#B">on the newspaper</rdg></app>.</p>
</source>

When witness #D is encoded and the phrase is 'The mongrel dog shat on the newspaper on the mat'...then I'm faced with a series of interesting editorial questions to be resolved before I can encode it, when witness #E is edited and overlaps in a different way...well you get the picture. Of course, if each word is encoded as an app, this is less of a problem but one loses other things. None of this indicates a real problem with critapp itself...in fact it copes with it quite well, but is like many TEI modules torn in two directions. It simultaneously allows you to encode an existing critical apparatus, as well as allowing you to structurally mark data in such a way as to enable you iteratively to generate such an apparatus. I'm much less interested in the former and more interested in the iterative nature of the latter (how we can make it better for those who are slowing building a deeply encoded resource by adding in one witness at a time).

When James and I discussed rebooting the Apparatus module a year or two ago, we thought not of picking at the TEI module with a bunch of markup experts and seeing if we could improve it, but rather of starting with a conversation completely outside of the TEI world with a bunch of textual scholars (the Apparatus Criticus YahooGroup was identified as a promising venue) to discuss what a brand-new Apparatus module would look like. (We never got around to getting this off the ground, but that doesn't mean we couldn't still.)

We did post a couple messages I recall, but no one really bit. What I'd say is that we might want to start discussing it hear in a TEI-specific instance and then when wanting to solicit information about 'how would people solve this' or 'do people actually do that' in a general non-markup question, that we might want to raise it there as well.

==From Dan O'Donnell==

Your issue with granularity, James, is in my view a fundamental issue of collation that the digital world has pointed out: in print you can fudge things a little, but in digital--especially if you are going to to a full segmented parallel text, you need to decide on what your collation units are going to be. Word? Phrase? line or paragraph?

Another thing that digital really emphases is what you can actually collate against each other. It is really difficult, for example, to collate inversions, unless your collation unit is some kind of phrase; in which case you lose the ability to collate spelling--especially spelling in inversions. Peter Robinson really took a solid approach to this in his work, but separating spelling out from other kinds of collation with his spelling databases.

==From Roberto Rosselli Del Turco==

I think James nailed it. I'd say that the current module is fine for
encoding existing critical apparatus of printed editions, but perhaps
less than adequate to allow for dynamic generation of the same in an
electronic edition (which, btw, is the development we should be
interested in more than everything else, in my opinion). The Parallel
Segmentation Method, for instance, is described as being "always [...]
satisfactory when there are just two texts for comparison", but it "will
become less convenient as traditions become more complex" etc., which is
somewhat off-putting when you think of the introductory paragraph and
the goodness it hints at.

I also agree with Elena that, again, there's a strong bias towards
Lachmannian editions apparatus, which makes it less than suitable for
genetic editions: so that's another aspect that needs attention.

Last but not least, in my students' experience (and also in some well
known scholar's, I might add), the current module is quite cumbersome.
This could also be due to the fact that it proposes different methods,
or the wording it uses, I don't know exactly (although I must say that
this was the module that had me re-reading it over and over again when I
first started studying the TEI Guidelines). So the task is not only to
add more functionalities and more granularity, but also not to make it
too difficult for people who've just started learning TEI.

-----------

==From Elena Pierazzo==

Hi all,

... and thanks to have started the discussion!

In the genetic edition workgroup the main issue has been the incapability of critapp to qualify variants. When you are collating two manuscripts written by teh same author (meaning they are not scribal copies, but different versions of the same text) you would like to be able to tell the kind of operation done by the author. so, to reause James example:

<source>
<p> The <app>
<rdg wit="#A #B">cat</rdg>
<rdg wit="#C">dog</rdg>
</app> sat <app>
<rdg wit="#A #C">on the mat</rdg>
<rdg wit="#B">on the newspaper</rdg></app>.</p>
</source>

You would like to say that <source><rdg wit="#C">dog</rdg></source> represent a substitution, while in
<source><rdg wit="#D">mongrel dog</rdg></source> 'mongrel' is an addition.

If you encode <rdg wit="#D"><add>mongrel</add> dog</rdg> it seems that the word as been added within the same manuscript (perhaps in the margin or superlinearly), so we where stuck on this point, wondering whether we should invent a new set of elements (like <interAdd> or <interDel> or whatever), or use an attribute on <add> or...???
Teh point is that the argument 'e-silentio' which lay at the base of a traditional apparatus does not help when you want to describe the operations done by an author while redrafting her/his own text.

The other big issue for us was how to describe transpositions, which happen very very often in an authorial process; while we were able to find a way to describe them at manuscript level (see http://users.ox.ac.uk/~lou/wip/geneticTEI.doc.html#index.xml-body.1_div.3_div.2_div.4), we were not able to describe within an apparatus other than an omission on one side and an addition at another...

@@ Line 34: / Line 34: @@
 One of the things I noticed, which is probably more an indication of poor editorial workflow than problems with , when editing a series of witnesses into a single parallel-segmentation model was that it was quite difficult for me to pre-determine an adequate level of granularity.  So each time a new witness was added, the borders of the <app> would often expand or contract depending on the nature of the variation.  So in the following example:
-*<p> The <app>
+<pre>
-*<rdg wit="#A #B">cat</rdg>
+ <p> The <app>
-*<rdg wit="#C">dog</rdg>
+            <rdg wit="#A #B">cat</rdg>
-*</app> sat <app>
+            <rdg wit="#C">dog</rdg>
-*<rdg wit="#A #C">on the mat</rdg>
+         </app> sat <app>
-*<rdg wit="#B">on the newspaper</rdg></app>.</p>
+            <rdg wit="#A #C">on the mat</rdg>
+            <rdg wit="#B">on the newspaper</rdg>
 When witness #D is encoded and the phrase is 'The mongrel dog shat on the newspaper on the mat'...then I'm faced with a series of interesting editorial questions to be resolved before I can encode it, when witness #E is edited and overlaps in a different way...well you get the picture.  Of course, if each word is encoded as an app, this is less of a problem but one loses other things.  None of this indicates a real problem with critapp itself...in fact it copes with it quite well, but is like many TEI modules torn in two directions.  It simultaneously allows you to encode an existing critical apparatus, as well as allowing you to structurally mark data in such a way as to enable you iteratively to generate such an apparatus.  I'm much less interested in the former and more interested in the iterative nature of the latter (how we can make it better for those who are slowing building a deeply encoded resource by adding in one witness at a time).
@@ Line 92: / Line 95: @@
 In the genetic edition workgroup the main issue has been the incapability of critapp to qualify variants. When you are collating two manuscripts written by teh same author (meaning they are not scribal copies, but different versions of the same text) you would like to be able to tell the kind of operation done by the author. so, to reause James example:
-*<p> The <app>
+<pre>
-*<rdg wit="#A #B">cat</rdg>
+ <p> The <app>
-*<rdg wit="#C">dog</rdg>
+            <rdg wit="#A #B">cat</rdg>
-*</app> sat <app>
+            <rdg wit="#C">dog</rdg>
-*<rdg wit="#A #C">on the mat</rdg>
+        </app> sat <app>
-*<rdg wit="#B">on the newspaper</rdg></app>.</p>
+            <rdg wit="#A #C">on the mat</rdg>
 You would like to say that <rdg wit="#C">dog</rdg> represent a substitution, while in

@@ Line 1: / Line 1: @@
 [[category:Critical Apparatus]]
 ==Notes==
@@ Line 6: / Line 14: @@
-==From Gabriel Bodard==
+===From Gabriel Bodard===
 I would approach this question differently. I don't think redesigning the Apparatus module of TEI is a question of saying what is wrong with the existing module, but of looking at the problem from the ground up and asking, what would we like the Apparatus module to do?
@@ Line 26: / Line 34: @@
-==From James Cummings==
+===From James Cummings===
 We tend not in my field to have much need for Lachmannian or genetic apparatus, so I've never worried about those.
@@ Line 53: / Line 61: @@
-==From Dan O'Donnell==
+===From Dan O'Donnell===
 Your issue with granularity, James, is in my view a fundamental issue of collation that the digital world has pointed out: in print you can fudge things a little, but in digital--especially if you are going to to a full segmented parallel text, you need to decide on what your collation units are going to be. Word? Phrase? line or paragraph?
@@ Line 59: / Line 67: @@
 Another thing that digital really emphases is what you can actually collate against each other. It is really difficult, for example, to collate inversions, unless your collation unit is some kind of phrase; in which case you lose the ability to collate spelling--especially spelling in inversions. Peter Robinson really took a solid approach to this in his work, but separating spelling out from other kinds of collation with his spelling databases.
-==From Roberto Rosselli Del Turco==
+===From Roberto Rosselli Del Turco===
 I think James nailed it. I'd say that the current module is fine for
@@ Line 86: / Line 94: @@
-==From Elena Pierazzo==
+===From Elena Pierazzo===
 Hi all,

@@ Line 85: / Line 85: @@
 too difficult for people who've just started learning TEI.
 ==From Elena Pierazzo==
@@ Line 93: / Line 92: @@
 ... and thanks to have started the discussion!
-In the genetic edition workgroup the main issue has been the incapability of critapp to qualify variants. When you are collating two manuscripts written by teh same author (meaning they are not scribal copies, but different versions of the same text) you would like to be able to tell the kind of operation done by the author. so, to reause James example:
+In the genetic edition workgroup the main issue has been the incapability of critapp to qualify variants. When you are collating two manuscripts written by teh same author (meaning they are not scribal copies, but different versions of the same text) you would like to be able to tell the kind of operation done by the author. so, to reuse James example:
 <pre>
@@ Line 110: / Line 109: @@
 If you encode <rdg wit="#D"><add>mongrel</add> dog</rdg> it seems that the word as been added within the same manuscript (perhaps in the margin or superlinearly), so we where stuck on this point, wondering whether we should invent a new set of elements (like <interAdd> or <interDel> or whatever), or use an attribute on <add> or...???
-Teh point is that the argument 'e-silentio' which lay at the base of a traditional apparatus does not help when you want to describe the operations done by an author while redrafting her/his own text.
+The point is that the argument 'e-silentio' which lay at the base of a traditional apparatus does not help when you want to describe the operations done by an author while redrafting her/his own text.
 The other big issue for us was how to describe transpositions, which happen very very often in an authorial process; while we were able to find a way to describe them at manuscript level (see http://users.ox.ac.uk/~lou/wip/geneticTEI.doc.html#index.xml-body.1_div.3_div.2_div.4), we were not able to describe within an apparatus other than an omission on one side and an addition at another...