Re: Some info on pagination practices

OK,  sounds like a plan.

1. We agreed that "numberOfPages" needs a slightly better definition than
what we currently have.  Great !
2. We like revisit the proposed new definition, after the Periodical
proposal comes through.

Thanks !


On Mon, Dec 16, 2013 at 4:48 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:

> +1. And perhaps we can hold this thought until the periodical proposal
> comes through, because it has a pagination property that isn't quite
> solidified yet.
>
> kc
>
>
> On 12/16/13, 2:20 PM, Paul Watson wrote:
>
>> 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/>
>>>
>>
>>
>> --
>>
>>
> --
> 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/>