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

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 Monday, 2 December 2013 04:43:52 UTC