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

Jean, thanks for the tip.

A quick look at the 185 page manual for the ISSN (!) reveals that it 
reads very much like a cataloging code for serials. (Variant titles, 
punctuation, various codes, rules for transcription of titles.) Because 
schema.org marks up existing data, some of this is outside of schema's 
control. The question is: are there significant properties that appear 
in web page displays that we are missing?

Note that in the area of books there is no attempt made in schema.org to 
replicate the level of detail found in library records. I consider that 
level of detail outside of the purview of schema.org, but one that will 
be taken up by library-specific standards. I am presuming that we should 
take the same approach with serials, leaving the details of descriptive 
cataloging to an ontology designed for that purpose.

That said, again, the question is: are we missing something? My approach 
to that is: we should try to be complete based on our use cases, but if 
we are missing something today, as schema.org is used those things can 
be added as needed.

kc

On 12/5/13 2:29 AM, jean delahousse wrote:
> Hello,
>
> It is both a question and a comment. Is there a link between the work
> you do to describe periodical/serial publications and the standards of
> the ISSN about periodical/serial publication description ?
>
> ISSN has models applied to Marc21, to LOD with the Press-oo model (based
> on FRBR-oo), and they might be already working on a Schema.org model.
> It could be really nice to have the schema.org <http://schema.org> model
> for periodical/serial publications easily interoperable with the ISSN
> standards as the periodical/serial publications are already described in
> the national library catalogs following those standards, and those
> catalogs are published on the web with semantic annotation based on
> schema.org <http://schema.org>.
>
> I copy Francois-Xavier from ISSN who has been working on Press-oo
> ontology (francois-xavier.pelegrin@issn.org
> <mailto:francois-xavier.pelegrin@issn.org>).
>
> Cheers
> Jean
>
>
>
> 2013/12/5 Dan Scott <denials@gmail.com <mailto:denials@gmail.com>>
>
>     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
>     <mailto: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
>     <http://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 <http://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 <http://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 <http://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
>     <mailto: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
>     <mailto: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 <http://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
>     <http://schema.org> creative
>      >> works at
>     http://lists.w3.org/Archives/Public/public-schemabibex/2013Nov/0091.html
>      >>
>      >>> Our model is derived from the comics.org <http://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
>     <http://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 <http://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
>     <http://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 <http://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 <http://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
>
>
>
>
> --
> Jean Delahousse
> JDC
> ----------------------------------------------------------------------------------------------------
> delahousse.jean@gmail.com <mailto:delahousse.jean@gmail.com> - +33 6 01
> 22 48 55 <tel:%2B33%206%2001%2022%2048%2055> http://jean-delahousse.net/
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet

Received on Thursday, 5 December 2013 15:58:24 UTC