Documents in an Ordered Series

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

Documents in an Ordered Series

Scott Vanderbilt (TEI-L)
Many of the projects on which I work have documents which are members in
a larger series of ordered documents. One of the features that users
find convenient is the able to browse through these documents in a
linear fashion, i.e., using links to the "previous" or "next" document
in the series.

My question is where in the TEI header would it make sense to store such
information? I can't seem to find any appropriate existing element that
is suited to this task.

At a minimum, I need both a pointer and a descriptive label for each
"direction" (i.e., forward and backward in the sequence), which I could
then convert to  "Previous Document" and "Next Document" links at render
time.

No doubt I am overlooking something obvious, but the only way I can see
to facilitate this feature are the @next and @prev attributes on the
<TEI> element, but those only get me half of what I need (i.e., the
pointers, but not the associated descriptive labels). Pointers alone are
insufficient as they do not support a human-readable label.

Thank you.
Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

Imsieke, Gerrit, le-tex
teiHeader/fileDesc/seriesStmt/biblScope accepts the @prev and @next
attributes and also descriptive text as content.

On 22.10.2020 00:37, Scott Vanderbilt (TEI-L) wrote:

> Many of the projects on which I work have documents which are members in
> a larger series of ordered documents. One of the features that users
> find convenient is the able to browse through these documents in a
> linear fashion, i.e., using links to the "previous" or "next" document
> in the series.
>
> My question is where in the TEI header would it make sense to store such
> information? I can't seem to find any appropriate existing element that
> is suited to this task.
>
> At a minimum, I need both a pointer and a descriptive label for each
> "direction" (i.e., forward and backward in the sequence), which I could
> then convert to  "Previous Document" and "Next Document" links at render
> time.
>
> No doubt I am overlooking something obvious, but the only way I can see
> to facilitate this feature are the @next and @prev attributes on the
> <TEI> element, but those only get me half of what I need (i.e., the
> pointers, but not the associated descriptive labels). Pointers alone are
> insufficient as they do not support a human-readable label.
>
> Thank you.
Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

Mylonas, Elli
That's what I would do, as well. 

Could you elaborate about the purpose of the descriptive text: is your example "previous document" and "next document" shorthand for substituting inscription IDs? The text content of <biblScope> would provide a human readable description of series numbering of  the current document. 

If that's what you want, you could also put it in the <title> element as well.

best, 
    --elli

[Elli Mylonas
 Center for Digital Scholarship
 University Library
 Brown University
 library.brown.edu/cds
(she, her, hers)]

On Wed, Oct 21, 2020 at 7:18 PM Imsieke, Gerrit, le-tex <[hidden email]> wrote:
teiHeader/fileDesc/seriesStmt/biblScope accepts the @prev and @next
attributes and also descriptive text as content.

On 22.10.2020 00:37, Scott Vanderbilt (TEI-L) wrote:
> Many of the projects on which I work have documents which are members in
> a larger series of ordered documents. One of the features that users
> find convenient is the able to browse through these documents in a
> linear fashion, i.e., using links to the "previous" or "next" document
> in the series.
>
> My question is where in the TEI header would it make sense to store such
> information? I can't seem to find any appropriate existing element that
> is suited to this task.
>
> At a minimum, I need both a pointer and a descriptive label for each
> "direction" (i.e., forward and backward in the sequence), which I could
> then convert to  "Previous Document" and "Next Document" links at render
> time.
>
> No doubt I am overlooking something obvious, but the only way I can see
> to facilitate this feature are the @next and @prev attributes on the
> <TEI> element, but those only get me half of what I need (i.e., the
> pointers, but not the associated descriptive labels). Pointers alone are
> insufficient as they do not support a human-readable label.
>
> Thank you.
Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

Scott Vanderbilt (TEI-L)
Thanks to you, Elli, and Gerrit for your replies.

I should have thought about the problem a little harder before posting.

Since my email, I've decided that @prev and @next on the TEI element are
in fact sufficient, because I can use those pointers to extract a value
from the target documents (with document() function) to use as my
descriptive values.

This actually is an ideal solution because it normalizes the descriptive
label value, reducing the need to maintain it in more than one place
should it ever change.

Thanks again.

- Scott

On 10/21/2020 4:32 PM, Mylonas, Elli wrote:

> That's what I would do, as well.
>
> Could you elaborate about the purpose of the descriptive text: is your
> example "previous document" and "next document" shorthand for
> substituting inscription IDs? The text content of <biblScope> would
> provide a human readable description of series numbering of  the current
> document.
>
> If that's what you want, you could also put it in the <title> element as
> well.
>
> best,
>      --elli
>
> [Elli Mylonas
>   Center for Digital Scholarship
>   University Library
>   Brown University
> library.brown.edu/cds <http://library.brown.edu/cds>
> (she, her, hers)]
>
> On Wed, Oct 21, 2020 at 7:18 PM Imsieke, Gerrit, le-tex
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     teiHeader/fileDesc/seriesStmt/biblScope accepts the @prev and @next
>     attributes and also descriptive text as content.
>
>     On 22.10.2020 00:37, Scott Vanderbilt (TEI-L) wrote:
>      > Many of the projects on which I work have documents which are
>     members in
>      > a larger series of ordered documents. One of the features that users
>      > find convenient is the able to browse through these documents in a
>      > linear fashion, i.e., using links to the "previous" or "next"
>     document
>      > in the series.
>      >
>      > My question is where in the TEI header would it make sense to
>     store such
>      > information? I can't seem to find any appropriate existing
>     element that
>      > is suited to this task.
>      >
>      > At a minimum, I need both a pointer and a descriptive label for each
>      > "direction" (i.e., forward and backward in the sequence), which I
>     could
>      > then convert to  "Previous Document" and "Next Document" links at
>     render
>      > time.
>      >
>      > No doubt I am overlooking something obvious, but the only way I
>     can see
>      > to facilitate this feature are the @next and @prev attributes on the
>      > <TEI> element, but those only get me half of what I need (i.e., the
>      > pointers, but not the associated descriptive labels). Pointers
>     alone are
>      > insufficient as they do not support a human-readable label.
>      >
>      > Thank you.
>
Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

Bauman, Syd
In reply to this post by Imsieke, Gerrit, le-tex
Although Gerrit is correct, <biblScope> does have @prev and @next attributes, and can have text content, use of @prev and @next for this purpose would be attribute abuse. More on that in a moment.

First, I have to admit I am a bit confounded by the stated requirements. Some questions jump to mind:
  • Why would it be necessary to use pointers to establish sequence? I am not suggesting there is never a reason, but it is usually the case that sequence can be established quite easily some other way. E.g., by giving each document a sequence number (perhaps expressed on /TEI/@xml:id, /TEI/@n, or /TEI/teiHeader/fileDesc/publicationStmt/idno), or by collecting each <TEI> document that is a member of the larger series in an outer <TEI> (or <teiCorpus>) document that represents the larger series.
  • If a pointer is to be used, and its value is to be consistently processed to what “Previous Document” and “Next Document” point to, why do you need descriptive labels? That is, couldn’t @nextDocumentOfLargerSeries always be processed in such a way as it gets the label “Next Document”?
Now on to @next and @prev, and then an actual answer to the question as posed.

Although I will not be surprised if this is not made clear enough in the Guidelines, the @next and @prev attributes exist for the purpose of getting around XML overlap problems. (I would say “sole purpose”; others might disagree.) They allow an encoder to say “this set of XML elements should be thought of as a single content object which I could not encode as a singe XML element because of the well-formedness rule of XML that forbids overlap”. Hence the recommendation in the Guidelines that the element a @next or @prev points to should be of the same element type as the element that bears the @next or @prev. That is, <biblScope xml:id="myscope02" prev="myscope01"> says “you should take the <biblScope> with ID "myscope01" and prepend it to this <biblScope> to make a complete <biblScope> that defines the scope of my parent bibliographic reference”.

(As a side note, I have often suggested the Guidelines should actually provide a constraint that requires the target of @next or @prev to be the same element type as the element bearing it; and that the Guidelines should do a better job of explaining what a processor should do with the attributes of the individual elements that are combined into one big virtual element.)

Now on to my actual response to the question as posed (where in the TEI header would it make sense to store information that allows us to figure out which is the previous and which is the next document in the larger series). If your documents in the series happen to be letters (or other correspondence) you are in luck. In such a case, TEI provides a very explicit place to provide this information:
/TEI/teiHeader/profileDesc/correspDesc/correspContext/ptr
where the <ptr> can have a @type of "next" or "prev". (If, BTW, you were to insist on providing a descriptive label, you can use <ref> instead of <ptr>.)

If your documents are not actually correspondence, you could either eschew <correspDesc> or decide to commit mild tag abuse and still use it to indicate sequence in your larger series. (Why I think this would be mild tag abuse but use of @next and @prev would be serious attribute abuse is an interesting question for another day, and might involve large psychiatry bills. :-)

Last, my preferred solution: nested <TEI> elements. To wit:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="/path/to/myProject.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="/path/to/myProject.sch" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<TEI xmlns="http://www.tei-c.org/ns/1.0">
  <teiHeader>
    <!-- metadata that applies to entire larger series -->
  </teiHeader>
  <TEI>
    <teiHeader>
      <!-- metadata specific to 1st document in series -->
    </teiHeader>
    <text>
      <!-- encoded representation of 1st document in series -->
    </text>
  </TEI>
  <TEI>
    <teiHeader>
      <!-- metadata specific to 2nd document in series -->
    </teiHeader>
    <text>
      <!-- encoded representation of 2nd document in series -->
    </text>
  </TEI>
  <!-- ... -->
  <TEI>
    <teiHeader>
      <!-- metadata specific to 142nd document in series -->
    </teiHeader>
    <text>
      <!-- encoded representation of 142nd document in series -->
    </text>
  </TEI>
</TEI>
Which, of course, could be stored on your file system as separate documents to make encoding and management easier:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="/path/to/myProject.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="/path/to/myProject.sch" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<TEI xmlns:xi="http://www.w3.org/2001/XInclude" xmlns="http://www.tei-c.org/ns/1.0">
  <teiHeader>
    <!-- metadata that applies to entire larger series -->
  </teiHeader>
  <xi:include href="./doc001.tei"/>
  <xi:include href="./doc002.tei"/>
  <!-- ... -->
  <xi:include href="./doc142.tei"/>
</TEI>
HTH.
Stay safe.


 
GI> teiHeader/fileDesc/seriesStmt/biblScope accepts the @prev and @next attributes and also descriptive text as content.

SV> Many of the projects on which I work have documents which are members in
SV> a larger series of ordered documents. One of the features that users
SV> find convenient is the able to browse through these documents in a
SV> linear fashion, i.e., using links to the "previous" or "next" document
SV> in the series.
SV>
SV> My question is where in the TEI header would it make sense to store such
SV> information? I can't seem to find any appropriate existing element that
SV> is suited to this task.
>
SV> At a minimum, I need both a pointer and a descriptive label for each
SV> "direction" (i.e., forward and backward in the sequence), which I could
SV> then convert to  "Previous Document" and "Next Document" links at render
SV> time.
>
SV> No doubt I am overlooking something obvious, but the only way I can see
SV> to facilitate this feature are the @next and @prev attributes on the
SV> <TEI> element, but those only get me half of what I need (i.e., the
SV> pointers, but not the associated descriptive labels). Pointers alone are
SV> insufficient as they do not support a human-readable label.

Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

