<app> of multiple lemmata

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

<app> of multiple lemmata

Daniele Marotta-2

Dear all,

I am encoding the critical edition of Avicenna's Ilāhiyyāt. The text presents parallel lemmata and their apparatus. I would like to find a good way to express this textual phenomenon in TEI. As an example I'll quote another simple text that exposes the encoding scenario. Suppose we need to collate a base text against several witnesses and some of these are not “simple” readings but transmit a second version of the text:

base text: “… it’s been the ruin of many a poor boy…”

witness A: “…it’s been the ruin of many a poor by…”

 

witness B: “…it’s been the ruin of many a poor girl…”

            witness C: “…it’s been the ruin of many a poor girls girl”

In the example the witness A transmits the first version of the text disagreeing with the base text on "boy", whereas the witnesses B and C transmit the second version of the text. Moreover, C is characterized by two phases: the first reads "girls" and the second  corrects it, then it agrees with B again.

I propose the following methods to encode such text, but they presents some flaws for which I am asking your help.

Method A)

<p>… it’s been the ruin of many a poor <anchor <a class="moz-txt-link-freetext" href="xml:id=">xml:id="a1"/>boy<anchor <a class="moz-txt-link-freetext" href="xml:id=">xml:id="a2"/>…</p>

<app from="#a1" to="#a2">
                <rdgGrp ana="#recensio_1">
                               <lem>boy</lem>
                               <rdg wit="#A">by</rdg>
                </rdgGrp>
                <rdgGrp ana="#recensio_2">
                               <lem wit="#B">girl</lem>
                               <rdgGrp ana="#sequence">
                                               <rdg varSeq="1" wit="C">girls</rdg>
                                               <rdg varSeq="2" wit="C"><subst><del>girls</del><add>girl</add></subst></rdg>
                               </rdgGrp>
                </rdgGrp>
</app>

This xml is not TEI valid since the standard declares

element rdgGrp

{…
   (
      ( rdgGrp, wit? )
    | ( ( lem, wit? )?, ( model.rdgLike, wit? ) )*
    | model.noteLike*   )+
}

Therefore <rdgGrp> can't appear after <lem>, because it is not a member of class model.rdgLike.

Method B)

Another hypothesis could be:

<p>… it’s been the ruin of many a poor <anchor <a class="moz-txt-link-freetext" href="xml:id=">xml:id="a1"/>boy<anchor <a class="moz-txt-link-freetext" href="xml:id=">xml:id="a2"/>…</p>

<app ana="recensio_1<a class="moz-txt-link-rfc2396E" href="xml:id=">" xml:id="ap1" from="#a1" to="#a2" exclude="#ap2">
                <lem>boy</lem>
                <rdg wit="#A">by</rdg>
</app>
<app ana="recensio_2<a class="moz-txt-link-rfc2396E" href="xml:id=">" xml:id="ap2" from="#a1" to="#a2" exclude="#ap1">
                <lem wit="#B">girl</lem>
                <rdgGrp ana="sequence">
                               <rdg varSeq="1" wit="C">girls</rdg>
                               <rdg varSeq="2" wit="C"><subst><del>girls</del><add>girl</add></subst></rdg>
                </rdgGrp>
</app>

This xml could be wrong because @from and @to of "ap2" refer to a base text which is different from its <lem>.

Method C)

A third approach could  consider the use of <choice> and <seg> in base text:

<p>… it’s been the ruin of many a poor <choice><seg ana="Recensio_1"><anchor <a class="moz-txt-link-freetext" href="xml:id=">xml:id="a1"/>boy<anchor <a class="moz-txt-link-freetext" href="xml:id=">xml:id="a2"/></seg> <seg ana="Recensio_2"><anchor <a class="moz-txt-link-freetext" href="xml:id=">xml:id="a3"/>girl<anchor <a class="moz-txt-link-freetext" href="xml:id=">xml:id="a4"/></seg></choice>…</p>

<app from="#a1" to="#a2">
                <lem>boy</lem>
                <rdg wit="#A">by</rdg>
</app>
<app from="#a3" to="#a4">
                <lem wit="#B">girl</lem>
                <rdgGrp ana="sequence">
                               <rdg varSeq="1" wit="C">girls</rdg>
                               <rdg varSeq="2" wit="C"><subst><del>girls</del><add>girl</add></subst></rdg>
                </rdgGrp>
</app>

I'm afraid that this way could pose overlap problems in some cases, that is why I have not chosen the parallel segmentation method.

Moreover, I can't guarantee that we won't need to insert in <seg> elements that can't be contained by it.

Note: when we use <rdgGrp>, the witnesses are repeated on each <rdg>, because @wit is member of classes att.rdgPart att.witnessed witDetail, but it is not member of class att.textCritical. Are the guidelines to be corrected where it is written: “The rdgGrp element is a member of class att.textCritical and therefore can carry the wit, type, cause, varSeq, hand, and resp…”?

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPSU

Do you have any suggestions about this issue?

Best

Daniele


Reply | Threaded
Open this post in threaded view
|

Re: <app> of multiple lemmata

Marjorie Burghart-2
So, Avicenna wrote the lyrics of "House of the Rising Sun", right? In De animalibus, presumably... ;)

Joking aside, my first choice would be your 2nd method, with the reading groups. I wonder what the TEI rationale is in forbidding the nesting of rdgGrp elements?

Best regards, Marjorie

----- Mail d'origine -----
De: Daniele Marotta <[hidden email]>
À: [hidden email]
Envoyé: Thu, 12 Jul 2018 09:47:48 +0200 (CEST)
Objet: <app> of multiple lemmata

Dear all,

I am encoding the critical edition of Avicenna's Ilāhiyyāt. The text
presents parallel lemmata and their apparatus. I would like to find a
good way to express this textual phenomenon in TEI. As an example I'll
quote another simple text that exposes the encoding scenario. Suppose we
need to collate a base text against several witnesses and some of these
are not “simple” readings but transmit a second version of the text:

base text: “… it’s been the ruin of many a poor boy…”

witness A: “…it’s been the ruin of many a poor by…”

witness B: “…it’s been the ruin of many a poor girl…”

             witness C: “…it’s been the ruin of many a poor girls girl”

In the example the witness A transmits the first version of the text
disagreeing with the base text on "boy", whereas the witnesses B and C
transmit the second version of the text. Moreover, C is characterized by
two phases: the first reads "girls" and the secondcorrects it, then it
agrees with B again.

I propose the following methods to encode such text, but they presents
some flaws for which I am asking your help.

Method A)

<p>… it’s been the ruin of many a poor <anchor xml:id="a1"/>boy<anchor
xml:id="a2"/>…</p>

<app from="#a1" to="#a2">
<rdgGrp ana="#recensio_1">
<lem>boy</lem>
<rdg wit="#A">by</rdg>
</rdgGrp>
<rdgGrp ana="#recensio_2">
<lem wit="#B">girl</lem>
<rdgGrp ana="#sequence">
<rdg varSeq="1" wit="C">girls</rdg>
<rdg varSeq="2" wit="C"><subst><del>girls</del><add>girl</add></subst></rdg>
</rdgGrp>
</rdgGrp>
</app>

This xml is not TEI valid since the standard declares

element rdgGrp

{…
(
( rdgGrp, wit? )
| ( ( lem, wit? )?, ( model.rdgLike, wit? ) )*
| model.noteLike*)+
}

Therefore <rdgGrp> can't appear after <lem>, because it is not a member
of class model.rdgLike.

Method B)

Another hypothesis could be:

<p>… it’s been the ruin of many a poor <anchor xml:id="a1"/>boy<anchor
xml:id="a2"/>…</p>

<app ana="recensio_1" xml:id="ap1" from="#a1" to="#a2" exclude="#ap2">
<lem>boy</lem>
<rdg wit="#A">by</rdg>
</app>
<app ana="recensio_2" xml:id="ap2" from="#a1" to="#a2" exclude="#ap1">
<lem wit="#B">girl</lem>
<rdgGrp ana="sequence">
<rdg varSeq="1" wit="C">girls</rdg>
<rdg varSeq="2" wit="C"><subst><del>girls</del><add>girl</add></subst></rdg>
</rdgGrp>
</app>

This xml could be wrong because @from and @to of "ap2" refer to a base
text which is different from its <lem>.

Method C)

A third approach couldconsider the use of <choice> and <seg> in base text:

<p>… it’s been the ruin of many a poor <choice><seg
ana="Recensio_1"><anchor xml:id="a1"/>boy<anchor xml:id="a2"/></seg>
<seg ana="Recensio_2"><anchor xml:id="a3"/>girl<anchor
xml:id="a4"/></seg></choice>…</p>

