Definition of hand attribute

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

Definition of hand attribute

Daniele Marotta-2
Dear all,

I would like get your opinion about the definition and use of the
attribute @hand. It is not clear to me why it cannot contain multiple
URIs like the @wit attribute.

If a given reading can refer to multiple witnesses, why can a particular
hand not be assigned for each witness listed in @wit? It looks like to
me that intelligibility is guaranteed by the uniqueness of the id that
identifies the single hand, just as each id in @wit uniquely identifies
each witness.

Listing more values can avoid redundancy in some cases. Let's suppose we
have:
1) in the base text the conjuction "et"
2) in the witnesses A and B:
      a) "et" is omitted in a first phase
      b) another hand adds "ac" in a second phase

In according to @hand definition, I should encode:

<app>
      <lem>et</lem>
      <rdgGrp ana="#sequence">
              <rdg wit="#A" cause="omission" varSeq="1"/>
              <rdg wit="#A" hand="#A2" cause="substitution"
varSeq="2">ac</rdg>
      </rdgGrp>
      <rdgGrp ana="#sequence">
            <rdg wit="#B" cause="omission" varSeq="1"/>
            <rdg wit="#B" hand="#B2" cause="substitution"
varSeq="2">ac</rdg>
      </rdgGrp>
</app>

Because every information is the same, except witnesses and related
hands, I think it would be clear enough if we encoded:
<app>
      <lem>et</lem>
      <rdgGrp ana="#sequence">
              <rdg wit="#A #B" cause="omission" varSeq="1"/>
              <rdg wit="#A #B" hand="#A2 #B2" cause="substitution"
varSeq="2">ac</rdg>
      </rdgGrp>
</app>

Therefore, I was wondering if it is right to customize the schema
defining a new attribute which can have more values.

Best wishes,
Daniele
Reply | Threaded
Open this post in threaded view
|

Re: Definition of hand attribute

Bauman, Syd
Caveat: I am not much of a manuscript encoder.

I sincerely doubt anyone has ever considered this possibility before. My instinct is that it is a very reasonable customization to invent a new @dm:witHand (or whatever) attribute to hold your multiple pointers to hands; and it is not an unreasonable customization to allow multiple values on @hand. But in either case proper and thorough documentation of this practice at least in your ODD, if not both in your ODD and your <teiHeader>, is essential.


I would like get your opinion about the definition and use of the
attribute @hand. It is not clear to me why it cannot contain multiple
URIs like the @wit attribute.

If a given reading can refer to multiple witnesses, why can a particular
hand not be assigned for each witness listed in @wit? It looks like to
me that intelligibility is guaranteed by the uniqueness of the id that
identifies the single hand, just as each id in @wit uniquely identifies
each witness.

Listing more values can avoid redundancy in some cases. Let's suppose we
have:
1) in the base text the conjuction "et"
2) in the witnesses A and B:
      a) "et" is omitted in a first phase
      b) another hand adds "ac" in a second phase

In according to @hand definition, I should encode:

<app>
      <lem>et</lem>
      <rdgGrp ana="#sequence">
              <rdg wit="#A" cause="omission" varSeq="1"/>
              <rdg wit="#A" hand="#A2" cause="substitution"
varSeq="2">ac</rdg>
      </rdgGrp>
      <rdgGrp ana="#sequence">
            <rdg wit="#B" cause="omission" varSeq="1"/>
            <rdg wit="#B" hand="#B2" cause="substitution"
varSeq="2">ac</rdg>
      </rdgGrp>
</app>

Because every information is the same, except witnesses and related
hands, I think it would be clear enough if we encoded:
<app>
      <lem>et</lem>
      <rdgGrp ana="#sequence">
              <rdg wit="#A #B" cause="omission" varSeq="1"/>
              <rdg wit="#A #B" hand="#A2 #B2" cause="substitution"
varSeq="2">ac</rdg>
      </rdgGrp>
</app>

Therefore, I was wondering if it is right to customize the schema
defining a new attribute which can have more values.

Reply | Threaded
Open this post in threaded view
|

Re: Definition of hand attribute

Daniele Marotta-2

  Thank you Syd for your reply. I'll follow your suggestion.

Best,

Daniele


Il 24/06/2020 17:00, Bauman, Syd ha scritto:
Caveat: I am not much of a manuscript encoder.

I sincerely doubt anyone has ever considered this possibility before. My instinct is that it is a very reasonable customization to invent a new @dm:witHand (or whatever) attribute to hold your multiple pointers to hands; and it is not an unreasonable customization to allow multiple values on @hand. But in either case proper and thorough documentation of this practice at least in your ODD, if not both in your ODD and your <teiHeader>, is essential.