Martin Mueller

I had the same response as Syd to the initial question.  If your documents are arranged in an order that matters, why not make that order visible in some explicit cataloguing, expressed in the filename or some high-level attribute.

 

From: "TEI (Text Encoding Initiative) public discussion list" <[hidden email]> on behalf of "Bauman, Syd" <[hidden email]>
Reply-To: "Bauman, Syd" <[hidden email]>
Date: Wednesday, October 21, 2020 at 7:12 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: Documents in an Ordered Series

 

Although Gerrit is correct, <biblScope> does have @prev and @next attributes, and can have text content, use of @prev and @next for this purpose would be attribute abuse. More on that in a moment.

 

First, I have to admit I am a bit confounded by the stated requirements. Some questions jump to mind:

  • Why would it be necessary to use pointers to establish sequence? I am not suggesting there is never a reason, but it is usually the case that sequence can be established quite easily some other way. E.g., by giving each document a sequence number (perhaps expressed on /TEI/@xml:id, /TEI/@n, or /TEI/teiHeader/fileDesc/publicationStmt/idno), or by collecting each <TEI> document that is a member of the larger series in an outer <TEI> (or <teiCorpus>) document that represents the larger series.
  • If a pointer is to be used, and its value is to be consistently processed to what “Previous Document” and “Next Document” point to, why do you need descriptive labels? That is, couldn’t @nextDocumentOfLargerSeries always be processed in such a way as it gets the label “Next Document”?

Now on to @next and @prev, and then an actual answer to the question as posed.

 

Although I will not be surprised if this is not made clear enough in the Guidelines, the @next and @prev attributes exist for the purpose of getting around XML overlap problems. (I would say “sole purpose”; others might disagree.) They allow an encoder to say “this set of XML elements should be thought of as a single content object which I could not encode as a singe XML element because of the well-formedness rule of XML that forbids overlap”. Hence the recommendation in the Guidelines that the element a @next or @prev points to should be of the same element type as the element that bears the @next or @prev. That is, <biblScope xml:id="myscope02" prev="myscope01"> says “you should take the <biblScope> with ID "myscope01" and prepend it to this <biblScope> to make a complete <biblScope> that defines the scope of my parent bibliographic reference”.

 

(As a side note, I have often suggested the Guidelines should actually provide a constraint that requires the target of @next or @prev to be the same element type as the element bearing it; and that the Guidelines should do a better job of explaining what a processor should do with the attributes of the individual elements that are combined into one big virtual element.)

 

Now on to my actual response to the question as posed (where in the TEI header would it make sense to store information that allows us to figure out which is the previous and which is the next document in the larger series). If your documents in the series happen to be letters (or other correspondence) you are in luck. In such a case, TEI provides a very explicit place to provide this information:

/TEI/teiHeader/profileDesc/correspDesc/correspContext/ptr

where the <ptr> can have a @type of "next" or "prev". (If, BTW, you were to insist on providing a descriptive label, you can use <ref> instead of <ptr>.)

 

If your documents are not actually correspondence, you could either eschew <correspDesc> or decide to commit mild tag abuse and still use it to indicate sequence in your larger series. (Why I think this would be mild tag abuse but use of @next and @prev would be serious attribute abuse is an interesting question for another day, and might involve large psychiatry bills. :-)

 

Last, my preferred solution: nested <TEI> elements. To wit:

<?xml version="1.0" encoding="UTF-8"?>

<?xml-model href="/path/to/myProject.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>

<?xml-model href="/path/to/myProject.sch" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>

<TEI xmlns="http://www.tei-c.org/ns/1.0">

  <teiHeader>

    <!-- metadata that applies to entire larger series -->

  </teiHeader>

  <TEI>

    <teiHeader>

      <!-- metadata specific to 1st document in series -->

    </teiHeader>

    <text>

      <!-- encoded representation of 1st document in series -->

    </text>

  </TEI>

  <TEI>

    <teiHeader>

      <!-- metadata specific to 2nd document in series -->

    </teiHeader>

    <text>

      <!-- encoded representation of 2nd document in series -->

    </text>

  </TEI>

  <!-- ... -->

  <TEI>

    <teiHeader>

      <!-- metadata specific to 142nd document in series -->

    </teiHeader>

    <text>

      <!-- encoded representation of 142nd document in series -->

    </text>

  </TEI>

</TEI>

Which, of course, could be stored on your file system as separate documents to make encoding and management easier:

<?xml version="1.0" encoding="UTF-8"?>

<?xml-model href="/path/to/myProject.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>

<?xml-model href="/path/to/myProject.sch" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>

<TEI xmlns:xi="http://www.w3.org/2001/XInclude" xmlns="http://www.tei-c.org/ns/1.0">

  <teiHeader>

    <!-- metadata that applies to entire larger series -->

  </teiHeader>

  <xi:include href="./doc001.tei"/>

  <xi:include href="./doc002.tei"/>

  <!-- ... -->

  <xi:include href="./doc142.tei"/>

</TEI>

HTH.

Stay safe.

 


 

GI> teiHeader/fileDesc/seriesStmt/biblScope accepts the @prev and @next attributes and also descriptive text as content.

SV> Many of the projects on which I work have documents which are members in
SV> a larger series of ordered documents. One of the features that users
SV> find convenient is the able to browse through these documents in a
SV> linear fashion, i.e., using links to the "previous" or "next" document
SV> in the series.
SV>
SV> My question is where in the TEI header would it make sense to store such
SV> information? I can't seem to find any appropriate existing element that
SV> is suited to this task.
>
SV> At a minimum, I need both a pointer and a descriptive label for each
SV> "direction" (i.e., forward and backward in the sequence), which I could
SV> then convert to  "Previous Document" and "Next Document" links at render
SV> time.
>
SV> No doubt I am overlooking something obvious, but the only way I can see
SV> to facilitate this feature are the @next and @prev attributes on the
SV> <TEI> element, but those only get me half of what I need (i.e., the
SV> pointers, but not the associated descriptive labels). Pointers alone are
SV> insufficient as they do not support a human-readable label.

Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

Imsieke, Gerrit, le-tex
In reply to this post by Bauman, Syd
Syd,

After reading the entire documentation of @prev and @next (as opposed to
only the first sentence), I concur that using them for the suggested
purpose is in fact attribute abuse. They are not meant to stitch
together any abstract “elements” (such as volumes of a series) to a
“virtual aggregate”, but the documentation is quite clearly thinking and
speaking of actual XML elements.

My original intent was to use (the repeatable element) <biblScope> like
this:

<biblScope prev="[URI of the preceding volume]">This is the title of the
preceding volume that might not available for querying its title when
the current file is processed</biblScope>
<biblScope next="[URI of the following volume]">This is the title of the
following volume</biblScope>

Then Elli says:

 > The text content of <biblScope> would provide a human readable
description of series numbering of the current document.

This I don’t see in the documentation. Why shouldn’t it be allowed to
encode the current work’s position within a series by referring to a
predecessor and to a successor, if there were canonical attributes or
elements available to point to these external resources.

Use of <biblScope> in the header seems to be poorly documented anyway.
Although it is allowed as per
https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-seriesStmt.html, it
isn’t mentioned as one of <seriesStmt>’s children here:
https://tei-c.org/release/doc/tei-p5-doc/en/html/HD.html#HD26

But the proposed solution falls flat anyway since it relies on severe
attribute abuse.

Gerrit

On 22.10.2020 02:12, Bauman, Syd wrote:

> Although Gerrit is correct, <biblScope> does have @prev and @next
> attributes, and can have text content, use of @prev and @next for this
> purpose would be attribute abuse. More on that in a moment.
>
> First, I have to admit I am a bit confounded by the stated requirements.
> Some questions jump to mind:
>
>   * Why would it be necessary to use pointers to establish sequence? I
>     am not suggesting there is never a reason, but it is usually the
>     case that sequence can be established quite easily some other way.
>     E.g., by giving each document a sequence number (perhaps expressed
>     on /TEI/@xml:id, /TEI/@n, or
>     /TEI/teiHeader/fileDesc/publicationStmt/idno), or by collecting each
>     <TEI> document that is a member of the larger series in an outer
>     <TEI> (or <teiCorpus>) document that represents the larger series.
>   * If a pointer is to be used, and its value is to be consistently
>     processed to what “Previous Document” and “Next Document” point to,
>     why do you need descriptive labels? That is, couldn’t
>     @nextDocumentOfLargerSeries always be processed in such a way as it
>     gets the label “Next Document”?
>
> Now on to @next and @prev, and then an actual answer to the question as
> posed.
>
> Although I will not be surprised if this is not made clear enough in the
> /Guidelines, /the @next and @prev attributes exist for the purpose of
> getting around XML overlap problems. (I would say “sole purpose”; others
> might disagree.) They allow an encoder to say “this set of XML elements
> should be thought of as a single content object which I could not encode
> as a singe XML element because of the well-formedness rule of XML that
> forbids overlap”. Hence the recommendation in the /Guidelines/ that the
> element a @next or @prev points to should be of the same element type as
> the element that bears the @next or @prev. That is, <biblScope
> xml:id="myscope02" prev="myscope01"> says “you should take the
> <biblScope> with ID "myscope01" and prepend it to this <biblScope> to
> make a complete <biblScope> that defines the scope of my parent
> bibliographic reference”.
>
> (As a side note, I have often suggested the /Guidelines/ should actually
> provide a constraint that *requires* the target of @next or @prev to be
> the same element type as the element bearing it; and that the
> /Guidelines/ should do a better job of explaining what a processor
> should do with the attributes of the individual elements that are
> combined into one big virtual element.)
>
> Now on to my actual response to the question as posed (where in the TEI
> header would it make sense to store information that allows us to figure
> out which is the previous and which is the next document in the larger
> series). If your documents in the series happen to be letters (or other
> correspondence) you are in luck. In such a case, TEI provides a very
> explicit place to provide this information:
> /TEI/teiHeader/profileDesc/correspDesc/correspContext/ptr
> where the <ptr> can have a @type of "next" or "prev". (If, BTW, you were
> to insist on providing a descriptive label, you can use <ref> instead of
> <ptr>.)
>
> If your documents are not actually correspondence, you could either
> eschew <correspDesc> or decide to commit mild tag abuse and still use it
> to indicate sequence in your larger series. (Why I think this would be
> mild tag abuse but use of @next and @prev would be serious attribute
> abuse is an interesting question for another day, and might involve
> large psychiatry bills. :-)
>
> Last, my preferred solution: nested <TEI> elements. To wit:
> <?xml version="1.0" encoding="UTF-8"?>
> <?xml-model href="/path/to/myProject.rng" type="application/xml"
> schematypens="http://relaxng.org/ns/structure/1.0"?>
> <?xml-model href="/path/to/myProject.sch" type="application/xml"
> schematypens="http://purl.oclc.org/dsdl/schematron"?>
> <TEI xmlns="http://www.tei-c.org/ns/1.0">
>    <teiHeader>
>      <!-- metadata that applies to entire larger series -->
>    </teiHeader>
>    <TEI>
>      <teiHeader>
>        <!-- metadata specific to 1st document in series -->
>      </teiHeader>
>      <text>
>        <!-- encoded representation of 1st document in series -->
>      </text>
>    </TEI>
>    <TEI>
>      <teiHeader>
>        <!-- metadata specific to 2nd document in series -->
>      </teiHeader>
>      <text>
>        <!-- encoded representation of 2nd document in series -->
>      </text>
>    </TEI>
>    <!-- ... -->
>    <TEI>
>      <teiHeader>
>        <!-- metadata specific to 142nd document in series -->
>      </teiHeader>
>      <text>
>        <!-- encoded representation of 142nd document in series -->
>      </text>
>    </TEI>
> </TEI>
> Which, of course, could be stored on your file system as separate
> documents to make encoding and management easier:
> <?xml version="1.0" encoding="UTF-8"?>
> <?xml-model href="/path/to/myProject.rng" type="application/xml"
> schematypens="http://relaxng.org/ns/structure/1.0"?>
> <?xml-model href="/path/to/myProject.sch" type="application/xml"
> schematypens="http://purl.oclc.org/dsdl/schematron"?>
> <TEI xmlns:xi="http://www.w3.org/2001/XInclude"
> xmlns="http://www.tei-c.org/ns/1.0">
>    <teiHeader>
>      <!-- metadata that applies to entire larger series -->
>    </teiHeader>
>    <xi:include href="./doc001.tei"/>
>    <xi:include href="./doc002.tei"/>
>    <!-- ... -->
>    <xi:include href="./doc142.tei"/>
> </TEI>
> HTH.
> Stay safe.
>
> ------------------------------------------------------------------------
> GI> teiHeader/fileDesc/seriesStmt/biblScope accepts the @prev and @next
> attributes and also descriptive text as content.
>
> SV> Many of the projects on which I work have documents which are
> members in
> SV> a larger series of ordered documents. One of the features that users
> SV> find convenient is the able to browse through these documents in a
> SV> linear fashion, i.e., using links to the "previous" or "next" document
> SV> in the series.
> SV>
> SV> My question is where in the TEI header would it make sense to store
> such
> SV> information? I can't seem to find any appropriate existing element that
> SV> is suited to this task.
>>
> SV> At a minimum, I need both a pointer and a descriptive label for each
> SV> "direction" (i.e., forward and backward in the sequence), which I could
> SV> then convert to  "Previous Document" and "Next Document" links at
> render
> SV> time.
>>
> SV> No doubt I am overlooking something obvious, but the only way I can see
> SV> to facilitate this feature are the @next and @prev attributes on the
> SV> <TEI> element, but those only get me half of what I need (i.e., the
> SV> pointers, but not the associated descriptive labels). Pointers alone
> are
> SV> insufficient as they do not support a human-readable label.
>
Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

Elisa Beshero-Bondar-2
I'm not sure I agree about these charges of attribute abuse. @prev and @next, as Syd has been emphasizing is meant to point to a preceding and following element (ideally the same element) in an aggregated series. Well, if you stitch together a series of TEI documents into a whole, why could we not be applying these attribute to point to the preceding or following TEI element, or fileDesc element? Surely this is not attribute abuse but merely pointing to the next of a thing in a series. I had thought that putting the attributes on fileDesc would permit a connection of fileDesc elements in a series. 

Elisa

On Wed, Oct 21, 2020 at 9:05 PM Imsieke, Gerrit, le-tex <[hidden email]> wrote:
Syd,

After reading the entire documentation of @prev and @next (as opposed to
only the first sentence), I concur that using them for the suggested
purpose is in fact attribute abuse. They are not meant to stitch
together any abstract “elements” (such as volumes of a series) to a
“virtual aggregate”, but the documentation is quite clearly thinking and
speaking of actual XML elements.

My original intent was to use (the repeatable element) <biblScope> like
this:

<biblScope prev="[URI of the preceding volume]">This is the title of the
preceding volume that might not available for querying its title when
the current file is processed</biblScope>
<biblScope next="[URI of the following volume]">This is the title of the
following volume</biblScope>

Then Elli says:

 > The text content of <biblScope> would provide a human readable
description of series numbering of the current document.

This I don’t see in the documentation. Why shouldn’t it be allowed to
encode the current work’s position within a series by referring to a
predecessor and to a successor, if there were canonical attributes or
elements available to point to these external resources.

Use of <biblScope> in the header seems to be poorly documented anyway.
Although it is allowed as per
https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-seriesStmt.html, it
isn’t mentioned as one of <seriesStmt>’s children here:
https://tei-c.org/release/doc/tei-p5-doc/en/html/HD.html#HD26

But the proposed solution falls flat anyway since it relies on severe
attribute abuse.

Gerrit

On 22.10.2020 02:12, Bauman, Syd wrote:
> Although Gerrit is correct, <biblScope> does have @prev and @next
> attributes, and can have text content, use of @prev and @next for this
> purpose would be attribute abuse. More on that in a moment.
>
> First, I have to admit I am a bit confounded by the stated requirements.
> Some questions jump to mind:
>
>   * Why would it be necessary to use pointers to establish sequence? I
>     am not suggesting there is never a reason, but it is usually the
>     case that sequence can be established quite easily some other way.
>     E.g., by giving each document a sequence number (perhaps expressed
>     on /TEI/@xml:id, /TEI/@n, or
>     /TEI/teiHeader/fileDesc/publicationStmt/idno), or by collecting each
>     <TEI> document that is a member of the larger series in an outer
>     <TEI> (or <teiCorpus>) document that represents the larger series.
>   * If a pointer is to be used, and its value is to be consistently
>     processed to what “Previous Document” and “Next Document” point to,
>     why do you need descriptive labels? That is, couldn’t
>     @nextDocumentOfLargerSeries always be processed in such a way as it
>     gets the label “Next Document”?
>
> Now on to @next and @prev, and then an actual answer to the question as
> posed.
>
> Although I will not be surprised if this is not made clear enough in the
> /Guidelines, /the @next and @prev attributes exist for the purpose of
> getting around XML overlap problems. (I would say “sole purpose”; others
> might disagree.) They allow an encoder to say “this set of XML elements
> should be thought of as a single content object which I could not encode
> as a singe XML element because of the well-formedness rule of XML that
> forbids overlap”. Hence the recommendation in the /Guidelines/ that the
> element a @next or @prev points to should be of the same element type as
> the element that bears the @next or @prev. That is, <biblScope
> xml:id="myscope02" prev="myscope01"> says “you should take the
> <biblScope> with ID "myscope01" and prepend it to this <biblScope> to
> make a complete <biblScope> that defines the scope of my parent
> bibliographic reference”.
>
> (As a side note, I have often suggested the /Guidelines/ should actually
> provide a constraint that *requires* the target of @next or @prev to be
> the same element type as the element bearing it; and that the
> /Guidelines/ should do a better job of explaining what a processor
> should do with the attributes of the individual elements that are
> combined into one big virtual element.)
>
> Now on to my actual response to the question as posed (where in the TEI
> header would it make sense to store information that allows us to figure
> out which is the previous and which is the next document in the larger
> series). If your documents in the series happen to be letters (or other
> correspondence) you are in luck. In such a case, TEI provides a very
> explicit place to provide this information:
> /TEI/teiHeader/profileDesc/correspDesc/correspContext/ptr
> where the <ptr> can have a @type of "next" or "prev". (If, BTW, you were
> to insist on providing a descriptive label, you can use <ref> instead of
> <ptr>.)
>
> If your documents are not actually correspondence, you could either
> eschew <correspDesc> or decide to commit mild tag abuse and still use it
> to indicate sequence in your larger series. (Why I think this would be
> mild tag abuse but use of @next and @prev would be serious attribute
> abuse is an interesting question for another day, and might involve
> large psychiatry bills. :-)
>
> Last, my preferred solution: nested <TEI> elements. To wit:
> <?xml version="1.0" encoding="UTF-8"?>
> <?xml-model href="/path/to/myProject.rng" type="application/xml"
> schematypens="http://relaxng.org/ns/structure/1.0"?>
> <?xml-model href="/path/to/myProject.sch" type="application/xml"
> schematypens="http://purl.oclc.org/dsdl/schematron"?>
> <TEI xmlns="http://www.tei-c.org/ns/1.0">
>    <teiHeader>
>      <!-- metadata that applies to entire larger series -->
>    </teiHeader>
>    <TEI>
>      <teiHeader>
>        <!-- metadata specific to 1st document in series -->
>      </teiHeader>
>      <text>
>        <!-- encoded representation of 1st document in series -->
>      </text>
>    </TEI>
>    <TEI>
>      <teiHeader>
>        <!-- metadata specific to 2nd document in series -->
>      </teiHeader>
>      <text>
>        <!-- encoded representation of 2nd document in series -->
>      </text>
>    </TEI>
>    <!-- ... -->
>    <TEI>
>      <teiHeader>
>        <!-- metadata specific to 142nd document in series -->
>      </teiHeader>
>      <text>
>        <!-- encoded representation of 142nd document in series -->
>      </text>
>    </TEI>
> </TEI>
> Which, of course, could be stored on your file system as separate
> documents to make encoding and management easier:
> <?xml version="1.0" encoding="UTF-8"?>
> <?xml-model href="/path/to/myProject.rng" type="application/xml"
> schematypens="http://relaxng.org/ns/structure/1.0"?>
> <?xml-model href="/path/to/myProject.sch" type="application/xml"
> schematypens="http://purl.oclc.org/dsdl/schematron"?>
> <TEI xmlns:xi="http://www.w3.org/2001/XInclude"
> xmlns="http://www.tei-c.org/ns/1.0">
>    <teiHeader>
>      <!-- metadata that applies to entire larger series -->
>    </teiHeader>
>    <xi:include href="./doc001.tei"/>
>    <xi:include href="./doc002.tei"/>
>    <!-- ... -->
>    <xi:include href="./doc142.tei"/>
> </TEI>
> HTH.
> Stay safe.
>
> ------------------------------------------------------------------------
> GI> teiHeader/fileDesc/seriesStmt/biblScope accepts the @prev and @next
> attributes and also descriptive text as content.
>
> SV> Many of the projects on which I work have documents which are
> members in
> SV> a larger series of ordered documents. One of the features that users
> SV> find convenient is the able to browse through these documents in a
> SV> linear fashion, i.e., using links to the "previous" or "next" document
> SV> in the series.
> SV>
> SV> My question is where in the TEI header would it make sense to store
> such
> SV> information? I can't seem to find any appropriate existing element that
> SV> is suited to this task.
>>
> SV> At a minimum, I need both a pointer and a descriptive label for each
> SV> "direction" (i.e., forward and backward in the sequence), which I could
> SV> then convert to  "Previous Document" and "Next Document" links at
> render
> SV> time.
>>
> SV> No doubt I am overlooking something obvious, but the only way I can see
> SV> to facilitate this feature are the @next and @prev attributes on the
> SV> <TEI> element, but those only get me half of what I need (i.e., the
> SV> pointers, but not the associated descriptive labels). Pointers alone
> are
> SV> insufficient as they do not support a human-readable label.
>


