Re: VideoGame proposal

Betrachte z.B. einmal die Vorgänge, die wir "Spiele" nennen. Ich meine
Brettspiele, Kartenspiele, Ballspiele, Kampfspiele, u.s.w. Was ist allen
diesen gemeinsam?– Sag nicht: "Es muß ihnen etwas gemeinsam sein, sonst
hießen sie nicht 'Spiele'"–sondern schau, ob ihnen allen etwas gemeinsam
ist.– Denn, wenn du sie anschaust, wirst du zwar nicht etwas sehen, was
allen gemeinsam wäre, aber du wirst Ähnlichkeiten, Verwandtschaften, sehen
und zwar eine ganze Reihe. Wie gesagt: denk nicht, sondern schau!

On Fri, May 16, 2014 at 2:23 PM, Aaron Bradley <aaranged@gmail.com> wrote:

> Thanks Owen - as previously indicated I'm all in favor of a Game type to
> contain such properties.  And yes, the semantics (ha) of game types can
> raise many interesting conundrums.  Is the Android game "Monopoly" still a
> board game, even though the board is virtual (and, to your comment, in
> playing either version I adopt the role of a ruthless capitalist - does
> that make "Monopoly" a role-playing game?:).
>
> Jeff, I forgot to mention:
> > 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.
>
> Yes, please do (if you don't deem the examples fully pertinent to this
> thread start a new one, or share them directly)!
>
>
> On Fri, May 16, 2014 at 11:09 AM, Owen Stephens <owen@ostephens.com>wrote:
>
>> Definitely agree on keeping the relevant properties - just think they
>> should be attached to 'game' as opposed to something more granular.
>>
>> There are games that I wouldn't regard as 'role playing' that have quests
>> (am I showing my age if I say Double Dragon? :). One can make an argument
>> that you are playing a role in such games but I don't think they'd commonly
>> be called RPGs.
>>
>> I also believe that many of the properties of video games can be applied
>> to games in general (including quests and number of players and any other
>> properties). In some cases the same game can be played as a physical or
>> video game - chess being the obvious example I guess.
>>
>> So +1 for keeping relevant properties - the proposal looked good to me
>> from that perspective.
>>
>> Owen
>>
>>
>>
>> On 16 May 2014, at 18:45, Aaron Bradley <aaranged@gmail.com> wrote:
>>
>> Thanks Jeff and Martin.
>>
>> Jeff > 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.
>>
>> Martin > Video game is definitely a class that should be in schema.org,
>> whereas for http://www.productontology.org/doc/Action_role-playing_game,
>> I think an external mechanism is a better place.
>>
>> What you say makes sense Martin.  And that'd fine if, as per your comment
>> Jeff, those "associated properties to describe a game" include those
>> currently proposed under RolePlayingGame.
>>
>> That is, the properties of the proposed RolePlayingGame type are (with
>> the possible exception of quest) useful in describing video games of all
>> sorts (especially min/maxNumberOfPlayer and statistic).  These properties
>> have equal utility whether they're included in the more general
>> CreativeWork Game type that's been discussed, and so inherited by
>> VideoGame, or whether they're included in the VideoGame type itself:  I'd
>> just be loathe to see these important video game properties disappear from
>> schema.org proper in the course of finessing VideoGame.
>>
>> FWIW, in describing the *type* of a video game, I'd be far more likely
>> to employ the now-available CreativeWork property genre rather than declare
>> an specific game type described by a productontology.org URI, except in
>> the case of declaring it a Product.
>>
>> I think another CreativeWork, Book, is a good example.
>>
>> An ebook is a *type *of book (in the physical sense), and is declared
>> using the enumeration value EBook for the BookFormatType value of the
>> bookFormat property of Book.
>> A novel is a *genre *of book, and would be probably be declared using
>> the genre property of CreativeWork.
>>
>> A mobile video game is a *type *of game (in the physical sense), and
>> might be declared either as more specific type of VideoGame, or using some
>> sort of enumeration.
>> A role playing game is a *genre* of game, and would probably best be
>> declared using the genre property of CreativeWork (or an enumeration like
>> VideoGameGenre, which is what Freebase does (
>> http://www.freebase.com/cvg/cvg_genre).
>>
>> This mostly in passing though: as long as core "game" properties
>> currently contained in the RolePlayingGame proposal become available in
>> schema.org, the needs of video game industry webmasters will be served
>> IMO. :)
>>
>>
>>
>> On Fri, May 16, 2014 at 1:22 AM, martin.hepp@ebusiness-unibw.org <
>> martin.hepp@ebusiness-unibw.org> wrote:
>>
>>> Hi Aaraon:
>>>
>>> On 15 May 2014, at 21:24, Aaron Bradley <aaranged@gmail.com> wrote:
>>>
>>> > While I understand the rationale behind using productontology.orgURIs 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).
>>> 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 schema.org - 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 schema.org, whereas
>>> for http://www.productontology.org/doc/Action_role-playing_game, I
>>> think an external mechanism is a better place.
>>>
>>> Martin
>>>
>>>
>>
>