W3C home > Mailing lists > Public > public-vocabs@w3.org > December 2013

Re: Some info on pagination practices

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Mon, 16 Dec 2013 14:48:17 -0800
Message-ID: <52AF8331.2080508@kcoyle.net>
To: lazarus@lazaruscorporation.co.uk, Thad Guidry <thadguidry@gmail.com>
CC: Dave Caroline <dave.thearchivist@gmail.com>, "public-vocabs@w3.org" <public-vocabs@w3.org>
+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
Received on Monday, 16 December 2013 22:48:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:36 UTC