- From: Dan Scott <denials@gmail.com>
- Date: Sun, 1 Dec 2013 23:43:24 -0500
- To: "Olson, Peter" <polson@marvel.com>
- Cc: "public-schemabibex@w3.org" <public-schemabibex@w3.org>, Henry Andrews <hha1@cornell.edu>
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