Yes, thanks.  I wasn’t aware of the double-end-point-attachment method.

******************************
Peter M. Scharf, President
The Sanskrit Library
******************************

On 18 Jan 2021, at 6:51 PM, Patrick McAllister <pma@rdorte.org> wrote:

On Mon, Jan 18 2021, Peter Scharf wrote:

Dear Patrick and colleagues,
Thanks, Patrick, for spelling out the details of the use of the subst, del, and add tags.  However, I’m confused by the statement at the end of your message, “the content of tei:lem becomes the actual lemma in the apparatus, but is not also the accepted text of the edition.”  In my understanding, the content of the lem-element is the accepted text of the edition.  Moreover, to indicate that a particular ms. supports that reading the simplest way is to include the sigla as the content of the wit-attribute in the lem element.
Perhaps you can clarify what you intended.

I made that remark because of how the double-end-point-attachment method
differs from the parallel segmentation method, where the tei:lem has a
different meaning.  With respect to the latter method, your observations
are perfectly correct.

Section “12.1.2 Readings”[1] explains the situation:

“The lem element may also be used to record the base text of the source
edition, to mark the readings of a base witness, to indicate the
preference of an editor or encoder for a particular reading, or (e.g. in
the case of an external apparatus) to indicate precisely to which
portion of the main text the variation applies. Those who prefer to work
without the notion of a base text or who are not using the parallel
segmentation method may prefer not to use it at all. How it is used
depends in part on the method chosen for linking the apparatus to the
text; for more information, see section 12.2 Linking the Apparatus to
the Text.”

So, the tei:lem has different functions, depending on different factors
(some just practical, as in the case of how to link apparatus and text).

The example I gave didn’t use the parallel segmentation method, and so
the tei:lem wasn’t doing anything very useful.

The “vijayaḥ” occurred twice in that example: once in the paragraph,
surrounded by anchors, and once in the lemma element.  The mention in
the lemma would only appear in the apparatus, e.g., the part typically
printed after the line numbers: “1–2 vijayaḥ] ...witnesses ...”.  In this
case, the characters in the paragraph represent the accepted reading,
and not the content of the tei:lem.

The only strong reason (in my opinion) for using tei:lem at all in this
method is to abbreviate longish readings in the apparatus:

“““
<p><anchor xml:id="a"/>a b c d e f<anchor xml:id="f"/></p>
<app from="#a" to="#b">
 <lem>a...f</lem>
 ...
</app>
”””

The “\lemma” command in (re)ledmac in LaTeX is very similar to how
tei:lem is used in an external TEI apparatus:

\edtext{A B C D E F}{\lemma{A...F}\Afootnote{...}}


Hope that clears it up!

On 18 Jan 2021, at 4:08 PM, Patrick McAllister <pma@rdorte.org> wrote:

Dear Peter,

thanks for pointing this out!  It led me to two relevant sections of the
TEI Guidelines, “11.3.1.4 Additions and Deletions”[1] and “11.3.1.5
Substitutions”[2].  They discuss an example that seems to fit the
present problem quite well:

“““
One must have lived longer
with <subst>
<del seq="1">this</del>
<del seq="2">
<add seq="1">such a</add>
</del>
<add seq="2">a</add>
</subst> system, to appreciate its advantages.
”””

This expresses a sequence of changes: “this -> such a -> a”

What’s helpful here is that the TEI Guidelines also give an example of
how to express that with a tei:app element (right at the bottom of
section 11.3.1.5):

“““
One must have lived longer with <app>
<rdg varSeq="1">
<del>this</del>
</rdg>
<rdg varSeq="2">
<del>
 <add>such a</add>
</del>
</rdg>
<rdg varSeq="3">
<add>a</add>
</rdg>
</app> system, to appreciate its advantages.
”””

This example is only about a single witness.  Perhaps an application to
Arlo’s case could look like this:

