- gutvol-d - lists.pglaf.org

re: [gutvol-d] foreign dishes
by Bowerbird＠aol.com 01 Aug '06

01 Aug '06

don said: > Why did you send this to me? i sent it to the gutvol-d listserve, which you must be subscribed to. are you aware you, too, sent your question to the hundreds of people on that listserve? -bowerbird

1 0

Re: [gutvol-d] foreign dishes
by kostuch＠earthlink.net 01 Aug '06

01 Aug '06

Why did you send this to me? Peace, Don -----Original Message----- >From: Bowerbird(a)aol.com >Sent: Aug 1, 2006 3:19 PM >To: gutvol-d(a)lists.pglaf.org, Bowerbird(a)aol.com >Subject: [gutvol-d] foreign dishes > >e-text #10011 is a delightful little recipe-book, >dating from 1908, with "365 foreign dishes" in it, >one "for every day in the year". in keeping with this, >entries are ordered from january 1 to december 31. > >the e-text was very well-done (a little cooking pun). > >close analysis in the process of z.m.l. transformation >revealed just one tiny glitch -- an extra empty-line -- >which was located rather easily, as can be seen here: >> http://snowy.arsc.alaska.edu/bowerbird/etext10011/10011glitch.jpg > >you can compare the original p.g. file with the z.m.l. version, >side-by-side, by opening up these url's in separate windows: >> http://snowy.arsc.alaska.edu/bowerbird/etext10011/10011.txt >> http://snowy.arsc.alaska.edu/bowerbird/etext10011/10011.zml > >to sum up, the changes involved reworking all the headers a little bit, >and introducing a "contents" menu for the dishes under each month... > >then i generated a .pdf of it: >> http://snowy.arsc.alaska.edu/bowerbird/etext10011/10011.pdf > >as you will notice, this .pdf presents each of the dishes on its own page. >this gives a very clean look, and will eventually provide great navigation. >(my work-flow does not yet provide auto-hotlinking in the .pdf version.) > >indeed, in cases like this, the .pdf makes a _better_ e-book than .html, >and you can judge it for yourself by viewing the p.g. html-book, here: >> http://www.gutenberg.org/files/10011/10011-h/10011-h.htm > >of course, you'd want to generate another .pdf if you were printing it, >so as to use fewer pages. but this format is great for on-screen use; >the ability to page from one recipe to the next, with each presented in >a consistent position, is far less trying than scrolling through them... > >this is a common scenario, actually, with another example of it being >the reading of a listserve digest. when each message comes up at the >top of the screen, automatically, and you can skip it with a keypress to >go to the next, it's much easier to navigate than when you must scroll >and scan the text to try and locate the beginning of the next message. > >i will share frequent observations as i go about the task of converting >the p.g. library over to .zml, so i thought i'd start with this simple one. >comments of any type are welcomed, from _just_about_ anyone... ;+) > >-bowerbird > >p.s. if you try the norwegian fish pudding (march 24), let us know!

1 0

foreign dishes
by Bowerbird＠aol.com 01 Aug '06

01 Aug '06

e-text #10011 is a delightful little recipe-book, dating from 1908, with "365 foreign dishes" in it, one "for every day in the year". in keeping with this, entries are ordered from january 1 to december 31. the e-text was very well-done (a little cooking pun). close analysis in the process of z.m.l. transformation revealed just one tiny glitch -- an extra empty-line -- which was located rather easily, as can be seen here: > http://snowy.arsc.alaska.edu/bowerbird/etext10011/10011glitch.jpg you can compare the original p.g. file with the z.m.l. version, side-by-side, by opening up these url's in separate windows: > http://snowy.arsc.alaska.edu/bowerbird/etext10011/10011.txt > http://snowy.arsc.alaska.edu/bowerbird/etext10011/10011.zml to sum up, the changes involved reworking all the headers a little bit, and introducing a "contents" menu for the dishes under each month... then i generated a .pdf of it: > http://snowy.arsc.alaska.edu/bowerbird/etext10011/10011.pdf as you will notice, this .pdf presents each of the dishes on its own page. this gives a very clean look, and will eventually provide great navigation. (my work-flow does not yet provide auto-hotlinking in the .pdf version.) indeed, in cases like this, the .pdf makes a _better_ e-book than .html, and you can judge it for yourself by viewing the p.g. html-book, here: > http://www.gutenberg.org/files/10011/10011-h/10011-h.htm of course, you'd want to generate another .pdf if you were printing it, so as to use fewer pages. but this format is great for on-screen use; the ability to page from one recipe to the next, with each presented in a consistent position, is far less trying than scrolling through them... this is a common scenario, actually, with another example of it being the reading of a listserve digest. when each message comes up at the top of the screen, automatically, and you can skip it with a keypress to go to the next, it's much easier to navigate than when you must scroll and scan the text to try and locate the beginning of the next message. i will share frequent observations as i go about the task of converting the p.g. library over to .zml, so i thought i'd start with this simple one. comments of any type are welcomed, from _just_about_ anyone... ;+) -bowerbird p.s. if you try the norwegian fish pudding (march 24), let us know!

