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

re: Re: [gutvol-d] on the question of sidenotes, footnotes, and end-notes
by Bowerbird＠aol.com 29 Oct '04

29 Oct '04

joshua said: > Most of the recent HTML texts from DP use that sort of thing. nope. you didn't read my post carefully. show me the .html e-books from d.p. where the reader can see the body of the text _and_ the note _simultaneously_... > Caught that, did you, genius? yep. just making sure everyone else did too. there's this myth going around -- and you're the biggest proponent of it -- that _i_ am the rude one around here... > If the only thing that does what you want > is a program that doesn't exist, > how is that serving the readers? another falsehood you are working hard to propagate... the newest beta of my program will go up this evening. and i expect that it'll come out of beta very soon now... -bowerbird

1 0

re: Re: [gutvol-d] on the question of sidenotes, footnotes, and end-notes
by Bowerbird＠aol.com 29 Oct '04

29 Oct '04

joshua said: > Yes, genius, we have that ability, too, in the HTML. do you now? then why don't i see more .html versions prepared this way? read what i wrote, carefully, and then show me some e-texts that have an .html version that can match those capabilities... and what's with the "genius" comment? are you being snide? > We were talking about the plain text version > which is reader program agnostic. my viewer-program takes plain-text files. you can be as "agnostic" as you care to be, but if you don't serve the readers, who are you serving? -bowerbird

2 1

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

29 Oct '04

----- Original Message ----- From: bkeir(a)pgdp.net > > > 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"? > > > Presumably <q> </q> is meant to top and tail a quotation, making it > possible to extract quotations from within a work if desired. > > However I'd be worried about going to <q> because of the possible > ambiguities in quotations of multiple paragraphs, and the dangers of these > being retransformed to " incorrectly for the text versions. > > > > "We often find at DP that people brought up on reading only contemporary > works, which rarely quote several paragraphs at a time, incorrectly expect > that each paragraph of a quotation needs a closing quote mark. > > "People who have read a lot of 19th century books are well aware that > correct usage is that while each paragraph in a quoted passage starts with > a quotation mark, only the final paragraph in a quoted passage gets a > closing one. > > "Like this." > There *is* a way to tell TEI to not print a closing quote, but it is rather cumbersome. I think <q></q> markup is acceptable if used, but should be optional at best. Josh

1 0

Re: [gutvol-d] draft TEI conventions and larger example file
by Joshua Hutchinson 29 Oct '04

29 Oct '04

All of this is very good stuff. But I hope you don't mind if most of it is pushed back to the second iteration of PGTEI. My personal thoughts are to get a "standard" in place that handles what DP would normally label Easy through Normal difficult, in Latin-1 compatible texts. Then, once we have that in place, move on the stuff that gives DP fits on a regular basis, like fraktur, long-s, non-Latin-1 texts (granted DP-Europe handles most of those now). I definitely want to see the issues you bring up addressed. I'm just trying to set some realistic boundaries on what we can address on an incremental basis. Josh ----- Original Message ----- From: "D. Starner" <shalesller(a)writeme.com> To: "Project Gutenberg Volunteer Discussion" <gutvol-d(a)lists.pglaf.org> Subject: Re: [gutvol-d] draft TEI conventions and larger example file Date: Thu, 28 Oct 2004 15:06:39 -0800 > > I have a few comments on the draft guidelines. It'd be nice to have page > numbers printed on the pages. A letter size PDF would be useful, but the > margins on this one seem generous enough to print on letter-sized paper. > > DP probably will not be preserving the long-s, and I think it a little > unrealistic to expect most of PG's XML documents to preserve it. Also, > the description is incorrect; in English, it's used everywhere except > at the end of the word, and it was used until about 1800, making it > used in the 18th century. > > It's always used in Fraktur; are we going to preserve that? Counting > that, it was used until the middle of the 20th century. It's probably > too minor for this document, but several German documents I've seen > use a non-ligatured long-s/s combination for the eszett, while not > using the long-s elsewhere. Even at the most pedantic, it's arguable > whether this should be encoded with the long-s. > > There should be an option to preserve running headers where they encode > information not found elsewhere. > > I think we should go with standards on the languages section; that is, > RFC 3066 or its successor in draft. That is, #1, #2, #3, #8 with #5 found > in the draft. #4 and #7 can be encoded as en-x-1800 and en-x-Scottish > (how does this differ from sco?) in the draft, and I doubt anything would > choke on it today. #6 is a bad idea, especially as 3 letter 639 codes > sometimes overlap with SIL codes; if you need to encode Gaddang, phi-x-SIL-gad > or x-gaddang is a better idea. > > What happened to emph? All I see is rend. Likewise, I'd rather see foreign > do italics and let you mark it with rend="none" if needed, as that would > match how most books do it, and give a guideline to when to use foreign. > > I partially marked up Japanese Literature, and eventually decided not to > mark up all the non-italics Japanese words used in running English text, > like names of plants and such. I think a comment to mark up running > foreign text and italized foreign words, but avoid single words, like > the names of plants and foods, in running text if not italized. > -- > ___________________________________________________________ > Sign-up for Ads Free at Mail.com > http://promo.mail.com/adsfreejump.htm > > _______________________________________________ > gutvol-d mailing list > gutvol-d(a)lists.pglaf.org > http://lists.pglaf.org/listinfo.cgi/gutvol-d >