“““
<app>
<lem wit="#Q">vijayaḥ</lem>
<rdg wit="#P" varSeq="1"><del>va</del>jayaḥ</rdg>
<rdg wit="#P" varSeq="2"><add>vi</add>jayaḥ</rdg>
<rdg wit="#R">vajayo</rdg>
</app>
”””

It’s still not easy to see that witness P supports the chosen reading,
however.  You could add a @sameAs (or @corresp) linking to the reading
you think is right:

“““
<app>
<lem xml:id="lem1" wit="#Q">vijayaḥ</lem>
<rdg wit="#P" varSeq="1"><del>va</del>jayaḥ</rdg>
<rdg wit="#P" varSeq="2" sameAs="#lem1"><add>vi</add>jayaḥ</rdg>
<rdg wit="#R">vajayo</rdg>
</app>
”””

The approach with tei:witDetail is certainly one that’s found in the TEI
Guidelines.  But I find that it is very hard to deal with in processing.
I usually just treat it as a note for a particular witness, and tack it
onto the end of the apparatus entry.  It seems that it’s mainly the text
content that determines the meaning of tei:witDetail (hence the doubts
about @type="pc" etc.).  I suppose if you are working with a large set
of editions you’ll want to express as much of your editorial work in the
structure of the markup, and not leave it up to the prose inside any
element to determine its relevance for your editorial decisions.

I was using something like the following myself, but in view of the
present discussion I’m rethinking this approach:

“““
<p>... <anchor xml:id="A"/>vijayaḥ<anchor xml:id="B"/> ...</p>

<app from="#A" to="#B">
<lem>vijayaḥ</lem>
<rdgGrp type="supports">
  <rdg wit="#Q">vijayaḥ</rdg>
  <rdg wit="#P"><add>vi</add>jayaḥ</rdg>
</rdgGrp>
<rdgGrp type="opposes">
  <rdg wit="#P"><del>va</del>jayaḥ</rdg>
  <rdg wit="#R">vajayo</rdg>
</rdgGrp>
</app>
”””

This is somewhat more verbose, but for me this was the easiest starting
point to get a typeset version from: it avoids the @wit on the tei:lem,
because (in this @from @to approach, the “double-end-point-attached
method”), the content of tei:lem becomes the actual lemma in the
apparatus, but is not also the accepted text of the edition.

The use of tei:rdgGrp is more work to encode, but it’s helpful since it
corresponds nicely to the left (pro) and right (con) part, and the
supporting/opposing readings all go into separate tei:rdg elements.

Arlo’s (and I guess most people’s) expectation for the display was:

vijayaḥ Ppc Q ◇ vajayaḥ Pac vajayo R

It seems to me that the approach with tei:rdgGrp-s is the closest to
this in structural terms.

With best wishes,


On Sat, Jan 16 2021, Peter Scharf wrote:

sic and corr are used for the critical editors corrections and designations of something as read.  They are not for use of in designating the changes made by a manuscript scribe.  To designate changes in a manuscript, use del and add instead.  So if the scribe corrected vajaya to vijaya one would write:

v<del>a</del><add>i</add>jaya

or perhaps if one wants to take syllables as the unit of correction:

<del>va</del><add>vi</add>jaya

This would then be the content of the witness.

******************************
Peter M. Scharf, President
The Sanskrit Library
scharf@sanskritlibrary.org
https://sanskritlibrary.org
******************************

On 15 Jan 2021, at 11:26 PM, Dániel Balogh <danbalogh@gmail.com> wrote:

Dear Arlo,
to your first question, I think it would be best to ask a TEI expert. Maybe one will speak up here; or you could try Axelle. Given the TEI guidelines, I think putting "pc" and so forth as the contents of witDetail is the officially endorsed method. For the second question, I am even less qualified to give an authoritative answer, except that if you do choose to go the second way, i.e. instead of @type on <lem> you use tags within lem, then I think "conj" should correspond to supplied rather than to corr with or without an attribute.
Best,
Dan

