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:46:53 -0800
Message-ID: <52AF82DD.30504@kcoyle.net>
To: Thad Guidry <thadguidry@gmail.com>
CC: Dave Caroline <dave.thearchivist@gmail.com>, "public-vocabs@w3.org" <public-vocabs@w3.org>
Thad, "frontMatter" does take care of a very common case. If nothing 
else, it clarifies what all of those Roman numerals are about in the 
library pagination statements, which, as I've learned, almost no users 
understand. In printing, the term "front matter" is pretty broad, since 
it also includes title pages and half title pages, but I think that your 
usage probably is clear for the vast majority of sentient beings, while 
at some point I'm sure you'll hear from a rare book purist citing 
something from 1503 that you haven't covered. But you're probably used 
to such complaints. ;-)

kc

On 12/16/13, 2:15 PM, 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
>         <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
>         <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:47:22 UTC

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