1 0

Re: [gutvol-d] draft TEI conventions and larger example file
by Jeroen.Hellingman＠kabelfoon.nl 29 Oct '04

29 Oct '04

Op 29-10-2004 01:06, schreef jij: Thanks for your comments. > I have a few comments on the draft guidelines. It'd be nice to have page > numbers printed on the pages. A letter size PDF would be useful, but the > margins on this one seem generous enough to print on letter-sized paper. I follow the ISO standard A4 size, which is an international standard, and offers several benefits to letter, which is only used in the US. I will keep margins generous though. > DP probably will not be preserving the long-s, and I think it a little > unrealistic to expect most of PG's XML documents to preserve it. Also, > the description is incorrect; in English, it's used everywhere except > at the end of the word, and it was used until about 1800, making it > used in the 18th century. Agreed. I will make this optional, and indeed, expect most people to drop it. I normally keep it. > It's always used in Fraktur; are we going to preserve that? Counting > that, it was used until the middle of the 20th century. It's probably > too minor for this document, but several German documents I've seen > use a non-ligatured long-s/s combination for the eszett, while not > using the long-s elsewhere. Even at the most pedantic, it's arguable > whether this should be encoded with the long-s. I would suggest, let the person who prepares the text decide. > There should be an option to preserve running headers where they encode > information not found elsewhere. I did this once, in an easy, but non TEI fashion, the formal method is to use <fw> tags. > I think we should go with standards on the languages section; that is, > RFC 3066 or its successor in draft. That is, #1, #2, #3, #8 with #5 found > in the draft. #4 and #7 can be encoded as en-x-1800 and en-x-Scottish > (how does this differ from sco?) in the draft, and I doubt anything would > choke on it today. #6 is a bad idea, especially as 3 letter 639 codes > sometimes overlap with SIL codes; if you need to encode Gaddang, phi-x-SIL-gad > or x-gaddang is a better idea. Isn't sco gaelic? I agree, and will adjust the guidelines (and the texts and tools I have) > What happened to emph? All I see is rend. Likewise, I'd rather see foreign > do italics and let you mark it with rend="none" if needed, as that would > match how most books do it, and give a guideline to when to use foreign. This is due to the way text are produced from printed sources, and it is often difficult to establish the reason a word is in italics. It could be because it is considered foreign, or for some other reason. I use foreign exclusively as a holder for the lang attribute. If you use the lang attribute consequently, you can use that to isolate fragments in a certain language. > I partially marked up Japanese Literature, and eventually decided not to > mark up all the non-italics Japanese words used in running English text, > like names of plants and such. I think a comment to mark up running > foreign text and italized foreign words, but avoid single words, like > the names of plants and foods, in running text if not italized. The decision to mark up words as foreign is sometimes difficult, and can impose a lot of work in such cases. I normally do this, as it helps much in spell checking. However, I would say, it is not required. Jeroen.

1 0

Working Group comments
by Jon Noring 29 Oct '04

29 Oct '04

