Clarify how to represent a Series of VideoGame #148

Closed
danbri opened this Issue Oct 17, 2014 · 22 comments

Projects

None yet

7 participants

@danbri
Contributor
danbri commented Oct 17, 2014

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

@danbri
Contributor
danbri commented Oct 23, 2014

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...).

@danbri danbri added this to the sdo-venkman release milestone Oct 23, 2014
@danbri
Contributor
danbri commented Nov 6, 2014

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

Proposal: minimal changes to bring games into Series

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.

@thadguidry

+1 Like it all.

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

@danbri danbri self-assigned this Nov 6, 2014
@dbs
Contributor
dbs commented Nov 6, 2014

+1

@danbri
Contributor
danbri commented Nov 7, 2014

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

@Dataliberate
Contributor

Good question I was going to raise too.

The basic concept of a series is similar across most CreativeWorks but some of the wording proposed would make it difficult to use for a book series.

Am I suggesting a generic Series type and TV/Radio, VideoGame, Book, Periodical sub types? - I think I am.

~Richard

On 7 Nov 2014, at 05:43, danbri notifications@github.com wrote:

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


Reply to this email directly or view it on GitHub.

@dbs
Contributor
dbs commented Nov 10, 2014

@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?

@danbri
Contributor
danbri commented Nov 12, 2014

"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...

@dbs
Contributor
dbs commented Nov 12, 2014

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

+1 - let's make it so :)

@vholland
Contributor

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.

@tilid
Contributor
tilid commented Nov 14, 2014

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"
  }
  ]
 }
@danbri
Contributor
danbri commented Nov 14, 2014

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.

@Dataliberate
Contributor

b) +1

~Richard.

On 14 November 2014 16:15, danbri notifications@github.com wrote:

Summarizing some various discussions yesterday.

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 BookSeries,
VideoGameSeries, Periodical, ... 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.


Reply to this email directly or view it on GitHub
#148 (comment).

Richard Wallis
Founder, Data Liberate
http://dataliberate.com
Tel: +44 (0)7767 886 005

Linkedin: http://www.linkedin.com/in/richardwallis
Skype: richard.wallis1
Twitter: @rjw

@vholland
Contributor

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.

@danbri
Contributor
danbri commented Nov 17, 2014

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.

@danbri
Contributor
danbri commented Nov 17, 2014

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.

@danbri danbri added a commit to danbri/schemaorg that referenced this issue Nov 18, 2014
@danbri danbri Generalized Series, added VideoGameSeries.
Made some adjustments to VideoGame-related types to
reference VideoGameSeries, and small tweaks to descriptions.
schemaorg#148
2465d87
@danbri
Contributor
danbri commented Nov 18, 2014

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!

@danbri danbri added a commit to danbri/schemaorg that referenced this issue Nov 18, 2014
@danbri danbri Updated to use VideoGameSeries. 99bb5ad
@danbri
Contributor
danbri commented Nov 18, 2014

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

@RLRichardson

Dan,

Being at a disadvantage based on my limited understanding of the schema.org construct, would any of the “product properties” belong in this schema?

Rich Richardson | Vice President, Emerging Capabilities and Industries | GS1 US
1009 Lenox Drive, Suite 202, Lawrenceville, NJ 08648 | T +1 609.620.4526 | M +1 609.610.3806 | E rrichardson@gs1us.orgmailto:rrichardson@gs1us.org | www.GS1US.orghttp://www.gs1us.org/
The Global Language of Business | Making it possible for industries and companies to move their business forward

See the It's Just Commerce™ Video at http://youtu.be/pkrxhefQIBs
P Before printing, think about ENVIRONMENTAL responsibility

From: danbri [mailto:notifications@github.com]
Sent: Tuesday, November 18, 2014 11:55 AM
To: rvguha/schemaorg
Subject: Re: [schemaorg] Clarify how to represent a Series of VideoGame (#148)

Please take a look:

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

Exact changes are here: danbri@2465d87danbri@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!


Reply to this email directly or view it on GitHubhttps://github.com/rvguha/schemaorg/issues/148#issuecomment-63503463.

@danbri danbri added a commit to danbri/schemaorg that referenced this issue Nov 19, 2014
@danbri danbri Fine-grained tweaking of Series-related type/properties links.
Emphasis on domainIncludes rather than rangeIncludes, we
push media-related properties down onto TVSeries, RadioSeries,
VideoGameSeries and MovieSeries. For example, all of these
might have actor, whereas a MovieSeries doesn't usually have
episodes. Also further legacy cleanup removing redundant types.

The Series type has a new more general description.

We move Periodical under Series, and add MovieSeries and BookSeries
as placeholders.

Issue tracking:

schemaorg#148
schemaorg#169
5294ca2
@danbri
Contributor
danbri commented Nov 20, 2014

@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.

@danbri
Contributor
danbri commented Nov 20, 2014

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).

@danbri danbri closed this Nov 20, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment