- gutvol-d - lists.pglaf.org

Re: Processing eTexts
by Bowerbird＠aol.com 26 Feb '10

26 Feb '10

carel said: > Direct comparison to the scans is part of > the formal proofing process and, > although available during the 'quest for perfection,' > should not be a forced issue. i disagree. it's largely a matter of "framing" the issue and its perception. i don't think we should ask the user to help with "proofing" per se. i don't want them to think of this as "the formal proofing process". i believe we need to put the books in front of them _to_read_... _that_ should be our understanding with them, how we "frame" it. they're there because _they_ want to _read_ this particular book. now, as part of the interface by which we present the book to them, we give them both the digital text _and_ the page-scan, together... most interfaces make the user _choose_ one of the other, but i see no reason (especially no _benefit_) in doing it that way... i think it's wise to give them _both_, and have them understand that there may have been some transcription errors during digitization, so we're giving them the page-scan too, for any cases they _suspect_ might be errors. in most cases, they'll see that we matched the scan. or they'll understand why we made the change that we did, if we did. _or_ -- in some rare cases, in which we request their assistance -- they'll find an actual transcription error that we made, and _tell_ us. this is the thing that project gutenberg doesn't do well. it doesn't _invite_ the reader to become a part of the transcription process, to become one of the instruments that marches texts to perfection. indeed, you can _feel_ deep in your gut the _contempt_and_scorn_ that jim tinsley and al haines have for the stupid people who _do_ report errors, because _half_ of those "errors" are not, in fact, errors. well, gee, big surprise. you haven't given them the page-scans, so how in the world are they gonna know if an apparent error _is_ real? > I think calling it a wiki makes it easier for quick comprehension > rather than explaining the whole process of storage, editing, etc. we should never _have_to_ "explain the whole process" to the public. for them, it should be as easy as clicking a button to say "check this!" they shouldn't even need to explain the error. (we can find it, right?) > Rather than working an editing interface > into an out-of-the-box wiki system we don't need to make "an editing interface"... > Has anyone ever just asked google if they could > use the scans and OCR text for PG? michael had a meeting with google when they were just starting out... he reported that they treated him rather rudely, hustling them out of their famous cafeteria before he had even finished his lunch. it's sad, but i don't think they really appreciate project gutenberg very much... > XML makes a nice standard for storage and conversion it's obtuse, and unnecessary obstructive to the text itself... > My only protest is that I believe > a human proofing stage is still a good choice. if you mean a word-by-word reading of the page by a person who has no real interest in reading the entire book, i disagree. a comparison of different digitizations is a much better process, in terms of finding errors, and it takes less work, and is more fun. i can't think of one single reason for a word-by-word proofing, let alone two or three rounds of it. it's simply not efficient, and anybody who explores the options can learn that for themselves. between aggressive clean-up of o.c.r., and the comparison method, and "smoothreading" by people from the general public, we're good. > Otherwise, I would say to have two people > run the same correction process, diff the results and > then present the mis-matches to a third set of eyes. close... but it's unnecessary for "people" to do the digitizations. two sets of cleaned-up o.c.r., diffed against each other, is enough... (but yes, it's necessary to have a sentient human doing the clean-up.) > the existance of a proofing round > creates a sense of belonging to the project and > could assist in recruiting people to try the 'harder' process of > running the 'automation' scripts and submitting books word-by-word proofing is a slow, boring, humdrum task. o.c.r. clean-up is a fast-paced, active, and energetic task. which does _not_ mean that it's "harder". just more fun... doing the former task won't help you at all with the latter. (except perhaps make you _extremely_ grateful that you don't have to do such a boring, miserable job ever again.) > People need a sense that they are not just > assisting tools to create book editions, > but are a fundamental part of the process. is the hammer more important than the carpenter? i doubt it, whether you ask the hammer _or_ the carpenter... i get the impression you think these clean-up tools are just a bunch of scripts that people turn on, and the results fall out. but that's not anything like what actually goes on. > I'm not sure I'm ready to program an AI engine > capable of "listening to the book." the software can't listen to the book. _you_ have to do that. > Which is why I do not believe in leaving people out of the process again, you have a profound misunderstanding of the process. the hammer can't do a thing without the active involvement of the carpenter. even then, the carpenter has to know what s/he is doing, or the hammer won't be able to do one bit of good... the best thing you can do, carel, is to play around with twister... -bowerbird

1 0

Processing eTexts (was RE: Re: d.p.'s undeserved superior attitude about "quality")
by cmiske＠ashzfall.com 26 Feb '10

26 Feb '10

Bowerbird said: >carel said: >> I've read your posts for many years > >so _you're_ the one who's been reading them! ;+) I'm sure many people read them. :) >> I'm not sure the most efficient system on earth >> could keep up with the scan rate. > >sure we can. just have 10 million people do 1 book each. > >piece'a'cake. It sounds easy when you put it that way.... ;) >> And, if you speed things up by skipping the manual proofing >> and use automation completely for the first release then you >> will have text little to no better than what google already has. > >oh, don't kid yourself. google's text is _much_ better than >what they're showing to us members of the general public. Their OCR software requires training, so I agree with you that they always have an at least one step better version on the backburner. They probably have a stepped up version of everything we see.... >i haven't been impressed by the wiki approach, honestly... The standard wiki layout is not a proper environment for editing. Better would be something that allows the vast majority of readers to just read the page and click a button to be presented with an interface for making/submitting corrections if such is required. Direct comparison to the scans is part of the formal proofing process and, although available during the 'quest for perfection,' should not be a forced issue. I think calling it a wiki makes it easier for quick comprehension rather than explaining the whole process of storage, editing, etc. Rather than working an editing interface into an out-of-the-box wiki system, it would be better to write a proprietary system with some of the social networking features of a wiki. That part would take a very firm second place to just getting some tools out there for people to produce decent quality texts in a minimal amount of time. Because of that fact, I haven't really given much thought to the 'wiki' interface as it will evolve by itself from wants/needs. [snip] in re: google: >people on this listserve have been cut off for scraping... >you can still do it, of course, but you have to be careful. Has anyone ever just asked google if they could use the scans and OCR text for PG? In regards to the scans, I believe they just require you to leave the branding. >i would bother to nitpick certain parts of it, like the x.m.l., >but really, my objection is at the more fundamental level. XML makes a nice standard for storage and conversion and can be human readable. I'm not one of those people who believes that XML is the answer to everything, but I do think it works well for this use-case scenerio. Opinions on this will vary, etc. >yes, i believe every page of every book should be online, >on its own webpage with unchanging u.r.l., text and scan, >with an error-report form that the general public can use >to detail any problems with the page, or ask questions, or >even make annotations and have dialog about that page... Agreed. >but i also believe that the text for the vast majority of these >pages should be _perfect_ at the time that text is mounted. We are in agreement on this point as well. The majority of the work towards corrections should be done via automation and human interaction with a software process so as to reduce the error level to a minimm before it is put in the hands of a proofreader (or the general public). >and i've demonstrated, repeatedly, that this is fully possible. It is very possible. [snip] >so here's how i see things going... >when you find a scanset online of a book you want to digitize, >you'll download it, along with the o.c.r. (if it comes from a site >that won't give you the o.c.r., you can upload it to archive.org, >and they'll o.c.r. it for you. providing you have no o.c.r. app.) >you'll use a handy-dandy tool to digitize it in an hour or two, >and then you'll make the results available to everyone online. My only protest is that I believe a human proofing stage is still a good choice. For one thing, it would be a way of catching errors that could be induced by the human assisted automation process. Otherwise, I would say to have two people run the same correction process, diff the results and then present the mis-matches to a third set of eyes. If that doesn't result in a book that is ready for release, I'm not sure what would. Ready for release != perfect. :) On a point in favor of the proofing round that really has nothing to do with the potential for automation, the existance of a proofing round creates a sense of belonging to the project and could assist in recruiting people to try the 'harder' process of running the 'automation' scripts and submitting books, etc. People need a sense that they are not just assisting tools to create book editions, but are a fundamental part of the process. If you try to proof after a release has been done, there will be little interests in it because you lose the motivation to 'get the book out there." >and carel, since you're interested in programming such tools, >we'll have plenty to talk about... Yes. :) It's very much a 'will do' at this point. I just have to survive my mid-terms. I look forward to your feedback and your input on the project. >well, like i told gardner just the other day, i really don't >_have_ any collection of scripts. i use a text-editor and >start looking at the book. i see an error, and devise a >global search-and-replace to deal with that type of error. >when they're all fixed, i look again to find the next error. That brings up the point that pretty much all of what my scripts would be doing could be done in word processing software.... >i think of this process as "listening to the book", in that >the book itself will tell you what kinds of errors it has... I like that. I'm not sure I'm ready to program an AI engine capable of "listening to the book." Which is why I do not believe in leaving people out of the process, but rather giving them tools to assist them with the process. And, the tools can 'learn' from the people who use them. I'll be busy finishing up a group project for my classes, so it'll be late March before I get any real time to work on scripts for this project. I'll work on some of the research, logic, and flow in the meantime so that I am ready to roll when I do have the time. Back to my programming.... Carel