I would like get your opinion about the definition and use of the
attribute @hand. It is not clear to me why it cannot contain multiple
URIs like the @wit attribute.

If a given reading can refer to multiple witnesses, why can a particular
hand not be assigned for each witness listed in @wit? It looks like to
me that intelligibility is guaranteed by the uniqueness of the id that
identifies the single hand, just as each id in @wit uniquely identifies
each witness.

Listing more values can avoid redundancy in some cases. Let's suppose we
have:
1) in the base text the conjuction "et"
2) in the witnesses A and B:
      a) "et" is omitted in a first phase
      b) another hand adds "ac" in a second phase

In according to @hand definition, I should encode:

<app>
      <lem>et</lem>
      <rdgGrp ana="#sequence">
              <rdg wit="#A" cause="omission" varSeq="1"/>
              <rdg wit="#A" hand="#A2" cause="substitution"
varSeq="2">ac</rdg>
      </rdgGrp>
      <rdgGrp ana="#sequence">
            <rdg wit="#B" cause="omission" varSeq="1"/>
            <rdg wit="#B" hand="#B2" cause="substitution"
varSeq="2">ac</rdg>
      </rdgGrp>
</app>

Because every information is the same, except witnesses and related
hands, I think it would be clear enough if we encoded:
<app>
      <lem>et</lem>
      <rdgGrp ana="#sequence">
              <rdg wit="#A #B" cause="omission" varSeq="1"/>
              <rdg wit="#A #B" hand="#A2 #B2" cause="substitution"
varSeq="2">ac</rdg>
      </rdgGrp>
</app>

Therefore, I was wondering if it is right to customize the schema
defining a new attribute which can have more values.

Reply | Threaded
Open this post in threaded view
|

Re: Definition of hand attribute

James Cummings-5
In reply to this post by Daniele Marotta-2
Hi Daniele,

Always interesting to see others encoding approaches -- In  your second example where you have: 

  <rdg wit="#A #B" hand="#A2 #B2" cause="substitution" varSeq="2">ac</rdg>

I was going to ask about how one relates which witness goes with which hand because I thought you were relying on the ID naming convention here. i.e.where presumably if you had a third hand for MS B it would be  'B3'. This may work for a small number of consistent witnesses but seems hard to generalise. However, since this #B2 is presumably pointing to a handNote element, that would solve it, right? We'd know what hand related to what witness because it would be in the msDesc/physDesc/handDesc/handNote of that witness's description. 

The problem is that handNote is _also_ available inside teiHeader/profileDesc/handNotes/handNote as well, no? So we might not be able to tell what manuscript #B2 refers to _except_ by informal ID naming convention. That sounds...fragile. But I guess there are other ways to point from that to say a witness element. eg. corresp) 

(Don't ask me why we have both handNotes and handDesc when they fulfill almost identical functions...) 

A feature request asking for the hands attribute to allow multiple pointers might be interesting, but this is the kind of question that might come up in doing so. For a small self-contained project, then using a new attribute that you document well is one approach. Besides, you could always generate the more redundant markup from this. 

Many thanks,

James 


--

Dr James Cummings, [hidden email]
Senior Lecturer in Late-Medieval Literature and Digital Humanities

School of English, Newcastle University


From: TEI (Text Encoding Initiative) public discussion list <[hidden email]> on behalf of Daniele Marotta <[hidden email]>
Sent: 24 June 2020 10:23
To: [hidden email] <[hidden email]>
Subject: Definition of hand attribute
 
⚠ External sender. Take care when opening links or attachments. Do not provide your login details.

Dear all,

I would like get your opinion about the definition and use of the
attribute @hand. It is not clear to me why it cannot contain multiple
URIs like the @wit attribute.

If a given reading can refer to multiple witnesses, why can a particular
hand not be assigned for each witness listed in @wit? It looks like to
me that intelligibility is guaranteed by the uniqueness of the id that
identifies the single hand, just as each id in @wit uniquely identifies
each witness.

Listing more values can avoid redundancy in some cases. Let's suppose we
have:
1) in the base text the conjuction "et"
2) in the witnesses A and B:
      a) "et" is omitted in a first phase
      b) another hand adds "ac" in a second phase

In according to @hand definition, I should encode:

<app>
      <lem>et</lem>
      <rdgGrp ana="#sequence">
              <rdg wit="#A" cause="omission" varSeq="1"/>
              <rdg wit="#A" hand="#A2" cause="substitution"
varSeq="2">ac</rdg>
      </rdgGrp>
      <rdgGrp ana="#sequence">
            <rdg wit="#B" cause="omission" varSeq="1"/>
            <rdg wit="#B" hand="#B2" cause="substitution"
