Re: Some info on pagination practices

I was just about to suggest the idea of a new property for Book that is 
actually a new Schema Type, to define the multiple numbered sections, 
plates (where not bound as a normal pages in the folded signatures), 
fold-out maps, and any other details of the content. It could  be 
expanded beyond just pagination to also include the counts of tables, 
figures, illustrations etc (and for each of these, whether colour or b&w).

If we take that route then the current "numberOfPages" property can be 
more clearly defined as the number of bound pages in the book, not 
including the covers, leaving the new property/type for a more 
detailed/specialist uses.

On 16/12/13 22:15, Thad Guidry wrote:
> Karen,
>
> In fact, we added "frontMatter" in Freebase incidentally! :-)  Please 
> look real quick at this 2 property "Pagination" for a /book (actually 
> a /book_edition) in Freebase: 
> https://www.freebase.com/book/pagination?schema=
>
> It is still a valid question on the current "numberOfPages" property, 
> I would say.
>
> I think the definition on "numberOfPages" still needs to be clarified 
> in Schema.org.
>
> Perhaps we can do the same in Schema.org and so we might also look at 
> adding another new property called "frontMatter" that is a text value 
> (not an integer), if folks think there's a great need for that on the 
> Book type, like we concluded in Freebase.  Thoughts ?
>
> On Mon, Dec 16, 2013 at 3:53 PM, Karen Coyle <kcoyle@kcoyle.net 
> <mailto:kcoyle@kcoyle.net>> wrote:
>
>     So perhaps I should have been more specific, but in fact, overly
>     specific may not help us.
>
>     What we seem to have here is "number of pages" versus
>     "pagination." Number of pages would be an integer, which may be
>     accurate or approximate. That we have no control over. Pagination
>     is an expression of the pagination patterns in the book, which can
>     distinguish, for example, an edition without a preface from an
>     edition with a 60-page preface. These patterns can be simple or
>     extremely complex, depending on how much one's community cares
>     about the details. (The rare book community cares a LOT.) The main
>     purpose of these patterns is to present an observable aspect of
>     the item being described, NOT to provide an accurate page count.
>     So if the last numbered page is "603" and there are really only 50
>     pages in the book, the pagination is listed as "603". A diligent
>     librarian will note that the book appears to have many fewer pages
>     in fact. But for identification purposes, the OBSERVED page number
>     is recorded.
>
>     I think that the essential goal should be to allow everyone to
>     input what they consider to be their statement about pages. It
>     might be:
>
>     208
>     [4] 13 leaves, [6] 9 p.
>     A1-13, B1-7, C1-83
>     xii, 356p.
>     approx. 654
>     603 p. [not consecutive, approx. 50 pages]
>
>     The question is: Is there a use case to include in schema.org
>     <http://schema.org> both a property that is defined as an integer,
>     and a separate property that takes a text string of unknown
>     complexity for pagination? What is this property for?
>
>     The obvious use case is that of displaying this to the user so
>     they can see if it's an 11 page or a 1024 page book. That should
>     be satisfiable by any of the more normal above examples. I'm not
>     aware of a use case that would require some guarantee of greater
>     precision, but if there is one then we may be looking at two
>     different properties because of the difference in their potential use.
>
>     Note that a proposal will be coming along that addresses articles
>     that has two additional properties: pageStart and pageEnd. These
>     are commonly used to aid in identification of articles in
>     journals, and were once essential for "fax-to-user" services of
>     libraries. (Odd how quickly such things pass.)
>
>     To sum, I would not word this as an either/or question, but as a
>     question of what properties are needed to accommodate the greatest
>     number of existing practices and use cases.
>
>     kc
>
>
>
>
>     On 12/16/13, 12:04 PM, Dave Caroline wrote:
>
>         I dont think there can be one rule or definition for
>         pagination in all
>         books, one has to look at the book when cataloguing it and be
>         sensible.
>
>         The actual numbers from my quoted examples
>
>         http://www.worldcat.org/isbn/0471634573
>         Last page is is number 16 this book has 11 sections plus a
>         four page
>         introduction a total of 277 pages.
>
>         http://www.worldcat.org/isbn/0534917852
>         It has a last page number of 608, but its fat book and on further
>         investigation it has a last page in the middle too of 607, so 1215
>         (this book was published as two volumes but later bound as one)
>
>
>         Dave Caroline
>
>
>     -- 
>     Karen Coyle
>     kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>     m: 1-510-435-8234 <tel:1-510-435-8234>
>     skype: kcoylenet
>
>
>
>
> -- 
> -Thad
> +ThadGuidry <https://www.google.com/+ThadGuidry>
> Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>


--