1 0

re: 19 million
by Bowerbird＠aol.com 27 Jul '06

27 Jul '06

greg said: > The download total as of right now is just over 19 million. 19 million downloads out of that measly p.r.? i'm impressed! i wouldn't have been surprised if nobody even heard about it. these days, if you don't have a multi-million-dollar ad budget, the big boys will usually drown you out with all their big noise. but i guess that word "free" still hasn't lost its magic touch, eh? people are sheep. so good job on the hype, michael! but now get back to work. :+) -bowerbird p.s. i think to become a discussion topic on one certain listserve and another certain blog, you have to be promoting some vapor, and make grandiose promises that e-books will soon cure cancer. reality -- especially .pdf reality -- is too humdrum for some people.

1 0

World eBook Fair: 12 million downloads. Anyone notice?
by Jon Noring 27 Jul '06

27 Jul '06

Everyone, I just posted a TeleRead blog article, which in turn links to the blog article posted by Catherine Hodge at DPP Store, about the World eBook Fair (WeBF). My blog article: http://www.teleread.org/blog/?p=5230 Catherine's blog article: http://dppebookstore.blogspot.com/2006/07/world-ebook-fair-12-million-downl… Both Catherine and I are perplexed by the lack of public discussion about the WeBF on the various ebook-related forums such as this one. What are your thoughts? Jon Noring

7 9

re: 1:5 scale
by Bowerbird＠aol.com 24 Jul '06

24 Jul '06

well, obviously, in prototyping a system, you use just part of the data, not all of it. especially on something like this. :+) i subset the content so i can _examine_ it, molding it into shape manually if necessary. in the process of that, i gain an understanding of what needs to be done, so i can program it, and i develop the first pass at those routines... for instance, as i said, one of the first tasks is whipping the catalog into the shape i want it... that job has already taken me a number of hours, and it's not done yet. the catalog was quite a mess -- and hey, it's just titles and author-names! -- so all told, it'll probably take me some 20 hours, and maybe 30, just for this 1:5 subset... you can see the current state of my clean-up work here: > http://snowy.arsc.alaska.edu/bowerbird/mcl/-catalog there's still work that needs to be done on subtitles, and on the "mirror" titles (which were a total disaster), but other than that, this data is now very consistent... by the time i'm done with this, i'll have good routines to clean it up automatically, to the extent it's possible. so i expect the next 1/5 of the catalog to be cleaned in half the time -- 10-15 hours. during each phase, i'll pick up more information on how to automate it. so the next 1/5 of the catalog will take half the time, about 6-8 hours. and the next 1/5 will take half that, about 3-4 hours. and the last 1/5 will take 1-2 hours. and by then, i'll have some very well-polished routines. so if i decided to do the whole job over, from scratch, for maximal consistency, it'd take about 4-10 hours... this time-savings, via automation, is what you want. that's why you just do a subset of the data in a model. -bowerbird

1 0

1:5 scale
by Bowerbird＠aol.com 24 Jul '06

24 Jul '06

i'm doing a 1:5 scale reworking of the p.g. library. i have selected e-texts 10000-14000 to work on. one early step is a massive clean-up of the catalog. this might involve serious breakage of compatibility with the existing library. (in other words, you won't necessarily be able to easily import my corrections.) if there is anyone out there who would like me to maintain a limited compatibility, so as to dovetail with their work, please do inform me immediately, and we can have a discussion about cooperation... thank you. -bowerbird p.s. if anyone would like to design the user interface for a program for end-users to access this reworking, feel free to share that too, frontchannel or backchannel.

4 3

re: [gutvol-d] 1:5 scale
by Bowerbird＠aol.com 23 Jul '06

23 Jul '06

