- gutvol-d - lists.pglaf.org

Works vs Expressions
by Jon Hurst 30 Nov '12

30 Nov '12

The distinction between works and expressions would seem to be at the heart of the difficulties in resurfacing reworks. As soon as you are able to group all expression numbers under a single work number, you can let transparency handle the rest. As far as I am aware there is currently only the most tenuous process available for linking expression numbers under a given work number. If any progress is to be made, the first step must be remedying this. The difficulty is that accurately and comprehensively assigning work numbers to expression numbers is non-trivial. What I would suggest then is this. Add a work number field to the PG database and default it to the expression number. Define the "correct" work number to be the lowest expression number of all the expressions that relate to that work. Then use some form of collaborative editing system (wiki page, google docs, web app, whatever...) to allow reporting of errors in the format: 41445=84 This wouldn't be comprehensive, of course, but it would allow capture of those works that people care about enough to report. Only a first small step of course, but that is how journeys begin. Regards Jon

1 0

{Disarmed} Re: Frankenstein
by Robert Cicconetti 29 Nov '12

29 Nov '12

Mine were getting held up for days to weeks for a while, but then started working. Something to do with the moderation. -Bob On Wed, Nov 28, 2012 at 1:46 PM, Greg Weeks <greg(a)durendal.org> wrote: > > I don't think any of my posts are getting to gutvol-d any more. > > The version for this is The Annotated Frankenstein which used microfilm > scans, but didn't keep the pagination. I'd love to get the scans posted too. > > I also have a clean 1831 edition I'm working on. > > > > On Wed, 28 Nov 2012, Robert Cicconetti wrote: > > >> On Wed, Nov 28, 2012 at 12:20 PM, Greg Newby <gbnewby(a)pglaf.org> wrote: >> On Mon, Nov 26, 2012 at 05:22:33PM +0000, Jon Hurst wrote: >> > The other day I noticed that DP has recently uploaded a >> reworking of >> > Frankenstein (#41445), the 12th most downloaded "work" on PG. >> I am >> > assuming that it wasn't cross-checked against #84, so I've >> started the >> > process of doing this. >> > >> > I've done the quick and easy bit and now have the text >> rewrapped to >> > the images. I would like to get these files uploaded to >> #41445's >> > fileset - they are sitting at: >> > >> > https://github.com/JonHurst/**frankenstein<https://github.com/JonHurst/frankenstein> >> > >> > If you want to just get a zip file rather than use git use: >> > >> > https://github.com/JonHurst/**frankenstein/archive/master.**zip<https://github.com/JonHurst/frankenstein/archive/master.zip> >> > >> > I'm not sure what the protocol for doing this is, beyond it >> being >> > "supported and encouraged" to have the scans present in the >> fileset of >> > a given "expression" -- Greg, please let me know what you >> would like >> > to do. >> >> You're saying you have the page scans that were used to make >> #41445, but they were not provided as part of the original >> file upload? >> >> Usually, scans come from whoever submitted the rest of the book. >> >> The only trick is there is a naming convention for the filenames. >> Did you already do that (sorry, I did not look at the files >> mentioned above)? There is a page at www.pgdp.net (somewhere) >> that describes the naming convention. I have it somewhere, too. >> >> If so, just get in touch with the WWer who posted the files, to >> arrange delivery. If you don't know who this is, or none of this >> makes sense, email me directly or email pgww(a)lists.pglaf.org >> >> Thanks! >> >> >> The page images are from a "photo-reprint" of the 1818 Lacking, Hughes, et >> al. edition, which, judging by the scans, is code for >> microfiche/microfilm. >> They're at DP for now, and when archived will end up at OLS. >> http://www.pgdp.net/c/project.**php?id=projectID508470307d6dd<http://www.pgdp.net/c/project.php?id=projectID508470307d6dd> >> >> Weren't there discussions at some point on automated or semi-automated >> uploading of DP scansets to PG? They all get archived, even the ones that >> aren't publicly displayed at OLS because of politeness/permission issues. >> >> -R C >> >> >> > -- > Greg Weeks > http://durendal.org:8080/greg/ >

2 1

Frankenstein
by Jon Hurst 29 Nov '12

29 Nov '12

The other day I noticed that DP has recently uploaded a reworking of Frankenstein (#41445), the 12th most downloaded "work" on PG. I am assuming that it wasn't cross-checked against #84, so I've started the process of doing this. I've done the quick and easy bit and now have the text rewrapped to the images. I would like to get these files uploaded to #41445's fileset - they are sitting at: https://github.com/JonHurst/frankenstein If you want to just get a zip file rather than use git use: https://github.com/JonHurst/frankenstein/archive/master.zip I'm not sure what the protocol for doing this is, beyond it being "supported and encouraged" to have the scans present in the fileset of a given "expression" -- Greg, please let me know what you would like to do. I've also taken the opportunity to knock up a very simplistic viewer interface to help errata reporters etc. This is at: http://www.hursts.eclipse.co.uk/viewer.html Make sure it has finished loading before you try to view a page image or you will end up opening the image in a new tab rather than next to the text. As I said, it's very simplistic. If there is some way that PG could host a more advanced version of this viewer it would certainly make checking errata a lot easier. I am intending to do the cross-checking with #84 at some point over the next month or so, so I'll send any errata once I'm done. I would also quite like to do a LaTeX version in order to produce A5 and Kindle sized PDFs with decent typography -- would PG be willing to host these? Regards Jon

6 16

washing a clean window with a dirty rag
by Bowerbird＠aol.com 29 Nov '12

29 Nov '12

jon said: > By cross-checking I mean > using #84 to polish #41445, > not the other way round; i'd love to see you document that work-process. because the image that springs to mind is that you're washing a clean window with a dirty rag. the clean window, of course, is the new d.p. text. it's just come out of 6-7 rounds of close analysis. i'm sure that it has errors in it, but not too many. #84, on the other hand, would be the dirty rag... and it's not that #84 is chock full of errors, either. the reason it's such a rotten e-text, though, is that its provenance is not just unknown, it is _murky_... (can't remember why, at this point, but there were _reasons_ noring/passey made it a stalking-horse.) a few quick looks indicate you'd be looking at about 2500 diffs, and i'd guess 2450 of them will be clean. the rest will be version-differences, or #84 errors... that's a lot of work to locate -- maybe -- 50 errors. or 25. or 10. (and to be honest, the number might be as low as 3; and by then, you are doing more edits for the cause of intra-book-consistency than "error-fixes" per se.) and i know it, for sure, since i just did it, on "huck"... the window/rag metaphor is not perfect, of course, since you _will_ end up with a little cleaner window. but the small benefit probably will not be worth the high cost that you will have to pay in order to get it. (if i could do it over on "huck", i would _not_ do it.) that's just my opinion, though, and even if i'm right, your time is _your_ time, to waste however you like, so i welcome you to take up the challenge and do it. and if you do, please document it, so we'll all learn... *** robert said: > The page images are from a "photo-reprint" > of the 1818 Lacking, Hughes, et al. edition, which, > judging by the scans, is code for microfiche/microfilm. oh geez, i wish i woulda known that before i put in _any_ work on these. do _not_ use reprints, folks! if one of the _original_ editions isn't scanned yet, the just wait until it happens, eventually, because these reprints will never serve as canonical copies. anywho, baby-que, here's a version i threw up: > http://zenmagiclove.com/frank/wisdom.py since the so-called "page-scans" aren't real scans, and the text has errors introduced by jon's process, i ain't gonna use any more time to make this better. for reference, wikipedia says that the 1818 edition had 280 pages, but we've got 311 scans somehow. of course, who knows if wikipedia is wrong or right? i am drowning in a sea of undependable data being pushed at me by people who don't care if it's wrong. so probably time to get out of this ridiculous racket. -bowerbird

1 0

bug off, you bug me
by Bowerbird＠aol.com 29 Nov '12

29 Nov '12

i'm not reading your posts, jim. so you've got free rein to slime me, dude, like you like to do. and, if anyone thinks you have made a good point -- or you're brave/stupid enough to take my bet -- they'll let me know about it, front-channel or back. so slime away, jimad... -bowerbird

1 0

bug off, you bug me
by Bowerbird＠aol.com 29 Nov '12

29 Nov '12

i have been told that jim has posted a message saying that he asked me to give him my "bug list" of errors in his "huck". perhaps he did ask for that. however, i do not read jim's posts any more, and nobody restated his request (at least that i saw), nor did anyone tell me back-channel when he made his request. *** at any rate, i don't have such a "bug list". moreover, it would be as simple for jim to generate that list as it would be for me to do it for him, so i will let him do it... *** what benefit do i get from making it simple for him to make _his_ version of "huck" as error-free as _my_ version is now? none, that i can see. it would just make my version superfluous at p.g., if i were to decide that i should submit it. so i see no motivation for me... *** jim thinks he can abuse me, and then ask me for a favor. ha! my version is online, free for the taking. jim can do it himself. > http://zenmagiclove.com/huckf/huckf-007.zml *** or, if any of _you_ wants to, _you_ could do the work for jim! download my text, and his text, and do the comparison, and test the diffs against his scan-set, and give him the "bug list". sounds like he would appreciate your help... (or maybe not.) *** i did inform jim that there were 22 paragraphing differences between his text and mine, and that roughly 75% were errors in _his_ version. he shoulda been able to find those easily... but he never reported back. so why should i do a follow-up? *** i also informed jim that he missed lots and lots of italics, and that is another set of errors he should be able to easily locate. but again, far as i've heard, he made no efforts in that regard. again, if he doesn't care, why should i? *** but, to repeat, just so the message gets through _clearly_, i do not have such a "bug list". never even generated one. i resolved my diffs, and didn't look back. didn't care about jim then. don't care about jim now. and i'm quite happy to know he don't care about me either. *** perhaps this means you believe i cannot correctly estimate the number of errors in jim's version. i can see your logic. so, what about you and i bet on my estimate vs. your logic? first, you can choose anyone reasonable as referee, who will hold the money from each of us, and rule on errors. (referee will, of course, promise to be totally impartial.) if there are _exactly_ 100 errors, it's a total _push_... if there are more than 100 errors, you owe me $200. or, if there are less than 100 errors, i owe you $200. plus you owe me $2 extra for every error _over_ 100, and i owe you $2 extra for every error _under_ 100... loser pays the referee 20% of the total pot as a gratuity... who wants to take the bet? step right up and take the bet! (if that's too rich for you, you can cut the amounts in half.) *** if jim does something worthwhile, i'll hear about it, and react. (heck, if you want to inform me, assuming you are not _also_ in my kill-filter, then i would be happy to receive your report; i want jim to receive every little bit of credit that he deserves.) but until then, jim, don't bother whining. won't do you any good. -bowerbird

2 1

welcome to the sausage-grinder machine
by Bowerbird＠aol.com 28 Nov '12

28 Nov '12

jon hurst said: > The other day I noticed that DP has recently > uploaded a reworking of Frankenstein (#41445), > the 12th most downloaded "work" on PG. > I am assuming that it wasn't cross-checked against #84, > so I've started the process of doing this. ok, well, you're gonna get schooled now, that's for sure... :+) "frankenstein" was a stalking-horse that jon noring and lee passey rode for a _very_ long time in their assault on p.g. some years back. basically, they destroyed any reputation that #84 might have had, and tried to extend the collateral damage as far as it'd possibly go. so i assume that post from lee that's sitting in my spam box now will have him crawling back up on that hobby-horse to spout off. the thing is, #84 was always a worst-case example, _very_ atypical. was it bad? heck yes. it was _awful_. just _dreadful_. and it _remains_ awful, to this very day. and _oft-downloaded._ (don't let the "updates" fool you, either. if you battle through a diff operation, you'll see the edits were relatively minor, akin to putting band-aids on a crashed motorcyclist with broken bones, simply because anyone can see the scratches, but not the bones.) so i guess the noring/passey gang lost the battle _and_ the war. because frankenstein #84 is alive, and well, and doing just fine... clearly, it takes more than 2 guys and a horse to kill frankenstein. and the new one is gonna plod along with relatively few downloads, because... well, because it has fewer downloads: p.g.'s vicious circle. and, for the reasons i posted, nothing about that will change. ever. welcome to the machine... the p.g. sausage-grinder machine. *** but there are other reasons a "comparison" would be bogus... mainly because even if you could point to a _difference_, or 1000, there's no way to _resolve_ the difference, because #84 is a mirage. there is no source to check against, at least as far as anyone knows. indeed, if you check the "old" versions, you'll find that the book was done in separate chunks, by different people. and they might have used entirely different editions. so, you know, have fun with _that_. but guess what? #41445 isn't much more clear about _its_ source! i mean, there's a print-date on a scan that we might _infer_ has come from the title-page of the work which served as the source, but i'd feel a whole lot more comfortable with an actual _link_ to a scan-set hosted at the internet archive or (if it's the case) google. even if you post the scans, and i do believe that's a great workflow, you still need to link to the external source from where you got 'em, so the end-user doesn't have to take your scans just on faith alone. *** so jon, here's feedback on your stuff... my main impression is that you lack some experience, so i'll explicate that to speed you along. first of all, if you used the text from #41445, you introduced some errors to it... you should do a diff to see what, so as to learn why, such that you can go back to your code and squash the bugs in it. also, when you rejoin end-line hyphenates, you're doing it wrong. (and the "clothing" of end-line em-dashes is completely ridiculous.) second, all of the page-scans from a book should be the same size. plucking each text-block is fine, but lay it on a standardized canvas. third, do _not_ remove the page-number from a scan; that's stupid. that page-number constitutes the auto-documentation for the scan. which is why you should also never ever remove the running-heads. fourth, don't remove the page-numbers from the text, either, for the very same reason. they are a grounding mechanism for _you_, as you are working with the content... otherwise, sooner or later, you _will_ get lost, and figuring your way out is a waste of energy. fifth, _never_ever_ give _any_ files generic names, like "003.png". again, sooner or later, you _will_ encounter problems with that... every book in your library should have a unique prefix, all its own, and each file associated with the book should start with that prefix. i use a 5-letter prefix, meaning it can handle over 3 million books. with generic filenames, you can't confidently handle _two_ books... every file should have a unique filename that identifies it _alone_. (you can have the same file saved under two different filenames, but you should _never_ have different files with the same name.) oh, and yes, the filename should also reflect the page-number, the _real_ page-number, the one that was printed on the page... sixth, don't split the book's text up into a file for every single page. put it all into a single file, so it's easy for the humans to work with. the computer can split and join with ease, so design for the people. seventh, i've done it both ways over the years, so i can tell you that a viewer-program that puts the whole book on one page is _not_ the one you will end up using for most operations, simply because it bogs down the browser once you've loaded multiple page-scans. all-on-one-page is nice as an option, but much less useful overall. don't get me wrong -- your viewer is nice. but its design is faulty. and if you actually use it enough, you'll agree from the experience. *** so there you go. 7 tips is quite enough for one day, i would say. especially because i know you're not too keen on receiving _any_... which is ok. i did it anyway, so someone else could learn from it, either right away, or sometime down the line. however it happens. -bowerbird p.s. good luck with getting p.g. to sponsor your viewer-program. i have offered them much better ones, which they never accepted, so i'm not optimistic for you, but it's certainly a thing p.g. needs... p.p.s. just exactly what is "a kindle-sized .pdf"?, i'd like to know. because kindles now come in a wide size variety, they really do.

1 0

the problem is intractable, and perhaps insoluble
by Bowerbird＠aol.com 28 Nov '12

28 Nov '12

i'm not sure why i work so hard to be accurate and fair when i'm discussing jim, when he in turn seems happy to engage in innuendo and outright _lies_ to slime me. some of the things he says are flat out 360-degree lies, so he obviously cares not even a whit for his credibility. which is why i feel no need any more to counter his crap. because once you've cleared away his smoke-screen and wiped off all of the mud he threw, it's transparently clear that jim hasn't done the thought to have any real answers. so it's a good thing nobody expects any answers from jim. *** on the other hand, people _do_ expect (or at least _hope_) that greg will have some real answers. alas, it seems not... this latest "solution" won't work, because it doesn't address the intractable nature of the problem that underlies all this. let's use #76 to focus our thinking. what we need to do to have any "success" here is to actively discourage users from downloading #76 for _any_ reason... ideally, we would like to drive its download-count to _zero_. (in a perfect world, we would also issue an apology for #76, alongside a promise that we would never fail so badly again; but for the sake of this post, let's just settle for "ideally", ok?) any kind of "note" on the download page will be meaningless, for the most part, because few people will bother to read it... so the download-count likely will not be appreciably changed. and if that's what turns out to be the result, that was a failure. but let's say the download-count _does_ decline, significantly. in some sense, yes sir, that outcome would be "a success"... but what it'll also do is engage david widger in a new battle. (and by "david widger", i mean the whitewashers as a group.) once the whitewashers got wind of greg's "experiment" at the start of the year, they scrapped it, and slapped marcello down. the outcome here would be the same, but even more extreme. it's easy for us to sit on the sidelines and declare e-texts to be "lacking in quality", but the whitewashers were the gatekeepers who passed through every single one of them as "acceptable"... meaning that the issue is not _just_ with those e-texts which were digitized by a whitewasher, but every book in the library. the whitewashers have the power of control when it comes to deciding what _is_ and _is_not_ "acceptable" for a p.g. e-text. and the whitewashers are long-accustomed to rejecting -- and even ignoring totally -- all criticisms of their curatorial efforts. *** so the crux of the issue revolves around the download-count. either it stays up for #76, in which case it means that you have _not_ solved the problem, or else it goes down, in which case you've created a poisonous engagement vs. the whitewashers. you might win that battle, but you'll lose the war when those whitewashers walk away and you have to try to replace them. and even the seemingly non-problemmatic course of action -- having david correct #76 -- isn't the panacea it promises to be. first, it's not all that easy to fix a text, not in their current state (namely, rewrapped, and rarely attached to a specific scan-set). and i'm referring here to _everyone_, not just the whitewashers. jim, for instance, has a hundred+ errors in his version of "huck". karen lofstrum had several hundred errors in the book she did. so even those rock-throwers have targets on their _own_ backs. second, and perhaps more important, it would force david to admit his work on "huck" -- which has stood for a _decade_ -- is substandard. he's gonna stonewall you on that contention. because as long as he can resist you on an example that bad, he knows he can resist you totally. he _also_ knows that once he's defeated on worst-case, it's slippery-slope on all the rest. and thus, the problem is intractable, perhaps even insoluble... -bowerbird

2 1

they won't allow you to use facts to embarrass them
by Bowerbird＠aol.com 28 Nov '12

28 Nov '12

they won't allow you to use facts to embarrass them... that seems to be jim's objection to the whitewashers. and they won't let you step in and replace their work... *** which is why david widger posted jim's version of "huck" at a separate number from david's own version of "huck". otherwise, david woulda voluntarily replaced his own work. which, quite realistically, we cannot expect anyone to do... but it wouldn't have been that different even if it had been some other volunteer's work david was reluctant to replace. as greg has pointed out, it's a somewhat delicate issue to answer the question about the removal of _anyone's_ work. and i certainly don't have the answer. (well, i could probably think up a number of ways to avoid the situation where jim's superior "huck" gets downloaded much less frequently than david's inferior version, but that just sidesteps the more thorny question of replacing work.) however, i pretty much accept that the whitewashers have the power to do whatever they want, so it wouldn't really make any difference even if i _did_ have the answer, since the whitewashers will just keep on doing what _they_ want. so i accept david's action. indeed, since jim has admitted that his version is _different_ than david's, i don't see how jim's version could replace david's version in any situation. it would be different if jim's version were the same as #76. it seems to me, though, that different versions _should_ be posted as different numbers. they're not exactly the same. but since jim has whined about this matter for so very long, i think it might be interesting to give him a thought problem about just exactly what he would recommend on this issue... so let's give him a little incentive... let's imagine... say i've corrected the errors in jim's version. i have generated a list of his errors, and created an interface where you can check that all those errors are indeed wrong. moreover, i have created a clean version of the same edition that jim used. so imagine that i am going to submit it to p.g., along with the pagescans, to create a better overall package... this is the question for jim. what should p.g. do with my submission? 1. reject it. 2. put it under a new number. 3. accept it, and overwrite jim's edition with mine, complete with a new credit-line mentioning "a volunteer", but no name. (i would not take a joint credit-line, because that might imply we'd worked together; and likely neither would jim, probably. it would be acceptable to me if the credit-line got _deleted_.) jim's flawed version could be stored in the "old" subdirectory, because hey, nobody ever looks inside those anyway, do they? anyone else is invited to chip in their opinion as well, but i am especially interested in jim's thoughts. and, if he makes a post before thanksgiving, i will consider it in my deliberations about whether or not, after thanksgiving weekend, i will indeed make a submission to p.g. of a corrected edition of jim's "huck finn". -bowerbird

7 13

Re: [gutvol-d] they won't allow you to use facts to embarrass them
by don kretz 26 Nov '12

26 Nov '12

I think a fair, easy non-controversial request would be to place a simple text dump with text schema of the database tables on readingroo.ms. Sent from my Phone From: Lee Passey Sent: 11/26/2012 10:15 AM To: Project Gutenberg Volunteer Discussion Subject: Re: [gutvol-d] they won't allow you to use facts to embarrass them On Sun, November 25, 2012 4:52 pm, Greg Newby wrote: > Karen's suggestion isn't that far from what we can do now, and > actually have done in practice: a note in the bibrec. Credit where credit is due, this was actually Mr. Hellingman's suggestion. Ms. Lofstrom's suggestion was simply a reiteration of my suggestion of allowing "the crowd" to evaluate the quality of any given version. > The bibrec for > #11 says to also look at #928. These are added by hand... any of the > team at gutcat(a)lists.pglaf.org can add them (usually Andrew Sly does > these, but Marcello and I also tweak the records). I suspect that if we knew the schema of the bibliographic database someone could probably write a script in about a half an hour to programmatically link all corresponding works. Unfortunately, it seems that the schema is a closely guarded secret, so this tedious manual process is the only, inadequate alternative. > Currently, the bibrec is not the main "tab" (see > www.gutenberg.org/etext/11 if you're not sure what I'm talking about). > But I'm sure the Note could appear on the Download tab instead. > > A simple technique to raise awareness of alternate versions would be > to add them to the bibrec as a Note. There might be some situations > when there is ambiguity in whether a note really refers to an > alternate edition of the same book. This applies with Alice, for > example: 11, 114, 928, 19033, 19573, 23716, 28885. And yet, the notes for bibrec #11 still only references #928 and none of the other texts you have just identified. And neither #928 nor #19033 (I didn't look at the other records) have a reverse reference back to #11 or to each other. It appears that the manual system is so error-prone as to be simply not worth the effort. And good luck getting Mr. Perathoner to change the default tab for texts. It is time to retire public references to e-text numbers. A search for _Alice's Adventures in Wonderland_ should return a single page. That page should link to downloadable files differentiated by modification date, file format and contributor's notes. A customer should get the file s/he wants without having to select 11, 928 or 19033; to the customer, this is just noise. [snip] > Editing the bibrec is easy enough to do. I encourage people with an > interest to simply email "like" records, and we can edit them in. The > Note field is flexible, and can be duplicated within a bibrec. This is clearly a hack, attempting to force the system to support a feature that it was not designed to support. If I know enough to follow the notes field on the bibrec tab (when it is actually correctly populated) I know enough to find the best version using other search tools. Squirreling data away in a "notes" field is hardly a user-friendly way to help higher-quality texts to become more visible. _______________________________________________ gutvol-d mailing list gutvol-d(a)lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d

1 0