October 2004 - gutvol-d - lists.pglaf.org

www.gutenberg.org
by Marcello Perathoner 25 Dec '05

25 Dec '05

As of my request ibiblio has changed our apache virtual host ServerName from gutenberg.net to www.gutenberg.org. What? Nothing changes in web site operation except one little particular (if you hit a non-existing url you get redirected to www.gutenberg.org instead of gutenberg.net) Why? The .org top-level domain is meant for non-profit organizations while the .net domain is meant for network infrastructure such as providers, backbones etc. We own both gutenberg.net and gutenberg.org, but using the latter one is just more standard-compliant. Although both urls www.gutenberg.net and www.gutenberg.org give exactly the same results, you should start using www.gutenberg.org in all publications, papers etc. -- Marcello Perathoner webmaster(a)gutenberg.org

3 2

re: Re: [gutvol-d] Re: barriers to XML posting
by Bowerbird＠aol.com 03 Jan '05

03 Jan '05

joshua said: > Honestly, I see an easy compromise here. oh-oh, something smells bad here... :+) > As long as a conformant TEXT file > and a conformant HTML file > show up with the XML file, > I say post all three. well then i'm sure glad you don't _have_ a say... > Granted, right now we don't have a method > for the WW'ers to verify the XML file is valid all these minor details, eh? > so if you want to put a disclaimer to that effect in the file ... fine. a disclaimer? that's your "compromise". yeah, right. for those on the outside, who wonder why this fuss is being made whether an .xml file can be "posted", it's because the x.m.l. people want the imprimatur of being "official". why is that so important? because that's how the x.m.l. ponzi game is being played these days. people are adopting x.m.l. not because they think it's the best route, but rather because they've been "convinced" that it is "inevitable". even though -- in too many situations -- it just plain doesn't work, this "inevitability" makes people shrug and say, "ok, give me some." after all, you don't want to miss out on the ground floor, do you? they will tell you time and time again how there are "so many tools" for dealing with x.m.l., how x.m.l. is gonna be able to do conversions for whatever format anyone wants, but they can't even demonstrate a simple ability to convert out a text file and an .html version now. and when you call them on that, they whine about how unreasonable you are being, and how unfair it is to expect "150% perfection". bull. it is _far_ more sensible -- especially in, as jim delicately put it, a "production environment rather than an experimental one" -- to make the process _work_ before you put it in play, the x.m.l. people don't want to be bothered with that "technicality" before the fact. that's something that someone will figure out "later". yeah, right. if x.m.l. gets the stamp of approval here, what's the motivation for x.m.l. experts to come make it work? after all, there's no money in it for them here. they're off being high-paid consultants, telling the next mark, "look, even project gutenberg is using x.m.l. now too." as marcello puts it: > At this point we need to set a signal that the TEI era has started. he's not interested in actually making t.e.i. _work_ in reality -- he tried, and got a grand total of two simple e-texts done -- he just wants to "set a signal" that the "era has started" here... -bowerbird

7 9

Re: [gutvol-d] jeroen's even-handed analysis
by Gutenberg9443＠aol.com 02 Nov '04

02 Nov '04

