As we finalize the design for VideoGame, there is a need to clarify how a series of video games should be represented.

Related discussion: http://lists.w3.org/Archives/Public/public-vocabs/2014Oct/0061.html

Current rough consensus and best practice is that a series of video games can be linked to a specific game in that series using hasPart (or the inverse property: isPartOf).

However several designs are being considered for typing those entities. The game series could be typed VideoGame, or Series; schema.org supports multiple typing, so the series could be typed "VideoGame" and "Series".

The Series type is currently oriented towards TV/Radio content, but is a good candidate for generalization (again see public-vocabs for discussion). The concept of "episodes" and "seasons" from http://schema.org/Series are also sometimes relevant to gaming.

For example from http://en.wikipedia.org/wiki/The_Wolf_Among_Us :

The game's first season consists of five episodes, with the first episode being released for
Microsoft Windows and Xbox 360 worldwide on October 11, 2013, for OS X worldwide on
October 14, 2013, for PlayStation 3 on October 15, 2013, in North America and on
October 16, 2013, in Europe and Australia, for iOS worldwide on December 4, 2013,
and PlayStation Vita before the end of 2014.

The initial release of VideoGame will not address every subtlety raised here: regional and platform-specific release dates, SoftwareApplication versioning etc. This issue serves to track the main outstanding concern (series); we may go into more detail around seasons, episodes, software versions etc eventually too.

See also related work on periodicals, http://blog.schema.org/2014/09/schemaorg-support-for-bibliographic_2.html

The plan so far:

For sdo-venkman, we show in an example that isPartOf / hasPart can be used, and that Series is applicable. Perhaps mild-reworking of definition of Series. Subsequently, more work needed on Series and perhaps tweaks to Episode, Season to allow possibility of games being episodal (e.g. Walking Dead ipad game Season 2, Episode 3...).

Here is a proposal for a mild-reworking of Series and nearby terms.

Proposal: minimal changes to bring games into Series

1.
Currently, "Series: A TV or radio series."

becomes, "A media series, e.g. TV, radio or video game."

1. Episode: A TV or radio episode which can be part of a series or season.

becomes, "A media episode (e.g. TV, radio, video game) which can be part of a series or season."

1. Season: A TV or radio season.

becomes, "A media season e.g. tv, radio, video game etc."

1. Properties a) http://sdo-venkman.appspot.com/season "A season in a tv/radio series."

becomes, "A season in a media series"

b) http://sdo-venkman.appspot.com/episode "An episode of a TV/radio series or season"

becomes, "An episode of a tv/radio/game media series or season"

1. Subtypes

At this stage, no need to subtype Episode, Season or Series for VideoGame[Episode|Season|Series]

... even though we have them for TVSeries, RadioSeries and elsewhere.

+1 Like it all.

Quibble, stay consistent with using commas... instead of / i.e. tv/radio/game

@dbs, any thoughts on how this relates to series of books, periodicals etc.?

More episodic game examples: http://en.wikipedia.org/wiki/Broken_Age
http://en.wikipedia.org/wiki/The_Walking_Dead_(video_game) (in addition to http://en.wikipedia.org/wiki/The_Wolf_Among_Us mentioned earlier).

@danbri @Dataliberate Actually, I don't have a problem with the wording; books, comic books, pamplets, etc are all forms of media (print media).

The applicability of the general Series to Book could certainly be strengthened by specifically mentioning "book" as an example in the generic "Series" description, along with TV, radio, video game, but I really want to avoid going down the road of having to create subtypes for every other new CreativeWork subtype (like when we add ComicBook, for example).

If we make Periodical a subtype of Series, then the major differentiation is that Periodical has an optional "issn" property and is intended to continue indefinitely, whereas many other types of series have an intended beginning and end (even though publishers/distributors/media conglomerates may subsequently decide that prequels or sequels would be a really good idea for financial reasons). So I'm tentatively okay with that.

That leaves room for the general "Series Book" multi-type entity to apply to the "Lord of the Rings" trilogy, with individual hasPart Book entities for each entry in the series; "Periodical" for a newspaper or scholarly journal for "published indefinitely" serial entities with their own hasPart PublicationIssue relationships; and similarly "Series VideoGame" MTE for "Sonic the Hedgehog" and the like with their own hasPart VideoGame relationships.

Yeah?

"A media series, e.g. TV, radio, book or video game."

+1 for not adding subtypes for all/every serial-able kind of thing, even if we have some already.

While it seems harmless and reasonable to make Periodical subtype of Series, except that it would gain about 10 tv/radio-centric properties that might be confusing for bibliographic-minded users. My proposal would be to tweak Series as sketched here but leave Periodical as a related sibling type, and hold open the option of pushing some of the broadcast properties onto an intermediate subtype later (eg. BroadcastSeries). I'd like to identify something modest and straightforward we can do as a first step...

"I'd like to identify something modest and straightforward we can do as a first step..."

