Re: Schema.org Sports Vocabulary Proposal

On Fri, Feb 7, 2014 at 1:22 PM, Gregg Kellogg <gregg@greggkellogg.net>wrote:

> On Feb 6, 2014, at 7:17 PM, Dan Scott <dan@coffeecode.net> wrote:
>
> On Thu, Feb 6, 2014 at 5:59 PM, Gregg Kellogg <gregg@greggkellogg.net>wrote:
>
> <snip>
>
> The teamSpecificRoles also seem a bit narrow, and people may play multiple
>> roles. Roles might better be modeled with something like a "Contribution"
>> class; we discussed this for the TV and Radio updates, although nothing
>> much came about from it. A person may contribute to a sports team using
>> multiple roles. This also allows modeling finer grained sports activities
>> such as a season, series, game, period, or individual play. The roles can
>> then be defined using an enumeration class similarly to sports disciplines.
>> Per-sport role properties are simpler, but also suffer from the cost of
>> adding them specifically to the vocabulary rather than allowing the use of
>> external enumerations.
>>
>
> This is also an issue in the latest draft of the Comics proposal that I'm
> working on; once we can base it on Periodicals, most of the remaining new
> properties are roles like artist, colorist, inker, letterer, penciler...
> but defining all of the potential contribution roles for every other
> potential domain seems like it is at best a duplicative effort of work that
> has been done elsewhere.I mentioned a potential approach back in September,
> and Niklas replied with an alternative (
> http://lists.w3.org/Archives/Public/public-vocabs/2013Sep/0190.html), but
> the discussion fizzled out at that point.
>
> Thinking about it further, having a Contributor type that extends Person
> by adding a "contributionType" property, which in turn points at an
> external enumeration (falling back to a literal value, of course) might
> suffice. For the sports context, SportsPlayer could then extend Contributor
> and add in the "hasStatistics" property so that that property doesn't have
> to be defined at the Person level.
>
>
> I don't follow how a contributionType helps, as you can't relate a
> Contributor's association with a SportsTeam or Event with the type of
> contribution without using an intermediate object.
>
>
So, umm... yes? Maybe we're talking past each other here. Here's what I was
thinking:

Person -> Contributor -> SportsPlayer

Contributor:
* all Person properties +
* contributionType - [Text, external_enumeration]

SportsPlayer:
* all Contributor properties +
* hasStatistics [Statistics]

SportsTeam:
- Instead of minting a ton of <teamSpecificRoleX> properties, offers:
* hasContributor [Contributor] - so the contribution type(s) is defined on
the SportsPlayer

Alternately, if we wanted to separate the Person from the roles they play
on any given team, it could be:

Contributor -> SportsPlayer

Contributor:
* hasPerson [Person]
* contributionType [Text, external_enumeration]

SportsPlayer:
* all Contributor properties +
* hasStatistics [Statistics]

... where the Person is encapsulated within the Contributor/SportsPlayer
types.


> At the most specific level of an individual play, I modeled this using
> PlayAction, which acts something like a Contributor as well, as you can
> separately relate event, agent and participant. It does require another way
> to describe the kind of play, but this could presumably be done with an
> additionalType and an enumeration object. Using ExcerciseAction provides
> more useful properties, but the name's not really appropriate for this.
> Perhaps if something like SportingAction were introduced between PlayAction
> and ExerciseAction having most of the properties from ExerciseAction, this
> would solve the problem. We could then add a sportsPlayType to reference an
> entity describing the type of play, also falling back to a literal. For
> example, "hit", "goal", "fumble", ...
>
> Perhaps it's worthwhile taking another kick at this? As Aaron Bradley has
> mentioned (https://plus.google.com/106943062990152739506/posts/VTdFR5R2PMs)
> if we go with external enumerations, providing some clear direction on
> which enumerations are acceptable will be important to implementers (I
> think the use of GoodRelations / ProductOntology for external enumerations
> set a nice example here). As for which external enumerations to use, I'm
> open to suggestions; the LC relators (
> http://id.loc.gov/vocabulary/relators.html) offer a decent start, but
> while they hit some of the radio, TV, and movie roles, they're certainly
> not exhaustive; they don't cover all of the roles in the Comics realm; and
> they don't even touch the sports realm.
>
>
> External enumerations should really be used more than schema-specific
> types for things like this, as it removes unnecessary central control for
> such concepts.
>

I believe we're in violent agreement on this point (along with many
others). The questions are: which external enumerations do we use, and how
do we surface those in a friendly guiding manner to practitioners?

Dan