dave said: > What on earth is one fifth of a library? first and foremost, it means porta-potties instead of rest-rooms. other than that, it means we have all the books, but just up through page 18 with each one, because statistics tell us that that's only how far most people read in a book that they buy... > Most readers do not get past page 18 in a book they have purchased. > http://www.parapublishing.com/sites/para/resources/statistics.cfm many of you might know dan poynter, who collected all these statistics from various places, as the guru of self-publishing... michael, once you get past the frustration of poynter's statistics, i'm positive you will find his web-page to be utterly fascinating... here are a few samples, on publishers: > 18. On average, they pay $465.17 for a simple cover design > to as much as $3,533.26 for a complex cover design. > Typical cover costs range $450 to $3,000. ... > 24. An average of 10 to 15 hours are spent designing a book cover. > 25. On average, 61 hours are spent in the editing process. > 26. On average, 29 hours are spent producing a news release for a new book. really, michael, i look forward to a ton of new posts from you based on the motivation you'll get from all of these statistics... :+) -bowerbird p.s. dave, actually it just means that i started out with 4,000 out of the (roughly) 20,000 e-texts in the p.g. library, so 1/5. for some reason (i'm not sure why), model-builders have always been fond of the 1/5 scale. it's big enough to be "realistic", yet still small enough to be a "model". it makes things very cute, too.

1 0

re: 1:5 scale
by Bowerbird＠aol.com 22 Jul '06

22 Jul '06

speaking of interfaces, wow, a whole shitload of librarians just got their asses kicked bad... > http://www.amitgupta.info/E41ST/ -bowerbird

1 0

re: [gutvol-d] first pass at a p.g. categorization scheme
by Bowerbird＠aol.com 21 Jul '06

21 Jul '06

joey said: > Really, the only difference I can see between your model and mine > is that mine is a server-side, collaborative effort, while yours > builds destkop-oriented data islands. well, you've done some semantic loading there, contrasting "collaborative" with "data-islands". i could counter with "nonpersonalized" versus "individualized", but i don't see much purpose. ultimately, the catalog should work both online and offline. and either approach is capable of it. the real difference is shown when you contrast your system with the wiki system marcello made, which operates in a fashion similar to my system. in your system, tags are applied toward e-texts. in marcello's system (or mine), the e-texts are applied toward categories. that's the difference. again, whether we want to consider that to be a "significant" difference doesn't really matter, as long as we understand that _is_ the difference. all this boils down to the catalogers: would they rather start with a _category_, and apply e-texts, or would they rather start with an e-text and then apply categories. i tend to think it'd be the former. (and certainly, from my standpoint of programmatic cataloging, rather than human-enacted, the former approach is far more easy for me to write code for.) there are still some things you haven't shown us with your example. the first is how nimble it is, once you have scaled it up to the 20,000 e-texts. so i multiplied your 1000-set by 20 times. it's here: > http://snowy.arsc.alaska.edu/bowerbird/misc/joeytags.html at 3.1 megs, it'll be a bit of a pain for dial-up users. the second is the back-end work that you will do to assign tags automatically. (for instance, although i recognize you were just using it for your example, language tags are unnecessary, because that info is already available in the current catalog, and just needs to be converted.) the third is how you're gonna let your catalogers add new tags to your standard set. the fourth -- a big one -- is how the catalog will be made into a public-facing entity end-users navigate. but none of these are especially _difficult_ challenges, so i'm sure you can manage them, and i look forward to experimenting with your system when it's finished. > And I don't see why they would need to be > mutually exclusive, either. sure, the data can be munged to work either way; as usual, it is just a question of _doing_ that work. and giving cataloger volunteers a choice of models would seem to me to be the best way to proceed... but my mission is not to work with volunteers at all, but rather to build a system myself and then put it directly into the hands of end-users. that's my focus. my gut feeling is that a wiki-style approach will be more successful at attracting volunteers than your tag model, but i wouldn't be surprised if i'm wrong. marcello's wiki has an inordinate level of difficulty; i'd allow people to simply enter the e-text number, and then automatically generate all the other info. having them enter that info (and then formatting all the links in wiki-markup) is a recipe for errors, plus it raises the cost of contributing to the point where i think you would have very few volunteers... > Perhaps you could populate your client-side app > with a list of "folders" and "alias files" generated by > polling my server-side app, and perhaps people could > publish their data island back to the world as a set of tags. you are welcome to collect data from my model if you want. and just as i'll be getting info from samizdat and blackmask, i'll also collect data from your server-side approach if i can... except i expect to be finished with my effort (limited as it is) before you even get fully started with your (unlimited) one... -bowerbird

2 1