Re: Comics: Page counts, etc.

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 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