<app from="#a1" to="#a2">
<lem>boy</lem>
<rdg wit="#A">by</rdg>
</app>
<app from="#a3" to="#a4">
<lem wit="#B">girl</lem>
<rdgGrp ana="sequence">
<rdg varSeq="1" wit="C">girls</rdg>
<rdg varSeq="2" wit="C"><subst><del>girls</del><add>girl</add></subst></rdg>
</rdgGrp>
</app>

I'm afraid that this way could pose overlap problems in some cases, that
is why I have not chosen the parallel segmentation method.

Moreover, I can't guarantee that we won't need to insert in <seg>
elements that can't be contained by it.

Note: when we use <rdgGrp>, the witnesses are repeated on each <rdg>,
because @wit is member of classes att.rdgPart att.witnessed witDetail,
but it is not member of class att.textCritical. Are the guidelines to be
corrected where it is written: “The rdgGrp element is a member of class
att.textCritical and therefore can carry the wit, type, cause, varSeq,
hand, and resp…”?
<http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPSU>

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPSU

Do you have any suggestions about this issue?

Best

Daniele
Reply | Threaded
Open this post in threaded view
|

Re: <app> of multiple lemmata

Roberto Rosselli Del Turco-2
Il 12/07/2018 10:26, Marjorie Burghart ha scritto:
> So, Avicenna wrote the lyrics of "House of the Rising Sun", right? In De animalibus, presumably... ;)
>
> Joking aside, my first choice would be your 2nd method, with the reading groups. I wonder what the TEI rationale is in forbidding the nesting of rdgGrp elements?

Just a very hasty note to say that I agree with you and that TEI does
allow nesting of <rdgGrp>s, at least according to its summary page:

http://www.tei-c.org/release/doc/tei-p5-doc/it/html/ref-rdgGrp.html

All best,

R

--

Roberto Rosselli Del Turco   roberto.rossellidelturco at unito.it
Dip. di Studi Umanistici     roberto.rossellidelturco at fileli.unipi.it
Universita' di Torino        VBD: http://vbd.humnet.unipi.it/beta2/
EVT: http://bit.ly/24D9kdE   VC: http://www.visionarycross.org/

  Hige sceal the heardra,     heorte the cenre,
  mod sceal the mare,       the ure maegen litlath.  (Maldon 312-3)

<shamelessPlug>Holidays in Tuscany http://www.imoricci.it/</shamelessPlug>
Reply | Threaded
Open this post in threaded view
|

Re: <app> of multiple lemmata

Torsten Schassan-2
In reply to this post by Marjorie Burghart-2
Dear Daniele,

I may be completely wrong but as far as I understand the concept of lem
vs. rdg, lem should be used to construct *the* (i.e. one and only one)
reading text. This may be the reason why no two lems are allowed, not
even via another rdgGrp.

If you want to represent two version of the text which are more or less
equal in its importance within the transmission, you would probably
still have to encode this as two rdgs and e.g. let the user of your
edition choose which of the versions he/she wants to see in the reading
text. All other readings will be listed and grouped in the apparatus.

Best, Torsten



Am 12.07.2018 um 10:26 schrieb Marjorie Burghart:

> So, Avicenna wrote the lyrics of "House of the Rising Sun", right? In De animalibus, presumably... ;)
>
> Joking aside, my first choice would be your 2nd method, with the reading groups. I wonder what the TEI rationale is in forbidding the nesting of rdgGrp elements?
>
> Best regards, Marjorie
>
> ----- Mail d'origine -----
> De: Daniele Marotta <[hidden email]>
> À: [hidden email]
> Envoyé: Thu, 12 Jul 2018 09:47:48 +0200 (CEST)
> Objet: <app> of multiple lemmata
>
> Dear all,
>
> I am encoding the critical edition of Avicenna's Ilāhiyyāt. The text
> presents parallel lemmata and their apparatus. I would like to find a
> good way to express this textual phenomenon in TEI. As an example I'll
> quote another simple text that exposes the encoding scenario. Suppose we
> need to collate a base text against several witnesses and some of these
> are not “simple” readings but transmit a second version of the text:
>
> base text: “… it’s been the ruin of many a poor boy…”
>
> witness A: “…it’s been the ruin of many a poor by…”
>
> witness B: “…it’s been the ruin of many a poor girl…”
>
>              witness C: “…it’s been the ruin of many a poor girls girl”
>
> In the example the witness A transmits the first version of the text
> disagreeing with the base text on "boy", whereas the witnesses B and C
> transmit the second version of the text. Moreover, C is characterized by
> two phases: the first reads "girls" and the secondcorrects it, then it
> agrees with B again.
>
> I propose the following methods to encode such text, but they presents
> some flaws for which I am asking your help.
>
> Method A)
>
> <p>… it’s been the ruin of many a poor <anchor xml:id="a1"/>boy<anchor
> xml:id="a2"/>…</p>
>
> <app from="#a1" to="#a2">
> <rdgGrp ana="#recensio_1">
> <lem>boy</lem>
> <rdg wit="#A">by</rdg>
> </rdgGrp>
> <rdgGrp ana="#recensio_2">
> <lem wit="#B">girl</lem>
> <rdgGrp ana="#sequence">
> <rdg varSeq="1" wit="C">girls</rdg>
> <rdg varSeq="2" wit="C"><subst><del>girls</del><add>girl</add></subst></rdg>
> </rdgGrp>
> </rdgGrp>
> </app>
>
> This xml is not TEI valid since the standard declares
>
> element rdgGrp
>
> {…
> (
> ( rdgGrp, wit? )
> | ( ( lem, wit? )?, ( model.rdgLike, wit? ) )*
> | model.noteLike*)+
> }
>
> Therefore <rdgGrp> can't appear after <lem>, because it is not a member
> of class model.rdgLike.
>
> Method B)
>
> Another hypothesis could be:
>
> <p>… it’s been the ruin of many a poor <anchor xml:id="a1"/>boy<anchor
> xml:id="a2"/>…</p>
>
> <app ana="recensio_1" xml:id="ap1" from="#a1" to="#a2" exclude="#ap2">
> <lem>boy</lem>
> <rdg wit="#A">by</rdg>
> </app>
> <app ana="recensio_2" xml:id="ap2" from="#a1" to="#a2" exclude="#ap1">
> <lem wit="#B">girl</lem>
> <rdgGrp ana="sequence">
> <rdg varSeq="1" wit="C">girls</rdg>
> <rdg varSeq="2" wit="C"><subst><del>girls</del><add>girl</add></subst></rdg>
> </rdgGrp>
> </app>
>
> This xml could be wrong because @from and @to of "ap2" refer to a base
> text which is different from its <lem>.
>
> Method C)
>
> A third approach couldconsider the use of <choice> and <seg> in base text:
>
> <p>… it’s been the ruin of many a poor <choice><seg
> ana="Recensio_1"><anchor xml:id="a1"/>boy<anchor xml:id="a2"/></seg>
> <seg ana="Recensio_2"><anchor xml:id="a3"/>girl<anchor
> xml:id="a4"/></seg></choice>…</p>
>
> <app from="#a1" to="#a2">
> <lem>boy</lem>
> <rdg wit="#A">by</rdg>
> </app>
> <app from="#a3" to="#a4">
> <lem wit="#B">girl</lem>
> <rdgGrp ana="sequence">
> <rdg varSeq="1" wit="C">girls</rdg>
> <rdg varSeq="2" wit="C"><subst><del>girls</del><add>girl</add></subst></rdg>
> </rdgGrp>
> </app>
>
> I'm afraid that this way could pose overlap problems in some cases, that
> is why I have not chosen the parallel segmentation method.
>
> Moreover, I can't guarantee that we won't need to insert in <seg>
> elements that can't be contained by it.
>
> Note: when we use <rdgGrp>, the witnesses are repeated on each <rdg>,
> because @wit is member of classes att.rdgPart att.witnessed witDetail,
> but it is not member of class att.textCritical. Are the guidelines to be
> corrected where it is written: “The rdgGrp element is a member of class
> att.textCritical and therefore can carry the wit, type, cause, varSeq,
> hand, and resp…”?
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPSU>
>
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPSU
>
> Do you have any suggestions about this issue?
>
> Best
>
> Daniele
>


--
Torsten Schassan - Digitale Editionen, Abteilung Handschriften und
Sondersammlungen
Herzog August Bibliothek, D-38299 Wolfenbuettel, Tel. +49 5331 808-130
Fax -165
Handschriftendatenbank <http://diglib.hab.de/?db=mss>
Reply | Threaded
Open this post in threaded view
|

Re: <app> of multiple lemmata

Hugh Cayless-2
I agree with Torsten, with a couple of additional notes: I personally prefer parallel segmentation and have found it to work even with very complex texts. Second, I'm a little concerned you may be using an out-of-date version of TEI. The current content model of <app> is (excluding attributes) 

( lem?, ( model.rdgLike | model.noteLike | wit | rdgGrp )* )

It is most definitely legal to have a <rdgGrp> following a <lem>.