Marcello wrote: >Jon Noring wrote: >> I would think and hope that DP will convene a formalized working group >> of the various experts and enthusiasts here and elsewhere to hammer >> out the DP Markup Specification based on requirements gathering and >> analysis, which is the proper way to do this. > I think design-by-committee is the wrong way to go about this. > Experimenting markup with more and more complicated books and refining > the specs along the way seems to me far more promising. Experimentation can be done *while* the working group is working on the specification, in an iterative process. It is important that experimentation itself is guided by the requirements established by the working group in looking at the bigger picture which can only be done by formalized collaboration between the members representing the various stakeholders interested in this. Of course, the most important player is DP, which has to implement the spec into their work flow, and they will certainly have their own laundry list of requirements. Anyway, you and others have already made a great head start on the experimental side, as well as establishing the first proposed "beta" specification, PGTEI. The working group will not need to start from scratch, but will be able to build upon the proverbial shoulders of giants. And to address the issue that the working group will likely not get it perfect the first time (it won't) -- in an informal chat I had with Charles a while back, one strategy he brought up is to come up with a "version 1.0" of the DP Markup spec, and implement that in the DP workflow. Then, as production rolls along, continue to update the spec as necessary to handle problem texts. The issue of compatibility (forward/backward) between versions of DP Markup spec will need to be addressed, and may be solved by keeping version 1.0 simpler (a smaller number of tags) and then add tags as needed over time. We don't want to remove tags as time goes on (since we may have finished texts using the deprecated/removed tags), but rather add support over time as needed. > But that's the Cathedral vs. the Bazaar discussion again. Yep. > To see a particularly disgusting example of design by committee just > look at XSLT. And to see another particularly disgusting example of design by committee, look at SGML and XML. And the worst of them all: TEI. Nothing good ever comes out of committees / formalized working groups. <smile/> >> The DPMWG will have a >> more formalized and committed leadership structure, with weekly >> teleconference calls. From my standards working group experience, it's >> amazing how much stuff gets done during weekly teleconferences and the >> occasional face-to-face meeting (biannual or annual), while written >> listserv exchanges in a group like gutvol-* usually ends up going >> around and around in circles. > Teleconferencing will essentially shut out all non-us based people > via the prohibitive costs or via the language barrier. Non native > English speakers like me may have a better standing in a written > discussion channel. This is of course an issue. There are now very inexpensive and free ways to hold a teleconference via VoIP or similar. In addition, all teleconference meetings, typically 1.0 to 1.5 hours in length, will be scribed and written Minutes produced. In-between teleconferences we can discuss details on a group forum. It is possible to hold the teleconferences at a time which is convenient for those in North/South America and those in Europe -- it gets tougher to find a good time when there are those in Australia/East Asia to include along with Europe/Americas, but this can be worked out somehow. >From firsthand experience it is amazing how more effective technical working groups are when they can at least meet by phone on a regular basis. It is a social and psychological thing which enhances working together and group creativity, which I've yet to see in text-only working relationships. At first I was skeptical (being a strong introvert myself who has always worked "online"), but came around as I observed the importance of human interaction by voice and in person for *technical working groups*. It's amazing, really. >> I would even ask someone like C. Michael Sperberg-McQueen to be an >> advisor to the working group > I don't know if the TEI people could advise us much. I think they will be very helpful -- I know a few others who are very knowledgeable about TEI in an XML-based publishing environment who can help establish requirements. A couple people I know are world-class at XSLT/XSL-FO (I think one of them served a while back on the original XSL working group at W3C.) A close business acquaintance presently serves on the CSS3 Working Group at W3C, and is working on high- quality presentation using XML+CSS in his business. Having varied views on the DP Markup vocabulary is important. > What we need is not advice about the use of TEI as markup language but > about the use of TEI as master format for automatic rendition into a > wide variety of output formats. There is the tei-presentation list for > this sort of thing but traffic there has been very light. Yes, definitely! But note that other groups will also be helpful by providing requirements, including end-user requirements. Having sharp tech people from the accessibility, the library/archive, the ebook publishing, and related communities, will contribute to the bigger picture by providing requirements that they see from their unique perspectives (e.g., metadata from the librarian types.) If we want DP-TNG (TNG: The Next Generation) texts to be good for a wide range of uses, then we have to have people representing the various user groups to have their say in the global design of DP Markup. And I need to re-emphasize the importance to the embracement and success of PG/DP by involving the various user groups with PG/DP, and the inclusive working group approach is one of several strategies to achieve this "buy in". > The only person who could really help is Sebastian Rahtz. Yes, definitely. I recall he and I chatted in private email a couple years ago (for what I don't remember). I'm not sure if he is subscribed to this forum. He is definitely very sharp and would make a great addition to the working group if he is able to participate in some capacity, even if only as an advisor. Jon Noring

1 0

Re: [gutvol-d] draft TEI conventions and larger example file
by D. Starner 28 Oct '04

28 Oct '04