varSeq="2">ac</rdg>
      </rdgGrp>
</app>

Because every information is the same, except witnesses and related
hands, I think it would be clear enough if we encoded:
<app>
      <lem>et</lem>
      <rdgGrp ana="#sequence">
              <rdg wit="#A #B" cause="omission" varSeq="1"/>
              <rdg wit="#A #B" hand="#A2 #B2" cause="substitution"
varSeq="2">ac</rdg>
      </rdgGrp>
</app>

Therefore, I was wondering if it is right to customize the schema
defining a new attribute which can have more values.

Best wishes,
Daniele
Reply | Threaded
Open this post in threaded view
|

Re: Definition of hand attribute

Hugh Cayless-2
Projects I've worked with that deal with these issues have dealt with this problem by pointing at hands in @wit, so we'd have   
  <rdg wit="#A2 #B2" cause="substitution" varSeq="2">ac</rdg>
where #A2 and #B2 point to handNotes in witnesses #A and #B respectively. You can easily get at the witness containing the handNote, so you're not losing any information this way.

All the best,
Hugh

On Thu, Jun 25, 2020 at 7:22 AM James Cummings <[hidden email]> wrote:
Hi Daniele,

Always interesting to see others encoding approaches -- In  your second example where you have: 

  <rdg wit="#A #B" hand="#A2 #B2" cause="substitution" varSeq="2">ac</rdg>

I was going to ask about how one relates which witness goes with which hand because I thought you were relying on the ID naming convention here. i.e.where presumably if you had a third hand for MS B it would be  'B3'. This may work for a small number of consistent witnesses but seems hard to generalise. However, since this #B2 is presumably pointing to a handNote element, that would solve it, right? We'd know what hand related to what witness because it would be in the msDesc/physDesc/handDesc/handNote of that witness's description. 

The problem is that handNote is _also_ available inside teiHeader/profileDesc/handNotes/handNote as well, no? So we might not be able to tell what manuscript #B2 refers to _except_ by informal ID naming convention. That sounds...fragile. But I guess there are other ways to point from that to say a witness element. eg. corresp) 

(Don't ask me why we have both handNotes and handDesc when they fulfill almost identical functions...) 

A feature request asking for the hands attribute to allow multiple pointers might be interesting, but this is the kind of question that might come up in doing so. For a small self-contained project, then using a new attribute that you document well is one approach. Besides, you could always generate the more redundant markup from this. 

Many thanks,

James 


--

Dr James Cummings, [hidden email]
Senior Lecturer in Late-Medieval Literature and Digital Humanities

School of English, Newcastle University


From: TEI (Text Encoding Initiative) public discussion list <[hidden email]> on behalf of Daniele Marotta <[hidden email]>
Sent: 24 June 2020 10:23
To: [hidden email] <[hidden email]>
Subject: Definition of hand attribute
 
⚠ External sender. Take care when opening links or attachments. Do not provide your login details.

Dear all,

I would like get your opinion about the definition and use of the
attribute @hand. It is not clear to me why it cannot contain multiple
URIs like the @wit attribute.

If a given reading can refer to multiple witnesses, why can a particular
hand not be assigned for each witness listed in @wit? It looks like to
me that intelligibility is guaranteed by the uniqueness of the id that
identifies the single hand, just as each id in @wit uniquely identifies
each witness.

Listing more values can avoid redundancy in some cases. Let's suppose we
have:
1) in the base text the conjuction "et"
2) in the witnesses A and B:
      a) "et" is omitted in a first phase
      b) another hand adds "ac" in a second phase

In according to @hand definition, I should encode:

<app>
      <lem>et</lem>
      <rdgGrp ana="#sequence">
              <rdg wit="#A" cause="omission" varSeq="1"/>
              <rdg wit="#A" hand="#A2" cause="substitution"
varSeq="2">ac</rdg>
      </rdgGrp>
      <rdgGrp ana="#sequence">
            <rdg wit="#B" cause="omission" varSeq="1"/>
            <rdg wit="#B" hand="#B2" cause="substitution"
varSeq="2">ac</rdg>
      </rdgGrp>
</app>

Because every information is the same, except witnesses and related
hands, I think it would be clear enough if we encoded:
<app>
      <lem>et</lem>
      <rdgGrp ana="#sequence">
              <rdg wit="#A #B" cause="omission" varSeq="1"/>
              <rdg wit="#A #B" hand="#A2 #B2" cause="substitution"
varSeq="2">ac</rdg>
      </rdgGrp>
</app>

Therefore, I was wondering if it is right to customize the schema
defining a new attribute which can have more values.

Best wishes,
Daniele
Reply | Threaded
Open this post in threaded view
|

Re: Definition of hand attribute