Hugh

On Thu, Jul 12, 2018 at 8:04 AM Torsten Schassan <[hidden email]> wrote:
Dear Daniele,

I may be completely wrong but as far as I understand the concept of lem
vs. rdg, lem should be used to construct *the* (i.e. one and only one)
reading text. This may be the reason why no two lems are allowed, not
even via another rdgGrp.

If you want to represent two version of the text which are more or less
equal in its importance within the transmission, you would probably
still have to encode this as two rdgs and e.g. let the user of your
edition choose which of the versions he/she wants to see in the reading
text. All other readings will be listed and grouped in the apparatus.

Best, Torsten



Am 12.07.2018 um 10:26 schrieb Marjorie Burghart:
> So, Avicenna wrote the lyrics of "House of the Rising Sun", right? In De animalibus, presumably... ;)
>
> Joking aside, my first choice would be your 2nd method, with the reading groups. I wonder what the TEI rationale is in forbidding the nesting of rdgGrp elements?
>
> Best regards, Marjorie
>
> ----- Mail d'origine -----
> De: Daniele Marotta <[hidden email]>
> À: [hidden email]
> Envoyé: Thu, 12 Jul 2018 09:47:48 +0200 (CEST)
> Objet: <app> of multiple lemmata
>
> Dear all,
>
> I am encoding the critical edition of Avicenna's Ilāhiyyāt. The text
> presents parallel lemmata and their apparatus. I would like to find a
> good way to express this textual phenomenon in TEI. As an example I'll
> quote another simple text that exposes the encoding scenario. Suppose we
> need to collate a base text against several witnesses and some of these
> are not “simple” readings but transmit a second version of the text:
>
> base text: “… it’s been the ruin of many a poor boy…”
>
> witness A: “…it’s been the ruin of many a poor by…”
>
> witness B: “…it’s been the ruin of many a poor girl…”
>
>              witness C: “…it’s been the ruin of many a poor girls girl”
>
> In the example the witness A transmits the first version of the text
> disagreeing with the base text on "boy", whereas the witnesses B and C
> transmit the second version of the text. Moreover, C is characterized by
> two phases: the first reads "girls" and the secondcorrects it, then it
> agrees with B again.
>
> I propose the following methods to encode such text, but they presents
> some flaws for which I am asking your help.
>
> Method A)
>
> <p>… it’s been the ruin of many a poor <anchor xml:id="a1"/>boy<anchor
> xml:id="a2"/>…</p>
>
> <app from="#a1" to="#a2">
> <rdgGrp ana="#recensio_1">
> <lem>boy</lem>
> <rdg wit="#A">by</rdg>
> </rdgGrp>
> <rdgGrp ana="#recensio_2">
> <lem wit="#B">girl</lem>
> <rdgGrp ana="#sequence">
> <rdg varSeq="1" wit="C">girls</rdg>
> <rdg varSeq="2" wit="C"><subst><del>girls</del><add>girl</add></subst></rdg>
> </rdgGrp>
> </rdgGrp>
> </app>
>
> This xml is not TEI valid since the standard declares
>
> element rdgGrp
>
> {…
> (
> ( rdgGrp, wit? )
> | ( ( lem, wit? )?, ( model.rdgLike, wit? ) )*
> | model.noteLike*)+
> }
>
> Therefore <rdgGrp> can't appear after <lem>, because it is not a member
> of class model.rdgLike.
>
> Method B)
>
> Another hypothesis could be:
>
> <p>… it’s been the ruin of many a poor <anchor xml:id="a1"/>boy<anchor
> xml:id="a2"/>…</p>
>
> <app ana="recensio_1" xml:id="ap1" from="#a1" to="#a2" exclude="#ap2">
> <lem>boy</lem>
> <rdg wit="#A">by</rdg>
> </app>
> <app ana="recensio_2" xml:id="ap2" from="#a1" to="#a2" exclude="#ap1">
> <lem wit="#B">girl</lem>
> <rdgGrp ana="sequence">
> <rdg varSeq="1" wit="C">girls</rdg>
> <rdg varSeq="2" wit="C"><subst><del>girls</del><add>girl</add></subst></rdg>
> </rdgGrp>
> </app>
>
> This xml could be wrong because @from and @to of "ap2" refer to a base
> text which is different from its <lem>.
>
> Method C)
>
> A third approach couldconsider the use of <choice> and <seg> in base text:
>
> <p>… it’s been the ruin of many a poor <choice><seg
> ana="Recensio_1"><anchor xml:id="a1"/>boy<anchor xml:id="a2"/></seg>
> <seg ana="Recensio_2"><anchor xml:id="a3"/>girl<anchor
> xml:id="a4"/></seg></choice>…</p>
>
> <app from="#a1" to="#a2">
> <lem>boy</lem>
> <rdg wit="#A">by</rdg>
> </app>
> <app from="#a3" to="#a4">
> <lem wit="#B">girl</lem>
> <rdgGrp ana="sequence">
> <rdg varSeq="1" wit="C">girls</rdg>
> <rdg varSeq="2" wit="C"><subst><del>girls</del><add>girl</add></subst></rdg>
> </rdgGrp>
> </app>
>
> I'm afraid that this way could pose overlap problems in some cases, that
> is why I have not chosen the parallel segmentation method.
>
> Moreover, I can't guarantee that we won't need to insert in <seg>
> elements that can't be contained by it.
>
> Note: when we use <rdgGrp>, the witnesses are repeated on each <rdg>,
> because @wit is member of classes att.rdgPart att.witnessed witDetail,
> but it is not member of class att.textCritical. Are the guidelines to be
> corrected where it is written: “The rdgGrp element is a member of class
> att.textCritical and therefore can carry the wit, type, cause, varSeq,
> hand, and resp…”?
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPSU>
>
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPSU
>
> Do you have any suggestions about this issue?
>
> Best
>
> Daniele
>


--
Torsten Schassan - Digitale Editionen, Abteilung Handschriften und
Sondersammlungen
Herzog August Bibliothek, D-38299 Wolfenbuettel, Tel. +49 5331 808-130
Fax -165
Handschriftendatenbank <http://diglib.hab.de/?db=mss>
Reply | Threaded
Open this post in threaded view
|

Re: <app> of multiple lemmata

Daniele Marotta-2

Dear all,

thank you for your feedback.

Like Marjorie have proposed, I would adopt the method B, but if I understand correctly, having an inner <lem> different from the referred one should not be a problem. Am I right?

With regards to Roberto and Hugh feedback, although TEI does allow nesting of <rdgGrp>s, that is not our case. In fact, we have a <rdgGrp> after a <lem> inside another <rdgGrp>.

<app>
    <rdgGrp ana="#recensio_2">
        <lem wit="#B">girl</lem>
        <rdgGrp ana="#sequence"> ...  </rdgGrp>
    </rdgGrp>
</app>

In the current version of TEI (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-rdgGrp.html)  this xml seem invalid due to model.rdgLike definition.
element rdgGrp
{
   (
      ( rdgGrp, wit? )
    | ( ( lem, wit? )?, ( model.rdgLike, wit? ) )*
    | model.noteLike*
   )+
}

Regarding Torsten and Hugh feedback, I agree with you that I will be probably forced to consider the second version as a reading of the base text.
So are you saying that there is no other way to encode the second version maintaining its dignity of lemma for the editor?
 
Best,
Daniele

On 12/07/2018 14:17, Hugh Cayless wrote:
I agree with Torsten, with a couple of additional notes: I personally prefer parallel segmentation and have found it to work even with very complex texts. Second, I'm a little concerned you may be using an out-of-date version of TEI. The current content model of <app> is (excluding attributes) 

( lem?, ( model.rdgLike | model.noteLike | wit | rdgGrp )* )

It is most definitely legal to have a <rdgGrp> following a <lem>.

Hugh

On Thu, Jul 12, 2018 at 8:04 AM Torsten Schassan <[hidden email]> wrote:
Dear Daniele,

I may be completely wrong but as far as I understand the concept of lem
vs. rdg, lem should be used to construct *the* (i.e. one and only one)
reading text. This may be the reason why no two lems are allowed, not
even via another rdgGrp.

If you want to represent two version of the text which are more or less
equal in its importance within the transmission, you would probably
still have to encode this as two rdgs and e.g. let the user of your
edition choose which of the versions he/she wants to see in the reading
text. All other readings will be listed and grouped in the apparatus.

Best, Torsten



