Need for a comprehensive list of app types

[jeffreycwitt]

Please add images or links to other sigla and abbreviations we need to make sure we can handle.

Right now my proposal for handling different variants is by creating a list of <rdg> types.

Each type should alert a processor to the kinds of elements, attributes, and values that will be available for processing within the <rdg> element. The lbp schema can also propose default and customary rendering of each @type, though any processor should have the freedom to experiment with its own rendering of the available data.

Keep in my mind: the @type should be describing a logical pattern and data structure, NOT A RENDERING. We can recommend a traditional way of rendering this data structure, however our primary job here is not to create a rendering, but to catalogue logical types of variants and the best way to structure the data that corresponds to this variant type.

[nivaca]

These come from Ockham's Opera Philosophica. Cheers! NV

[jeffreycwitt]

Prior to our meeting I think we need a working summary of what each of these means and maybe a couple of examples.

I propose we make a separate issue for each apparatus type. Each issue should include an initial definition and description. We can then add examples and discuss the best encoding strategy within each issue.

I'll then use the github tags to collect all these issues into one category.

[jeffreycwitt]

I found this fairly comprehensive list today:

http://udallasclassics.org/maurer_files/APPARATUSABBREVIATIONS.pdf

We will probably not be able to get through this whole list. I think we should prioritize "must have" apparatus type for schema 1.0.0, and then make a set of issues for types we would like to add for version 1.1.0

[nivaca]

Excellent! Cheers, Nick

On Tue, Jun 21, 2016 at 08:39, jeffreycwitt notifications@github.com wrote: I found this fairly comprehensive list today:

http://udallasclassics.org/maurer_files/APPARATUSABBREVIATIONS.pdf [http://udallasclassics.org/maurer_files/APPARATUSABBREVIATIONS.pdf]

We will probably not be able to get through this whole list. I think we should prioritize "must have" apparatus type for schema 1.0.0, and then make a set of issues for types we would like to add for version 1.1.0

— You are receiving this because you commented. Reply to this email directly, view it on GitHub [https://github.com/lombardpress/lombardpress-schema/issues/17#issuecomment-227442508] , or mute the thread [https://github.com/notifications/unsubscribe/ACM7jfy1O5dJPBkefkn2QrVQjyKOkCYdks5qN-mqgaJpZM4I58xE] .

[nivaca]

There are some strange things in this list---things that don't match the standard use I've seen in medieval critical editions. Take e.g. the "addidit (add.)." According to the list, it's use in the same way as "supplevit (supl.)", which is not the standard use. As I've seen in medieval critical editions, "add." is used to note that a Ms. has some text which other Mss. are missing. It isn't a "suppl." (for nobody is supplying missing information) nor a correction (for in this single Ms. it doesn't appear as if the scribe corrected the text). Nick

On Tue, Jun 21, 2016 at 08:39, jeffreycwitt notifications@github.com wrote: I found this fairly comprehensive list today:

http://udallasclassics.org/maurer_files/APPARATUSABBREVIATIONS.pdf [http://udallasclassics.org/maurer_files/APPARATUSABBREVIATIONS.pdf]

We will probably not be able to get through this whole list. I think we should prioritize "must have" apparatus type for schema 1.0.0, and then make a set of issues for types we would like to add for version 1.1.0

— You are receiving this because you commented. Reply to this email directly, view it on GitHub [https://github.com/lombardpress/lombardpress-schema/issues/17#issuecomment-227442508] , or mute the thread [https://github.com/notifications/unsubscribe/ACM7jfy1O5dJPBkefkn2QrVQjyKOkCYdks5qN-mqgaJpZM4I58xE] .

[stenskjaer]

I would like to make my proposal of a draft of a reading type list.

As I wrote in #6 I am actually not quite convinced yet that the @type-tag is strictly necessary, but I am starting to lean to the usefulness of it anyway, since it removes the burden of inferring the reading type from the structure of the tags used from the processor. It also might reduce the risk of mistakes as there needs (I suppose) to be a correspondence between the declared reading type and the type implied by the structure of the tags. If they don't fit, something is wrong. Either the editor has misinterpreted the reading or his encoding does not say what he intended it to say (provided of course that the processor is bug free).

A draft of reading types:

Corrections (changes made in one witness, either by the same or a later hand with the result of an improved text)

• correction-deletion: an erroneous word/phrase is removed from the text, see #24
• correction-addition: a missing word/phrase is added to the text, see #34.
• correction-substitution: an expression is improved by the substitution of a word/phrase by another. The correction-transposition might actually be a type of correction-substitution.
• correction-cancellation: a previous change is cancelled. In the case of deletion, the word is reinstated, in the case of a substitution, the original word/phrase replaces the most recent, in the case of an addition, the added word is removed.

Other (mostly error types)

• omission: The witness lacks a word/phrase. An alternative term: absent, cf. #33.
• addition (in textu, opposite of omission): The witness contains a word/phrase that is not present in all versions of the text. This is used when the presence of the word/phrase is not reflected in the edited text. See more in #32 where I also suggest to use the term present in stead.
• inversion: The order or two words/phrases is inverted in comparison to the edited text.
• iteration: A word/phrase is iterated superfluously (is this an instance of addition?)

These are my suggested type names. As you can see, I prefer underscores to indicate a hierarchical division (meaning that if we wanted correction_deletion_overstrike would signify a subtype of deletions). I am not sure it is better than camelcase, but I think there is a strength in having a specific sign to indicate a structural point rather than just the distinction between upper and lower case letters. I also prefer writing the terms in full to improve readability. What do you think?

There are of course lots of other abbreviations in the critical apparatus (as we see in the long list that @jeffreycwitt linked, or just by glancing at the concspectus siglorum of any critical edition), but most of them don't refer to reading types. I am curious to see how many more you can find.

I think I will start posting issues with examples of each type later today or tomorrow, but if any of you want to, be my guest.

Related issues are #1, #4 and #6.

Edit (2016-06-29):

• Removed correction-restoration as it might be confused with an editor restoring a corrupt passage. That is not a correction that takes place in a witness (which the others are), but a editorial correction. That might be indicated in a different way (do we want to use the @type attribute on the <lem> element? Now the correction-cancellation includes what I previously thought of as a restoration (deletion of deletion, so to speak).
• Removed the correction-transposition and asked whether that might actually be a version of correction-substitution.
• Added short descriptions of the reading types.
• Removed alternative because it seemed to go across a range of the other types. Many (all maybe) of them present alternative readings, to it is actually meaningless.
• Added references to #32 and #33.
• Added reference to #34 on correction-addition.

[jeffreycwitt]

We have attempted to solve this be reducing app types to a set of classes, variations, corrections, and conjecture.

The rendering processor can then decide how it wants to renders these kinds of app entries.

See 1.0.0 critical guidelines Critical Apparatus section.