Daniele Marotta-2

Hi James and Hugh,

to reply to James:
We have a <listBibl> which lists every edition and manuscript used to create the critical text and apparatus. Therefore, hands are defined in sourceDesc/listBibl/msDesc[@xml:id]/physDesc/handDesc/handNote[@xml:id]. Then we have a <listWit>, where each <witness> is related to a <msDesc> with @corresp.

To reply to Hugh:

We thought your solution as well, but we prefer maintain the difference between agent responsible for a reading and the physical entity where the reading is, as the guidelines suggest in 12.1.2 (https://tei-c.org/release/doc/tei-p5-doc/en/html/TC.html#TCAPLR).

Many thanks,

Daniele

Of courss

Il 25/06/2020 14:10, Hugh Cayless ha scritto:
Projects I've worked with that deal with these issues have dealt with this problem by pointing at hands in @wit, so we'd have   
  <rdg wit="#A2 #B2" cause="substitution" varSeq="2">ac</rdg>
where #A2 and #B2 point to handNotes in witnesses #A and #B respectively. You can easily get at the witness containing the handNote, so you're not losing any information this way.

All the best,
Hugh

On Thu, Jun 25, 2020 at 7:22 AM James Cummings <[hidden email]> wrote:
Hi Daniele,

Always interesting to see others encoding approaches -- In  your second example where you have: 

  <rdg wit="#A #B" hand="#A2 #B2" cause="substitution" varSeq="2">ac</rdg>

I was going to ask about how one relates which witness goes with which hand because I thought you were relying on the ID naming convention here. i.e.where presumably if you had a third hand for MS B it would be  'B3'. This may work for a small number of consistent witnesses but seems hard to generalise. However, since this #B2 is presumably pointing to a handNote element, that would solve it, right? We'd know what hand related to what witness because it would be in the msDesc/physDesc/handDesc/handNote of that witness's description. 

The problem is that handNote is _also_ available inside teiHeader/profileDesc/handNotes/handNote as well, no? So we might not be able to tell what manuscript #B2 refers to _except_ by informal ID naming convention. That sounds...fragile. But I guess there are other ways to point from that to say a witness element. eg. corresp) 

(Don't ask me why we have both handNotes and handDesc when they fulfill almost identical functions...) 

A feature request asking for the hands attribute to allow multiple pointers might be interesting, but this is the kind of question that might come up in doing so. For a small self-contained project, then using a new attribute that you document well is one approach. Besides, you could always generate the more redundant markup from this. 

Many thanks,

James 


--

Dr James Cummings, [hidden email]
Senior Lecturer in Late-Medieval Literature and Digital Humanities

School of English, Newcastle University


From: TEI (Text Encoding Initiative) public discussion list <[hidden email]> on behalf of Daniele Marotta <[hidden email]>
Sent: 24 June 2020 10:23
To: [hidden email] <[hidden email]>
Subject: Definition of hand attribute
 
⚠ External sender. Take care when opening links or attachments. Do not provide your login details.

Dear all,

I would like get your opinion about the definition and use of the
attribute @hand. It is not clear to me why it cannot contain multiple
URIs like the @wit attribute.

If a given reading can refer to multiple witnesses, why can a particular
hand not be assigned for each witness listed in @wit? It looks like to
me that intelligibility is guaranteed by the uniqueness of the id that
identifies the single hand, just as each id in @wit uniquely identifies
each witness.

Listing more values can avoid redundancy in some cases. Let's suppose we
have:
1) in the base text the conjuction "et"
2) in the witnesses A and B:
      a) "et" is omitted in a first phase
      b) another hand adds "ac" in a second phase

In according to @hand definition, I should encode:

<app>
      <lem>et</lem>
      <rdgGrp ana="#sequence">
              <rdg wit="#A" cause="omission" varSeq="1"/>
              <rdg wit="#A" hand="#A2" cause="substitution"
varSeq="2">ac</rdg>
      </rdgGrp>
      <rdgGrp ana="#sequence">
            <rdg wit="#B" cause="omission" varSeq="1"/>
            <rdg wit="#B" hand="#B2" cause="substitution"
varSeq="2">ac</rdg>
      </rdgGrp>
</app>

Because every information is the same, except witnesses and related
hands, I think it would be clear enough if we encoded:
<app>
      <lem>et</lem>
      <rdgGrp ana="#sequence">
              <rdg wit="#A #B" cause="omission" varSeq="1"/>
              <rdg wit="#A #B" hand="#A2 #B2" cause="substitution"
varSeq="2">ac</rdg>
      </rdgGrp>
</app>

Therefore, I was wondering if it is right to customize the schema
defining a new attribute which can have more values.

Best wishes,
Daniele