Re: Comics and periodicals in schema.org (was Re: journal article for next call?)

A quick update on the synthesized periodical / comics draft proposal
[1]; I updated it to use the "hasZzz" pattern Dan Brickley mentioned
[2] as a potential future direction for schema.org properties that
point at "Zzz" types, rather than using the lower case "zzz" property
for the same purpose. For example, we had been using "article" to
point at "Article", but in the mean time http://schema.org/article was
defined for use in Actions... we can always adjust, of course,
depending on which way schema.org swings, but I figured it might as
well be consistent.

Is it out of the realm of possibility to get yeas / +1s, yeas with
caveats, or nays with concrete suggestions / counter-proposals for
this aired on the mailing list before our next call on December
11th... hopefully with time to also resolve the caveats / suggestions
/ counter-proposals prior to the call?

I'm almost afraid to mention this, but given the excitement about the
increased granularity of the TV-related vocabulary in the schema.org
1.0e release [3] (Series -> Season -> Episode -> Clip), I'm now
tempted to go even further than the Periodical -> PeriodicalIssue ->
Article level of granularity that we currently offer and interpose a
PeriodicalVolume type that would live between Periodical and
PeriodicalIssue, and would nicely parallel the existing ComicSeries
proposed type. So we would have "Periodical -> PeriodicalVolume ->
PeriodicalIssue -> Article" and "Periodical -> ComicSeries ->
ComicIssue -> ComicStory" to parallel the TV structure. (Hrm, looking
at that perhaps we should add a "Comic" subtype of Periodical to keep
everything uniform?)

The impact on the current proposal would (roughly) be to change
PeriodicalIssue::issueVolume to
PeriodicalIssue::partOfPeriodicalVolume and to add a
hasPeriodicalVolume property to Periodical; the benefit would be
increased granularity for those who desire to express that (for
example, you get to provide startDate / endDate for each volume, which
seems like a win) while still retaining the ability to support the
arxiv.org "we don't need no stinking volumes or issues!" use case.

1. http://www.w3.org/community/schemabibex/wiki/Periodicals_and_Comics_synthesis
2. http://lists.w3.org/Archives/Public/public-vocabs/2013Dec/0037.html
3. http://blog.schema.org/2013/12/schemaorg-for-tv-and-radio-markup.html