I have a few comments on the draft guidelines. It'd be nice to have page numbers printed on the pages. A letter size PDF would be useful, but the margins on this one seem generous enough to print on letter-sized paper. DP probably will not be preserving the long-s, and I think it a little unrealistic to expect most of PG's XML documents to preserve it. Also, the description is incorrect; in English, it's used everywhere except at the end of the word, and it was used until about 1800, making it used in the 18th century. It's always used in Fraktur; are we going to preserve that? Counting that, it was used until the middle of the 20th century. It's probably too minor for this document, but several German documents I've seen use a non-ligatured long-s/s combination for the eszett, while not using the long-s elsewhere. Even at the most pedantic, it's arguable whether this should be encoded with the long-s. There should be an option to preserve running headers where they encode information not found elsewhere. I think we should go with standards on the languages section; that is, RFC 3066 or its successor in draft. That is, #1, #2, #3, #8 with #5 found in the draft. #4 and #7 can be encoded as en-x-1800 and en-x-Scottish (how does this differ from sco?) in the draft, and I doubt anything would choke on it today. #6 is a bad idea, especially as 3 letter 639 codes sometimes overlap with SIL codes; if you need to encode Gaddang, phi-x-SIL-gad or x-gaddang is a better idea. What happened to emph? All I see is rend. Likewise, I'd rather see foreign do italics and let you mark it with rend="none" if needed, as that would match how most books do it, and give a guideline to when to use foreign. I partially marked up Japanese Literature, and eventually decided not to mark up all the non-italics Japanese words used in running English text, like names of plants and such. I think a comment to mark up running foreign text and italized foreign words, but avoid single words, like the names of plants and foods, in running text if not italized. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

Re: [gutvol-d] on the question of sidenotes, footnotes, and end-notes
by D. Starner 28 Oct '04

28 Oct '04

"Joshua Hutchinson" writes: > (I think if I had a scan of the original, I'd probably more > fully understand what you were trying to do.) Take a look at any of the EETS works by PM EETS (that is, all of them except the book titled Early Middle English). They've got good examples of where you'd want to attach a note to a strech of text. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

re: Re: [gutvol-d] Final PGTEI... page numbers
by Bowerbird＠aol.com 28 Oct '04

28 Oct '04

brad said: > Detractors of XML on this list have brought up > the fact that the TEI manual is 1400 pages long > as a negative. Why? actually, it was jeroen who initially mentioned that fact. but since you asked, the reason this is seen as a "negative" is because we think that precious few of the volunteers who have traditionally shouldered the effort of creating e-texts will continue to do so if an understanding of those 1400 pages of t.e.i. documentation were to become a prerequisite. but maybe now distributed proofreaders has enough people on-board that they feel less uncomfortable taking that risk... or maybe not, as their tentative plan thus far involves adding two "markup" rounds (at least, and maybe more) to their existing two "proofing" rounds, so as to minimize the number of people who need to be concerned with markup. > This shows that TEI is well documented. um, well, yes, i guess it does. although _more_ documentation is not _always_ a good sign of _better_ documentation, is it? > As a general rule, the more documentation that is available > for a spec the more mature and useful the standard > and the easier it is to learn and implement. i'm not quite so sure i agree with that "general rule", brad... i think it would be just as possible -- and more compelling -- to formulate a "general rule" that the more documentation that a spec needs, the more complex it is, which means that it is _harder_ to "learn and implement"... i'm not afraid of documentation. indeed, quite to the contrary, i'm one of those rare people who often prefers reading it _first_, because if you can stomach it, it'll save you lots of fiddling time. and i'm a word geek too. so i find the massive t.e.i. documentation -- and indeed the whole framework itself -- to be a remarkable and fascinating piece of work. it is mind-boggling to witness how _complex_ and _variegated_ a comprehensive examination of text can become, once you pour a foundation and start building a building. on the other hand, i can equally admire a system that boils things down to their essence, and creates great benefits with few costs. if all the volunteers contributing their efforts to project gutenberg were word geeks as willing to throw themselves into a devotion of documentation, like you and me, brad, it might not matter whether we went with the complex system or one that is a lot more easy. but given that they probably aren't, we should think very carefully before committing them to a world with a high degree of difficulty. as you put it, the learning of a complex system like t.e.i. is often "a gradual process of incremental epiphanies". can we _survive_ the situation where thousands of volunteers are put through that? with perhaps many becoming alienated in the course of doing so? unless i miss my guess, just the last few days of "how do we do this?" posts on this listserve have tried the patience of most subscribers... (which leads me to suggest that perhaps there is another listserve that is more appropriate for that, where the markup geeks can go?) -bowerbird

3 2

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

28 Oct '04

----- Original Message ----- From: Brad Collins <brad(a)chenla.org> <snipped explanation of using <seg> vs using <note> > OK, the gist I got was that you want to be able to tie the information from the margins to specific sections (a beginning and ending point) rather than tie to a single spot and assume it applies to some indeterminate length ahead. I can see where <seg> allows that. Is that much fidelity in the original? For instance, the <seg> marks you applied ... is there something in the original that says this segment stops *right here*? I ask because while the beginning of the <seg> seems clear, in the text I'm picturing in my head, the end of the segment would be kinda of fuzzy. (Unless the text used a marker or line break or something at the same spot you are using <seg> breaks.) If it is fuzzy, it seems the <note place="margin"> markup provides the same "here forward to some point" fidelity in information. (I think if I had a scan of the original, I'd probably more fully understand what you were trying to do.) Josh

1 0