- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 16 Dec 2013 14:48:17 -0800
- 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