Am 12.07.2018 um 10:26 schrieb Marjorie Burghart:
> So, Avicenna wrote the lyrics of "House of the Rising Sun", right? In De animalibus, presumably... ;)
>
> Joking aside, my first choice would be your 2nd method, with the reading groups. I wonder what the TEI rationale is in forbidding the nesting of rdgGrp elements?
>
> Best regards, Marjorie
>
> ----- Mail d'origine -----
> De: Daniele Marotta <[hidden email]>
> À: [hidden email]
> Envoyé: Thu, 12 Jul 2018 09:47:48 +0200 (CEST)
> Objet: <app> of multiple lemmata
>
> Dear all,
>
> I am encoding the critical edition of Avicenna's Ilāhiyyāt. The text
> presents parallel lemmata and their apparatus. I would like to find a
> good way to express this textual phenomenon in TEI. As an example I'll
> quote another simple text that exposes the encoding scenario. Suppose we
> need to collate a base text against several witnesses and some of these
> are not “simple” readings but transmit a second version of the text:
>
> base text: “… it’s been the ruin of many a poor boy…”
>
> witness A: “…it’s been the ruin of many a poor by…”
>
> witness B: “…it’s been the ruin of many a poor girl…”
>
>              witness C: “…it’s been the ruin of many a poor girls girl”
>
> In the example the witness A transmits the first version of the text
> disagreeing with the base text on "boy", whereas the witnesses B and C
> transmit the second version of the text. Moreover, C is characterized by
> two phases: the first reads "girls" and the secondcorrects it, then it
> agrees with B again.
>
> I propose the following methods to encode such text, but they presents
> some flaws for which I am asking your help.
>
> Method A)
>
> <p>… it’s been the ruin of many a poor <anchor <a class="moz-txt-link-freetext" href="xml:id=">xml:id="a1"/>boy<anchor
> <a class="moz-txt-link-freetext" href="xml:id=">xml:id="a2"/>…</p>
>
> <app from="#a1" to="#a2">
> <rdgGrp ana="#recensio_1">
> <lem>boy</lem>
> <rdg wit="#A">by</rdg>
> </rdgGrp>
> <rdgGrp ana="#recensio_2">
> <lem wit="#B">girl</lem>
> <rdgGrp ana="#sequence">
> <rdg varSeq="1" wit="C">girls</rdg>
> <rdg varSeq="2" wit="C"><subst><del>girls</del><add>girl</add></subst></rdg>
> </rdgGrp>
> </rdgGrp>
> </app>
>
> This xml is not TEI valid since the standard declares
>
> element rdgGrp
>
> {…
> (
> ( rdgGrp, wit? )
> | ( ( lem, wit? )?, ( model.rdgLike, wit? ) )*
> | model.noteLike*)+
> }
>
> Therefore <rdgGrp> can't appear after <lem>, because it is not a member
> of class model.rdgLike.
>
> Method B)
>
> Another hypothesis could be:
>
> <p>… it’s been the ruin of many a poor <anchor <a class="moz-txt-link-freetext" href="xml:id=">xml:id="a1"/>boy<anchor
> <a class="moz-txt-link-freetext" href="xml:id=">xml:id="a2"/>…</p>
>
> <app ana="recensio_1<a class="moz-txt-link-rfc2396E" href="xml:id=">" xml:id="ap1" from="#a1" to="#a2" exclude="#ap2">
> <lem>boy</lem>
> <rdg wit="#A">by</rdg>
> </app>
> <app ana="recensio_2<a class="moz-txt-link-rfc2396E" href="xml:id=">" xml:id="ap2" from="#a1" to="#a2" exclude="#ap1">
> <lem wit="#B">girl</lem>
> <rdgGrp ana="sequence">
> <rdg varSeq="1" wit="C">girls</rdg>
> <rdg varSeq="2" wit="C"><subst><del>girls</del><add>girl</add></subst></rdg>
> </rdgGrp>
> </app>
>
> This xml could be wrong because @from and @to of "ap2" refer to a base
> text which is different from its <lem>.
>
> Method C)
>
> A third approach couldconsider the use of <choice> and <seg> in base text:
>
> <p>… it’s been the ruin of many a poor <choice><seg
> ana="Recensio_1"><anchor <a class="moz-txt-link-freetext" href="xml:id=">xml:id="a1"/>boy<anchor <a class="moz-txt-link-freetext" href="xml:id=">xml:id="a2"/></seg>
> <seg ana="Recensio_2"><anchor <a class="moz-txt-link-freetext" href="xml:id=">xml:id="a3"/>girl<anchor
> <a class="moz-txt-link-freetext" href="xml:id=">xml:id="a4"/></seg></choice>…</p>
>
> <app from="#a1" to="#a2">
> <lem>boy</lem>
> <rdg wit="#A">by</rdg>
> </app>
> <app from="#a3" to="#a4">
> <lem wit="#B">girl</lem>
> <rdgGrp ana="sequence">
> <rdg varSeq="1" wit="C">girls</rdg>
> <rdg varSeq="2" wit="C"><subst><del>girls</del><add>girl</add></subst></rdg>
> </rdgGrp>
> </app>
>
> I'm afraid that this way could pose overlap problems in some cases, that
> is why I have not chosen the parallel segmentation method.
>
> Moreover, I can't guarantee that we won't need to insert in <seg>
> elements that can't be contained by it.
>
> Note: when we use <rdgGrp>, the witnesses are repeated on each <rdg>,
> because @wit is member of classes att.rdgPart att.witnessed witDetail,
> but it is not member of class att.textCritical. Are the guidelines to be
> corrected where it is written: “The rdgGrp element is a member of class
> att.textCritical and therefore can carry the wit, type, cause, varSeq,
> hand, and resp…”?
> <http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPSU>
>
> http://www.tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPSU
>
> Do you have any suggestions about this issue?
>
> Best
>
> Daniele
>


--
Torsten Schassan - Digitale Editionen, Abteilung Handschriften und
Sondersammlungen
Herzog August Bibliothek, D-38299 Wolfenbuettel, Tel. +49 5331 808-130
Fax -165
Handschriftendatenbank <http://diglib.hab.de/?db=mss>

Reply | Threaded
Open this post in threaded view
|

Re: <app> of multiple lemmata

Torsten Schassan-2
Dear Daniele,

>
> Regarding Torsten and Hugh feedback, I agree with you that I will be
> probably forced to consider the second version as a reading of the base
> text.
> So are you saying that there is no other way to encode the second
> version maintaining its dignity of lemma for the editor?
>  

I think that your idea about a lemma and the TEI encoding are in
conflict: The TEI seems to propose that there is no such thing as a text
that has at any place a second lemma with the same dignity as another one.

I, as well, would think that your understanding of such a text with more
than one lemma possible is an edition which should be encoded as two
parallel texts, aligned by some textual structures. (div or whatever)
Thus, each of these texts would have to be encoded separately, including
the readings only for the respective recension. There shouldn't be a
problem to represent this in TEI.

Your idea to store readings of two different texts in one apparatus
entry is why it gets complicated or merely impossible because there are
two different ideas of text involved. Thus, I think, it isn't a
technical problem in the first place but a theoretical.

Best, Torsten


--
Torsten Schassan - Digitale Editionen, Abteilung Handschriften und
Sondersammlungen
Herzog August Bibliothek, D-38299 Wolfenbuettel, Tel. +49 5331 808-130
Fax -165
Handschriftendatenbank <http://diglib.hab.de/?db=mss>
Reply | Threaded
Open this post in threaded view
|

Re: <app> of multiple lemmata

Roberto Rosselli Del Turco-2
Dear Torsten,
actually I think that there is a case where you would want to encode a
second lemma, and it's that of a double recensio edition: you don't have
two separate texts, but only one which diverges at some point for a
short span because of author's subsequent corrections, or other
phenomena (f.i. this may happen in the classical tradition, afaik). This
is exactly what Daniele is dealing with, and I think that encoding two
different versions of the same text wouldn't be suitable for his
edition's purposes.

About the nesting of <rdgGrp>: perhaps this could be an issue / feature
request to open on github? Because I see no reason why this is valid

          <app>
             <rdgGrp ana="#recensio_2">
                <lem wit="#B">girl</lem>
                <rdg></rdg>
                <rdgGrp ana="#sequence">
                   <rdg>whirl</rdg>
                   <rdg>twirl</rdg>
                </rdgGrp>
             </rdgGrp>
          </app>

and this is not

          <app>
             <rdgGrp ana="#recensio_2">
                <lem wit="#B">girl</lem>
                <rdgGrp ana="#sequence">
                   <rdg>whirl</rdg>
                   <rdg>twirl</rdg>
                </rdgGrp>
             </rdgGrp>
          </app>

In other words: if <rdgGrp>s can nest, why can't you have a <rdgGrp> to
group variants unless you have at least one <rdg> before it? It seems
like a bit of a stretch to me.

Best,

R

Il 12/07/2018 16:51, Torsten Schassan ha scritto:

> Dear Daniele,
>
>>
>> Regarding Torsten and Hugh feedback, I agree with you that I will be
>> probably forced to consider the second version as a reading of the base
>> text.
>> So are you saying that there is no other way to encode the second
>> version maintaining its dignity of lemma for the editor?
>>  
>
> I think that your idea about a lemma and the TEI encoding are in
> conflict: The TEI seems to propose that there is no such thing as a text
> that has at any place a second lemma with the same dignity as another one.
>
> I, as well, would think that your understanding of such a text with more
> than one lemma possible is an edition which should be encoded as two
> parallel texts, aligned by some textual structures. (div or whatever)
> Thus, each of these texts would have to be encoded separately, including
> the readings only for the respective recension. There shouldn't be a
> problem to represent this in TEI.
>
> Your idea to store readings of two different texts in one apparatus
> entry is why it gets complicated or merely impossible because there are
> two different ideas of text involved. Thus, I think, it isn't a
> technical problem in the first place but a theoretical.
>
> Best, Torsten
>
>


--

Roberto Rosselli Del Turco   roberto.rossellidelturco at unito.it
Dip. di Studi Umanistici     roberto.rossellidelturco at fileli.unipi.it
Universita' di Torino        VBD: http://vbd.humnet.unipi.it/beta2/
EVT: http://bit.ly/24D9kdE   VC: http://www.visionarycross.org/

  Hige sceal the heardra,     heorte the cenre,
  mod sceal the mare,       the ure maegen litlath.  (Maldon 312-3)

<shamelessPlug>Holidays in Tuscany http://www.imoricci.it/</shamelessPlug>
Reply | Threaded
Open this post in threaded view
|

Re: <app> of multiple lemmata

Hugh Cayless-2
First, apologies for confusing which content model you were talking about, Daniele. I'm not sure why <rdgGrp> doesn't permit <lem> followed by <rdgGrp>. Possibly there's a technical issue with it being hard to create a deterministic content model that allows it. I'll have to look at it and will raise an issue in the Guidelines' GitHub repo.

I still agree with Torsten though. If you're dealing with multiple recensions, either you're going to have a text for each recension, with a <lem> for each, or you're going to have a single text and one <lem> (the other variants being readings).  The definition of <lem> is that it records the "base text" of an edition.

To be sure, there are workarounds for this, but the ones I'm aware of involve forking the text to record the different recensions.

Hugh

On Thu, Jul 12, 2018 at 12:56 PM Roberto Rosselli Del Turco <[hidden email]> wrote:
Dear Torsten,
actually I think that there is a case where you would want to encode a
second lemma, and it's that of a double recensio edition: you don't have
two separate texts, but only one which diverges at some point for a
short span because of author's subsequent corrections, or other
phenomena (f.i. this may happen in the classical tradition, afaik). This
is exactly what Daniele is dealing with, and I think that encoding two
different versions of the same text wouldn't be suitable for his
edition's purposes.

About the nesting of <rdgGrp>: perhaps this could be an issue / feature
request to open on github? Because I see no reason why this is valid

          <app>
             <rdgGrp ana="#recensio_2">
                <lem wit="#B">girl</lem>
                <rdg></rdg>
                <rdgGrp ana="#sequence">
                   <rdg>whirl</rdg>
                   <rdg>twirl</rdg>
                </rdgGrp>
             </rdgGrp>
          </app>

and this is not

          <app>
             <rdgGrp ana="#recensio_2">
                <lem wit="#B">girl</lem>
                <rdgGrp ana="#sequence">
                   <rdg>whirl</rdg>
                   <rdg>twirl</rdg>
                </rdgGrp>
             </rdgGrp>
          </app>

In other words: if <rdgGrp>s can nest, why can't you have a <rdgGrp> to
group variants unless you have at least one <rdg> before it? It seems
like a bit of a stretch to me.

Best,

R

Il 12/07/2018 16:51, Torsten Schassan ha scritto:
> Dear Daniele,
>
>>
>> Regarding Torsten and Hugh feedback, I agree with you that I will be
>> probably forced to consider the second version as a reading of the base
>> text.
>> So are you saying that there is no other way to encode the second
>> version maintaining its dignity of lemma for the editor?
>>   
>
> I think that your idea about a lemma and the TEI encoding are in
> conflict: The TEI seems to propose that there is no such thing as a text
> that has at any place a second lemma with the same dignity as another one.
>
> I, as well, would think that your understanding of such a text with more
> than one lemma possible is an edition which should be encoded as two
> parallel texts, aligned by some textual structures. (div or whatever)
> Thus, each of these texts would have to be encoded separately, including
> the readings only for the respective recension. There shouldn't be a
> problem to represent this in TEI.
>
> Your idea to store readings of two different texts in one apparatus
> entry is why it gets complicated or merely impossible because there are
> two different ideas of text involved. Thus, I think, it isn't a
> technical problem in the first place but a theoretical.
>
> Best, Torsten
>
>


--

Roberto Rosselli Del Turco   roberto.rossellidelturco at unito.it
Dip. di Studi Umanistici     roberto.rossellidelturco at fileli.unipi.it
Universita' di Torino        VBD: http://vbd.humnet.unipi.it/beta2/
EVT: http://bit.ly/24D9kdE   VC: http://www.visionarycross.org/

  Hige sceal the heardra,     heorte the cenre,
  mod sceal the mare,       the ure maegen litlath.  (Maldon 312-3)

<shamelessPlug>Holidays in Tuscany http://www.imoricci.it/</shamelessPlug>
Reply | Threaded
Open this post in threaded view
|

Re: <app> of multiple lemmata

Daniele Marotta-2

Dear Hugh,

thank you for raising an issue in the Guidelines' GitHub about <rdgGrp>. Regarding multiple lemmata, Roberto fully caught our needs. Moreover, as the critical edition is the same, if we had two separate texts with a few diverging points, we would cause too much redundancy. From a teoric  point of view, I will quote the reasons expressed by editors of the Ilahiyyat.

"A reason for our choice to display two versions of one and the same work at a time is the impossibility to make a neat discrimination between a fully authorial version and a non-authorial one and, consequently, the unwillingness to make an arbitrary discrimination of the sort. According to the biographical accounts concerning the composition of the work at stake in our project, the author composed it under the impulse and request of his fellow scholars within a lively intellectual milieu. The work was even the object of public lectures within the author’s school and of a constant debate involving the author and his students and fellows. Arguably, at least a part of the divergences shown by the manuscript tradition can be expected to be the result of modifications due to the constant lectures and discussions around the text that went on incessantly during the entire process of composition. In such a cultural context, it is rather difficult to tell to which extent the modifications to the text that can be individuated as ‘later’ were non-authorial, since they were supposedly introduced during the author’s lifetime and all along the process of composition of the work, and we can expect that the author was well aware of them and might have somehow given his consent to them. The final version of the work reflects not only a scholastic recension of the work, but also somehow a compromise between the author’s first intentions and his school’s requests and needs, and it would be quite interesting to compare the first authorial version of the text that can be reconstructed with the second one, in order to show the author’s effort to meet the requirements of his fellow scholars, who gave impulse to the composition of the work."


On 12/07/2018 19:16, Hugh Cayless wrote:
First, apologies for confusing which content model you were talking about, Daniele. I'm not sure why <rdgGrp> doesn't permit <lem> followed by <rdgGrp>. Possibly there's a technical issue with it being hard to create a deterministic content model that allows it. I'll have to look at it and will raise an issue in the Guidelines' GitHub repo.

I still agree with Torsten though. If you're dealing with multiple recensions, either you're going to have a text for each recension, with a <lem> for each, or you're going to have a single text and one <lem> (the other variants being readings).  The definition of <lem> is that it records the "base text" of an edition.

To be sure, there are workarounds for this, but the ones I'm aware of involve forking the text to record the different recensions.

Hugh

On Thu, Jul 12, 2018 at 12:56 PM Roberto Rosselli Del Turco <[hidden email]> wrote:
Dear Torsten,
actually I think that there is a case where you would want to encode a
second lemma, and it's that of a double recensio edition: you don't have
two separate texts, but only one which diverges at some point for a
short span because of author's subsequent corrections, or other
phenomena (f.i. this may happen in the classical tradition, afaik). This
is exactly what Daniele is dealing with, and I think that encoding two
different versions of the same text wouldn't be suitable for his
edition's purposes.

About the nesting of <rdgGrp>: perhaps this could be an issue / feature
request to open on github? Because I see no reason why this is valid

          <app>
             <rdgGrp ana="#recensio_2">
                <lem wit="#B">girl</lem>
                <rdg></rdg>
                <rdgGrp ana="#sequence">
                   <rdg>whirl</rdg>
                   <rdg>twirl</rdg>
                </rdgGrp>
             </rdgGrp>
          </app>

and this is not

          <app>
             <rdgGrp ana="#recensio_2">
                <lem wit="#B">girl</lem>
                <rdgGrp ana="#sequence">
                   <rdg>whirl</rdg>
                   <rdg>twirl</rdg>
                </rdgGrp>
             </rdgGrp>
          </app>