On Fri, 15 Jan 2021 at 18:46, Arlo Griffiths <arlo.griffiths@efeo.net <mailto:arlo.griffiths@efeo.net> <mailto:arlo.griffiths@efeo.net <mailto:arlo.griffiths@efeo.net>>> wrote:
Dear Dan and Andrew,

Wonderful. We’ll adopt that use of <witDetail> in the DHARMA Encoding Guide for Critical Editions, but whould it not be better to do it in this way?

<witDetail wit="#P" type="ac"/>
<witDetail wit="#P" type="pc"/>

Andrew’s version of my approach 2 would not have worked for us, for the reason that Andrew points out himself, that a given <lem> or <rdg> may be
supported by more than one witness, and the @type would not succeed in making clear to which of the witnesses the label ac/pc applies.

Also, in our Encoding Guide as it stands now we have prescribed the following use of @type on <lem>:

‘If
the adopted reading is not directly supported by any of the witnesses, then you must apply to the <lem> an attribute @type. The permitted values are “norm”, “conj” and “emn”, respectively for normalization, conjecture and emendation.’


Examples:


<lem type=“norm”>pariśrānto ’pi</lem>
<lem
type=“emn”>pariśrānto ’pi</lem>
<lem
type=“conj”>pariśrānto ’pi</lem>

This discussion now has
made me wonder whether it would perhaps be preferable to encode those three scenarios as follows:


<lem><reg>pariśrānto ’pi</reg</lem>
<lem><corr cert="low">pariśrānto ’pi</corr</lem>
<lem><corr>pariśrānto
’pi</corr</lem>

Thanks in advance for further feedback on the pros and cons of either method.

Best wishes,

Arlo



Le 15 janv. 2021 à 17:15, Andrew Ollett <andrew.ollett@gmail.com <mailto:andrew.ollett@gmail.com> <mailto:andrew.ollett@gmail.com <mailto:andrew.ollett@gmail.com>>> a écrit :

Hmm, Dániel’s suggestion of witDetail seems like it's the most straightforward and most TEI-compliant. I'll have to start using it in my project!