On Sun, Dec 1, 2013 at 11:43 PM, Dan Scott <denials@gmail.com> wrote:
> Peter:
>
> This is awesome information, thank you!
>
> I have some questions inline, below:
>
> On Sat, Nov 30, 2013 at 5:41 PM, Olson, Peter <polson@marvel.com> wrote:
>> Hi all -
>>
>> I am always happy to talk about comic semantics.  This probably says more about me than it should.
>>
>> I'll talk a little bit about how we model comics internally - the schema.org proposal is a simplification of this (we kind of omit the lowest level of the hierarchy in that in order to make it easier for people like comics retailers to implement).
>
> Ah, rereading your email, I think this is crucial to my understanding;
> by "omit the lowest level of the hierarchy", do you mean that you
> thought about, but did not, create a "ComicStory" type? If that's the
> case, then the ComicStory seems analogous to the scholarly Article,
> and may very well be worth modelling (even if retailers might not
> implement it, I'm sure that comics enthusiasts would jump on it). To
> me, at least, it seems that one might want to find a summary of an
> obscure story about a favourite character, and from there find out
> where you can read that story (e.g. in various issues including
> reprints, or in a graphic novel that collects the story amongst
> others, or via an online service where access to it can be purchased
> directly). On the academic side of periodicals, the Article is in many
> ways the driver of most of our use cases, so perhaps I'm biased on
> this front.
>
> Similarly, those obsessive about variant covers may very well want to
> track down each of the covers by a given artist, or all of the covers
> for a given series. You might be interested in a quick, rough proposal
> I made to give cover art more pride of place in schema.org creative
> works at http://lists.w3.org/Archives/Public/public-schemabibex/2013Nov/0091.html
>
>> Our model is derived from the comics.org model (and they have done a lot of good work in terms of creating workable comic models that capture the range of behaviors in comics).
>
> Thanks for the pointer; it has been fun to explore comics.org a bit!
>
>> We have a hierarchical model for comics: series collect issues and issues collect stories, stories being an indivisible unit of a comic.
>
> This really interests me, because on the more academic side of
> periodicals we're (mostly) working towards periodicals collecting
> issues and issues collecting articles (or other creative works, in the
> case of photo spreads in magazines like National Geographic or the
> like).
>
>>  The term "story" is a bit overloaded, but can be thought of as roughly analogous to an article in a magazine.  It means any indivisible, re-printable unit of a comic, including the interior stories, covers, backmatter, etc.  For example, most comics have two stories - a cover and an interior story.  Many comics, however, have multiple stories - a cover, a handful of interior stories, and whatever backmatter.  Amazing Fantasy #15 (http://marvel.com/comics/issue/16926/amazing_fantasy_1962_15) is an example of this - there were several stories including one about a wizard, a Martian invasion and a short throwaway piece about some kid getting bitten by a spider.  Anthology books like this are still fairly common - A+X is one which is currently published (http://marvel.com/comics/series/16450/ax_2012_-_present).
>>
>> Stories can be (and often are) reprinted in issues and collections (e.g. trade paperbacks, hardcovers etc.), so we track creative assignments and character appearances at the story level. In our system, collections and graphic novels are functionally identical to other comics (a collection just has a larger number of collected stories).  We generally track the stories in collections and then bubble up the collected issues from the stories' original appearance.  For formality we require all comics, including collections and graphic novels, to have a series so we assign collections to a series of one issue.
>
> Again, this is very interesting as it parallels a discussion that
> we've been having on this list about whether you should call something
> a "collection" if it collects only one element; there have been some
> fairly strong opinions expressed about this on this list! But it seems
> like a practical approach to me :)
>
>> Let me know if you have more specific questions.   Always happy to help.
>
> Hah, seeing the length of this email, you might regret that statement / offer :)
>
> I was drilling into comics.org a bit, because I'm really interested in
> what distinguishes each series for a given comic. So, for example,
> http://www.comics.org/series/35015/
> http://www.comics.org/series/53696/
> http://www.comics.org/series/53702/ are all "The Muppet Show" from
> 2009, but listed as three separate series. Is the first one a
> four-part series because it is organized around the notion of
> "Kermit's Story", and then the next two are single-issue series
> because there are self-contained stories?
>
> Understanding this is important because achieving a synthesized
> periodicals & comics proposal that satisfies the academic journal,
> popular magazine, newspaper, book series, and comics use cases is
> going to hinge on some of these distinctions.
>
> Part of me wondered if the "series" need might be more generally
> served by a "StoryArc" collection type, such that each story could
> have a "partOfStoryArc" property (and conversely, StoryArc could have
> "containsStory" properties), but for now let's work with the
> ComicSeries approach.
>
> That being said, even at the limited state of understanding that I
> currently have attained, I've gone ahead and drafted a proposal that
> synthesizes what we've done for periodicals & issues in this group to
> date with the comics proposal. The proposal tries to tie in some
> patterns of the recently added TV types, too, so it's a tad messy...
> but here's what I'm thinking at this point:
>
> * One big overall change is that we no longer inherit from
> "Intangible"; instead, we inherit from CreativeWork (and in some cases
> Collection).
>
> * New types to parallel TVSeries: Periodical and ComicSeries
> ** Periodical: add "startDate" and "endDate" standard schema.org
> properties instead of minting new "endYear" / "startYear" properties;
> we could add "numberOfIssues" and "numberOfVolumes" properties if we
> wanted to _really_ parallel TVSeries
> ** ComicSeries: inherit from Periodical, include "imprint" and
> "volume" properties from Comics proposal (note that range of "imprint"
> is now "Organization" to keep it similar to "publisher"; and "volume"
> is here because that seems to be of particular importance in the comic
> world, while in other domains such as newspapers "The New York Times"
> is recognized as the same overall entity no matter what volume it is
> as)
>
> * Changes to Periodical Issue / Issuance:
> ** Adopt "PeriodicalIssue" as the standard name
> ** Use "pagination" instead of "numberOfPages" to allow more precision
> (although, come to think of it, we could offer both properties, to
> avoid forcing processors to parse the "pagination" field to figure out
> how many pages are in a given issue...)
> ** Omit "subtitle" as CreativeWork offers both "alternateName" and
> "alternativeHeadline" for similar purposes
> ** Use "partOfPeriodical" property to point at Periodical instead of "series"
> ** Omit "upc" property and move to ComicIssue (aside: maybe
> http://schema.org/gtin13 should be reused instead of a new "upc"
> property)?
>
> * Add "ComicStory" as a parallel to "Article". This enables sites that
> want to go that deep to use the "partOfComicIssue" /
> "partOfComicSeries" properties to link back to those collections - and
> the proposed Collection property "isPartOf" would also be available
> for use to point at GraphicNovel collections.
>
> * In "GraphicNovel", rename "collectedIssues" to "comicIssue";
> schema.org generally prefers singular property names and this
> hopefully makes it clearer for implementers that they should repeat
> the "comicIssue" property for each collected issue, rather than
> putting them all in a space-delimited list and forcing processors to
> figure out what might be meant...
>
> I've reformatted the comics schemata to try and reflect what we would
> need for the final proposal--so for the comics types, I've added
> descriptions that paraphrase or directly lift what you (Peter) said in
> your email or what the Comics proposal stated elsewhere in the text.
> Hope that's okay!
>
> In passing, I noticed that the descriptive text refers to a
> "distributor code" for comic issues, but there is no property defined
> for it in ComicIssue the comics proposal; however, one example uses
> "productID" which is currently associated with the Product type in
> schema.org. Peter, do you know if your group intended to broaden the
> domain of "productID" to include ComicIssue?
>
> The "Comics and Periodical synthesis" proposal is available in its
> current state at
> http://www.w3.org/community/schemabibex/wiki/Periodicals_and_Comics_synthesis
> - I think it's reasonably sound in its current form. I started by
> copying and pasting the two separate existing proposals in their
> current form, and then edited it in stages from there, trying to use
> useful wiki changelog comments, so if you want to track the evolution,
> it should be pretty straightforward to see what happened.
>
> Thus far I've made no attempt to weave in the rough "cover art"
> proposal, as I'd like that to mature a bit, but I'm sure you can
> figure out where it would fit in :)
>
> I'd love to hear what you think!
>
> Thanks,
> Dan

Received on Wednesday, 4 December 2013 18:48:59 UTC