1 0

roundlessness -- 008
by Bowerbird＠aol.com 26 Feb '10

26 Feb '10

by the way, i've coded an offline program that hooks into rfrank's system. if anyone would be interested in using such a beast, take it up with roger. or, if you just want to use it to scrape the books on his site, talk to me... -bowerbird

1 0

roundlessness -- 007
by Bowerbird＠aol.com 26 Feb '10

26 Feb '10

ok now, remember how i said that preprocessing is a _simple_ thing, typically with no need for a large set of checks that need to be done? on the current chunk of text i'm analyzing from rfrank's experiment, it looks like a dozen simple checks would've found 75% of the errors, right off the bat, with no need for a word-by-word proofing round... save the time and energy and _focus_ of your proofers: preprocess. -bowerbird

1 0

Re: the d.p. opinion on "prerelease" of e-texts
by Bowerbird＠aol.com 26 Feb '10

26 Feb '10

donovan said: > I stand by my characterization of PG's pre-press scheme as > both unnecessary and a disturbing shift in attitude towards DP. i don't have a dog in this fight. but i'm glad it's all "amiable" and such. -bowerbird

1 0

Our 400th Portuguese eBook
by Michael S. Hart 26 Feb '10

26 Feb '10

We are up to #398 and I have not received any suggestions for #400. Should we reserve one? Just go with whatever comes along? Other suggestions? Thanks!!! Michael

