Bowerbird wrote:
as one improvement, i would suggest _not_ using "001.png", etc. instead, preface each one with a string that will make it _unique_, such as "ma2005feb001.png". it's easy to tell that to the o.c.r. app -- you just type it in one time -- and it's an unmistakable stamp.
Yes, a very good suggestion, and one that is being planned. I held off because we are still thinking through the exact syntax of the book identifier, although it *might* be based somewhat on the WEMI (Work/ Expression/Manifestation/Item) principle. The LibraryCity ID used at the current "My Antonia" site is just a quick improvisation of the WEMI principle. For example: Work: "Frankenstein" by Mary Shelley Expression: Second edition (which differs a lot from the First) Manifestation: 1895 printing edited by John Doe (just a dummy example) Item: XHTML So in Trusted Editions, filed under the WorkID for "Frankenstein", we could have multiple Expressions each with its own ExprID, e.g. First Edition, Second Edition, a lost manuscript for a third edition, etc. (many books will have only Expression since they did not become popular and no author manuscript exists.) Under Manifestation we could have several (with ManfID's) based on later edited editions as well as a modern "Michael Hart" style amalgamated/edited edition. And then for each Manifestation we can have several formats (Items, ItemID -- yeah, this is a small twist on WEMI as it officially exists since 'item' in the pbook world usually refers to a particular printed copy of a Manifestation, with coffee stains and page rips and all -- but this works well for ebooks/etexts where each item is a duplicatable digital format derived from the paper Manifestation. This is not yet etched in concrete -- it is still in the idea stage.) So, as an example, we might have for Identifiers: WorkID: 00000000025 (enough for 100 billion general Works.) ExprID: 02 ManfID: 03 ItemID: 008 (referring to some standardized list which expands over time) So the overall ID for a particular format of a particular source paper book might be: 00000000025-02-03-008 (yeah, it's long) Page scans only need the WEM portion of the ID for prefixing on the filename: 00000000025-02-03-p295.png (If we only care about 100 million Works, then we may have: 00000025-02-03-p295.png ) Of course, the WEM-ID itself does not contain any metadata other than identifiers, but that would mesh with a database. It is very problematic to include any Dublin Core type of metadata within an identifier. It is understandable maybe using the two first letters associated with the first two words of the title (ignoring articles), such as MA for "My Antonia", but that's as far as I'd go.
and of course, if you're going to do hundreds or thousands of books, you want to cook up a naming convention that conveys information. on big multimedia projects, it is not at all uncommon to have one _full-time_ employee dedicated _solely_ to maintaining filenames. because if things go wrong, it can waste a whole lot of man-hours.
Every scanned image is a unique digital object, so it needs to have a unique identifier in the object's file name, applied when it is created, along with a metadata record somewhere to describe and keep track of it. The catalogers will take care of the identifers and metadata, which go hand in hand.
oh yeah, one more suggestion. your front-matter filenames were prefaced with an "r". my typical recommendation is that they be prefaced with an "f", and that the regular pages be named with a "p", so the front-matter files will sort _on_top_of_ the regular pages. i want to be able to depend on the operating-system filename sort to give me pages in the exact order they appear in the book itself. so i use a "q" on back-matter files, so they will drop to the bottom. for illustration plates, i use a name that sorts _them_ correctly; for instance, if an illustration page is between pages 168 and 169, name it "p168a.png". (and don't forget the blank verso side either!, which you will name "p168b.png".)
Also an excellent suggestion. The 'r' stands for "Roman", but I noticed in sorting that the pages are not ordered, so the front-/body-/end-matter approach makes sense. Too bad 'b' comes before 'f', as you noted.
It was my intent to reproduce each page for direct reading purposes -- that is, if somebody wanted to read the book as it was printed, then they could.
that's why things like _blank_pages_ are so important to include. because if you toss them out, you screw up the left/right sequence. a convention of paper-books is that odd pages always go on the right. screw that up and you make yourself look silly.
Definitely! I will certainly need to relook at what I did to make sure it's all there. Handling inserted illustrations is a problem name-wise since in "My Antonia", the illustrations were inserts between numbered pages. So for naming/sorting purposes that will need to be worked out. Thanks for the ideas. Jon