New element for grouping notes: <noteGrp>

[joeytakeda]

Stemming from a discussion on the TEI-L (https://listserv.brown.edu/archives/cgi-bin/wa?A2=TEI-L;c694031.1810), I would like to propose a new element for grouping together notes: <noteGrp>. [Thanks to Peter Boot for making the original suggestion for this element and for the others on that chain for their helpful recommendations and suggestions!]

The <noteGrp> element would be similar to the <spanGrp> element insofar as it would simply be a wrapper for grouping together series of notes. Usually this will be for the purposes of attachment (i.e. all of the children <note>s in <noteGrp> all attach to the same place in a document defined by the @target and @targetEnd attributes on <noteGrp>), but it could also simply be for providing a convenient way to group together notes of a similar type.

Classes

<noteGrp> would be a member of all the same classes as the <note> element:

<classes>
                  <memberOf key="att.global"/>
                  <memberOf key="model.noteLike"/>
                  <memberOf key="att.placement"/>
                  <memberOf key="att.pointing"/>
                  <memberOf key="att.typed"/>
                  <memberOf key="att.written"/>
                  <memberOf key="model.correspDescPart"/>
                  <memberOf key="model.correspActionPart"/>
                  <memberOf key="model.correspContextPart"/>
               </classes>

Content

<noteGrp> can only contains a sequence of <note> elements (this is the same content model as <spanGrp>):

               <content>
                  <elementRef key="note" minOccurs="0" maxOccurs="unbounded"/>
               </content>

Attributes

The <noteGrp> would also have the same attributes as <note>. I would suggest creating a new attribute class (att.noteAttachment or something) and include the @anchored and @targetEnd attributes defined within this new attribute class.

But since the @targetEnd attribute is not recommended, however, I would also suggest that, if desired, the @to and @from attributes on <span> and <app> are harmonized into a class called att.pointingRange and that class be added to <note> and <noteGrp> instead of the creation of att.noteAttachment. However, this is a somewhat separate concern that may or may not be necessary to implement, depending on what Council thinks about @targetEnd.

Summary

A new element for grouping notes that can go wherever notes can go; it will contain 0 or more <note> elements (following <spanGrp>'s content model); it will also bear the same attributes as the <note> element.

[joeytakeda]

To add to my earlier point re: @to and @from, it seems that this is basically happening already in #1666 . If, following this comment #1666 (comment), the individually defined @to and @from on app are changed to att.referring, then I certainly think that <note> and <noteGrp> could also be added to att.referring.

[lb42]

Per previous discussion about *List vs *Grp, I think you want noteList here (or possibly listNote) : noteGrp would imply that all the children functioned together to form a single note in some way.

[martindholmes]

@lb42 I believe Joey's original requirement includes the grouping together of notes which are in intended to be versions of the same note, but at increasing levels of detail or specificity. So noteGrp would be right for that.

If a list element is created, it must be called listNote, not *noteList. I think we established that principle some years ago. But I think it's clear we need noteGrp; the case for listNote has not been made.

[lb42]

Ah, OK. Apologies for not reading more attentively! That would indeed be an appropriate use for the GRP suffix. Maybe should add listNote too, so we can demonstrate what the difference is!

[jamescummings]

To play devil's advocate so we do our due diligence, could someone explain why a group of notes acting as a single structure shouldn't just be nested inside a parent note? I recognise noteGrp might be better, but thought we should be clear on why existing structures don't work.

[PFSchaffner]

James, the only reason I can think of would be the assumed semantics of nested notes, i.e. most nested notes consist of a note (which comments on or addresses the main text in some way), which itself contains notes (which comment on or address the text of the first-level note in some way). At least, that is the common scenario in which I've used them -- notes to notes. OTOH, notes are att.typed, so you can always distinguish this grouping-type note from others as a type of note (note type="grouping" or whatever). I don't see how adding a noteGrp actually adds to the functionality of the schema at all.

[martindholmes]

I'm tending to join the nested-notes camp too, now that I think about it. @joeytakeda , any reason not to use nested typed notes?

[joeytakeda]

To re-iterate and clarify the problem here: we have multiple notes that are associated with a single span of text; they are taken not necessarily as a single note (i.e. you don't necessarily need noteGrp/note[3] for noteGrp/note[1] to make sense), but, for the project's purposes, they do comprise the full set of editorial annotations for a particular span of text. So, I think <noteGrp> actually describes what's going on a bit better: this is not just a type of note with multiple subnotes, but a grouping of notes all attached to a particular point.

The case could also be made that having a <noteGrp> element makes a lot of sense in relation to the other *Grp elements. Like <rdg> and <interp>s and <span>s, <note>s might need to be placed in alternation; they might also just need to be grouped for some analytic purpose (i.e. editorial notes versus corrigenda versus translations, et cetera). I don't think it's necessarily that it needs to be for attachment (even though that is what I want to use it for and I think it's a good solution for my problem). Peter Boot (on the listServ) gave a few good examples:

Other situations where such an element would be useful:

• Group notes by language (if an edition has annotation in multiple languages)
• Group notes by type (explanatory, paleographical, ...)
• Group notes by text division

So, I can see <noteGrp> being akin to <rdgGrp>, <personGrp>, <spanGrp> et cetera in that it brings together <note>s not only for purposes of attachment, but also to conveniently group them for some reason. In a sense, then, this is partially an argument for completeness: if <span>s et al get to be grouped, why can't <note>s?

[sydb]

In addition, we need to think through how this proposal interacts with the <listAnnotation> proposal from the LingSIG. (See #374 and #1745.) The good news is that the Council sub-group charged with the next steps for that proposal (writ large), which had been thwarted for months by illnesses and deaths in the family, has finally started to make some progress.

Note, though @joeytakeda, that <personGrp> is not an element that groups a set of <person> elements: it documents a set of people who are treated as a single entity in your analysis. The example in the Guidelines is the audience of a drama. To use a USA-centric example, I could imagine someone today using it for "republicans" and "democrats". (For voting blocks in congress; I would encode the proper names of the parties themselves with <orgName type="party">.)

[ebeshero]

@sydb (aside) : One of our students found her way to personGrp as a solution for coding personified references to nations, like “<personGrp>France</personGrp> will join us in the fight” (context is a project on George Washington’s letters).
Was this “Grp” element from an earlier moment before we started applying the Grp suffix for elements that bundle elements?

As I am finally catching up on this thread, I like the versatility of <noteGrp> for stand-off contexts as well as for curating annotations made on the same passage at different moments, or even at the same moment by different annotators. Example: a TEI project to curate hypothesis.is annotations made in distinct social groups on a popular online edition of Frankenstein during its bicentennial year. The potential for such a project is real: the edition and annotation groups exist via hypothesis.is, which facilitates creating social groups who annotate the same text independently of others. The annotations are stand-off and dereferenced via Xpath and string location cues. We could use <noteGrp> to bundle together the notes from separate annotators on a much-marked passage.

[joeytakeda]

Thanks, @sydb, for the clarification re: <personGrp>. My mistake! But I do think <noteGrp> is similar to other *Grp elements like <spanGrp>, <rdgGrp> and <interGrp>. And I agree with you and @ebeshero that this should be done in concert with the standoff annotation stuff.

[tuurma]

Agree that listNote would be the obvious candidate for a standoff element. While grouping notes with a noteGrp makes sense I'm wondering how would that be different from listNote? Opinions? In my understanding Grp elements are more meant for grouping things 'on the spot' so to say - like rdgGrp within app entry while list elements are also used for grouping but usually (not always) detached from the text (like listPerson, listWit etc).

To summarise: I would propose listNote element that obviously would be self-nesting and typed and I hope it would fit @joeytakeda's use case.

[joeytakeda]

Thanks for picking this back up, @tuurma! I've re-read the thread here and I am wondering the same thing: what really is the difference between a group and a list?

From what I can tell from a quick comb through of the Guidelines, *Grp can mean a few different things:

• A grouping of things collected together because they explicitly share something, like a pointed to object, or an inherited attribute:

<interpGrp> (interpretation group) collects together a set of related interpretations which share responsibility or type. [17.3 Spans and Interpretations]

<rdgGrp> (reading group) within a textual variation, groups two or more readings perceived to have a genetic relationship or other affinity. [12.1 The Apparatus Entry, Readings, and Witnesses]

<measureGrp> (measure group) contains a group of dimensional specifications which relate to the same object, for example the height and width of a manuscript page. [10.3.4 Dimensions]

• A grouping of things to define a group of things such that they comprise a singular unit or for some other administrative convenience:

<surfaceGrp> defines any kind of useful grouping of written surfaces, for example the recto and verso of a single leaf, which the encoder wishes to treat as a single unit.

<personGrp> (personal group) describes a group of individuals treated as a single person for analytic purposes. [15.2.2 The Participant Description]
(Listing here because, even though as @sydb points out, <personGrp> is of a different kind than the other grouping elements, the definition is similar to the surfaceGrp et al)

<joinGrp> (join group) groups a collection of join elements and possibly pointers. [16.7 Aggregation]

<linkGrp> (link group) defines a collection of associations or hypertextual links. [16.1 Links]
(Though note the caveat in the remarks that: "A web or link group is an administrative convenience, which should be used to collect a set of links together for any purpose, not simply to supply a default value for the type attribute.")

The list* elements are less interesting to list here, since they primarily use the same language of "<fooList> (foo list) contains a list of foo elements".

But the critical distinction, as far as I can tell, is that *Grp elements are always created by the encoder, cannot be found in a source text, and inherit the attributes of the parent; whereas a <list*> can either be something found within a primary source document OR an administrative collection to create database-y ography things. It's not clear, from my reading at least, that attributes on a <list*> element are meant to be inherited by its children.

So the end result of this ramble is that I think <noteGrp> serves my purposes well, but I do see how <listNote> has broader applicability for standoff annotations et cetera. In part, I would be tempted to say that the standoff annotations that I want to encode could look something like this:

<listNote>
     <noteGrp to="ptr:blort" from="ptr:foo">
           <note type="gloss"><!--Stuff--></note>
           <note type="pedagogical"><!--Stuff--></note>
           <note type="performance"><!--Stuff--></note>
           <note type="etymological"><!--Stuff--></note>
      </noteGrp>
</listNote>

[martindholmes]

I have a fairly strong impression (from somewhere, I don't know where) that in Grp contents, it is assumed that order doesn't matter, whereas in list element contents, it does.

[jamescummings]

In case it helps, the place TEI currently defines what Grp and similar mean is at https://www.tei-c.org/release/doc/tei-p5-doc/en/html/AB.html#index-front.1_div.4_div.1_div.2_div.1

[tuurma]

Personally I'm convinced with @joeytakeda's argument and example and think it'd be good to have both listNote and noteGrp. Council is discussing it atm

[tuurma]

F2F Washington Council agrees with the proposal and is convinced with the example presented. MT will elaborate it for the GL presenting eg. short and long notes grouped (which could be intended eg for print vs online versions) or notes in various languages or such like.

[ebeshero]

Council approves <noteGrp> to be a member of model.noteLike , and wants to open a new ticket on <listNote>.

[joeytakeda]

Excellent! We'll start using this in a project soon, then, which means that we can provide some real world examples if needed.

[jamescummings]

Real world examples are always useful.

[tuurma]

tentative example to demonstrate use of noteGrp for grouping notes stating the same in different languages

<p>... Parwum vadit theoloneum, tamen reuerendos dominos archiepiscopum et canonicos Leopolienses 
            necnon episcopum in duplicibus Quatuortemporibus
            <noteGrp>
               <note xml:lang="en">Quatuor Tempora, so called dry fast days (Wednesday, Friday and Saturday)
                  falling on each of the quarters of the year. In the first quarter they were called Cinerum (following Ash Wednesday), 
                  second Spiritus (following Pentecost), third Crucis (after the Exaltation of the Holy Cross, September 14th), 
                  and Luciae in the fourth (after the feast of St. Lucia, December 13th).
                  </note>
               <note xml:lang="pl">Quatuor Tempora, tzw. Suche dni postne (środa, piątek i sobota) przypadające cztery razy w roku. 
                  W pierwszym kwartale zwały się Cinerum (po Popielcu), w drugim Spiritus (po Zielonych Świętach), 
                  w trzecim Crucis (po święcie Podwyższenia Krzyża 14 września), w czwartym Luciae (po dniu św. Łucji 13 grudnia).
               </note>
            </noteGrp> 
            totaliter expediui.</p>

[tuurma]

Thinking about it, should noteGrp belong to core module or some other?

[tuurma]

Could I please ask for PR review