In a message dated 10/19/2004 12:16:07 AM Mountain Standard Time, Bowerbird(a)aol.com writes: Doing fully automatic convertion to good paged PDFs for > printing nice copies (and I mean good, as different from workable) > will probably always remain a dream This is A goal. It is not, and cannot be, THE goal. It would be great to have everything in printable PDF for people who want printable PDF. If you want to keep ten thousand books on your computer, printable PDF isn't worth the end product of bovine digestion. I loathe PDF. I'm sure I'm not the only person who uses Gutenberg who is in my situation: I'm going blind--slowly, fortunately, unlike a neighbor who went blind overnight--and I can't get PDF documents on my Rocket, which means that as my vision continues to deteriorate I'm going to have to read sitting in front of my computer if I want to read something that is not available in a format I can convert to text or HTML in order to convert it to Rocket. I agree with Michael. Post everything in TXT first AND THEN do anything else you want to do with it. I believe that is one of the goals of of the DP team, which has all the scanned pages on computer to work from. HTML, even the "Save As" kind of HTML, can maintain formatting if you tell it to; I know because I've done it often. A basic problem in this entire discussion is that there are a lot of people here who are program-happy, as opposed to computer-happy. I'm computer- happy, but like the vast majority of people who use Gutenberg, I'm really not interested in umpteen different programs. I just want a book I can read. As a scholar, I might at times need the specific coding which will tell me what used this punctuation mark or that whatever that doesn't come across on txt, but if I need that, I can obtain the book someway and reinsert the punctuation and formatting and whatever. The village schoolmaster in a third world village, who has two hours of electricity a day, one cellular phone for the entire village, and an obsolete laptop donated to him by a first world company with a connection from the phone to the laptop cobbled together by a gadget-minded Peace Corps volunteer or church or UN aid worker, doesn't give a squiddly about umlauts and grave accents. He just wants BOOKS that he can READ to his students during the two hours a day that the electricity is on. The cowboy who's going to be stuck all winter in a back-country cabin looking after a herd of cattle in a snowed-in high pasture, or the astronaut, or the submariner, or the scientists in a South Pole research station, or the kids going to bush- school on the radio in Australia or Alaska--these people don't need pretty pages. THEY NEED BOOKS. They need good books. That's all. If we go back to the very basics, this is the goal of Project Gutenberg. It is no mistake that the very first things Michael posted were the most important documents of freedom. An educated populace can be kept enslaved for only so long, and then the privy hits the fan. We are the world's free public library. We do not serve, nor do we even NEED to serve, the few people in elite professions who want, and need, to be able to account for every comma and every umlaut. People who are arguing their heads off about ten different ways to format are losing sight of the goal. It is hard to remember that your goal was draining the swamp if you are up to your a** in alligators. Stop creating alligators. If YOU--whoever YOU happens to be--want to create all kinds of pretty formats, do it. That's grand. But don't try to inflict your vision on all of PGLAF. The TXT versions MUST come first. Then people can be joyfully reading the new books, while other people create other formats for those nice new books. Now can we go back to draining the swamp? Notice I said "can," not "may." We Ph.D.s in English know our grammar. I MEANT "can." Anne

20 53

re: [gutvol-d] I'm sorry but I don't get it... (the reprise)
by Bowerbird＠aol.com 31 Oct '04

31 Oct '04

john said: > Please picture this scenario: > > I'm a volunteer who has scanned a public-domain book and > wants to make it available through the PG distribution mechanism > (free of charge, available until the Internet collapses under the weight of > spam and next-generation pornography, yadda, yadda, yadda). > > Today, if I can convert this book to plain text (according to > some stated formatting conventions), I may submit the book. > If I'm ambitious, I can create an HTML version, which presents > the same information, but allows "real" formatting rather than > _italic_ and *bold*. > > In the background, however, there is this Whole New World(tm) > of semantic tagging, which presumably will allow the book to > make snacks and provide entertainment during the reading process. > But, for me, as a volunteer, who spends a considerable amount of time > working on books, but enjoys actually finishing one and seeing it posted, > I can't get my arms around the benefits. > > Except for recognizing the acronyms, I am agnostic to > XML/ZML/TEI/ABC/EIEIO. > > Could someone please explain the benefit of semantic tagging > and why it won't horribly lengthen the amount of time required > to produce an eBook? > > Thank you. well? -bowerbird

4 4

Re: [gutvol-d] PGTEI and more
by Scott Lawton 31 Oct '04

31 Oct '04

