Re: VideoGame proposal

Revisions look good - I've a couple of further thoughts upon reviewing the
proposal again.

*1.  Video game series*

The proposal lacks any mechanism for declaring a video game to be part of a

I think this is an important concept to address, as many video games - and
especially the most popular, mass-market video games - exist as series.
 Individual video games belonging to that series continue to be release
after the introduction of the original title in that series, sometimes
spanning decades.

For example, "Battlefield 3" is a video game in the series "Battlefield".
 Without a distinction between a game and series to which it belong, a
publisher could declare this to be a VideoGame:

But without a video game series type for:
... the publisher could only unhelpfully declare this as something like
WebPage, or ambiguously declare it to be a VideoGame - which it is not,
because while you can play "Battlefield 3" you can't play "Battlefield"
(the first game in the franchise was "Battlefield 1942").

This is precisely how Freebase handles video games:
Battlefield 3 = "Video Game"
Battlefield = "Video Game Series"



Suggested added type:
Thing > Creative Work > Series > VideoGameSeries

Properties from VideoGameSeries

property:  videoGame
Expected type:  VideoGame
Description:  A game in a video game series.


Suggested added property for:
Thing > Creative Work > Game > VideoGame

property:  partOfSeries
Expected type:  Series
Description [revision of existing]:  The series to which this video game,
episode or season belongs.


Note that it might appear as though the softwareVersion property could be
used to declare the specific version of a game, but it cannot for a couple
of reasons.

"Battlefield 3" is a video game title in the video game series
"Battlefield", rather than a softwareVersion of the SoftwareApplication
"Battlefield".  The software in question here is "Battlefield 3", which can
have its own versions.

As well, video games within a series often have their own names, and this
additional types and additional properties provide a way of binding the two.


<div itemscope itemtype="">
<h1 itemprop="name">Plants Vs. Zombies Garden Warfare</h1>
The latest <span itemprop="partOfSeries" itemscope
itemtype=""><span itemprop="name">Plants
Vs. Zombies</span></span> game!

*2.  Video game trailers*

As a more specific type of Series, VideoGameSeries would also be able to
use the series property "trailer".

Video game trailers are among the most consumed and searched-for media
associated with video games.  While being able to use this for
VideoGameSeries would be good, it's actually a property far more useful for
VideoGame itself.  Just as TVEpisode has this as a property in addition to
TVSeries, so I think it should fall under VideoGame.


Suggested added property for:
Thing > Creative Work > Game > VideoGame

property:  trailer
Expected type:  VideoObject
Description [revision of existing]:  The trailer of a movie, video game or
tv/radio series, season, or episode.

Aaron Bradley
SEO Analyst, Electronic Arts

On Thu, Jun 12, 2014 at 7:54 AM, Yuliya Tikhokhod <>

> This is new version of proposal with some minor changes
> (statistic->characterAttribute) and additional examples
> 24.05.2014, 01:37, "Jeff Mixter" <>:
> I think that the changes help a lot.  The overall structure seems to be
> more lightweight and fit within the current paradigm.  It
> seems like one property that is missing is rating. If we do not want to get
> embroiled in picking and choosing properties that relate to specific
> standards, as I think Guha alluded to previously, I would suggest that you
> use the existing schema:contentRating <>
> property.  As is listed in the example, people can then list the rating
> system as well as the rating for example "ERSB T"
> I still think it would be interesting to find a lightweight way, using
> existing classes and properties, to connect users, the games
> they play and the servers/services that they use.  Again, I think this can
> probably be done with the existing vocabulary so it certainly
> does not need to be included in any proposal but it might be worthwhile
> drafting up as a sort of cookbook for describing video games.
> Jeff
> On Fri, May 23, 2014 at 12:20 PM, Guha <> wrote:
> If there is a very wide usage of a particular external standard, then of
> course, it makes sense for to refer to that standard. Note
> that I say 'wide usage' not 'consensus' (among vocabulary creators).
> The cost of bouncing webmasters between different namespaces is just too
> high.
> Guha
> On Fri, May 16, 2014 at 1:22 AM, <
>> wrote:
> Hi Aaraon:
> On 15 May 2014, at 21:24, Aaron Bradley <> wrote:
> > While I understand the rationale behind using URIs
> I come down squarely against relying upon them in any situation where the
> class and/or properties in question are likely to be widely used by a large
> number of webmasters.  I feel confident in saying that potential benefits
> of employing URIs for something like the proposed
> platform property will ever remain potential because hardly anyone will
> employ it.'s better-than-anticipated success has been
> predicated not only because it's easy to employ, but on the fact that it's
> self-contained.  IMO, every time we punt to an external vocabulary we're
> shooting ourselves in the foot:  I can't stress this enough (and I welcome
> Martin Hepp's input on this, both because I know he's had something to say
> about this recently in the context of his generic property/value pair
> proposal and, of course, because of his experience with
> My point on mechanisms for externalizing or deferring consensus is as
> follows:
> 1. When there exists consensus in an external standard, it is better to
> refer to that standard than to incorporate it into - e.g.
> currency codes, GPC classes, most enumerations.
> 2. When site owners are not able to easily link their data to a more
> standardized representation, it is better to allow them publishing as much
> "lightweight" semantics as possible than making it too costly for them to
> publish any data.
> Video game is definitely a class that should be in, whereas
> for, I think
> an external mechanism is a better place.
> Martin
> --
> Jeff Mixter
> 440-773-9079
> --
> Юля Тихоход

Received on Thursday, 12 June 2014 20:39:19 UTC