Re: Some info on pagination practices

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> 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 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 http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet
>



-- 
-Thad
+ThadGuidry <https://www.google.com/+ThadGuidry>
Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>