+1 - let's make it so :)

For the 80% case, Series works as-is for books. Books tend to be weird in unique ways: a book may be a part of multiple series, book series can have non-linear ordering or no real order other than publication date, series can have sub-series (which I guess aligns with season vs episode).

The Ender's Game books are a good use case as the "series" has evolved over time and the Shadow series can are a sub-series.

I looked at examples of different series (not only video game and concluded) that almost all of the series contain properties specific to individual elements of the series
That's why I think the most appropriate way to represent series will be multy type. In this case we can made series with different type of creative work (book+game). But may be I don't see something important

Something like this:

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": ["VideoGame", "Series"],
  "name":"The Elder Scrolls",
  "startDate":"1994",
  "endDate":"April 4, 2014",
  "productionCompany":["Bethesda Game Studios, ZeniMax Online Studios, Vir2L Studios"],
  "gamePlatform":["MS-DOS", "Microsoft Windows", "Xbox", "Xbox 360", "PlayStation 3", "N-Gage", "Java ME", "Xbox One", "PlayStation 4", "OS X"],
  "episode":[
  {
  "@type": ["VideoGame", "Episode"],
  "name":"The Elder Scrolls: Arena",
  "episodeNumber":"1",
  "trailer":"http://example.com/videotes",
  "playMode":"SinglePlayer"
  },
   {
  "@type": ["VideoGame", "Episode"],
  "name":"The Elder Scrolls II: Daggerfall",
  "episodeNumber":"2",
  "trailer":"http://example.com/videotes2",
  "playMode":"SinglePlayer"
  }
  ]
 }

Summarizing some various discussions yesterday.

1. Yuliya notes that often with VideoGameSeries, we will want to draw upon properties defined for VideoGame, and that this extends to other kinds of series too, e.g. TVSeries.

2. As discussed here, Periodical makes sense as a kind of series, however if it formally subtyped schema.org/Series then anyone visiting http://schema.org/Periodical would see a ton of properties that very rarely make sense for a periodical (actors, episodes etc.).

3. Guha suggests that we should be thinking of this more "bottom up", and that a webmaster/publisher will generally be looking for a specific series type (VideoGameSeries, TVSeries) rather than at Series in the general case. And that we are giving up too easily at the thought of making a bunch of specific concrete task-specific subtypes. He suggested e.g. MovieSeries, VideoGameSeries, Periodical, BookSeries, maybe a few others might eventually be useful ... and attaching properties at the appropriate level.

4. There seems to be general consensus around the changes I outlined here that would make the top Series type less particular to TV/Radio. Following Guha's argument we should then define the subtypes and anchor "actor", "numberOfEpisodes" etc on each subtype as appropriate.

5. Coming back to Yuliya's point, how then do we mix in the properties that currently attach to VideoGame so that they are available on VideoGameSeries?

a) assert the generality that VideoGameSeries has two supertypes: Series + VideoGame
b) re-associate the relevant properties manually, explicitly.

Guha argued for (b) on the basis that multiple typing is a fairly heavy (complexity-adding) mechanism that ought to be used for cases where it is a huge win. Here it just saves a few minutes editing work.

Looking through the subtypes of CreativeWork, the model is all over the map (in part due to not having hasPart/isPartOf until recently). We could pick off a few of the big types for Series:

Book
Movie
Periodical
Radio
TV

Painting and Photograph don't seem as commonly marked up, but museums and archives may be able to make use of Series for these types.

Ok! I had a chat with Yuliya today, she's OK with this direction on the basis of the arguments summarized above, so I think we have a plan. I've move towards getting the above implemented, either in a branch or directly in sdo-venkman depending on whether I find anything to quibble over as I code it up.

Tagging with "Decided but left Open For Implementation", which is an experiment in keeping track of consensus and implementation tasks. Maybe there's a more conventional workflow (close and make an implementation-oriented issue) but it'll do for now.

Please take a look:

http://sdo-venkman.appspot.com/Series
http://sdo-venkman.appspot.com/VideoGameSeries
and nearby.

Exact changes are here: danbri@2465d87

I've drafted the edits in a separate branch but for simplicity pushed out a test build over the top of the general sdo-venkman release candidate, as we'll likel integrate the branch in a matter of hours.

Please take a look!

I've also just updated the final (currently JSON-LD only) example in http://sdo-venkman.appspot.com/VideoGame to use VideoGameSeries.

@RLRichardson I think there's a broader question here about a more freeform mixing of properties on different types, building on the observation that real world entities can quite reasonably be members of multiple schema.org types simultaneously. I see no reason you shouldn't mix-in Product properties with anything from elsewhere in schema.org that could be offered for sale. Whether schema.org's RDFS and navigation structure should anticipate that explicitly, I'm less sure.

I believe we have consensus and it is implemented reasonably well in sdo-venkman, http://sdo-venkman.appspot.com/Series (including lots of associated housekeeping and tidying).