>>langUsage: I suggest the standard should be to omit the content of >>the tag (e.g. "British", which is probably more useful as "British >>English" or "English (British)"). This information should be >>generated to ensure consistency. (They appear in the generated PGTEI >>and in alice.tei, but not in lmiss.tei.) > >You have to include only the languages you actually use in the text. What about the content of the tag? i.e. which is correct? <language id="en-gb"></language> # lmiss.tei <language id="en-gb">British</language> # alice.tei I think the first is much better. Given the second, it will be extra work to enforce a consistent word or phrase. >The converter includes some more because it is easier to delete than to add and if you declare too many it doesn't hurt. I agree that it's easier to delete; hence my suggestion to include a note. Actually, all languages except the main one should be able to be determined programmatically, right? Just extract and dedup lang= attributes. We certainly don't want to include languages that aren't used; no point in bothering with all this XML if we're just going to populate it with wrong data. >>Having separate index tags for TOC, PDF and PDB strikes me as >>unnecessary and prone to error. Shouldn't the TOC one suffice for >>all? > >Some formats have limitations. eg. PamlDoc bookmarks have a maximum of 16 characters. PDF bookmarks have to use iso-8859-1 chars. Moreover you don't always want the full <head> to appear in the contents. So, the PalmDoc and PDF headers can be generated to conform to those limitations. I don't see the benefit of including these extra tags for every chapter of every document in the PG collection! -- Cheers, Scott S. Lawton http://Classicosm.com/ - classic books http://ProductArchitect.com/ - consulting

2 1

Re: [gutvol-d] PGTEI and more
by Joshua Hutchinson 31 Oct '04

31 Oct '04

----- Original Message ----- From: Scott Lawton <scott_bulkmail(a)productarchitect.com> > > My feedback on PGTEI is too long for email, so I posted it here: > http://Classicosm.com/xml/feedbackonpgtei.html > > Feedback welcome!!! quote is used in an example but apparently isn't part of TEI Lite (it's not in link_outAppendix A). What's the story? It is part of the full TEI spec. Thanks for pointing it out. I meant to have it in my test.xml, but I forgot. The test.xml should have <quote rend="display"> for blockquotes (and will on the next update.) TEI-Lite is the starting point, but we will probably pull in other stuff from the full spec where we need it. ** q: in cases where the quotation marks don't balance, it may be difficult to automatically convert quotation marks to the appropriate q.../q form, and time consuming to manually proof. Accordingly, I suggest this step be left as optional. I actually agree here. I prefer using " instead of <q>. Can any of the experts explain why this is a "bad idea"? ** pgHeader looks like it's contains information that should be described in teiHeader (though I'm new to TEI so may be wrong). alice.tei and lmiss.tei both contain pgHeader; the generated PGTEI does not. Assuming I understand this part right ... The teiHeader contains all the information. pgHeader is the call out to the part that takes the info in teiHeader and formats into a standard display header when you convert to HTML or TEXT. Marcello is probably the guy to explain it more fully. ** Having separate index tags for TOC, PDF and PDB strikes me as unnecessary and prone to error. Shouldn't the TOC one suffice for all? In fact, the tag itself seems redundant. Shouldn't the head itself suffice? (If TEI requires it, that's another example of where I think TEI is too complex.) Well, the reason they are separate is for the occasion where you have a header, but you don't want that header to appear in the Tabel of Contents. HTML requires an anchor and <h1> markup both ... this is the TEI equivalent. As for the multiple index entries, I wondered about the need myself, but I haven't gotten around to asking Marcello about it (or digging through documentation to try to understand the need). ** alice.tei: reg="Carroll, Lewis" should use the complete "authority" form, which I believe is "Carroll, Lewis, 1832-1898". Note that unlike the PG website, there are no parens around the dates. Here's an illustration of paren usage: "Baum, L. Frank (Lyman Frank), 1856-1919". I'm hoping consistency in format will be achieved when we have 1) some examples in place and 2) a web form for generating the, admittedly confusing, teiHeader section. ** There appear to be two validation errors, e.g. in the link_outPGTEI documentation: Error (7/117): <SPAN> must not contain block level elements like <H1>. Error (379/1): The start tag for </P> can't be found. Marcello knows about these and they will be fixed. ** In the documentation, why is "Versprich mir, Heinrich" repeated in the output, the second time in white? This one confused me for a minute, too... Then I realized, it is the only way a HTML browser will be able to space over the right amount. In effect, Marcello is trying to make the text invisible. There may be a better way to hide the spacing text, but I haven't given it much thought yet. It works now, if not in an "elegant solution" manner. ** The lack of space between paragraphs goes against Web conventions. (It's fine as an option but a poor choice for the default.) Agreed. I promise it will be changed. ** Thanks again for your analysis! Josh

