RE: Sports Vocabulary Proposal

> -----Original Message-----
> From: Gregg Kellogg []
> Sent: Thursday, February 6, 2014 3:00 PM
> To: Jason Johnson (BING)
> Cc:
> Subject: Re: Sports Vocabulary Proposal
> On Feb 6, 2014, at 11:56 AM, Jason Johnson (BING) <>
> wrote:
> > The partners, in collaboration with experts from the BBC and
> IPTC/SportsML, are pleased to share a proposal for improving the
> sports vocabulary.  The proposal includes support for describing
> sports organizations, athletes, and events, with a focus on the most common
> sports types being published on the Web today. Although the proposal
> includes support for describing sports statistics within these domains, the
> initial set of properties are limited to those which are broadly applicable.
> More detailed, sport-specific statistics will be the subject of future additions
> to the base statistic classes.
> >
> > The sports vocabulary proposal is available as an exported PDF
> in the W3C Web Schemas - Sports wiki and a machine readable version of the
> schema will be posted soon.  We encourage the web community to review
> and provide feedback via the wiki, this mailing list, or by joining the
> sports vocabulary discussion group.
> >
> > See Also:
> vocabulary.html
> I'm really happy to see progress in this area, as I've been working on
> something similar myself.
> Getting into some specifics:
> OrderedEvent seems like it's instituting a patter that could also be useful in
> other contexts. Perhaps something which leverages schema:ItemList, such as
> an OrderedItemList; this could use techniques from the Ordered List
> Ontology [1]. One advantage of such a vocabulary is to not require traversing
> the list through first/previous links, as they can be directly indexed. This is
> also much friendlier for doing SPARQL queries. However, this would add a
> layer of indirection. Did the group consider this type of model? Alternatively,
> makeing something like a schema:eventList property, which specifically takes
> a sub-class of rdf:List that restricts the range of rdf:first to be a schema:Event
> would work well with existing list representations (e.g., JSON-LD and RDFa),
> without requiring more "semantic overhead".
> Regarding sub-types of SportsTeam, this may be an example where some
> enumeration is more valuable. In my modeling, I defined a "sportsDiscipline"
> property with the range of SportsDiscipline. This can then allow any number
> of disciplines to be defined as instances and relate them, e.g., to
> DBpedia/Freebase URIs. For example
> :sfgiants a schema:SportsTeam
>   schema:name "San Francisco Giants";
>   schema:sportsDiscipline :MajorLeagueBaseball .
> :MajorLeagueBaseball a schema:SportsDiscipline
>   schema:sameAs <>,
> <> .
> Otherwise, trying to enumerate every possible type of sport as a distinct sub-
> class becomes futile. A sportsDiscipline can also be useful in describing player
> skills.

In an ideal world you are correct in that there would be no sub-classes of SportsTeam and enumerations would allow us to define the different types of sports teams and their respective roles (positions) at instantiation via properties like 'hasDiscipline' and 'hasRole' tied to SportsDiscipline and Role classes respectively.  Along with temporal relationships, efficiently modeling sports roles (e.g. coach and player types) were the two fundamental headaches we faced in moving forward with this proposal.  As others in this thread have indicated, those issues apply more broadly than just sports.  Rather than delay an initial proposal, we chose to sidestep those quagmires by implementing each unique role as a property and simply not supporting temporal relationships.  It's not pretty but it's simple.

> 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.

See prior comment re: 'hasRole' and 'Role'.  Again, not pretty, but simple.

> More team hierarchies: Defining something like SportsAssociation, League,
> and Division allows many team sports to be contained within an
> organizational hierarchy consistent with many amateur and professional
> sports, and allows more interesting information to be described for those
> various organizations.

I know there is precedent in, but I tend to shy away from defining sub-classes that don't add additional properties.  However, I can appreciate the desire to introduce those semantics somewhere within the definition of a sports organization.  If there is sufficient interest from the community, I'm open to introducing them.

> Other things to model in sports.
> The concept of a sports team really is something that refers to some instance
> of the organization. For example, the 1957 Giants and 2013 Giants are really
> two different teams. We defined a "Season" class for this, so that a
> SportsTeam has many seasons, and players are associated with given
> seasons. A Season is modeled as a sub-class of SportsEvent, as it has a
> beginning and end, but there may be some other kind of event which is
> more appropriate. Similarly, a Season can have series which have games, or
> may simply have games. A game is divided into periods and plays. Below this
> level, a PlayAction becomes more useful than an event, to describe some
> particular play (such as at-bat, down, or individual event).
> I'd certainly like to know if you considered modeling at such detail, and how
> this meshes with your own thoughts.

Absolutely considered the potential desire to model this.  The assumption was that folks would define these as SportEvents and leverage the name and description properties to establish the difference in semantics between a season, series, inning, etc.

This somewhat relates to prior thoughts on sub-classes. 

> > Cheers,
> >
> > Jason Johnson
> > Microsoft
> [1]

Received on Wednesday, 12 February 2014 19:51:16 UTC