on the question of sidenotes, footnotes, and end-notes
joshua said:
Both methods lose a little fidelity, since the Sidenote is not printed exactly right by the text it refers to, like it would in the original. But method two keeps it fairly close, and context should allow the reader to easily tell the part of the paragraph it refers to. Method one would allow the marker to appear near its original source location, but the information is now not in the same eye region. The user must click to the notes section to see the information, which is commonly meant to be more accessible/more important than a typical footnote.
is it unreasonable to want to view _all_ notes -- sidenotes, footnotes, _and_ endnotes _too_ -- right there close to the context where they apply? i think not. in print form, it cannot be done, of course. (not by the printer, anyway, although readers can do a pretty good job of using their hands to hold both pages, and switch between them.) hotlinks between a note and its referent can enable a person to "switch" in a similar way. but you're still looking at either one page or the other, when you want to look at _both_. and in the electronic arena, we can easily go that step better, so why not take advantage? in my viewer-program, all notes are stored in an end-note section, but any note can be "popped up" by a user just by clicking on its note-indicator. so on the left half of the screen, they have the body of the text, and on the right-half they have the end-note section in a scrollable edit-field. (actually the whole file, but it's auto-positioned at the appropriate note in the end-note section.) this lets them see each note in the context of the notes that surround it -- which can be very useful when the author has used ibids and op cits. in addition, if the user double-clicks inside the scrolling-field on the number of _another_ note, the display on the left-hand side jumps to show the page that has the text that calls _that_ note. so even though the notes are collected together in a place that is removed from their referents in the _file_, the viewer-program brings them together in a way giving users maximum power, letting them see text and note at the same time, and navigate easily amongst all of the notes. as i experiment with this system, i'm quite happy i've achieved a very good solution to the problem, and i consider myself to be "done" working on it... (at least until i consider what to do when printing.) but if you can think of any other capability i should add to it, please suggest it, i would love to hear it! and let the programmers of _your_ favorite viewer -- whoever they are -- know that _you_ would enjoy this ability to view _all_ notes just like sidenotes, simultaneously with the text that references them, so you would appreciate it if they would program that. let those programmers know that you'll be willing to format notes however they require in order to provide this feature, but you definitely _want_ the capability. and if you're not on speaking terms with the people who are programming your viewer-tools, _why_not_? -bowerbird
Yes, genius, we have that ability, too, in the HTML. We were talking about the plain text version which is reader program agnostic. Josh Bowerbird@aol.com wrote:
joshua said:
Both methods lose a little fidelity, since the Sidenote is not printed exactly right by the text it refers to, like it would in the original. But method two keeps it fairly close, and context should allow the reader to easily tell the part of the paragraph it refers to. Method one would allow the marker to appear near its original source location, but the information is now not in the same eye region. The user must click to the notes section to see the information, which is commonly meant to be more accessible/more important than a typical footnote.
is it unreasonable to want to view _all_ notes -- sidenotes, footnotes, _and_ endnotes _too_ -- right there close to the context where they apply?
i think not.
in print form, it cannot be done, of course. (not by the printer, anyway, although readers can do a pretty good job of using their hands to hold both pages, and switch between them.)
hotlinks between a note and its referent can enable a person to "switch" in a similar way.
but you're still looking at either one page or the other, when you want to look at _both_.
and in the electronic arena, we can easily go that step better, so why not take advantage?
in my viewer-program, all notes are stored in an end-note section, but any note can be "popped up" by a user just by clicking on its note-indicator.
so on the left half of the screen, they have the body of the text, and on the right-half they have the end-note section in a scrollable edit-field. (actually the whole file, but it's auto-positioned at the appropriate note in the end-note section.)
this lets them see each note in the context of the notes that surround it -- which can be very useful when the author has used ibids and op cits.
in addition, if the user double-clicks inside the scrolling-field on the number of _another_ note, the display on the left-hand side jumps to show the page that has the text that calls _that_ note.
so even though the notes are collected together in a place that is removed from their referents in the _file_, the viewer-program brings them together in a way giving users maximum power, letting them see text and note at the same time, and navigate easily amongst all of the notes.
as i experiment with this system, i'm quite happy i've achieved a very good solution to the problem, and i consider myself to be "done" working on it... (at least until i consider what to do when printing.)
but if you can think of any other capability i should add to it, please suggest it, i would love to hear it!
and let the programmers of _your_ favorite viewer -- whoever they are -- know that _you_ would enjoy this ability to view _all_ notes just like sidenotes, simultaneously with the text that references them, so you would appreciate it if they would program that.
let those programmers know that you'll be willing to format notes however they require in order to provide this feature, but you definitely _want_ the capability.
and if you're not on speaking terms with the people who are programming your viewer-tools, _why_not_?
-bowerbird _______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/listinfo.cgi/gutvol-d
The side note is not always the same as an end note or foot note. Take the following attempt at an ascii version of the first page of the EETS edition of the Romance of Merlin. It's the best I could do using a proportional font. Note: This example is 80 columns--some mail programs might mangle this. If it looks like it's a mess, try re-sizing your window larger. If it still doesn't look right then your mailer has inserted hard line-breaks. -- Begin -- The Romance of Merlin. --------- CHAPTER I . CONSULTATION OF DEVILS, AND BIRTH OF MERLIN. Fvll wrothe and angry was the Deuell, whan that oure lorde [Fol 1a.] hadde ben in helle, and had take oute Adam and Eve, and Anger of the other at his plesier; and whan the fendes sien that, they hadden Devil against right grete feer and gret merveile; thei assembleden to-gedir, our Lord. and seiden, "What is he this thus vs supprisith and dis- troyeth, in so moche that our strengthes ne nought ellis that we Assembly of haue may nought with-holde hym, nor again hym stonde in no the fiends diffence; but that he doth all that hym lyketh, we ne trowe not and their dis- that eny man myght be bore of woman, but that he sholde ben cussion. oures, and he that thus vs distroyeth, how is he born in whom we [did]1 knowe non erthely delyte." Than ansuerde anothir fende and seide, "He this hath distroyed that which we wende sholde haue be mooste oure a-vaile. Remembre ye not how the prophetes The prophets seiden, how that god shulde come in to erthe for to saue the said that God synners of Adam and Eve, and we yeden bysily a-boute theym should come that so seiden, and dide them moste turment of eny othir pepill, on earth to and it semed by their [feire]1 semblant, that it greved hem but save sinners. litill or nought, but they comforted hem that weren synners, and seide that oon sholde come, which sholde delyuer hem out of tharldome and disese. 1 Illegible 1 -- End -- First let's ignore the running analysis and do a simple markup of the main body of the passage: --- <div n="1" type="chapter"> <head type="title">The Romance of Merlin.</head> <head type="section title">CHAPTER I</head> <head type="subtitle">CONSULTATION OF DEVILS, AND BIRTH OF MERLIN.</head> <pb ed="folio" n="1a" /> <p>Fvll wrothe and angry was the Deuell, whan that oure lorde hadde ben in helle, and had take oute Adam and Eve, and other at his plesier; and whan the fendes sien that, they hadden right grete feer and gret merveile; thei assembleden to-gedir, and seiden, "What is he this thus vs supprisith and dis-troyeth, in so moche that our strengthes ne nought ellis that we haue may nought with-holde hym, nor again hym stonde in no diffence; but that he doth all that hym lyketh, we ne trowe not that eny man myght be bore of woman, but that he sholde ben oures, and he that thus vs distroyeth, how is he born in whom we <unclear resp="wheatly">did</unclear> knowe non erthely delyte." Than ansuerde anothir fende and seide, "He this hath distroyed that which we wende sholde haue be mooste oure a-vaile. Remembre ye not how the prophetes seiden, how that god shulde come in to erthe for to saue the synners of Adam and Eve, and we yeden bysily a-boute theym that so seiden, and dide them moste turment of eny othir pepill, and it semed by their <unclear resp="wheatly">feire</unclear> semblant, that it greved hem but litill or nought, but they comforted hem that weren synners, and seide that oon sholde come, which sholde delyuer hem out of tharldome and disese.</p> <pb ed="eets" n="1" /> </div> ... Except for the <unclear> tag this is all basic TEI-Lite. We have replaced the page break note and the page break with <pb> tags which indicate which edition they came from (the original folio manuscript or the EETS edition). We have also marked up the `Illegible' text with the <unclear> tag with the responsibility attribute indicating that the original editor of the EETS edition, Henry B. Wheatley was responsible for indicating that the marked text was unclear. Now, what about the running analysis. Can we use TEI to mark this up as well? Yes. --- <div n="1" type="chapter"> <head type="title">The Romance of Merlin.</head> <head type="section title">CHAPTER I</head> <head type="sybtitle">CONSULTATION OF DEVILS, AND BIRTH OF MERLIN.</head> <pb ed="folio" n="1a" /> <p> <seg id="1">Fvll wrothe and angry was the Deuell, whan that oure lorde hadde ben in helle, and had take oute Adam and Eve, and other at his plesier; and whan the fendes sien that, they hadden right grete feer and gret merveile;</seg> <seg id="2">thei assembleden to-gedir, and seiden, "What is he this thus vs supprisith and dis- troyeth, in so moche that our strengthes ne nought ellis that we haue may nought with-holde hym, nor again hym stonde in no diffence; but that he doth all that hym lyketh, we ne trowe not that eny man myght be bore of woman, but that he sholde ben oures, and he that thus vs distroyeth, how is he born in whom we <unclear resp="wheatly">did</unclear> knowe non erthely delyte." Than ansuerde anothir fende and seide, "He this hath distroyed that which we wende sholde haue be mooste oure a-vaile.</seg> <seg id="3">Remembre ye not how the prophetes seiden, how that god shulde come in to erthe for to saue the synners of Adam and Eve, and we yeden bysily a-boute theym that so seiden, and dide them moste turment of eny othir pepill, and it semed by their <unclear resp="wheatly">feire</unclear> semblant, that it greved hem but litill or nought, but they comforted hem that weren synners, and seide that oon sholde come, which sholde delyuer hem out of tharldome and disese.</seg> </p> <pb ed="eets" n="1" /> <interpGrp type='analysis' resp="wheatley"> <interp id='1' value='Anger of the Devil against our Lord.' /> <interp id='2' value='Assembly of the fiends and their discussion.' /> <interp id='3' value='The prophets said that God should come on earth to save sinners.' /> </interpGrp> </div> ... We've broken the paragraph into sections which each have an id which is used to link textual analysis using <interp> tags which are collected in a `interpGrp' group tag. An <interpGrp> can be created for the whole chapter or paragraph by paragraph. Obviously this solution uses full blown TEI, not just the TEI-Lite subset, but it does work. I would suggest that in the case of works like The Romance of Merlin, that PG should create two editions. The first would be a clean, reference edition of the original text, and then a second edition with all of the textual analysis and notes from the victorian edition. So using FRBR Entities the resulting texts would look something like this (I think, this is very confusing and I could have screwed this up). W Romance of Merlin (circa 1450-1460). E ... Text of Middle Eng. Translation of Middle French Suite De Merlin. M ...... Original MS. Transcription. I ......... Manuscript (University Library, Cambridge University) E ...... Merlin A Prose Romance (Edited By Henry B. Wheatley, Introduction by Edward Mead, 1899) M ......... EETS ed. London, 1899. M ......... PG TEI Master ed based on EETS ed. 2004. F ............... PG Plain Text Ed. F ............... PG HTML Ed. E ...... Text Only Electronic Edition (TEI Ed. 2004). M ............ PG TEI Master Ed. F ............... PG Plain Text Ed. F ............... PG HTML Ed. W ==> Work E ==> Expression M ==> Manifestation F ==> Format I ==> Item/Instance The Text-Only TEI version could then be used as a base reference text by anyone to create new annotated editions. b/ -- Brad Collins <brad@chenla.org>, Bangkok, Thailand
I'd like to address a different issue raised by Brad's example. It may even be a typo of sorts or just a quick-and-dirty sample that's not representative -- but I've seen it elsewhere and think it should be covered in docs and perhaps verification suites.
CHAPTER I . CONSULTATION OF DEVILS, AND BIRTH OF MERLIN.
<div n="1" type="chapter"> <head type="title">The Romance of Merlin.</head> <head type="section title">CHAPTER I</head> <head type="sybtitle">CONSULTATION OF DEVILS, AND BIRTH OF MERLIN.</head>
Using the plain meaning of the terms (rather than any special TEI meaning), it's clear that "CONSULTATION..." is the chapter title. In this particular book, the chapter number appears on the previous line, as a roman numeral, preceeded by the word "CHAPTER" in all caps. That's worth recording so that we can reproduce the original, but I don't think the above is the best way to do it. I'm going to suggest some alternatives that seem more logical; perhaps TEI experts can "translate" these into valid TEI (or suggest extensions that are TEI-like). First, let's take a simpler case; a chapter that starts with just the bare title: CONSULTATION OF DEVILS, AND BIRTH OF MERLIN. I think the markup here can be very simple: <div n="1" type="chapter"> <head>CONSULTATION OF DEVILS, AND BIRTH OF MERLIN.</head> I don't think any TYPE attribute is required; that's clear from context. Now, let's add "CHAPTER I". It's sort of a label that precedes the actual chapter title (much like "Figure" or such for certain illustrations); that gives us: <div n="1" type="chapter"> <head type="label">CHAPTER I</head> <head>CONSULTATION OF DEVILS, AND BIRTH OF MERLIN.</head> NOTE: when automatically extracting chapter titles, it's important to get the first unadorned <head>, i.e. skip <head type="label">. And, AFAIK, no "index" tag is required. Since the original example is the first chapter, it has an additional (and common) complication: the book title appears first. Well, that description suggests: <div n="1" type="chapter"> <head type="book">The Romance of Merlin.</head> <head type="label">CHAPTER I</head> <head>CONSULTATION OF DEVILS, AND BIRTH OF MERLIN.</head> Thoughts? -- Cheers, Scott S. Lawton http://Classicosm.com/ - classic books http://ProductArchitect.com/ - consulting
Scott Lawton wrote:
Since the original example is the first chapter, it has an additional (and common) complication: the book title appears first. Well, that description suggests:
<div n="1" type="chapter"> <head type="book">The Romance of Merlin.</head> <head type="label">CHAPTER I</head> <head>CONSULTATION OF DEVILS, AND BIRTH OF MERLIN.</head>
Thoughts?
The book title is at a different level from a chapter title so it gets its own div. If you find multiple chapter titles, you decide which is the main one and which are subtitles. <div type="book"> <head>The Romance of Merlin</head> <div type="chapter"> <head type="sub">Chapter I</head> <index index="toc" /> <head>Consultations of Devils, and Birth of Merlin</head> In PGTEI the <index level1> attribute defaults to the contents of the next <head> element. This will give you "Consultatons ..." in the TOC instead of "Chapter I". If you want it different just use <index index="toc" level1="Chapter I, Birth of Merlin" /> or something like this. -- Marcello Perathoner webmaster@gutenberg.org
Marcello Perathoner <marcello@perathoner.de> writes:
The book title is at a different level from a chapter title so it gets its own div. If you find multiple chapter titles, you decide which is the main one and which are subtitles.
In the case of this specific example, the title of the book is included on the first page of the first chapter.... which I wasn't quite sure how to markup. There is no need to include it in an electronic edition. The title page in it's own div is the correct way to go. The markup for the head elements was off the top of my head, I'm glad someone caught that and pointed it out. Cheers, b/ -- Brad Collins <brad@chenla.org>, Bangkok, Thailand
<div n="1" type="chapter"> <head type="book">The Romance of Merlin.</head> <head type="label">CHAPTER I</head> <head>CONSULTATION OF DEVILS, AND BIRTH OF MERLIN.</head>
Thoughts?
The book title is at a different level from a chapter title so it gets its own div. If you find multiple chapter titles, you decide which is the main one and which are subtitles.
<div type="book"> <head>The Romance of Merlin</head>
<div type="chapter"> <head type="sub">Chapter I</head> <index index="toc" /> <head>Consultations of Devils, and Birth of Merlin</head>
I want to make sure that I understand how <div type=book> fits into the big picture. Is the following correct? <text> <front> ... table of contents, introduction ... </front> <body> <div type="book"> <head>The Romance of Merlin</head> <div type="chapter"> <head type="sub">Chapter I</head> ... or type="label" <head>Consultations of Devils, and Birth of Merlin</head> If so: 1. I agree that it's consistent, and may be the best TEI-centric solution 2. it introduces a level of hierarchy that some may find confusing Whether #2 is important depends in part on who will be doing the most markup: volunteers who have some HTML experience vs. volunteers who are already TEI savvy (or don't mind the additional complexity).
<head type="sub">Chapter I</head>
I much prefer type=label. "Chapter I" is not a subhead according to the plain meaning of the term. Also, unlike a true subhead, it may be something that some people want to strip out or translate or standardize. -- Cheers, Scott S. Lawton http://Classicosm.com/ - classic books http://ProductArchitect.com/ - consulting
ALl you need is this: <div id="ch1" type="chapter" n="1"> <head>CONSULTATION OF DEVILS, AND BIRTH OF MERLIN.</head> The "rendering agent" can then, if desired, use the type and n attributes to generate the additional "Chapter 1" heading. Steve Scott Lawton wrote:
I'd like to address a different issue raised by Brad's example. It may even be a typo of sorts or just a quick-and-dirty sample that's not representative -- but I've seen it elsewhere and think it should be covered in docs and perhaps verification suites.
CHAPTER I . CONSULTATION OF DEVILS, AND BIRTH OF MERLIN.
<div n="1" type="chapter"> <head type="title">The Romance of Merlin.</head> <head type="section title">CHAPTER I</head> <head type="sybtitle">CONSULTATION OF DEVILS, AND BIRTH OF MERLIN.</head>
Using the plain meaning of the terms (rather than any special TEI meaning), it's clear that "CONSULTATION..." is the chapter title. In this particular book, the chapter number appears on the previous line, as a roman numeral, preceeded by the word "CHAPTER" in all caps. That's worth recording so that we can reproduce the original, but I don't think the above is the best way to do it.
I'm going to suggest some alternatives that seem more logical; perhaps TEI experts can "translate" these into valid TEI (or suggest extensions that are TEI-like).
First, let's take a simpler case; a chapter that starts with just the bare title:
CONSULTATION OF DEVILS, AND BIRTH OF MERLIN.
I think the markup here can be very simple:
<div n="1" type="chapter"> <head>CONSULTATION OF DEVILS, AND BIRTH OF MERLIN.</head>
I don't think any TYPE attribute is required; that's clear from context.
Now, let's add "CHAPTER I". It's sort of a label that precedes the actual chapter title (much like "Figure" or such for certain illustrations); that gives us:
<div n="1" type="chapter"> <head type="label">CHAPTER I</head> <head>CONSULTATION OF DEVILS, AND BIRTH OF MERLIN.</head>
NOTE: when automatically extracting chapter titles, it's important to get the first unadorned <head>, i.e. skip <head type="label">. And, AFAIK, no "index" tag is required.
Since the original example is the first chapter, it has an additional (and common) complication: the book title appears first. Well, that description suggests:
<div n="1" type="chapter"> <head type="book">The Romance of Merlin.</head> <head type="label">CHAPTER I</head> <head>CONSULTATION OF DEVILS, AND BIRTH OF MERLIN.</head>
Thoughts?
-- Stephen Thomas, Senior Systems Analyst, Adelaide University Library ADELAIDE UNIVERSITY SA 5005 AUSTRALIA Tel: +61 8 8303 5190 Fax: +61 8 8303 4369 Email: stephen.thomas@adelaide.edu.au URL: http://staff.library.adelaide.edu.au/~sthomas/
Steve Thomas <stephen.thomas@adelaide.edu.au> writes:
ALl you need is this:
<div id="ch1" type="chapter" n="1"> <head>CONSULTATION OF DEVILS, AND BIRTH OF MERLIN.</head>
The "rendering agent" can then, if desired, use the type and n attributes to generate the additional "Chapter 1" heading.
Steve
This should work, at least on the vast majority of modern texts. And I agree that the purpose of marking up a text is to markup the content of the text, not duplicate the original layout or typography. PG is producing electronic editions, not electronic facimiles of an original. This is no problem in texts like A Christmas Carol where Chapters are called `staves', but what if the text uses an alternate spelling for the word chapter, or only uses numbers or spells out the number into words? For example. 1 i. Chapter One CHAPTER ONE chapter 1. Chap 1. CH I First Chapter The type attribute should generally use enumerated values so that processing software can understand that all of these different forms of the concept `chapter' are the same. We could normalize all headings, no matter what the original was, but I would prefer to keep the original. In rare cases it reflects authorial intent or is a stylistic element in the overall flow of the work. For A Christmas Carol I would rather use Scott's approach: <div id="ch1" type="chapter" n="1"> <head type="DivLabel">STAVE ONE.</head> <head>MARLEY’S GHOST.</head> Rather than: <div id="ch1" type="stave" n="1"> In this way processing software would understand that a stave is a chapter when it looks up a reference in another work which points to Chapter 1, page 4 in the Carol. I also think that the type of label should be stated clearly. There might be many kinds of labels in a complex document. ------ Ack! Before sending this I had a look through the TEI manual and found this example: <div1 type="book" n="Herod I"> <head>Libro Primo</head> Which is somewhere between Scott's idea and and Steve's. If you used this for the Carol it might look like this: <div id="ch1" type="chapter" n="Stave 1"> <head>MARLEY’S GHOST.</head> This preserves the type value as an enumerated value, but using the `n' value as a text string rather than an integer make's it more difficult for processing agents to understand the structure of the text. I would prefer that the `n' value be an integer and use the head/label approach. I believe that as a general rule attribute values should be used for items which help process a text, or clarify the meaning of a text, rather than for any part of the text which is displayed. The spec defines the datatype for `n' as CDATA. So `Stave 1' is a legal value, but I would seriously consider making the value more restrictive. All in all I think I still like Scott's approach but I'm still open to any better suggestions. BTW: This has been a fantastic discussion and has helped me clarify a lot of details in using TEI which I hadn't completely worked out before. This is very difficult stuff folks, and b/ -- Brad Collins <brad@chenla.org>, Bangkok, Thailand
Brad Collins wrote:
For A Christmas Carol I would rather use Scott's approach:
<div id="ch1" type="chapter" n="1"> <head type="DivLabel">STAVE ONE.</head> <head>MARLEY’S GHOST.</head>
Rather than:
<div id="ch1" type="stave" n="1">
You'll also have to consider XPath queries. In a couple of years we'll likely put all of the PG TEI files into a giant XML database. No more files. You'll retrieve a book with an XPath query like (simplyfied): /org/gutenberg/etext/12345 You'll get the book title(s) with /org/gutenberg/etext/12345//titleStmt/title and the title of the first chapter with /org/gutenberg/etext/12345//div[@type="chapter"][@n=1]/head Of course this will only work if the first chapter always has attribute type="chapter" and attribute n=1 and not n="I" or n="Chapter 1" or n="Chapter I" ... -- Marcello Perathoner webmaster@gutenberg.org
H. G. Wells texts very often use: Chapter the First Chapter the Second Chapter the Third etc. Andrew On Sat, 30 Oct 2004, Brad Collins wrote:
This is no problem in texts like A Christmas Carol where Chapters are called `staves', but what if the text uses an alternate spelling for the word chapter, or only uses numbers or spells out the number into words? For example.
1 i. Chapter One CHAPTER ONE chapter 1. Chap 1. CH I First Chapter
participants (7)
-
Andrew Sly -
Bowerbird＠aol.com -
Brad Collins -
Joshua Hutchinson -
Marcello Perathoner -
Scott Lawton -
Steve Thomas