10 16

on the question of sidenotes, footnotes, and end-notes
by Bowerbird＠aol.com 30 Oct '04

30 Oct '04

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

7 10

Re: [gutvol-d] PGTEI and more
by D. Starner 30 Oct '04

30 Oct '04

Jon Noring writes: > Whether to preserve the "long-s" or not is more problematic, since > where do we draw the line? For example, if we have an old Russian > text, do we transliterate the character set to Latin? Of course we > don't. Yes, because that would be stupid and useless. The real question is if we have an old Russian text, do we convert the fitas and other letters that are strictly redundant and hence abandoned in modern Russian to their modern Russian equivalent? Most English editions convert the long-s, and I believe most Russian editions convert the old letters to the modern equivalents. Or how about the o with e above that was the written form of o-umlaut? Do we preserve that or convert it to the modern form? There's one book in DP that preserves it in the Unicode edition because umlauts were used in a brief section, but I don't know that it was more important than a change to Fraktur or bold. Again, modern German that was original printed with an o-e above is converted to umlauts when reprinted; the e above was encoded for people who wanted to use it with middle German to contrast with modern German. > Isn't the use of a "long-s" part of a variant character used at > the time of publication? It is easy to auto-convert the Unicode > equivalent of the 'long-s' character to an ordinary 's' (as it is for > the German ess-tsett), but going the other way is much more difficult. It depends. In English, most of the long-s usage is trivial to convert; if it's not at the end of a word, it's a long-s. Sometimes a long-s s combination is seen for ss, but that's consistent within one work generally. In German, it takes a dictionary lookup and there's one or two minor examples, comparable to the ones about Polish and polish in English, where it can't be automatically converted. But one question should be our readers. There's a lot of well-educated people who aren't familiar with the long-s; are we doing more good in keeping what's more a detail of the typography than the spelling at the cost of some of our readers? The vast majority of the editions I've seen that reprint pre-1800 English works or German works orginally printed in Fraktur in modern fonts do not use the long-s, even when preserving original spelling. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

PGTEI notes webpage
by Joshua Hutchinson 30 Oct '04

30 Oct '04

I have almost no notes on the page, but I do have a link to the current test.xml I'm using and the resulting html and text from the online conversion. If you're at all interested in on-going progress, you can see if here. http://home.alltel.net/hutch2000/test.html Josh

4 5

Re: [gutvol-d] on the question of sidenotes, footnotes, and end-notes
by Joshua Hutchinson 30 Oct '04

30 Oct '04

That does work, but why note use the already existing <note place="margin"> markup? Then, you don't have to do the extra work of segmenting your paragraph for the same result. For an HTML edition, it already works in our transform. The text version we just have to decide HOW to handle it, then code up the transform. My version of your example: <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><note place="margin">Anger of the Devil against our Lord.</note> 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; <note place="margin">Assembly of the fiends and their discussion.</note> 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. <note place="margin">The prophets said that God should come on earth to save sinners.</note> 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> Josh ----- Original Message ----- From: Brad Collins <brad(a)chenla.org> To: Project Gutenberg Volunteer Discussion <gutvol-d(a)lists.pglaf.org> Subject: Re: [gutvol-d] on the question of sidenotes, footnotes, and end-notes Date: Thu, 28 Oct 2004 20:57:42 +0700 > > > > 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(a)chenla.org>, Bangkok, Thailand > _______________________________________________ > gutvol-d mailing list > gutvol-d(a)lists.pglaf.org > http://lists.pglaf.org/listinfo.cgi/gutvol-d >

4 3