--
Elisa Beshero-Bondar, PhD
Program Chair of Digital Media, Arts, and Technology | Professor of Digital Humanities |  Director of the Digital Humanities Lab at Penn State Erie, The Behrend College 
Development site: https://newtfire.org 
Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

Martin Mueller

What would the ‘textualists’ and ‘originalists’ say about this argument?

 

From: "TEI (Text Encoding Initiative) public discussion list" <[hidden email]> on behalf of Elisa Beshero-Bondar <[hidden email]>
Reply-To: Elisa Beshero-Bondar <[hidden email]>
Date: Wednesday, October 21, 2020 at 8:18 PM
To: "[hidden email]" <[hidden email]>
Subject: Re: Documents in an Ordered Series

 

I'm not sure I agree about these charges of attribute abuse. @prev and @next, as Syd has been emphasizing is meant to point to a preceding and following element (ideally the same element) in an aggregated series. Well, if you stitch together a series of TEI documents into a whole, why could we not be applying these attribute to point to the preceding or following TEI element, or fileDesc element? Surely this is not attribute abuse but merely pointing to the next of a thing in a series. I had thought that putting the attributes on fileDesc would permit a connection of fileDesc elements in a series. 

Elisa

 

On Wed, Oct 21, 2020 at 9:05 PM Imsieke, Gerrit, le-tex <[hidden email]> wrote:

Syd,

After reading the entire documentation of @prev and @next (as opposed to
only the first sentence), I concur that using them for the suggested
purpose is in fact attribute abuse. They are not meant to stitch
together any abstract “elements” (such as volumes of a series) to a
“virtual aggregate”, but the documentation is quite clearly thinking and
speaking of actual XML elements.

My original intent was to use (the repeatable element) <biblScope> like
this:

<biblScope prev="[URI of the preceding volume]">This is the title of the
preceding volume that might not available for querying its title when
the current file is processed</biblScope>
<biblScope next="[URI of the following volume]">This is the title of the
following volume</biblScope>

Then Elli says:

 > The text content of <biblScope> would provide a human readable
description of series numbering of the current document.

This I don’t see in the documentation. Why shouldn’t it be allowed to
encode the current work’s position within a series by referring to a
predecessor and to a successor, if there were canonical attributes or
elements available to point to these external resources.

Use of <biblScope> in the header seems to be poorly documented anyway.
Although it is allowed as per
https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-seriesStmt.html, it
isn’t mentioned as one of <seriesStmt>’s children here:
https://tei-c.org/release/doc/tei-p5-doc/en/html/HD.html#HD26

But the proposed solution falls flat anyway since it relies on severe
attribute abuse.

Gerrit

On 22.10.2020 02:12, Bauman, Syd wrote:
> Although Gerrit is correct, <biblScope> does have @prev and @next
> attributes, and can have text content, use of @prev and @next for this
> purpose would be attribute abuse. More on that in a moment.
>
> First, I have to admit I am a bit confounded by the stated requirements.
> Some questions jump to mind:
>
>   * Why would it be necessary to use pointers to establish sequence? I
>     am not suggesting there is never a reason, but it is usually the
>     case that sequence can be established quite easily some other way.
>     E.g., by giving each document a sequence number (perhaps expressed
>     on /TEI/@xml:id, /TEI/@n, or
>     /TEI/teiHeader/fileDesc/publicationStmt/idno), or by collecting each
>     <TEI> document that is a member of the larger series in an outer
>     <TEI> (or <teiCorpus>) document that represents the larger series.
>   * If a pointer is to be used, and its value is to be consistently
>     processed to what “Previous Document” and “Next Document” point to,
>     why do you need descriptive labels? That is, couldn’t
>     @nextDocumentOfLargerSeries always be processed in such a way as it
>     gets the label “Next Document”?
>
> Now on to @next and @prev, and then an actual answer to the question as
> posed.
>
> Although I will not be surprised if this is not made clear enough in the
> /Guidelines, /the @next and @prev attributes exist for the purpose of
> getting around XML overlap problems. (I would say “sole purpose”; others
> might disagree.) They allow an encoder to say “this set of XML elements
> should be thought of as a single content object which I could not encode
> as a singe XML element because of the well-formedness rule of XML that
> forbids overlap”. Hence the recommendation in the /Guidelines/ that the
> element a @next or @prev points to should be of the same element type as
> the element that bears the @next or @prev. That is, <biblScope
> xml:id="myscope02" prev="myscope01"> says “you should take the
> <biblScope> with ID "myscope01" and prepend it to this <biblScope> to
> make a complete <biblScope> that defines the scope of my parent
> bibliographic reference”.
>
> (As a side note, I have often suggested the /Guidelines/ should actually
> provide a constraint that *requires* the target of @next or @prev to be
> the same element type as the element bearing it; and that the
> /Guidelines/ should do a better job of explaining what a processor
> should do with the attributes of the individual elements that are
> combined into one big virtual element.)
>
> Now on to my actual response to the question as posed (where in the TEI
> header would it make sense to store information that allows us to figure
> out which is the previous and which is the next document in the larger
> series). If your documents in the series happen to be letters (or other
> correspondence) you are in luck. In such a case, TEI provides a very
> explicit place to provide this information:
> /TEI/teiHeader/profileDesc/correspDesc/correspContext/ptr
> where the <ptr> can have a @type of "next" or "prev". (If, BTW, you were
> to insist on providing a descriptive label, you can use <ref> instead of
> <ptr>.)
>
> If your documents are not actually correspondence, you could either
> eschew <correspDesc> or decide to commit mild tag abuse and still use it
> to indicate sequence in your larger series. (Why I think this would be
> mild tag abuse but use of @next and @prev would be serious attribute
> abuse is an interesting question for another day, and might involve
> large psychiatry bills. :-)
>
> Last, my preferred solution: nested <TEI> elements. To wit:
> <?xml version="1.0" encoding="UTF-8"?>
> <?xml-model href="/path/to/myProject.rng" type="application/xml"
> schematypens="http://relaxng.org/ns/structure/1.0"?>
> <?xml-model href="/path/to/myProject.sch" type="application/xml"
> schematypens="http://purl.oclc.org/dsdl/schematron"?>
> <TEI xmlns="http://www.tei-c.org/ns/1.0">
>    <teiHeader>
>      <!-- metadata that applies to entire larger series -->
>    </teiHeader>
>    <TEI>
>      <teiHeader>
>        <!-- metadata specific to 1st document in series -->
>      </teiHeader>
>      <text>
>        <!-- encoded representation of 1st document in series -->
>      </text>
>    </TEI>
>    <TEI>
>      <teiHeader>
>        <!-- metadata specific to 2nd document in series -->
>      </teiHeader>
>      <text>
>        <!-- encoded representation of 2nd document in series -->
>      </text>
>    </TEI>
>    <!-- ... -->
>    <TEI>
>      <teiHeader>
>        <!-- metadata specific to 142nd document in series -->
>      </teiHeader>
>      <text>
>        <!-- encoded representation of 142nd document in series -->
>      </text>
>    </TEI>
> </TEI>
> Which, of course, could be stored on your file system as separate
> documents to make encoding and management easier:
> <?xml version="1.0" encoding="UTF-8"?>
> <?xml-model href="/path/to/myProject.rng" type="application/xml"
> schematypens="http://relaxng.org/ns/structure/1.0"?>
> <?xml-model href="/path/to/myProject.sch" type="application/xml"
> schematypens="http://purl.oclc.org/dsdl/schematron"?>
> <TEI xmlns:xi="http://www.w3.org/2001/XInclude"
> xmlns="http://www.tei-c.org/ns/1.0">
>    <teiHeader>
>      <!-- metadata that applies to entire larger series -->
>    </teiHeader>
>    <xi:include href="./doc001.tei"/>
>    <xi:include href="./doc002.tei"/>
>    <!-- ... -->
>    <xi:include href="./doc142.tei"/>
> </TEI>
> HTH.
> Stay safe.
>
> ------------------------------------------------------------------------
> GI> teiHeader/fileDesc/seriesStmt/biblScope accepts the @prev and @next
> attributes and also descriptive text as content.
>
> SV> Many of the projects on which I work have documents which are
> members in
> SV> a larger series of ordered documents. One of the features that users
> SV> find convenient is the able to browse through these documents in a
> SV> linear fashion, i.e., using links to the "previous" or "next" document
> SV> in the series.
> SV>
> SV> My question is where in the TEI header would it make sense to store
> such
> SV> information? I can't seem to find any appropriate existing element that
> SV> is suited to this task.
>>
> SV> At a minimum, I need both a pointer and a descriptive label for each
> SV> "direction" (i.e., forward and backward in the sequence), which I could
> SV> then convert to  "Previous Document" and "Next Document" links at
> render
> SV> time.
>>
> SV> No doubt I am overlooking something obvious, but the only way I can see
> SV> to facilitate this feature are the @next and @prev attributes on the
> SV> <TEI> element, but those only get me half of what I need (i.e., the
> SV> pointers, but not the associated descriptive labels). Pointers alone
> are
> SV> insufficient as they do not support a human-readable label.
>


 

--

Elisa Beshero-Bondar, PhD

Program Chair of Digital Media, Arts, and Technology | Professor of Digital Humanities |  Director of the Digital Humanities Lab at Penn State Erie, The Behrend College 

Development site: https://newtfire.org 

Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

Bauman, Syd
In reply to this post by Elisa Beshero-Bondar-2
But @next and @prev are not meant to stitch together disparate things into a series, they are meant to indicate that separate XML elements are a single object. They are meant to be a hack around overlap. Period. Any other use will make figuring out how to process these things a nightmare. (As if it weren’t hard enough already!)

Putting @next on <fileDesc> does not say “go over there for the next file description in a series of distinct file descriptions”, rather it says “go over there for the rest of the single aggregrate file description of which I am also a part”.


 
I'm not sure I agree about these charges of attribute abuse. @prev and @next, as Syd has been emphasizing is meant to point to a preceding and following element (ideally the same element) in an aggregated series. Well, if you stitch together a series of TEI documents into a whole, why could we not be applying these attribute to point to the preceding or following TEI element, or fileDesc element? Surely this is not attribute abuse but merely pointing to the next of a thing in a series. I had thought that putting the attributes on fileDesc would permit a connection of fileDesc elements in a series. 

Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

C. M. Sperberg-McQueen
In reply to this post by Bauman, Syd
> On 21,Oct2020, at 6:12 PM, Bauman, Syd <[hidden email]> wrote:
>
> Although Gerrit is correct, <biblScope> does have @prev and @next attributes, and can have text content, use of @prev and @next for this purpose would be attribute abuse. More on that in a moment.
>
> First, I have to admit I am a bit confounded by the stated requirements. Some questions jump to mind:
> • Why would it be necessary to use pointers to establish sequence? I am not suggesting there is never a reason, but it is usually the case that sequence can be established quite easily some other way. E.g., by giving each document a sequence number (perhaps expressed on /TEI/@xml:id, /TEI/@n, or /TEI/teiHeader/fileDesc/publicationStmt/idno), or by collecting each <TEI> document that is a member of the larger series in an outer <TEI> (or <teiCorpus>) document that represents the larger series.
> • If a pointer is to be used, and its value is to be consistently processed to what “Previous Document” and “Next Document” point to, why do you need descriptive labels? That is, couldn’t @nextDocumentOfLargerSeries always be processed in such a way as it gets the label “Next Document”?

Here are two — ok, three -- use cases at they have presented themselves in my experience:

(1) An online documentary edition is presenting a selection of documents.  A simple-minded user interface will provide a toc pointing to each document, but once the reader is there, they have to go back to the toc to move forward.  Bad UI design, perhaps, but I committed that error some years ago in the Model Editions Partnership [1], see for example especially [2], the selection from the Margaret Sanger Papers.

[1] http://modeleditions.blackmesatech.com/mep/
[2] http://modeleditions.blackmesatech.com/mep/MS/docs/ms-table.html

The documents had identifiers, but not sequence numbers, so a solution based on document number does not work.  (Nor is the sequence number within the selection being presented in any way intrinsic to the document.)

The user interface I would like to have been able to build (and still hope to build someday when time permits) would allow multiple trails through the edition, so that the ’next document’ and ‘previous document’ links would depend on which trail the user was following.  And in the general case, the link to the next document might require some explanatory or bridging text.

(2) The documentation for a complex system is being presented online.  Some sections of the documentation are intended only for readers already familiar in some detail with the system; others are intended to be accessible to first-time readers and new users of the system.  It would be convenient to be able to provide an interface in which the next segment of material to be presented to the user depends on whether the user is following the first-reader or the show-everything trail through the documentation.

Off the top of my head, I can think of three or four systems with documentation in this style:  the IBM user manual for the Rexx programming language; the TeX Book; probably also the LaTeX book (but I’m too lazy to go check); the online documentation for ACL2.  If it were more convenient to provide trails through a collection of material, I could readily imagine at least three trails through each of these.

Here, distinctive text for the links appears not to be necessary, though it might be convenient.

(3) An online edition of Julio Cortázar’s novel Hopscotch, for which the author provides two different reading orders.  I believe this is also true for some other fictions.

Here, distinctive text for the links appears not to be necessary.


My private recommendation to the original poster was to make an independent document consisting of a set of links, which can have as many end-points as is desired and which can of course carry arbitrarily complicated link descriptions.  The publication workflow would consult the independent trail document(s) as well as the primary source documents, in building the user’s view of the material.

It is true that the spread of the World Wide Web appears to have killed off a lot of the theoretical and practical discussion of hypertext, but the notion of trails through complex collections of material is worth preserving, and supporting.

********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
[hidden email]
http://www.blackmesatech.com
********************************************
Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

Paul Schaffner
In reply to this post by Martin Mueller
I'm certainly not going THERE.

But over here among the ad-hoccers, whenever we have a bunch of stuff
we want to arrange in an ordered sequence -- the entries in a dictionary,
for example, or illustrative quotations in a dictionary entry,
or images in a slide show, or even pages in a book -- we tend to
add a simple sortable numerical sequence (seq or pseq or qseq or whatever)
attribute to the appropriate element.

Makes it easier to sort them, and easier also to point to the
next one.

pfs



On Wed, Oct 21, 2020, at 21:23, Martin Mueller wrote:

>  
> What would the ‘textualists’ and ‘originalists’ say about this argument?
>
>  
>
> *From: *"TEI (Text Encoding Initiative) public discussion list"
> <[hidden email]> on behalf of Elisa Beshero-Bondar
> <[hidden email]>
> *Reply-To: *Elisa Beshero-Bondar <[hidden email]>
> *Date: *Wednesday, October 21, 2020 at 8:18 PM
> *To: *"[hidden email]" <[hidden email]>
> *Subject: *Re: Documents in an Ordered Series
>
>  
>
> I'm not sure I agree about these charges of attribute abuse. @prev and
> @next, as Syd has been emphasizing is meant to point to a preceding and
> following element (ideally the same element) in an aggregated series.
> Well, if you stitch together a series of TEI documents into a whole,
> why could we not be applying these attribute to point to the preceding
> or following TEI element, or fileDesc element? Surely this is not
> attribute abuse but merely pointing to the next of a thing in a series.
> I had thought that putting the attributes on fileDesc would permit a
> connection of fileDesc elements in a series.
>
> Elisa
>
>  
>
> On Wed, Oct 21, 2020 at 9:05 PM Imsieke, Gerrit, le-tex
> <[hidden email]> wrote:
>
> > Syd,
> >
> > After reading the entire documentation of @prev and @next (as opposed to
> > only the first sentence), I concur that using them for the suggested
> > purpose is in fact attribute abuse. They are not meant to stitch
> > together any abstract “elements” (such as volumes of a series) to a
> > “virtual aggregate”, but the documentation is quite clearly thinking and
> > speaking of actual XML elements.
> >
> > My original intent was to use (the repeatable element) <biblScope> like
> > this:
> >
> > <biblScope prev="[URI of the preceding volume]">This is the title of the
> > preceding volume that might not available for querying its title when
> > the current file is processed</biblScope>
> > <biblScope next="[URI of the following volume]">This is the title of the
> > following volume</biblScope>
> >
> > Then Elli says:
> >
> >  > The text content of <biblScope> would provide a human readable
> > description of series numbering of the current document.
> >
> > This I don’t see in the documentation. Why shouldn’t it be allowed to
> > encode the current work’s position within a series by referring to a
> > predecessor and to a successor, if there were canonical attributes or
> > elements available to point to these external resources.
> >
> > Use of <biblScope> in the header seems to be poorly documented anyway.
> > Although it is allowed as per
> > https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-seriesStmt.html <https://urldefense.com/v3/__https:/tei-c.org/release/doc/tei-p5-doc/en/html/ref-seriesStmt.html__;!!Dq0X2DkFhyF93HkjWTBQKhk!FbeApKFz4tqHehQz0smu26hONevkARtNAnav3tmia2kZtYzzdXSUA4YbjaS6rjgqeoiU_rwIXA$>, it
> > isn’t mentioned as one of <seriesStmt>’s children here:
> > https://tei-c.org/release/doc/tei-p5-doc/en/html/HD.html#HD26 <https://urldefense.com/v3/__https:/tei-c.org/release/doc/tei-p5-doc/en/html/HD.html*HD26__;Iw!!Dq0X2DkFhyF93HkjWTBQKhk!FbeApKFz4tqHehQz0smu26hONevkARtNAnav3tmia2kZtYzzdXSUA4YbjaS6rjgqeog5Hw5_NA$>
> >
> > But the proposed solution falls flat anyway since it relies on severe
> > attribute abuse.
> >
> > Gerrit
> >
> > On 22.10.2020 02:12, Bauman, Syd wrote:
> > > Although Gerrit is correct, <biblScope> does have @prev and @next
> > > attributes, and can have text content, use of @prev and @next for this
> > > purpose would be attribute abuse. More on that in a moment.
> > >
> > > First, I have to admit I am a bit confounded by the stated requirements.
> > > Some questions jump to mind:
> > >
> > >   * Why would it be necessary to use pointers to establish sequence? I
> > >     am not suggesting there is never a reason, but it is usually the
> > >     case that sequence can be established quite easily some other way.
> > >     E.g., by giving each document a sequence number (perhaps expressed
> > >     on /TEI/@xml:id, /TEI/@n, or
> > >     /TEI/teiHeader/fileDesc/publicationStmt/idno), or by collecting each
> > >     <TEI> document that is a member of the larger series in an outer
> > >     <TEI> (or <teiCorpus>) document that represents the larger series.
> > >   * If a pointer is to be used, and its value is to be consistently
> > >     processed to what “Previous Document” and “Next Document” point to,
> > >     why do you need descriptive labels? That is, couldn’t
> > >     @nextDocumentOfLargerSeries always be processed in such a way as it
> > >     gets the label “Next Document”?
> > >
> > > Now on to @next and @prev, and then an actual answer to the question as
> > > posed.
> > >
> > > Although I will not be surprised if this is not made clear enough in the
> > > /Guidelines, /the @next and @prev attributes exist for the purpose of
> > > getting around XML overlap problems. (I would say “sole purpose”; others
> > > might disagree.) They allow an encoder to say “this set of XML elements
> > > should be thought of as a single content object which I could not encode
> > > as a singe XML element because of the well-formedness rule of XML that
> > > forbids overlap”. Hence the recommendation in the /Guidelines/ that the
> > > element a @next or @prev points to should be of the same element type as
> > > the element that bears the @next or @prev. That is, <biblScope
> > > xml:id="myscope02" prev="myscope01"> says “you should take the
> > > <biblScope> with ID "myscope01" and prepend it to this <biblScope> to
> > > make a complete <biblScope> that defines the scope of my parent
> > > bibliographic reference”.
> > >
> > > (As a side note, I have often suggested the /Guidelines/ should actually
> > > provide a constraint that *requires* the target of @next or @prev to be
> > > the same element type as the element bearing it; and that the
> > > /Guidelines/ should do a better job of explaining what a processor
> > > should do with the attributes of the individual elements that are
> > > combined into one big virtual element.)
> > >
> > > Now on to my actual response to the question as posed (where in the TEI
> > > header would it make sense to store information that allows us to figure
> > > out which is the previous and which is the next document in the larger
> > > series). If your documents in the series happen to be letters (or other
> > > correspondence) you are in luck. In such a case, TEI provides a very
> > > explicit place to provide this information:
> > > /TEI/teiHeader/profileDesc/correspDesc/correspContext/ptr
> > > where the <ptr> can have a @type of "next" or "prev". (If, BTW, you were
> > > to insist on providing a descriptive label, you can use <ref> instead of
> > > <ptr>.)
> > >
> > > If your documents are not actually correspondence, you could either
> > > eschew <correspDesc> or decide to commit mild tag abuse and still use it
> > > to indicate sequence in your larger series. (Why I think this would be
> > > mild tag abuse but use of @next and @prev would be serious attribute
> > > abuse is an interesting question for another day, and might involve
> > > large psychiatry bills. :-)
> > >
> > > Last, my preferred solution: nested <TEI> elements. To wit:
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <?xml-model href="/path/to/myProject.rng" type="application/xml"
> > > schematypens="http://relaxng.org/ns/structure/1.0 <https://urldefense.com/v3/__http:/relaxng.org/ns/structure/1.0__;!!Dq0X2DkFhyF93HkjWTBQKhk!FbeApKFz4tqHehQz0smu26hONevkARtNAnav3tmia2kZtYzzdXSUA4YbjaS6rjgqeoj3JK6Sqw$>"?>
> > > <?xml-model href="/path/to/myProject.sch" type="application/xml"
> > > schematypens="http://purl.oclc.org/dsdl/schematron <https://urldefense.com/v3/__http:/purl.oclc.org/dsdl/schematron__;!!Dq0X2DkFhyF93HkjWTBQKhk!FbeApKFz4tqHehQz0smu26hONevkARtNAnav3tmia2kZtYzzdXSUA4YbjaS6rjgqeoiGf8DZLQ$>"?>
> > > <TEI xmlns="http://www.tei-c.org/ns/1.0 <https://urldefense.com/v3/__http:/www.tei-c.org/ns/1.0__;!!Dq0X2DkFhyF93HkjWTBQKhk!FbeApKFz4tqHehQz0smu26hONevkARtNAnav3tmia2kZtYzzdXSUA4YbjaS6rjgqeohNdITZVA$>">
> > >    <teiHeader>
> > >      <!-- metadata that applies to entire larger series -->
> > >    </teiHeader>
> > >    <TEI>
> > >      <teiHeader>
> > >        <!-- metadata specific to 1st document in series -->
> > >      </teiHeader>
> > >      <text>
> > >        <!-- encoded representation of 1st document in series -->
> > >      </text>
> > >    </TEI>
> > >    <TEI>
> > >      <teiHeader>
> > >        <!-- metadata specific to 2nd document in series -->
> > >      </teiHeader>
> > >      <text>
> > >        <!-- encoded representation of 2nd document in series -->
> > >      </text>
> > >    </TEI>
> > >    <!-- ... -->
> > >    <TEI>
> > >      <teiHeader>
> > >        <!-- metadata specific to 142nd document in series -->
> > >      </teiHeader>
> > >      <text>
> > >        <!-- encoded representation of 142nd document in series -->
> > >      </text>
> > >    </TEI>
> > > </TEI>
> > > Which, of course, could be stored on your file system as separate
> > > documents to make encoding and management easier:
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <?xml-model href="/path/to/myProject.rng" type="application/xml"
> > > schematypens="http://relaxng.org/ns/structure/1.0 <https://urldefense.com/v3/__http:/relaxng.org/ns/structure/1.0__;!!Dq0X2DkFhyF93HkjWTBQKhk!FbeApKFz4tqHehQz0smu26hONevkARtNAnav3tmia2kZtYzzdXSUA4YbjaS6rjgqeoj3JK6Sqw$>"?>
> > > <?xml-model href="/path/to/myProject.sch" type="application/xml"
> > > schematypens="http://purl.oclc.org/dsdl/schematron <https://urldefense.com/v3/__http:/purl.oclc.org/dsdl/schematron__;!!Dq0X2DkFhyF93HkjWTBQKhk!FbeApKFz4tqHehQz0smu26hONevkARtNAnav3tmia2kZtYzzdXSUA4YbjaS6rjgqeoiGf8DZLQ$>"?>
> > > <TEI xmlns:xi="http://www.w3.org/2001/XInclude <https://urldefense.com/v3/__http:/www.w3.org/2001/XInclude__;!!Dq0X2DkFhyF93HkjWTBQKhk!FbeApKFz4tqHehQz0smu26hONevkARtNAnav3tmia2kZtYzzdXSUA4YbjaS6rjgqeogsaTQE1Q$>"
> > > xmlns="http://www.tei-c.org/ns/1.0 <https://urldefense.com/v3/__http:/www.tei-c.org/ns/1.0__;!!Dq0X2DkFhyF93HkjWTBQKhk!FbeApKFz4tqHehQz0smu26hONevkARtNAnav3tmia2kZtYzzdXSUA4YbjaS6rjgqeohNdITZVA$>">
> > >    <teiHeader>
> > >      <!-- metadata that applies to entire larger series -->
> > >    </teiHeader>
> > >    <xi:include href="./doc001.tei"/>
> > >    <xi:include href="./doc002.tei"/>
> > >    <!-- ... -->
> > >    <xi:include href="./doc142.tei"/>
> > > </TEI>
> > > HTH.
> > > Stay safe.
> > >
> > > ------------------------------------------------------------------------
> > > GI> teiHeader/fileDesc/seriesStmt/biblScope accepts the @prev and @next
> > > attributes and also descriptive text as content.
> > >
> > > SV> Many of the projects on which I work have documents which are
> > > members in
> > > SV> a larger series of ordered documents. One of the features that users
> > > SV> find convenient is the able to browse through these documents in a
> > > SV> linear fashion, i.e., using links to the "previous" or "next" document
> > > SV> in the series.
> > > SV>
> > > SV> My question is where in the TEI header would it make sense to store
> > > such
> > > SV> information? I can't seem to find any appropriate existing element that
> > > SV> is suited to this task.
> > >>
> > > SV> At a minimum, I need both a pointer and a descriptive label for each
> > > SV> "direction" (i.e., forward and backward in the sequence), which I could
> > > SV> then convert to  "Previous Document" and "Next Document" links at
> > > render
> > > SV> time.
> > >>
> > > SV> No doubt I am overlooking something obvious, but the only way I can see
> > > SV> to facilitate this feature are the @next and @prev attributes on the
> > > SV> <TEI> element, but those only get me half of what I need (i.e., the
> > > SV> pointers, but not the associated descriptive labels). Pointers alone
> > > are
> > > SV> insufficient as they do not support a human-readable label.
> > >
>
>
>
>  
>
> --
>
> Elisa Beshero-Bondar, PhD
>
> Program Chair of Digital Media, Arts, and Technology | Professor of
> Digital Humanities |  Director of the Digital Humanities Lab at Penn
> State Erie, The Behrend College
>
> Development site: https://newtfire.org 
> <https://urldefense.com/v3/__https:/newtfire.org/__;!!Dq0X2DkFhyF93HkjWTBQKhk!FbeApKFz4tqHehQz0smu26hONevkARtNAnav3tmia2kZtYzzdXSUA4YbjaS6rjgqeoilLDPFYQ$>
>