On Fri, Jan 15, 2021 at 10:06 AM Dániel Balogh <danbalogh@gmail.com <mailto:danbalogh@gmail.com> <mailto:danbalogh@gmail.com <mailto:danbalogh@gmail.com>>> wrote:
Hello, while I have no experience with critical editions in TEI, I can't resist chiming in. My first thought was that witnesses should be defined separately for P, Pac and Ppc. This may be a bit cumbersome, but it gets what you want without hacking TEI, and is methodologically simple. I've had a look at the Digital Latin Library linked by Andrew, and it seems that this is one of the two methods they propose (https://digitallatin.github.io/guidelines/LDLT-Guidelines.html#apparatus-criticus-correction-as-metadata <https://digitallatin.github.io/guidelines/LDLT-Guidelines.html#apparatus-criticus-correction-as-metadata> <https://digitallatin.github.io/guidelines/LDLT-Guidelines.html#apparatus-criticus-correction-as-metadata <https://digitallatin.github.io/guidelines/LDLT-Guidelines.html#apparatus-criticus-correction-as-metadata>>), while their other method (in the section to which Andrew links, https://digitallatin.github.io/guidelines/LDLT-Guidelines.html#apparatus-criticus-correction-specs <https://digitallatin.github.io/guidelines/LDLT-Guidelines.html#apparatus-criticus-correction-specs> <https://digitallatin.github.io/guidelines/LDLT-Guidelines.html#apparatus-criticus-correction-specs <https://digitallatin.github.io/guidelines/LDLT-Guidelines.html#apparatus-criticus-correction-specs>>) involves the use of the TEI element <witDetail> (https://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPLW <https://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPLW> <https://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPLW <https://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPLW>>), which seems to be the proper TEI-sanctioned method for adding anything about a particular witness at a particular spot, including but not limited to "ac" and "pc".
Having thought a bit about this, I think your encoding use this latter method. According to TEI, witDetail is " a specialized note, which can be linked to both a reading and to one or more of the witnesses for that reading " and which " refers to the closest preceding lem <https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-lem.html <https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-lem.html>> or rdg <https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-rdg.html <https://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-rdg.html>>. " Thus, you might use

<app>
<lem wit=”#P #Q”>vijayaḥ</lem>
<rdg wit=”#P”>vajayaḥ</rdg>
<witDetail wit="#P">ac</witDetail>
<rdg wit=”#R”>vajayo</rdg>
</app>
--- assuming that a siglum by default means the PC reading, and only the AC reading needs to be indicated separately, to make your encoding simpler;
or,
<app>
<lem wit=”#P #Q”>vijayaḥ</lem>
<witDetail wit="#P">pc</witDetail>
<rdg wit=”#P”>vajayaḥ</rdg>
<witDetail wit="#P">ac</witDetail>
<rdg wit=”#R”>vajayo</rdg>
</app>
-- assuming that both the PC and the AC readings need to be tagged explicitly.

All best,
Dan

On Fri, 15 Jan 2021 at 16:38, Andrew Ollett <andrew.ollett@gmail.com <mailto:andrew.ollett@gmail.com> <mailto:andrew.ollett@gmail.com <mailto:andrew.ollett@gmail.com>>> wrote:
Dear Arlo,

I have opted for solution #2 (marking corrections with @type, although in those cases I mark both the a.c. and p.c. reading with type):
e.g.
<app>
<lem wit="#J" type="pc">मेत्ता</lem>
<rdg wit="#J" type="ac">मत्ता</rdg>
<rdg source="#N #Bh">मित्ता</rdg>
</app>
rendered (in XeLaTeX with reledmac):
<image.png>
and for the opposite situation:
<app>
<lem wit="#J" type="ac">णो</lem>
<rdg wit="#J" type="pc" source="#N #Bh">णे</rdg>
</app>
rendered:
<image.png>

The only problem with this is that the @type attribute applies to the entire rdg/lem element, which means that if there are other attributes indicating other manuscripts or sources (as the second example shows), nothing explicitly links "a.c." or "p.c." to the manuscript witness. In my setup I have a convention whereby these @type attributes are interpreted as "going with" with @wit attribute, not with the @source attribute, but in a situation where you have multiple witnesses, you might need to refine this.

I note that the Digital Latin Library has (independently) adopted a similar approach: https://digitallatin.github.io/guidelines/LDLT-Guidelines.html#apparatus-criticus-correction-specs <https://digitallatin.github.io/guidelines/LDLT-Guidelines.html#apparatus-criticus-correction-specs><https://digitallatin.github.io/guidelines/LDLT-Guidelines.html#apparatus-criticus-correction-specs <https://digitallatin.github.io/guidelines/LDLT-Guidelines.html#apparatus-criticus-correction-specs>>

Another, probably better, option is to use <rdgGrp> for all of the readings of a particular witness, although this makes rendering/processing a little bit more difficult.

Andrew

On Fri, Jan 15, 2021 at 9:16 AM Arlo Griffiths <arlo.griffiths@efeo.net <mailto:arlo.griffiths@efeo.net> <mailto:arlo.griffiths@efeo.net <mailto:arlo.griffiths@efeo.net>>> wrote:
Dear colleagues,

Say we have declared three witnesses P Q and R and we are facing a scenario whereby the accepted reading is in one case the result of scribal correction in the witness.

Say that the display I desire is like this:

vijayaḥ
Ppc
Q
◇ vajayaḥ
Pac
vajayo
R


How
do I get there? I am surprised to find no guidance in the TEI guidelines.


I
have imagined the following two encoding approaches. What do you think?


APPROACH
1
<app>

<lem wit=”#P #Q”>vijayaḥ</lem>
<rdg wit=”#P”><sic>vajayaḥ</sic></rdg>
<rdg wit=”#R”>vajayo</rdg>
</app>
and its counterpart if it is
actually the ac reading that is accepted:
<app>

<lem wit=”#P #Q”>vijayaḥ</lem>
<rdg wit=”#P”><corr>vajayaḥ</corr></rdg>
<rdg wit=”#R”>vajayo</rdg>
</app>

APPROACH
2
<app>

<lem wit=”#P #Q”>vijayaḥ</lem>
<rdg wit=”#P” type=”ac”>vajayaḥ</sic></rdg>
<rdg wit=”#R”>vajayo</rdg>
</app>
and
its counterpart if it is actually the ac reading that is accepted:
<app>

<lem wit=”#P #Q”>vijayaḥ</lem>
<rdg wit=”#P” type=”pc”>vajayaḥ</sic></rdg>
<rdg wit=”#R”>vajayo</rdg>
</app>



Thanks and best wishes,




Arlo






_______________________________________________
Indic-texts mailing list
Indic-texts@lists.tei-c.org <mailto:Indic-texts@lists.tei-c.org> <mailto:Indic-texts@lists.tei-c.org <mailto:Indic-texts@lists.tei-c.org>>
http://lists.lists.tei-c.org/mailman/listinfo/indic-texts <http://lists.lists.tei-c.org/mailman/listinfo/indic-texts> <http://lists.lists.tei-c.org/mailman/listinfo/indic-texts <http://lists.lists.tei-c.org/mailman/listinfo/indic-texts>>
_______________________________________________
Indic-texts mailing list
Indic-texts@lists.tei-c.org <mailto:Indic-texts@lists.tei-c.org> <mailto:Indic-texts@lists.tei-c.org <mailto:Indic-texts@lists.tei-c.org>>
http://lists.lists.tei-c.org/mailman/listinfo/indic-texts <http://lists.lists.tei-c.org/mailman/listinfo/indic-texts> <http://lists.lists.tei-c.org/mailman/listinfo/indic-texts <http://lists.lists.tei-c.org/mailman/listinfo/indic-texts>>

_______________________________________________
Indic-texts mailing list
Indic-texts@lists.tei-c.org <mailto:Indic-texts@lists.tei-c.org>
http://lists.lists.tei-c.org/mailman/listinfo/indic-texts <http://lists.lists.tei-c.org/mailman/listinfo/indic-texts>

_______________________________________________
Indic-texts mailing list
Indic-texts@lists.tei-c.org <mailto:Indic-texts@lists.tei-c.org>
http://lists.lists.tei-c.org/mailman/listinfo/indic-texts <http://lists.lists.tei-c.org/mailman/listinfo/indic-texts>



Footnotes:
[1]  https://tei-c.org/Vault/P5/4.1.0/doc/tei-p5-doc/en/html/PH.html#PHAD <https://tei-c.org/Vault/P5/4.1.0/doc/tei-p5-doc/en/html/PH.html#PHAD>

[2]  https://tei-c.org/Vault/P5/4.1.0/doc/tei-p5-doc/en/html/PH.html#PHSU <https://tei-c.org/Vault/P5/4.1.0/doc/tei-p5-doc/en/html/PH.html#PHSU>

--
Patrick McAllister
long-term email: pma@rdorte.org <mailto:pma@rdorte.org>
_______________________________________________
Indic-texts mailing list
Indic-texts@lists.tei-c.org
http://lists.lists.tei-c.org/mailman/listinfo/indic-texts



Footnotes:
[1]  https://tei-c.org/Vault/P5/4.1.0/doc/tei-p5-doc/en/html/TC.html#TCAPLR

--
Patrick McAllister
long-term email: pma@rdorte.org