- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 16 Dec 2013 08:26:37 -0800
- To: public-schemabibex@w3.org
Note also that the "page count" that publishers give to books is a physical count -- the actual number of sheets of paper x 2. The publisher knows this because he paid the printer for them. The page count that a library gives is the number on the highest numbered page (of each pagination type), which is what is visible and readily available (without having to sit and count the pages). Here are two "pages" statements for the same book: publisher: 208 pages library: xiv, 178 p. (which does not add up to 208 because blank pages aren't counted) So those are two other community practices that each is perfectly logical but will give different results. And note that it is probably the publisher number of pages that is currently in schema.org/Book. kc On 12/16/13, 8:01 AM, Wallis,Richard wrote: > Hi Henry, > > Great to have this interaction going between our groups. > > You wrote: > > I'm not sure how much any of this is a problem for the schema. The > main issue is that if you do not include the cover in the page > count, it is possible for your "interior" pages to add up to more > than the supposed total page count of the publication. > > > At the level of general vocabularies such as Schema we will be bridging > communities whose default habits may well be conflict at this level of > specificity. I think it would be best left to the interpretation of the > individual [data] publisher. > > If you try to guide implementation in documentation it probably won’t > work, because for some it will go against their normal practice. > > > ~Richard > > On 15 Dec 2013, at 21:30, Henry Andrews <hha1@cornell.edu > <mailto:hha1@cornell.edu>> wrote: > >> [New thread title since this got specific] >> >> Thanks, Dan! Clearly I still have a lot to learn about the various >> types and how they do and can interact. Thank you for your patient >> explanations. One definition of the "pagination" field seemed to >> include numberOfPages as a usage option, so I'm glad this is actually >> unambiguous- the four fields serve distinct use cases now. (well, >> three- numberOfPages, pagination, and pageStart+pageEnd). >> >> Another page counting issue that doesn't tend to come up with books >> but may have come up with periodicals is how to treat the covers. The >> GCD counts the covers as pages. This particularly makes sense when >> there is no distinct cover to the comic, and when stories start on the >> inside of the front cover (Fox Feature Syndicate habitually did this >> in the late 1940s). >> >> For consistency, this is carried over into book format although it >> makes much less sense there. >> >> I'm not sure how much any of this is a problem for the schema. The >> main issue is that if you do not include the cover in the page count, >> it is possible for your "interior" pages to add up to more than the >> supposed total page count of the publication. >> >> thanks, >> -henry >> >> ------------------------------------------------------------------------ >> *From:* Dan Scott <denials@gmail.com <mailto:denials@gmail.com>> >> *To:* Henry Andrews <hha1@cornell.edu <mailto:hha1@cornell.edu>> >> *Cc:* "public-schemabibex@w3.org >> <mailto:public-schemabibex@w3.org>" <public-schemabibex@w3.org >> <mailto:public-schemabibex@w3.org>> >> *Sent:* Sunday, December 15, 2013 7:19 AM >> *Subject:* Re: Comics and periodicals, call for feedback: round 2 >> (was Re: Comics and periodicals in schema.org <http://schema.org>) >> >> Hi Henry: >> >> On Sat, Dec 14, 2013 at 1:33 AM, Henry Andrews <hha1@cornell.edu >> <mailto:hha1@cornell.edu>> wrote: >> > Does this mean that there's no field in which one can simply >> store the >> > number of pages to an article/story? In modern US comics, ads are >> > interleaved with story pages and Marvel and DC in particular >> have gone >> > through phases of barely allowing more than two or three >> consecutive pages >> > without an ad being thrown in. This is one reason why the GCD >> tracks page >> > count instead of specific page numbers (although the latter has >> also been >> > suggested). GCD users are generally more interested in how long >> the story >> > is rather than how much it was chopped up by ads. >> >> schema.org <http://schema.org> already offers the >> http://schema.org/numberOfPages >> <http://schema.org/numberOfPages>property >> on the Book type, which is probably a better match for your purpose >> than either the "pagination" or "pageStart" / "pageEnd" properties. >> >> There are a few possible approaches for moving forward, that might >> depend on the timing of when we bring the Comics proposal back to >> public-vocabs for a decision: >> >> a) If we move forward with the Bibo alignment work >> (http://lists.w3.org/Archives/Public/public-schemabibex/2013Dec/0076.html) >> and introduce a "Document" class that would live between CreativeWork >> and Article, then we could move "numberOfPages" from Book to Document, >> and then all of the classes that inherit from Document would be able >> to use it. That's likely also where "pagination", "pageStart", >> "pageEnd", and a few other properties would ultimately live, as Book, >> PublicationIssue, PublicationVolume, Article, and other Document >> classes would be able to benefit from those properties and we would be >> able to simplify the RDFS. >> >> b) If we move forward with the Bibo alignment work but decide not to >> introduce a "Document" class, then we could move the document-centric >> properties directly to CreativeWork. Our classes of interest would >> still get access to those properties; the drawback is that sculptures >> and movies would get those properties too (although, hey, who is to >> say that a sculpture made from random pages of books and journals >> wouldn't be interested in a numberOfPages property - heh!) >> >> c) If the Bibo work is delayed and Comics moves forward, then we could >> simply assert via a domainIncludes directive that ComicStory should >> have access to the numberOfPages property as well. >> >> In any case, we should be able to make this work :) >> >> >> Dan >> >> > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet
Received on Monday, 16 December 2013 16:27:05 UTC