--
Paul Schaffner  Digital Content & Collections
University of Michigan Libraries
[hidden email] | http://www.umich.edu/~pfs/
Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

Elisa Beshero-Bondar-2
In reply to this post by Bauman, Syd
Syd calls @prev and @next "a hack around overlap," and the bluntness of that phrasing is a little jarring because it's not what we say in the Guidelines. (Should we limit the use of @next and @prev only to instances of working around hierarchy problems?) How are we to understand the finer nuances of this phrase, in the Guidelines' explanation of @next?
"points to the next element of a virtual aggregate of which the current element is part."

What is "a virtual aggregate"? I take it to be whole formed by distinct parts, which in this case we have some need of marking in a set sequence.

 I don't understand why setting an attribute to point fore and aft in a series makes processing a nightmare. In my XSLT work, it makes processing easier to have a set of attributes pinned reliably on an element that points, well, to the next or to the previous. 

Elisa

On Wed, Oct 21, 2020 at 9:28 PM Bauman, Syd <[hidden email]> wrote:
But @next and @prev are not meant to stitch together disparate things into a series, they are meant to indicate that separate XML elements are a single object. They are meant to be a hack around overlap. Period. Any other use will make figuring out how to process these things a nightmare. (As if it weren’t hard enough already!)

Putting @next on <fileDesc> does not say “go over there for the next file description in a series of distinct file descriptions”, rather it says “go over there for the rest of the single aggregrate file description of which I am also a part”.


 
I'm not sure I agree about these charges of attribute abuse. @prev and @next, as Syd has been emphasizing is meant to point to a preceding and following element (ideally the same element) in an aggregated series. Well, if you stitch together a series of TEI documents into a whole, why could we not be applying these attribute to point to the preceding or following TEI element, or fileDesc element? Surely this is not attribute abuse but merely pointing to the next of a thing in a series. I had thought that putting the attributes on fileDesc would permit a connection of fileDesc elements in a series. 



--
Elisa Beshero-Bondar, PhD
Program Chair of Digital Media, Arts, and Technology | Professor of Digital Humanities |  Director of the Digital Humanities Lab at Penn State Erie, The Behrend College 
Development site: https://newtfire.org 
Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

C. M. Sperberg-McQueen
In reply to this post by Bauman, Syd
> On 21,Oct2020, at 7:28 PM, Bauman, Syd <[hidden email]> wrote:
>
> But @next and @prev are not meant to stitch together disparate things into a series, they are meant to indicate that separate XML elements are a single object.

Can you cite normative text to support that claim?

I am having a little trouble understanding how to indicate that separate XML elements x, y, and z form a single object without somehow stitching them together into a series.

(I am assuming that by ‘are a single object’ you mean ’together form a single object’ rather than ‘are the same object, represented twice’, for which I believe the expected markup is @sameAs.)


> They are meant to be a hack around overlap. Period. Any other use will make figuring out how to process these things a nightmare. (As if it weren’t hard enough already!)

I think that the utility (and intended use, if the psychology of the specifiers were relevant, which is at best problematic, as Martin Mueller has already reminded us in this thread) of ’next’ and ‘prev’ goes well beyond overlap as I understand that term.  In particular, the disordered haiku in the Hughie / Louis / Dewey example of sec. 16.7 cannot, I think, be represented with simple overlap.  But ’next’ and ‘prev’ can certainly be used to handle disordered and discontinuous material like this, and not solely cases of overlap.

>
> Putting @next on <fileDesc> does not say “go over there for the next file description in a series of distinct file descriptions”, rather it says “go over there for the rest of the single aggregrate file description of which I am also a part”.

I think it’s fair to say that the text could be a little more explicit on this, though making the meaning of things like ’next’, ‘prev’, and the ‘join’ element explicit is very challenging, if one would also like not to bewilder most readers — I think the current text does better than P3 did, but Syd’s interpretation seems to me to rely very heavily on what looks rhetorically like a side remark.

If I understand Syd’s position correctly, he holds that in the H/L/D example, if we wish to record both the sequence of utterances and a (virtual) haiku consisting of an ‘lg’ and three ‘l’ elements, doing so with ’next’ and ‘prev’ would require the attributes to be carried on ‘lg’ elements and not on the ‘l’ elements.  In the example as given in 16.7, this is clearly a bit awkward, because the lg elements in the example also contain the lines “da-da-da” and “…”.  Also, on this account of things, we cannot use ’next’ and ‘prev’ to identify a sequence of things (e.g. a sequence of ‘l’ elements without a surrounding ‘lg’).


>
>    
> I'm not sure I agree about these charges of attribute abuse. @prev and @next, as Syd has been emphasizing is meant to point to a preceding and following element (ideally the same element) in an aggregated series. Well, if you stitch together a series of TEI documents into a whole, why could we not be applying these attribute to point to the preceding or following TEI element, or fileDesc element? Surely this is not attribute abuse but merely pointing to the next of a thing in a series. I had thought that putting the attributes on fileDesc would permit a connection of fileDesc elements in a series.
>

