Re: VideoGame proposal

Thanks Jeff.  Just quickly you reminded me that I forgot, in my previous
message, that it's probably worthwhile to consider the implications of the
new types in the context of schema.org/PlayAction to see if there's any
connections we should be drawing.  This came to mind in your discussion of
Steam/BattleNet (analogous in the EA environment to Origin). One way or
another I like where you're going with this Jeff (and I'll note that the
inherited PlayAction property agent does indeed use Person).

While I understand the rationale behind using productontology.org 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 productontology.org URIs for something like the proposed
platform property will ever remain potential because hardly anyone will
employ it.  schema.org'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 productontology.org
).



On Thu, May 15, 2014 at 11:39 AM, Jeff Mixter <jeffmixter@gmail.com> wrote:

> I think the proposal for exploring video game modeling in Schema.org is
> very interesting and could have very significant implications.  As Dan and
> others pointed out, there seems to be some good general properties that
> could be applied to higher level Classes (such as Thing).  As Aaron also
> pointed out, there might be some subjective issues in classifying very
> granular types of video games (such as Role Playing).  I do think that
> granular classes are important but it might be better to defer to something
> like Product Type Ontology for this. For example one could use a generic
> schema:VideoGame class and associated properties to describe a game and add
> an additional rdf type of
> http://www.productontology.org/id/Role-playing_video_game. The problem
> with this approach would obviously be if there are specific properties that
> are unique to a certain sub-class of video games.  I think that mocking up
> enough use cases could help sort out some of these issues.
>
> An aspect that I have been exploring/thinking about that was not directly
> addressed in this proposal was modeling the management of video game.  This
> could allow video game producers and more importantly service
> supporters/content providres (such as Steam or BattleNet) to manage users
> and the relationships they have across games.  For example Steam acts as a
> universal online platform for disseminating games and Steam users have
> usernames that are linked to their Steam accounts.  There are though some
> games (available through Steam) that require separate accounts to be
> created for online play.  It would be very interesting if there were a way
> connect users (arguably schema:Person instances) across games and service
> providers.  I have thought a bit about this and it could be done using
> primarily existing classes/properties.  If there is interest, I could mock
> up a few examples and send them out.
>
> This topic is very interesting to me and if there is continued interests
> in the modeling of video games, I would jump at the opportunity to
> contribute either ideas of data examples.
>
> Thanks,
>
> Jeff Mixter
> 440-773-9079
> mixterjeff@gmail.com
>
>
> On Thu, May 15, 2014 at 1:38 PM, Aaron Bradley <aaranged@gmail.com> wrote:
>
>> Thanks for this Yuliya, and for your thoughtful feedback Dan and Owen.
>>  Some intial thoughts...
>>
>> Does it makes sense also to have MobileGame, as a more specific type of
>> MobileApplication - the properties of which it would inherit?  Aside from
>> that property inheritance, mobile games bear the same relationship to video
>> games as mobile applications do to software applications, so it makes sense
>> IMO to carry over that logic (e.g. [1]).
>>
>> OnlineGame is, I think, a little problematic insofar as the bulk of
>> packaged video games published these days have online components to them.
>>  For example, Battlefield 4 [2] would be classified as a VideoGame if
>> played offline, in single-player mode, but would be classfied as an
>> OnlineGame if played in online mode.  I'd opt for simply rolling those
>> OnlineGame properties into VideoGame.
>>
>> In the spirit of both those comments and following the *Application path,
>> if one were to drop OnlineGame because its mode-dependent, might one wish
>> to instead to have WebGame, which is a game specifically played on a
>> browser and - like WebApplication, often has specific requirements, like
>> Flash support, or use of a specific browser [3].
>>
>> +1 to all of Dan's comments.  In particular, I like the idea of making
>> "playModes" (or "playMode") an enumeration.  And yes, "playersNumber" is
>> ambiguous and would almost certainly end up being confused by some with
>> max/minNumberOfPlayer:  either of Dan's suggestions are preferable.
>>
>> Big +1 to Owen's suggestion to reconstitute "RolePlayingGame" simply as
>> "Game".  On one hand what does and doesn't qualify as a "role playing" game
>> is a highly subjective judgement.  On the other hand, as Owen points out,
>> some of the proposed properties are applicable to broader categories of
>> games, which would also make this type more broadly useful.
>>
>> As this proposal for VideoGame just barely forestalls my own (which, in
>> light of this excellent work by Yandex, won't be forthcoming:), I can
>> confirm that Electronic Arts - one of the world's largest video game
>> publishers - enthusiastically supports this proposal.
>>
>> Aaron Bradley
>> SEO Analyst, Electronic Arts
>>
>> [1]
>> https://play.google.com/store/apps/details?id=com.ea.game.simpsons4_na
>> [2] http://www.battlefield.com/battlefield-4
>> [3] http://chrome.angrybirds.com/
>>
>>
>>
>> On Thu, May 15, 2014 at 9:36 AM, Owen Stephens <owen@ostephens.com>wrote:
>>
>>> RolePlayingGame seems specific while at least some of the properties
>>> (min/max players at the very least) seem common to other types of game.
>>> Would it make more sense to simply have /Game as a creative work?
>>>
>>>  Owen Stephens
>>> Owen Stephens Consulting
>>> Web: http://www.ostephens.com
>>> Email: owen@ostephens.com
>>> Telephone: 0121 288 6936
>>>
>>> On 15 May 2014, at 11:48, Yuliya Tikhokhod <tilid@yandex-team.ru> wrote:
>>>
>>> This is proposal from Yandex (one of the schema.org sponsors).
>>>
>>> There are many sites dedicated to games (for example,
>>> http://store.steampowered.com/app/244850/,
>>> http://www.gamespot.com/eve-online/,
>>> https://play.google.com/store/apps/details?id=com.zeptolab.ctr2.f2p.google).
>>> They contain some specific information, for which we have no specific
>>> classes and properties in schema.org.
>>>
>>> We made separate class for game as a creative work (with  complicated
>>> rules, characters, narrative). And called it RolePlayingGame. Maybe this is
>>> not a very good name and we will be thankful if you suggest better name for
>>> class describing games with complicated rules, fictional characters and
>>> specific locations.
>>> Then VideoGame class is a child of two parents -  RolePlayingGame and
>>> SoftwareApplication.
>>>
>>> We also added some additional properties to SoftwareApplication class.
>>>
>>> This is test build of schema.org with this proposal
>>> http://sdo-yavg.appspot.com/VideoGame
>>> http://sdo-yavg.appspot.com/RolePlayingGame
>>> http://sdo-yavg.appspot.com/OnlineGame
>>> http://sdo-yavg.appspot.com/SoftwareApplication
>>>
>>> In attachment you can find pdf version of this proposal
>>>
>>> --
>>> Yuliya Tikhokhod
>>>
>>> Yandex
>>>
>>> <VideoGame.pdf>
>>>
>>>
>>>
>>
>
>
> --
> Jeff Mixter
> jeffmixter@gmail.com
> 440-773-9079
>

Received on Thursday, 15 May 2014 19:24:52 UTC