In other words: if <rdgGrp>s can nest, why can't you have a <rdgGrp> to
group variants unless you have at least one <rdg> before it? It seems
like a bit of a stretch to me.

Best,

R

Il 12/07/2018 16:51, Torsten Schassan ha scritto:
> Dear Daniele,
>
>>
>> Regarding Torsten and Hugh feedback, I agree with you that I will be
>> probably forced to consider the second version as a reading of the base
>> text.
>> So are you saying that there is no other way to encode the second
>> version maintaining its dignity of lemma for the editor?
>>   
>
> I think that your idea about a lemma and the TEI encoding are in
> conflict: The TEI seems to propose that there is no such thing as a text
> that has at any place a second lemma with the same dignity as another one.
>
> I, as well, would think that your understanding of such a text with more
> than one lemma possible is an edition which should be encoded as two
> parallel texts, aligned by some textual structures. (div or whatever)
> Thus, each of these texts would have to be encoded separately, including
> the readings only for the respective recension. There shouldn't be a
> problem to represent this in TEI.
>
> Your idea to store readings of two different texts in one apparatus
> entry is why it gets complicated or merely impossible because there are
> two different ideas of text involved. Thus, I think, it isn't a
> technical problem in the first place but a theoretical.
>
> Best, Torsten
>
>


--

Roberto Rosselli Del Turco   roberto.rossellidelturco at unito.it
Dip. di Studi Umanistici     roberto.rossellidelturco at fileli.unipi.it
Universita' di Torino        VBD: http://vbd.humnet.unipi.it/beta2/
EVT: http://bit.ly/24D9kdE   VC: http://www.visionarycross.org/

  Hige sceal the heardra,     heorte the cenre,
  mod sceal the mare,       the ure maegen litlath.  (Maldon 312-3)

<shamelessPlug>Holidays in Tuscany http://www.imoricci.it/</shamelessPlug>

Reply | Threaded
Open this post in threaded view
|

Re: <app> of multiple lemmata

Hugh Cayless-2
ear Daniele,

This confuses me, and I'd really like to understand it. Apologies if I'm being dense! Your quote says "A reason for our choice to display two versions of one and the same work at a time is the impossibility to make a neat discrimination between a fully authorial version and a non-authorial one..." Doesn't that mean there are two versions of "the text" in the edition? That sounds like exactly the point that I was trying to make... What am I missing?

In general, on this sort of problem, my paper on editing Servius might be of some interest: https://blogs.library.duke.edu/dcthree/2018/01/10/digital-servius/

Thanks,
Hugh


On Fri, Jul 13, 2018 at 8:23 AM Daniele Marotta <[hidden email]> wrote:

Dear Hugh,

thank you for raising an issue in the Guidelines' GitHub about <rdgGrp>. Regarding multiple lemmata, Roberto fully caught our needs. Moreover, as the critical edition is the same, if we had two separate texts with a few diverging points, we would cause too much redundancy. From a teoric  point of view, I will quote the reasons expressed by editors of the Ilahiyyat.

"A reason for our choice to display two versions of one and the same work at a time is the impossibility to make a neat discrimination between a fully authorial version and a non-authorial one and, consequently, the unwillingness to make an arbitrary discrimination of the sort. According to the biographical accounts concerning the composition of the work at stake in our project, the author composed it under the impulse and request of his fellow scholars within a lively intellectual milieu. The work was even the object of public lectures within the author’s school and of a constant debate involving the author and his students and fellows. Arguably, at least a part of the divergences shown by the manuscript tradition can be expected to be the result of modifications due to the constant lectures and discussions around the text that went on incessantly during the entire process of composition. In such a cultural context, it is rather difficult to tell to which extent the modifications to the text that can be individuated as ‘later’ were non-authorial, since they were supposedly introduced during the author’s lifetime and all along the process of composition of the work, and we can expect that the author was well aware of them and might have somehow given his consent to them. The final version of the work reflects not only a scholastic recension of the work, but also somehow a compromise between the author’s first intentions and his school’s requests and needs, and it would be quite interesting to compare the first authorial version of the text that can be reconstructed with the second one, in order to show the author’s effort to meet the requirements of his fellow scholars, who gave impulse to the composition of the work."


On 12/07/2018 19:16, Hugh Cayless wrote:
First, apologies for confusing which content model you were talking about, Daniele. I'm not sure why <rdgGrp> doesn't permit <lem> followed by <rdgGrp>. Possibly there's a technical issue with it being hard to create a deterministic content model that allows it. I'll have to look at it and will raise an issue in the Guidelines' GitHub repo.

I still agree with Torsten though. If you're dealing with multiple recensions, either you're going to have a text for each recension, with a <lem> for each, or you're going to have a single text and one <lem> (the other variants being readings).  The definition of <lem> is that it records the "base text" of an edition.

To be sure, there are workarounds for this, but the ones I'm aware of involve forking the text to record the different recensions.

Hugh

On Thu, Jul 12, 2018 at 12:56 PM Roberto Rosselli Del Turco <[hidden email]> wrote:
Dear Torsten,
actually I think that there is a case where you would want to encode a
second lemma, and it's that of a double recensio edition: you don't have
two separate texts, but only one which diverges at some point for a
short span because of author's subsequent corrections, or other
phenomena (f.i. this may happen in the classical tradition, afaik). This
is exactly what Daniele is dealing with, and I think that encoding two
different versions of the same text wouldn't be suitable for his
edition's purposes.

About the nesting of <rdgGrp>: perhaps this could be an issue / feature
request to open on github? Because I see no reason why this is valid

          <app>
             <rdgGrp ana="#recensio_2">
                <lem wit="#B">girl</lem>
                <rdg></rdg>
                <rdgGrp ana="#sequence">
                   <rdg>whirl</rdg>
                   <rdg>twirl</rdg>
                </rdgGrp>
             </rdgGrp>
          </app>

and this is not

          <app>
             <rdgGrp ana="#recensio_2">
                <lem wit="#B">girl</lem>
                <rdgGrp ana="#sequence">
                   <rdg>whirl</rdg>
                   <rdg>twirl</rdg>
                </rdgGrp>
             </rdgGrp>
          </app>

In other words: if <rdgGrp>s can nest, why can't you have a <rdgGrp> to
group variants unless you have at least one <rdg> before it? It seems
like a bit of a stretch to me.

Best,

R

Il 12/07/2018 16:51, Torsten Schassan ha scritto:
> Dear Daniele,
>
>>
>> Regarding Torsten and Hugh feedback, I agree with you that I will be
>> probably forced to consider the second version as a reading of the base
>> text.
>> So are you saying that there is no other way to encode the second
>> version maintaining its dignity of lemma for the editor?
>>   
>
> I think that your idea about a lemma and the TEI encoding are in
> conflict: The TEI seems to propose that there is no such thing as a text
> that has at any place a second lemma with the same dignity as another one.
>
> I, as well, would think that your understanding of such a text with more
> than one lemma possible is an edition which should be encoded as two
> parallel texts, aligned by some textual structures. (div or whatever)
> Thus, each of these texts would have to be encoded separately, including
> the readings only for the respective recension. There shouldn't be a
> problem to represent this in TEI.
>
> Your idea to store readings of two different texts in one apparatus
> entry is why it gets complicated or merely impossible because there are
> two different ideas of text involved. Thus, I think, it isn't a
> technical problem in the first place but a theoretical.
>
> Best, Torsten
>
>


--

Roberto Rosselli Del Turco   roberto.rossellidelturco at unito.it
Dip. di Studi Umanistici     roberto.rossellidelturco at fileli.unipi.it
Universita' di Torino        VBD: http://vbd.humnet.unipi.it/beta2/
EVT: http://bit.ly/24D9kdE   VC: http://www.visionarycross.org/

  Hige sceal the heardra,     heorte the cenre,
  mod sceal the mare,       the ure maegen litlath.  (Maldon 312-3)

<shamelessPlug>Holidays in Tuscany http://www.imoricci.it/</shamelessPlug>

Reply | Threaded
Open this post in threaded view
|

Re: <app> of multiple lemmata

Roberto Rosselli Del Turco-2
Dear Hugh,
thanks for your answer and the linke, before replying I noticed this bit
in a previous mail of yours:

> I personally prefer parallel segmentation and have found it to work even with very complex texts.

I've been experimenting a little as well with the parallel segmentation
method, f.i. to see if it can be used overlapping variants, would you
like to share your findings? In private if you prefer, but I'd say this
is of interest for the list.

Il 13/07/2018 14:53, Hugh Cayless ha scritto:
> This confuses me, and I'd really like to understand it. Apologies if I'm
> being dense! Your quote says "A reason for our choice to display two
> versions of one and the same work at a time is the impossibility to make
> a neat discrimination between a fully authorial version and a
> non-authorial one..." Doesn't that mean there are two versions of "the
> text" in the edition? That sounds like exactly the point that I was
> trying to make... What am I missing?