I sympathize with this view, but it does seem to contradict the statement in 16.7 that the third example of next/prev given "is equivalent to specifying a link element”, where the example given is clearly intended (as the ensuing prose suggests) to represent a single element of the same element type as the two elements linked by ’next’ and ‘prev’.  My recollection is that those who drafted this part of P2 and P3 were not completely clear in their minds about whether two elements of a given type joined by next and prev should form, virtually, a single element of that type or a sequence of such elements, and did not as a group have the patience to work it out in full detail.  In practice, sometimes I find I want one behavior, and sometimes I want the other.  But since in TexMecs Claus Huitfeldt and I introduced anonymous character-data chunks to which identifiers could be assigned, I rather suspect that we thought that ‘join’ (which is said to be equivalent to a next/prev chain, though bizarrely the current text says this is true only when the next/prev chain is doubly linked) worked the way Syd now says it works.  

But I may be wrong.

Michael




********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
[hidden email]
http://www.blackmesatech.com
********************************************
Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

Imsieke, Gerrit, le-tex
In reply to this post by Elisa Beshero-Bondar-2
Maybe this can be resolved by specifying on which elements (in the XML
sense) @prev and @next are meant to merge overlapping units and on which
they are meant to convey sequence order.

<ref>, <ptr>, <seriesStmt> come to my mind for the latter. If the
processor knows that it must not attempt to merge units if @prev or
@next occur on these elements, it can interpret them in any other way,
hopefully in a canonical way.

The current linking problem can then be encoded as
<publicationStmt>
   <ref next="[URI of following]">Description of Following Volume</ref>
   …
</publicationStmt>
or as
<seriesStmt next="[URI of following]">
   …
</seriesStmt>
where [URI of following] can point to bibliographical information in the
current document, using fragment identifiers, or it can be the URI of an
external resource.

Gerrit

On 22.10.2020 03:45, Elisa Beshero-Bondar wrote:

> Syd calls @prev and @next "a hack around overlap," and the bluntness of
> that phrasing is a little jarring because it's not what we say in the
> Guidelines. (Should we limit the use of @next and @prev only to
> instances of working around hierarchy problems?) How are we
> to understand the finer nuances of this phrase, in the Guidelines'
> explanation of @next?
> "points to the next element of a virtual aggregate of which the current
> element is part."
>
> What is "a virtual aggregate"? I take it to be whole formed by distinct
> parts, which in this case we have some need of marking in a set sequence.
>
>   I don't understand why setting an attribute to point fore and aft in a
> series makes processing a nightmare. In my XSLT work, it makes
> processing easier to have a set of attributes pinned reliably on an
> element that points, well, to the next or to the previous.
>
> Elisa
>
> On Wed, Oct 21, 2020 at 9:28 PM Bauman, Syd <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     But @next and @prev are *not* meant to stitch together disparate
>     things into a series, they are meant to indicate that separate XML
>     elements are a single object. They are meant to be a hack around
>     overlap. Period. Any other use will make figuring out how to process
>     these things a nightmare. (As if it weren’t hard enough already!)
>
>     Putting @next on <fileDesc> does not say “go over there for the next
>     file description in a series of distinct file descriptions”, rather
>     it says “go over there for the rest of the single aggregrate file
>     description of which I am also a part”.
>
>     ------------------------------------------------------------------------
>     I'm not sure I agree about these charges of attribute abuse. @prev
>     and @next, as Syd has been emphasizing is meant to point to a
>     preceding and following element (ideally the same element) in an
>     aggregated series. Well, if you stitch together a series of TEI
>     documents into a whole, why could we not be applying these attribute
>     to point to the preceding or following TEI element, or fileDesc
>     element? Surely this is not attribute abuse but merely pointing to
>     the next of a thing in a series. I had thought that putting the
>     attributes on fileDesc would permit a connection of fileDesc
>     elements in a series.
>
>
>
> --
> Elisa Beshero-Bondar, PhD
> Program Chair of Digital Media, Arts, and Technology | Professor of
> Digital Humanities |  Director of the Digital Humanities Lab at Penn
> State Erie, The Behrend College
> Development site: https://newtfire.org <https://newtfire.org/>
Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

Martin Holmes
Hi all,

How about:

<relatedItem type="nextInSeries" target="thing.xml">

Seems to fit the definition of relatedItem perfectly well.

Cheers,
Martin

On 2020-10-21 7:19 p.m., Imsieke, Gerrit, le-tex wrote:

> Maybe this can be resolved by specifying on which elements (in the XML
> sense) @prev and @next are meant to merge overlapping units and on which
> they are meant to convey sequence order.
>
> <ref>, <ptr>, <seriesStmt> come to my mind for the latter. If the
> processor knows that it must not attempt to merge units if @prev or
> @next occur on these elements, it can interpret them in any other way,
> hopefully in a canonical way.
>
> The current linking problem can then be encoded as
> <publicationStmt>
>    <ref next="[URI of following]">Description of Following Volume</ref>
>    …
> </publicationStmt>
> or as
> <seriesStmt next="[URI of following]">
>    …
> </seriesStmt>
> where [URI of following] can point to bibliographical information in the
> current document, using fragment identifiers, or it can be the URI of an
> external resource.
>
> Gerrit
>
> On 22.10.2020 03:45, Elisa Beshero-Bondar wrote:
>> Syd calls @prev and @next "a hack around overlap," and the bluntness
>> of that phrasing is a little jarring because it's not what we say in
>> the Guidelines. (Should we limit the use of @next and @prev only to
>> instances of working around hierarchy problems?) How are we
>> to understand the finer nuances of this phrase, in the Guidelines'
>> explanation of @next?
>> "points to the next element of a virtual aggregate of which the
>> current element is part."
>>
>> What is "a virtual aggregate"? I take it to be whole formed by
>> distinct parts, which in this case we have some need of marking in a
>> set sequence.
>>
>>   I don't understand why setting an attribute to point fore and aft in
>> a series makes processing a nightmare. In my XSLT work, it makes
>> processing easier to have a set of attributes pinned reliably on an
>> element that points, well, to the next or to the previous.
>>
>> Elisa
>>
>> On Wed, Oct 21, 2020 at 9:28 PM Bauman, Syd <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     But @next and @prev are *not* meant to stitch together disparate
>>     things into a series, they are meant to indicate that separate XML
>>     elements are a single object. They are meant to be a hack around
>>     overlap. Period. Any other use will make figuring out how to process
>>     these things a nightmare. (As if it weren’t hard enough already!)
>>
>>     Putting @next on <fileDesc> does not say “go over there for the next
>>     file description in a series of distinct file descriptions”, rather
>>     it says “go over there for the rest of the single aggregrate file
>>     description of which I am also a part”.
>>
>>    
>> ------------------------------------------------------------------------
>>     I'm not sure I agree about these charges of attribute abuse. @prev
>>     and @next, as Syd has been emphasizing is meant to point to a
>>     preceding and following element (ideally the same element) in an
>>     aggregated series. Well, if you stitch together a series of TEI
>>     documents into a whole, why could we not be applying these attribute
>>     to point to the preceding or following TEI element, or fileDesc
>>     element? Surely this is not attribute abuse but merely pointing to
>>     the next of a thing in a series. I had thought that putting the
>>     attributes on fileDesc would permit a connection of fileDesc
>>     elements in a series.
>>
>>
>>
>> --
>> Elisa Beshero-Bondar, PhD
>> Program Chair of Digital Media, Arts, and Technology | Professor of
>> Digital Humanities |  Director of the Digital Humanities Lab at Penn
>> State Erie, The Behrend College
>> Development site: https://newtfire.org <https://newtfire.org/>

--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

Jean-Paul Rehr
Notwithstanding the question of rightness of using @prev and @next,  this solution requires significant maintenance overhead (multiple attribute coordination) with high risk of data entry error. Moreover, it also tries to address interface design within the TEI document, which isn't best practice re: separation of concerns.

Is there a reason not to use @n with an integer value? Any calculation later on for interface design is a matter of TEI/@n +1 and TEI/@n -1 . It is also useful for producing an ordered list in any output, etc. 

JPR

On Thu, Oct 22, 2020 at 5:48 AM Martin Holmes <[hidden email]> wrote:
Hi all,

How about:

<relatedItem type="nextInSeries" target="thing.xml">

Seems to fit the definition of relatedItem perfectly well.

Cheers,
Martin

On 2020-10-21 7:19 p.m., Imsieke, Gerrit, le-tex wrote:
> Maybe this can be resolved by specifying on which elements (in the XML
> sense) @prev and @next are meant to merge overlapping units and on which
> they are meant to convey sequence order.
>
> <ref>, <ptr>, <seriesStmt> come to my mind for the latter. If the
> processor knows that it must not attempt to merge units if @prev or
> @next occur on these elements, it can interpret them in any other way,
> hopefully in a canonical way.
>
> The current linking problem can then be encoded as
> <publicationStmt>
>    <ref next="[URI of following]">Description of Following Volume</ref>
>    …
> </publicationStmt>
> or as
> <seriesStmt next="[URI of following]">
>    …
> </seriesStmt>
> where [URI of following] can point to bibliographical information in the
> current document, using fragment identifiers, or it can be the URI of an
> external resource.
>
> Gerrit
>
> On 22.10.2020 03:45, Elisa Beshero-Bondar wrote:
>> Syd calls @prev and @next "a hack around overlap," and the bluntness
>> of that phrasing is a little jarring because it's not what we say in
>> the Guidelines. (Should we limit the use of @next and @prev only to
>> instances of working around hierarchy problems?) How are we
>> to understand the finer nuances of this phrase, in the Guidelines'
>> explanation of @next?
>> "points to the next element of a virtual aggregate of which the
>> current element is part."
>>
>> What is "a virtual aggregate"? I take it to be whole formed by
>> distinct parts, which in this case we have some need of marking in a
>> set sequence.
>>
>>   I don't understand why setting an attribute to point fore and aft in
>> a series makes processing a nightmare. In my XSLT work, it makes
>> processing easier to have a set of attributes pinned reliably on an
>> element that points, well, to the next or to the previous.
>>
>> Elisa
>>
>> On Wed, Oct 21, 2020 at 9:28 PM Bauman, Syd <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     But @next and @prev are *not* meant to stitch together disparate
>>     things into a series, they are meant to indicate that separate XML
>>     elements are a single object. They are meant to be a hack around
>>     overlap. Period. Any other use will make figuring out how to process
>>     these things a nightmare. (As if it weren’t hard enough already!)
>>
>>     Putting @next on <fileDesc> does not say “go over there for the next
>>     file description in a series of distinct file descriptions”, rather
>>     it says “go over there for the rest of the single aggregrate file
>>     description of which I am also a part”.
>>
>>     
>> ------------------------------------------------------------------------
>>     I'm not sure I agree about these charges of attribute abuse. @prev
>>     and @next, as Syd has been emphasizing is meant to point to a
>>     preceding and following element (ideally the same element) in an
>>     aggregated series. Well, if you stitch together a series of TEI
>>     documents into a whole, why could we not be applying these attribute
>>     to point to the preceding or following TEI element, or fileDesc
>>     element? Surely this is not attribute abuse but merely pointing to
>>     the next of a thing in a series. I had thought that putting the
>>     attributes on fileDesc would permit a connection of fileDesc
>>     elements in a series.
>>
>>
>>
>> --
>> Elisa Beshero-Bondar, PhD
>> Program Chair of Digital Media, Arts, and Technology | Professor of
>> Digital Humanities |  Director of the Digital Humanities Lab at Penn
>> State Erie, The Behrend College
>> Development site: https://newtfire.org <https://newtfire.org/>

