Re: Sports Vocabulary Proposal

On Fri, Feb 7, 2014 at 1:22 PM, Gregg Kellogg <>wrote:

> On Feb 6, 2014, at 7:17 PM, Dan Scott <> wrote:
> On Thu, Feb 6, 2014 at 5:59 PM, Gregg Kellogg <>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 (
>, 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

Person -> Contributor -> SportsPlayer

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

* all Contributor properties +
* hasStatistics [Statistics]

- 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

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

* all Contributor properties +
* hasStatistics [Statistics]

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

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


Received on Friday, 7 February 2014 20:07:00 UTC