Waiting for Daniele's answer, here's my take:

- you don't have two entirely different versions of the work: you are
reconstructing a base text which, at some specific points, has been
modified by the author;
- so, the same base text except you have two equally authoritative
(literally) versions of some text spans, which the project's editors
want to record as such;
- which is why you don't want to use <rdg>: those are not rejected
variants, they all are equally important in the eyes of the editors;
- also you can't have only one <lem> (perhaps using @varSeq) because
each authorial lectio has its actual variants;
- in the end, a <rdgGrp> for each recensio is the solution that makes
more sense IMHO.

Hope that this hasty note makes sense to you, in any case! :)

All best,

R

--

Roberto Rosselli Del Turco   roberto.rossellidelturco at unito.it
Dip. di Studi Umanistici     roberto.rossellidelturco at fileli.unipi.it
Universita' di Torino        VBD: http://vbd.humnet.unipi.it/beta2/
EVT: http://bit.ly/24D9kdE   VC: http://www.visionarycross.org/

  Hige sceal the heardra,     heorte the cenre,
  mod sceal the mare,       the ure maegen litlath.  (Maldon 312-3)

<shamelessPlug>Holidays in Tuscany http://www.imoricci.it/</shamelessPlug>
Reply | Threaded
Open this post in threaded view
|

Re: <app> of multiple lemmata

Daniele Marotta-2
Dear Hugh,

I think that the Roberto's synthesis is clear and expresses well what we
mean with multiple recensio.

All best,

Daniele


On 13/07/2018 16:32, Roberto Rosselli Del Turco wrote:

> Dear Hugh,
> thanks for your answer and the linke, before replying I noticed this
> bit in a previous mail of yours:
>
>> I personally prefer parallel segmentation and have found it to work
>> even with very complex texts.
>
> I've been experimenting a little as well with the parallel
> segmentation method, f.i. to see if it can be used overlapping
> variants, would you like to share your findings? In private if you
> prefer, but I'd say this is of interest for the list.
>
> Il 13/07/2018 14:53, Hugh Cayless ha scritto:
>> This confuses me, and I'd really like to understand it. Apologies if
>> I'm being dense! Your quote says "A reason for our choice to display
>> two versions of one and the same work at a time is the impossibility
>> to make a neat discrimination between a fully authorial version and a
>> non-authorial one..." Doesn't that mean there are two versions of
>> "the text" in the edition? That sounds like exactly the point that I
>> was trying to make... What am I missing?
>
> Waiting for Daniele's answer, here's my take:
>
> - you don't have two entirely different versions of the work: you are
> reconstructing a base text which, at some specific points, has been
> modified by the author;
> - so, the same base text except you have two equally authoritative
> (literally) versions of some text spans, which the project's editors
> want to record as such;
> - which is why you don't want to use <rdg>: those are not rejected
> variants, they all are equally important in the eyes of the editors;
> - also you can't have only one <lem> (perhaps using @varSeq) because
> each authorial lectio has its actual variants;
> - in the end, a <rdgGrp> for each recensio is the solution that makes
> more sense IMHO.
>
> Hope that this hasty note makes sense to you, in any case! :)
>
> All best,
>
> R
>
Reply | Threaded
Open this post in threaded view
|

Re: <app> of multiple lemmata

Torsten Schassan-2
In reply to this post by Roberto Rosselli Del Turco-2
Dear Daniele, dear Roberto,

I don't think that there's a real misunderstanding here, I think Hugh
and I understood you point. But there's a real difference in your
understanding of what the encoded text represents and that you want to
take a short road and save some effort (which I understand perfectly well!):

A text that exists in two recensions, both of which vary only in some
spans, seems to be in its entirety the same text to you but are two
different texts to Hugh and me.

If we agree on that, how about that, thinking from the presentational
aspects of the edited text first:

- The base text is the same for both recensions for most parts and
therefore these parts of the text could/should be presented using one
column.

- Those spans that differ have to be presented side-by-side in order to
show their equal importance.

And coming back to the encoding of this text/these texts: If you want to
take the short road and save some effort, this last aspect should result
in a separate encoding of the spans and both of them can have their own
lemmata and readings. You only have to make clear that the edited text
doesn't run through both of these spans at a stretch but that these
spans are mutually exclusive. (We use to use <choice> for such phenomena
on the phrase level.)

Am I getting it right this way?

Best, Torsten


> - you don't have two entirely different versions of the work: you are
> reconstructing a base text which, at some specific points, has been
> modified by the author;
> - so, the same base text except you have two equally authoritative
> (literally) versions of some text spans, which the project's editors
> want to record as such;
> - which is why you don't want to use <rdg>: those are not rejected
> variants, they all are equally important in the eyes of the editors;
> - also you can't have only one <lem> (perhaps using @varSeq) because
> each authorial lectio has its actual variants;
> - in the end, a <rdgGrp> for each recensio is the solution that makes
> more sense IMHO.
>
> Hope that this hasty note makes sense to you, in any case! :)
>
> All best,
>
> R
>


--
Torsten Schassan - Digitale Editionen, Abteilung Handschriften und
Sondersammlungen
Herzog August Bibliothek, D-38299 Wolfenbuettel, Tel. +49 5331 808-130
Fax -165
Handschriftendatenbank <http://diglib.hab.de/?db=mss>
Reply | Threaded
Open this post in threaded view
|

Re: <app> of multiple lemmata

Roberto Rosselli Del Turco-2
Hello again Torsten

Il 13/07/2018 18:15, Torsten Schassan ha scritto:
> Dear Daniele, dear Roberto,
>
> I don't think that there's a real misunderstanding here, I think Hugh
> and I understood you point. But there's a real difference in your
> understanding of what the encoded text represents and that you want to
> take a short road and save some effort (which I understand perfectly well!):

Actually, there *is* a slight misunderstanding here: Daniele is handling
the text encoding in preparation of the *digital* edition of this work
(and doing an excellent job at it, if I may say so), but the actual
editorial decisions are taken by the editorial pool which is working at
the *printed* edition. In other words, Daniele is trying to translate in
sound TEI encoding solutions the editorial practices that have been
established for the printed version of this edition.

Daniele will correct me if I got it somewhat wrong, of course.

> A text that exists in two recensions, both of which vary only in some
> spans, seems to be in its entirety the same text to you but are two
> different texts to Hugh and me.

I guess we'll have to disagree here :)

> If we agree on that, how about that, thinking from the presentational
> aspects of the edited text first:
>
> - The base text is the same for both recensions for most parts and
> therefore these parts of the text could/should be presented using one
> column.
>
> - Those spans that differ have to be presented side-by-side in order to
> show their equal importance.

This is exactly what is planned both for the printed and the digital
version of this edition, see this screenshot referring to the latter:

https://www.dropbox.com/s/nzccd9zock66xtj/evt2-avicenna-mrecensio-2.png?dl=0

we developed a "Multiple recensio" view into EVT to cater to this
specific need, so that it is very easy to see where there are
divergences due to different recensions in the reconstructed text.

This is better than the standard solution of having two columns because
you're going to access all other features, such as sources and analogues
besides critical apparatus, simply by changing the view (see
http://evt.labcd.unipi.it/demo/evt2-beta1/index.html in any case, still
in beta version though!).

> And coming back to the encoding of this text/these texts: If you want to
> take the short road and save some effort, this last aspect should result
> in a separate encoding of the spans and both of them can have their own
> lemmata and readings. You only have to make clear that the edited text
> doesn't run through both of these spans at a stretch but that these
> spans are mutually exclusive. (We use to use <choice> for such phenomena
> on the phrase level.)

Are you suggesting to use a <choice> with two or more <seg>s one for
each recensio? Fact is, iirc it gets a bit wider than "phrase level", I
wonder if there aren't multiple hierarchy problems barring this approach.

> Am I getting it right this way?

Apart from the fact that this is not "taking the short road", yes :)

Thank you,

R

--

Roberto Rosselli Del Turco   roberto.rossellidelturco at unito.it
Dip. di Studi Umanistici     roberto.rossellidelturco at fileli.unipi.it
Universita' di Torino        VBD: http://vbd.humnet.unipi.it/beta2/
EVT: http://bit.ly/24D9kdE   VC: http://www.visionarycross.org/

   Hige sceal the heardra,     heorte the cenre,
   mod sceal the mare,       the ure maegen litlath.  (Maldon 312-3)

<shamelessPlug>Holidays in Tuscany http://www.imoricci.it/</shamelessPlug>
Reply | Threaded
Open this post in threaded view
|

Re: <app> of multiple lemmata

Hugh Cayless-2
I think I understand what you're doing now, and I disagree with it :-). I don't think the apparatus is the place to handle different recensions. I agree with Torsten that it should be dealt with in the text. To take Daniele's initial example and the way I've proposed doing this sort of thing for Servius, he wrote:

<p>… it’s been the ruin of many a poor <anchor xml:id="a1"/>boy<anchor xml:id="a2"/>…</p>

and I would do

<p>… it’s been the ruin of many a poor <choice<seg source="#recensio_1"><anchor xml:id="a1"/>boy<anchor xml:id="a2"/></seg><seg source="#recensio_2"><anchor xml:id="b1"/>girl<anchor xml:id="b2"/></seg></choice>…</p>

with separate <app>s for #a1...#a2 and #b1...#b2 (I would also do it with inline apparatus, but that's a different argument). 

To be theoretical about it, I think what you're doing is suppressing Recensio 2 by not including it in your text. Obviously that's your choice as an editor, but I don't think the apparatus in TEI really gives you a way to "reinstate" Recensio 2 after having suppressed it. It can only present it as an alternative, i.e. as a <rdg>. The paper I linked to has several examples of this kind of thing. Servius is absolutely full of them.

Hugh

On Fri, Jul 13, 2018 at 12:55 PM Roberto Rosselli Del Turco <[hidden email]> wrote:
Hello again Torsten

Il 13/07/2018 18:15, Torsten Schassan ha scritto:
> Dear Daniele, dear Roberto,
>
> I don't think that there's a real misunderstanding here, I think Hugh
> and I understood you point. But there's a real difference in your
> understanding of what the encoded text represents and that you want to
> take a short road and save some effort (which I understand perfectly well!):

Actually, there *is* a slight misunderstanding here: Daniele is handling
the text encoding in preparation of the *digital* edition of this work
(and doing an excellent job at it, if I may say so), but the actual
editorial decisions are taken by the editorial pool which is working at
the *printed* edition. In other words, Daniele is trying to translate in
sound TEI encoding solutions the editorial practices that have been
established for the printed version of this edition.

Daniele will correct me if I got it somewhat wrong, of course.

> A text that exists in two recensions, both of which vary only in some
> spans, seems to be in its entirety the same text to you but are two
> different texts to Hugh and me.

I guess we'll have to disagree here :)

> If we agree on that, how about that, thinking from the presentational
> aspects of the edited text first:
>
> - The base text is the same for both recensions for most parts and
> therefore these parts of the text could/should be presented using one
> column.
>
> - Those spans that differ have to be presented side-by-side in order to
> show their equal importance.

This is exactly what is planned both for the printed and the digital
version of this edition, see this screenshot referring to the latter:

https://www.dropbox.com/s/nzccd9zock66xtj/evt2-avicenna-mrecensio-2.png?dl=0

we developed a "Multiple recensio" view into EVT to cater to this
specific need, so that it is very easy to see where there are
divergences due to different recensions in the reconstructed text.

This is better than the standard solution of having two columns because
you're going to access all other features, such as sources and analogues
besides critical apparatus, simply by changing the view (see
http://evt.labcd.unipi.it/demo/evt2-beta1/index.html in any case, still
in beta version though!).

> And coming back to the encoding of this text/these texts: If you want to
> take the short road and save some effort, this last aspect should result
> in a separate encoding of the spans and both of them can have their own
> lemmata and readings. You only have to make clear that the edited text
> doesn't run through both of these spans at a stretch but that these
> spans are mutually exclusive. (We use to use <choice> for such phenomena
> on the phrase level.)

Are you suggesting to use a <choice> with two or more <seg>s one for
each recensio? Fact is, iirc it gets a bit wider than "phrase level", I
wonder if there aren't multiple hierarchy problems barring this approach.

> Am I getting it right this way?

Apart from the fact that this is not "taking the short road", yes :)

Thank you,

R

--

Roberto Rosselli Del Turco   roberto.rossellidelturco at unito.it
Dip. di Studi Umanistici     roberto.rossellidelturco at fileli.unipi.it
Universita' di Torino        VBD: http://vbd.humnet.unipi.it/beta2/
EVT: http://bit.ly/24D9kdE   VC: http://www.visionarycross.org/

   Hige sceal the heardra,     heorte the cenre,
   mod sceal the mare,       the ure maegen litlath.  (Maldon 312-3)

<shamelessPlug>Holidays in Tuscany http://www.imoricci.it/</shamelessPlug>
Reply | Threaded
Open this post in threaded view
|

Re: <app> of multiple lemmata

Daniele Marotta-2

Thanks to all of you for your suggestions, I will analyse them and choose the solution that will be the better compromise between our needs and the flaws pointed out in the debate.

Daniele


On 13/07/2018 20:20, Hugh Cayless wrote:
I think I understand what you're doing now, and I disagree with it :-). I don't think the apparatus is the place to handle different recensions. I agree with Torsten that it should be dealt with in the text. To take Daniele's initial example and the way I've proposed doing this sort of thing for Servius, he wrote:

<p>… it’s been the ruin of many a poor <anchor xml:id="a1"/>boy<anchor xml:id="a2"/>…</p>

and I would do

<p>… it’s been the ruin of many a poor <choice<seg source="#recensio_1"><anchor xml:id="a1"/>boy<anchor xml:id="a2"/></seg><seg source="#recensio_2"><anchor xml:id="b1"/>girl<anchor xml:id="b2"/></seg></choice>…</p>

with separate <app>s for #a1...#a2 and #b1...#b2 (I would also do it with inline apparatus, but that's a different argument). 

To be theoretical about it, I think what you're doing is suppressing Recensio 2 by not including it in your text. Obviously that's your choice as an editor, but I don't think the apparatus in TEI really gives you a way to "reinstate" Recensio 2 after having suppressed it. It can only present it as an alternative, i.e. as a <rdg>. The paper I linked to has several examples of this kind of thing. Servius is absolutely full of them.

Hugh

On Fri, Jul 13, 2018 at 12:55 PM Roberto Rosselli Del Turco <[hidden email]> wrote:
Hello again Torsten

Il 13/07/2018 18:15, Torsten Schassan ha scritto:
> Dear Daniele, dear Roberto,
>
> I don't think that there's a real misunderstanding here, I think Hugh
> and I understood you point. But there's a real difference in your
> understanding of what the encoded text represents and that you want to
> take a short road and save some effort (which I understand perfectly well!):

Actually, there *is* a slight misunderstanding here: Daniele is handling
the text encoding in preparation of the *digital* edition of this work
(and doing an excellent job at it, if I may say so), but the actual
editorial decisions are taken by the editorial pool which is working at
the *printed* edition. In other words, Daniele is trying to translate in
sound TEI encoding solutions the editorial practices that have been
established for the printed version of this edition.

Daniele will correct me if I got it somewhat wrong, of course.

> A text that exists in two recensions, both of which vary only in some
> spans, seems to be in its entirety the same text to you but are two
> different texts to Hugh and me.

I guess we'll have to disagree here :)

> If we agree on that, how about that, thinking from the presentational
> aspects of the edited text first:
>
> - The base text is the same for both recensions for most parts and
> therefore these parts of the text could/should be presented using one
> column.
>
> - Those spans that differ have to be presented side-by-side in order to
> show their equal importance.

This is exactly what is planned both for the printed and the digital
version of this edition, see this screenshot referring to the latter:

https://www.dropbox.com/s/nzccd9zock66xtj/evt2-avicenna-mrecensio-2.png?dl=0

we developed a "Multiple recensio" view into EVT to cater to this
specific need, so that it is very easy to see where there are
divergences due to different recensions in the reconstructed text.

This is better than the standard solution of having two columns because
you're going to access all other features, such as sources and analogues
besides critical apparatus, simply by changing the view (see
http://evt.labcd.unipi.it/demo/evt2-beta1/index.html in any case, still
in beta version though!).

> And coming back to the encoding of this text/these texts: If you want to
> take the short road and save some effort, this last aspect should result
> in a separate encoding of the spans and both of them can have their own
> lemmata and readings. You only have to make clear that the edited text
> doesn't run through both of these spans at a stretch but that these
> spans are mutually exclusive. (We use to use <choice> for such phenomena
> on the phrase level.)

Are you suggesting to use a <choice> with two or more <seg>s one for
each recensio? Fact is, iirc it gets a bit wider than "phrase level", I
wonder if there aren't multiple hierarchy problems barring this approach.

> Am I getting it right this way?

Apart from the fact that this is not "taking the short road", yes :)

Thank you,

R

--

Roberto Rosselli Del Turco   roberto.rossellidelturco at unito.it
Dip. di Studi Umanistici     roberto.rossellidelturco at fileli.unipi.it
Universita' di Torino        VBD: http://vbd.humnet.unipi.it/beta2/
EVT: http://bit.ly/24D9kdE   VC: http://www.visionarycross.org/

   Hige sceal the heardra,     heorte the cenre,
   mod sceal the mare,       the ure maegen litlath.  (Maldon 312-3)

<shamelessPlug>Holidays in Tuscany http://www.imoricci.it/</shamelessPlug>