2 1

Re: the d.p. opinion on "prerelease" of e-texts
by Bowerbird＠aol.com 26 Feb '10

26 Feb '10

david (donovan) said: > All that's required is to convince the 'right' people at DP to either > A) expend limited resources towards that end > _instead_of_ where they're needed, or, > B) stand aside and allow PG to take unreasonable advantage of > what have _so_far_ been amiable terms of relationship. emphasis added... here's an obvious ploy to push things to the ultimatum stage... behold the biggest bottleneck at distributed proofreaders: donovan. -bowerbird

2 1

Re: the d.p. opinion on "prerelease" of e-texts
by Bowerbird＠aol.com 26 Feb '10

26 Feb '10

michael said: > I just figured they would perfect themselves in growing up, how? by _magic_? > I just figured they would perfect themselves in growing up, > through the natural process of our reader sending errors. but you do nothing to encourage the process of reporting errors. and it often takes _years_ for reported errors to be corrected... (and i have _never_ seen a person credited for error-reporting.) > Now we want to pretend there ARE no errors, even to points > where our bigmouth says "perfect" in referring to this. well, my big mouth _often_ says "perfect", because that is what i am aiming at, and working toward, and _attaining_, in some measure, by using methods that find and fix errors. where is the equivalent push by project gutenberg? the whitewashers announce "corrected editions" which they _know_ (or _should_ know) are woefully lacking in accuracy, because all they did was apply the corrections readers sent, instead of aggressively using known methods to find errors. nor are the whitewashers (and p.g. more generally) the sole problem in this equation... the d.p. people _love_ to go on and on about their "quality", but they have shown _absolutely_no_ interest in going back and fixing their own early crappy books. and let's not even talk about going back and fixing the early crappy p.g. books. so the d.p. people are full of horse shit on "quality" as well. > This pretense is causing us HUGE problems and denying > book access to thousands of titles we could release as "0.x." i haven't taken a stand on this issue because, as i already said, i _want_ d.p. to choke on their backlog. as a big reminder that something is very, very much wrong in their current workflow. plus there is some merit to the argument that most of these books are already available to the public in one form or other. but i wouldn't be opposed to releasing the _semi-improved_ versions that've come out of the various rounds over at d.p. (although i think some of us are kidding ourselves greatly about exactly how much that text has been "improved", i.e., very little. the typos have been removed, yes. but i could do the same job, for the most part, with a simple spellcheck, so that's no big deal.) and i think it would be great if these in-progress works were being released so people "on the outside" could improve them, but i doubt p.g. or d.p. could build the proper infrastructure for the general public to _do_ that, so i think that's nonsense. i believe everyone has good motivations in this situation. (well, except donovan, and you better watch out for him.) unfortunately, good motivations can't prevent an implosion. > I would like to see PG & DP be a little less proprietary, > a little less about who gets how much credit and a little > more about getting the books out there ASAP and then work > them up to a never ending Xeno's progress to perfection. couldn't avoid using the "p" word yourself, could you, michael? ;+) -bowerbird

1 0

Re: opinions on pre-release
by Greg M. Johnson 26 Feb '10

26 Feb '10

> Are we more worried about who > gets credit or getting books out? I don't mind seeing "produced by" in the intro to a book, but it is a bit odd to see people getting editor and author citations in the PG database. o__O The workers at Googlebooks afaics have made completely anonymous contributions-- their names aren't in the epubs. But I think we are all at a loss for not knowing the name of that lady whose lovely hand is preserved forever in so many photocopiess in their collection.

2 1

roundlessness -- 006
by Bowerbird＠aol.com 26 Feb '10

26 Feb '10

in looking at some of the text from rfrank's "roundless" experiment, there's a chunk of a book which contained 192 lines that got changed. a closer analysis showed _80_ of those lines (over 40% of the total) were unchanged except that a spacey-quotemark had been fixed... however, since the repair of spacey-quotemarks can be _automated_, that means all of those 80 lines could have been corrected in advance. if you really want roundless to work, you have to do it correctly... -bowerbird

1 0