--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

Laurent Romary
In the same vain, if one wants to sort objects in the TEI, we do have @sortKey (https://tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.sortable.html).
I appears on a number of specific elements and if need be can be added to others wit a little customisation.
Laurent


Le 22 oct. 2020 à 09:56, Jean-Paul Rehr <[hidden email]> a écrit :

Notwithstanding the question of rightness of using @prev and @next,  this solution requires significant maintenance overhead (multiple attribute coordination) with high risk of data entry error. Moreover, it also tries to address interface design within the TEI document, which isn't best practice re: separation of concerns.

Is there a reason not to use @n with an integer value? Any calculation later on for interface design is a matter of TEI/@n +1 and TEI/@n -1 . It is also useful for producing an ordered list in any output, etc. 

JPR

On Thu, Oct 22, 2020 at 5:48 AM Martin Holmes <[hidden email]> wrote:
Hi all,

How about:

<relatedItem type="nextInSeries" target="thing.xml">

Seems to fit the definition of relatedItem perfectly well.

Cheers,
Martin

On 2020-10-21 7:19 p.m., Imsieke, Gerrit, le-tex wrote:
> Maybe this can be resolved by specifying on which elements (in the XML
> sense) @prev and @next are meant to merge overlapping units and on which
> they are meant to convey sequence order.
>
> <ref>, <ptr>, <seriesStmt> come to my mind for the latter. If the
> processor knows that it must not attempt to merge units if @prev or
> @next occur on these elements, it can interpret them in any other way,
> hopefully in a canonical way.
>
> The current linking problem can then be encoded as
> <publicationStmt>
>    <ref next="[URI of following]">Description of Following Volume</ref>
>    …
> </publicationStmt>
> or as
> <seriesStmt next="[URI of following]">
>    …
> </seriesStmt>
> where [URI of following] can point to bibliographical information in the
> current document, using fragment identifiers, or it can be the URI of an
> external resource.
>
> Gerrit
>
> On 22.10.2020 03:45, Elisa Beshero-Bondar wrote:
>> Syd calls @prev and @next "a hack around overlap," and the bluntness
>> of that phrasing is a little jarring because it's not what we say in
>> the Guidelines. (Should we limit the use of @next and @prev only to
>> instances of working around hierarchy problems?) How are we
>> to understand the finer nuances of this phrase, in the Guidelines'
>> explanation of @next?
>> "points to the next element of a virtual aggregate of which the
>> current element is part."
>>
>> What is "a virtual aggregate"? I take it to be whole formed by
>> distinct parts, which in this case we have some need of marking in a
>> set sequence.
>>
>>   I don't understand why setting an attribute to point fore and aft in
>> a series makes processing a nightmare. In my XSLT work, it makes
>> processing easier to have a set of attributes pinned reliably on an
>> element that points, well, to the next or to the previous.
>>
>> Elisa
>>
>> On Wed, Oct 21, 2020 at 9:28 PM Bauman, Syd <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     But @next and @prev are *not* meant to stitch together disparate
>>     things into a series, they are meant to indicate that separate XML
>>     elements are a single object. They are meant to be a hack around
>>     overlap. Period. Any other use will make figuring out how to process
>>     these things a nightmare. (As if it weren’t hard enough already!)
>>
>>     Putting @next on <fileDesc> does not say “go over there for the next
>>     file description in a series of distinct file descriptions”, rather
>>     it says “go over there for the rest of the single aggregrate file
>>     description of which I am also a part”.
>>
>>     
>> ------------------------------------------------------------------------
>>     I'm not sure I agree about these charges of attribute abuse. @prev
>>     and @next, as Syd has been emphasizing is meant to point to a
>>     preceding and following element (ideally the same element) in an
>>     aggregated series. Well, if you stitch together a series of TEI
>>     documents into a whole, why could we not be applying these attribute
>>     to point to the preceding or following TEI element, or fileDesc
>>     element? Surely this is not attribute abuse but merely pointing to
>>     the next of a thing in a series. I had thought that putting the
>>     attributes on fileDesc would permit a connection of fileDesc
>>     elements in a series.
>>
>>
>>
>> --
>> Elisa Beshero-Bondar, PhD
>> Program Chair of Digital Media, Arts, and Technology | Professor of
>> Digital Humanities |  Director of the Digital Humanities Lab at Penn
>> State Erie, The Behrend College
>> Development site: https://newtfire.org <https://newtfire.org/>

--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]

Laurent Romary
Inria, team ALMAnaCH






Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

Frederik Elwert-2
In reply to this post by Elisa Beshero-Bondar-2
Am 22.10.20 um 03:45 schrieb Elisa Beshero-Bondar:

> Syd calls @prev and @next "a hack around overlap," and the bluntness of
> that phrasing is a little jarring because it's not what we say in the
> Guidelines. (Should we limit the use of @next and @prev only to
> instances of working around hierarchy problems?) How are we
> to understand the finer nuances of this phrase, in the Guidelines'
> explanation of @next?
> "points to the next element of a virtual aggregate of which the current
> element is part."
>
> What is "a virtual aggregate"? I take it to be whole formed by distinct
> parts, which in this case we have some need of marking in a set sequence.

I generally agree with Syd here. I would add that it’s not only overlap,
but also elements broken into parts, and potentially other constructs.

As I always understood @next and @prev, as well as the prose of “a
virtual aggregate”, is that @next and @prev are processing instructions
that work around limitations in the serialization format (XML). In my
understanding, they hint at the construction of something like a
“virtual DOM” that represents the “real”, intended set of elements that
can be distinct from the XML elements that were used in encoding.

The example in the guidelines is a sentence that is split due to an
interruption (shortened):

  <s xml:id="qs3" next="#qs4"><emph>But</emph>,</s>
  <s>she pushed her face nearer,</s>
  <s xml:id="qs4" prev="#qs3">he never stops stirring it!</s>

I think the vital information here is that “But he never stops stirring
it” is a single sentence. So in our virtual DOM, there a two s elements,
not three.

Unfortunately, as Syd also points out, the guidelines are never really
specific about how such a virtual DOM would actually look like and how
processors should implement these instructions.[1]

But I would agree that saying "This sentences comes after the other" is
a very different thing from saying "There is only one sentence, but it
is serialized using two XML elements".

Frederik


[1]: A side note: I would be very interested to see how the
Text-as-Graph approach could actually be regarded as an implementation
of a TEI virtual DOM, including parsing and serialization instructions
for TEI-XML.


>  I don't understand why setting an attribute to point fore and aft in a
> series makes processing a nightmare. In my XSLT work, it makes
> processing easier to have a set of attributes pinned reliably on an
> element that points, well, to the next or to the previous. 
>
> Elisa
>
> On Wed, Oct 21, 2020 at 9:28 PM Bauman, Syd <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     But @next and @prev are *not* meant to stitch together disparate
>     things into a series, they are meant to indicate that separate XML
>     elements are a single object. They are meant to be a hack around
>     overlap. Period. Any other use will make figuring out how to process
>     these things a nightmare. (As if it weren’t hard enough already!)
>
>     Putting @next on <fileDesc> does not say “go over there for the next
>     file description in a series of distinct file descriptions”, rather
>     it says “go over there for the rest of the single aggregrate file
>     description of which I am also a part”.
>
>     ------------------------------------------------------------------------
>      
>     I'm not sure I agree about these charges of attribute abuse. @prev
>     and @next, as Syd has been emphasizing is meant to point to a
>     preceding and following element (ideally the same element) in an
>     aggregated series. Well, if you stitch together a series of TEI
>     documents into a whole, why could we not be applying these attribute
>     to point to the preceding or following TEI element, or fileDesc
>     element? Surely this is not attribute abuse but merely pointing to
>     the next of a thing in a series. I had thought that putting the
>     attributes on fileDesc would permit a connection of fileDesc
>     elements in a series. 
>
>
>
> --
> Elisa Beshero-Bondar, PhD
> Program Chair of Digital Media, Arts, and Technology | Professor of
> Digital Humanities |  Director of the Digital Humanities Lab at Penn
> State Erie, The Behrend College 
> Development site: https://newtfire.org <https://newtfire.org/

--
Dr. Frederik Elwert

Digital Humanities coordinator
Center for Religious Studies
Ruhr-University Bochum

Universitätsstr. 90a
D-44780 Bochum

Room 2.06
Tel. +49 (0)234 32-23024
Reply | Threaded
Open this post in threaded view
|

Re: Documents in an Ordered Series

James Cummings-5
In reply to this post by Scott Vanderbilt (TEI-L)

Notwithstanding the more theoretical aspects of this discussion and loose definitions of different approaches, I've always tended towards the more pragmatic approaches to the original poster's issue. When having many documents (or fragments of documents) and providing Prev/Next buttons on a website for users to browse through I am usually basing that on:

a) A series of xml:id's unique throughout the collection often stored somewhere like the <TEI> or <text> element
b) A series<idno type="Something"> that is also programmatically determined to be unique throughout the collection
c) Filenames of the individual files or burst-out xml source fragments or at worst
d) A separate file (sometimes generated) storing a master list of some sort with each item (or whatever) storing those extra bits of information and a pointer to the file. 

In the case where it is generated from xml:id, <idno> or Filename, then I've always created a consistent place for any information for labels or similar (but usually that is title or indeed an id number of some sort that makes sense to the user). While those options are in descending order of preference for me, if the collection isn't subject to a lot of change then d) is perfectly reasonable. 

While fascinating of course, personally I don't think the use of TEI @next and @prev are actually what the original poster wants.

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 Scott Vanderbilt (TEI-L) <[hidden email]>
Sent: 21 October 2020 23:37
To: [hidden email] <[hidden email]>
Subject: Documents in an Ordered Series
 
⚠ External sender. Take care when opening links or attachments. Do not provide your login details.

Many of the projects on which I work have documents which are members in
a larger series of ordered documents. One of the features that users
find convenient is the able to browse through these documents in a
linear fashion, i.e., using links to the "previous" or "next" document
in the series.

My question is where in the TEI header would it make sense to store such
information? I can't seem to find any appropriate existing element that
is suited to this task.

At a minimum, I need both a pointer and a descriptive label for each
"direction" (i.e., forward and backward in the sequence), which I could
then convert to  "Previous Document" and "Next Document" links at render
time.

No doubt I am overlooking something obvious, but the only way I can see
to facilitate this feature are the @next and @prev attributes on the
<TEI> element, but those only get me half of what I need (i.e., the
pointers, but not the associated descriptive labels). Pointers alone are
insufficient as they do not support a human-readable label.

Thank you.