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

Hi Dan - 

This looks very promising.  I had some questions/comments (I also don't have rights to edit the Bibex wiki for some reason): 

Definition of Comic Series - this may be just a terminology thing in the example, but I don't think we or the comics community would consider the Amazing Spider-Man storyline listed as a distinct series.  We have two distinct Amazing Spider-Man series, one which started in 1963 and one which started in 1999 (http://marvel.com/comics/series/1987/amazing_spider-man_1963_-_1998 and http://marvel.com/comics/series/454/amazing_spider-man_1999_-_2013).  We generally consider storylines to be a smaller organizational unit distinct from series. 

(Storylines generally are complicated because they often don't stay neatly within the comics' bibliographic structures.  I gave a talk a while back that touches on some of these issues here, if you're morbidly curious: http://new.livestream.com/hugeinc/events/2474611)

Definition of Comic - There's some potential for ambiguity here so I wanted to dig down on some specific examples.  Often several comic series are published simultaneously with very similar names.  For example, we currently publish the following:
X-Men
Uncanny X-Men
Ultimate X-Men
X-Men Legacy 

If I'm reading the proposal right, each of those would be distinct comics (each containing one or more distinct series).  

Another example - over the years we published a series of Comic Series in which the titles changed but the numbering was continuous: X-Men -> New X-Men  -> X-Men -> X-Men Legacy -> X-Men (again see the talk, which lists out a few more examples).  Under the definition in the proposal each distinct title would be a distinct Comic, correct?

Comic Stories - because stories can be and are reprinted, the original comic issue in which they appeared should probably be identified in the schema.  For example, the Spider-Man origin story has been reprinted hundreds of times, but it's always "from" Amazing Fantasy #15.  

It might be worthwhile looking at the comics.org schema as well: http://docs.comics.org/wiki/Current_Schema

- peter

Peter Olson | VP, Web and Application Development | Marvel Entertainment | polson@marvel.com | 212-475-4028
________________________________________
From: Dan Scott [denials@gmail.com]
Sent: Wednesday, December 04, 2013 11:36 PM
To: Olson, Peter
Cc: public-schemabibex@w3.org; Henry Andrews
Subject: Re: Comics and periodicals in schema.org (was Re: journal article for next call?)

Well, with no feedback after ten hours (heh, I know), and figuring
that it's better to make things concrete, I've gone ahead and revamped
the "Periodicals and Comics synthesis" proposal to see what it would
look like it was fleshed out with PeriodicalVolume and Comic types. In
the worst case schenario, we can roll back to a previous version of
the proposal.

In any case, the hierarchies now look like:

Periodical -> PeriodicalVolume -> PeriodicalIssue -> Article
Comic -> ComicSeries -> ComicIssue -> ComicStory

... with the Comic types inheriting from the more generic Periodical
types at each point. Of course, Article can still skip the issue and
volume layers and point directly at Periodical where appropriate;
similarly ComicStory can point directly at Comic.

I've changed the structure of the proposal to match that generic /
specialized approach as well ("Periodical schemata", then "Comic
schemata"), and beefed up & corrected the examples in a number of
places to reflect the new types and properties.

Still need to work more on the Comic examples but I think that they
should fall into place relatively easy.

Overall, I'm feeling much better about the state of this proposal. I
think we could have lived with what we had before, but it was
impoverished compared to what is emerging here, and the enhanced TV
vocabulary really crystallized that for me.

On Wed, Dec 4, 2013 at 1:48 PM, Dan Scott <denials@gmail.com> wrote:
> 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
******************************************************************************
Nothing contained in this e-mail shall (a) be considered a legally binding agreement, amendment or modification of any agreement with Marvel, each of which requires a fully executed agreement to be received by Marvel or (b) be deemed approval of any product, packaging, advertising or promotion material, which may only come from Marvel's Legal Department.
******************************************************************************
THINK GREEN - SAVE PAPER - THINK BEFORE YOU PRINT!

Received on Friday, 6 December 2013 04:57:30 UTC