Re: Schema.org Sports Vocabulary Proposal

Gregg Kellogg
gregg@greggkellogg.net

On Feb 12, 2014, at 4:54 PM, Jason Johnson (BING) <jasjoh@microsoft.com> wrote:

>  
>  
> From: Gregg Kellogg [mailto:gregg@greggkellogg.net] 
> Sent: Wednesday, February 12, 2014 4:29 PM
> To: Jason Johnson (BING)
> Cc: public-vocabs@w3.org
> Subject: Re: Schema.org Sports Vocabulary Proposal
>  
> On Feb 12, 2014, at 12:20 PM, Jason Johnson (BING) <jasjoh@microsoft.com> wrote:
> 
> 
> What are your thoughts on http://vocab.org/participation/schema as a solution to this problem?
>  
> It pretty adequately describes the important concepts, but I'm not a big fan of having reverse properties, which can be difficult to manage. Anyway, JSON-LD doesn't really require them because of the @reverse relationship type.
>  
>  
> Agreed.
> 
> Also, where do you draw the line between a relationship that should be expressed as a ‘Role’ or ‘Contribution’, and a relationship that is not?  Is the location of a restaurant the ‘location’ role of that ‘restaurant’?
>  
> I think that Role and Contribution are two different things; Role describes a specific function, and Contribution relates some entity with this role. I think it's best used for people or organizations, and not things like locations. Best modeling would relate a team to a set of member Contributions, each of which relate an individual (person or organization) with one or more roles. The tradeoff is that this introduces a layer of indirection which doesn't exist otherwise. However, you might have both "member" and "contributor" properties, so that the "member" property can directly reference the individual members irrespective of their specific contribution. Of course, this can also be inferred information.
>  
> Gregg
>  
> So something like this then?
>  
> class: Organization
>   property: hasContribution [range: Contribution]
>  
> class: Contribution
>   property: role [range: RoleType]
>   property: contributor [range: Person, Organization]
>  
> class: RoleType
>   subClassOf: Enumeration
>  hasSubClass: TeamRole
>  
> class: TeamRole
>   subClassOf: RoleType
>   hasSubClass: CoachRole
>  
> “@context”: “http://schema.org”,
> “@type”: “Organization”,
> “name”: “Seattle Seahawks”,
> “hasContribution”: {
>   “@type”: “Contribution”,
>   “role”: “http://schema.org/CoachRole”,
>   “contributor”: “Pete Carroll”
> }

Yes, but I'd be more inclined to use a sameAs relationship from a RoleType instance to, say, a Freebase URI to describe the role rather than concrete subclasses, but this is definitely a step in the right direction. Alternatively, this could be a string, but a URI would be best practice.

Gregg

> From: Gregg Kellogg [mailto:gregg@greggkellogg.net] 
> Sent: Friday, February 7, 2014 12:55 PM
> To: Dan Scott
> Cc: Jason Johnson (BING); public-vocabs@w3.org
> Subject: Re: Schema.org Sports Vocabulary Proposal
>  
> On Feb 7, 2014, at 12:06 PM, Dan Scott <dan@coffeecode.net> wrote:
> 
> 
> 
> 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.
>  
> The second works better for me. I'm thinking of a couple of scenarios:  Bo Jackson played both professional baseball and football (he also had college careers). In my Contribution style, we might have something like the following:
>  
> :KansasCityRoyals a s:SportsTeam;
>   s:member [
>     a s:Contribution;
>     s:contributor :BoJackson;
>     s:contributionType :outfielder
>   ] .
>  
> :TampaBayBuccaneers a s:SportsTeam;
>   s:member [
>     a s:Contribution;
>     s:contributor :BoJackson;
>     s:contributionType :WideReceiver
>   ] .
>  
> :BoJackson a s:SportsPlayer .
>  
> Alternatively, the same player playing multiple positions within the same game, or as player in one season and coach in another.
>  
> I don't quite understand how the first of your alternatives would express these separate roles.
> 
> 
> 
> 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?
>  
> Probably; best talk with examples, I suppose.
>  
> I'm not sure we need to specify which external enumerations to use, but I of course favor DBpedia, and Freebase. I would most likely cast my own instances, and make them equivalents of the DBpedia/Freebase identifiers:
>  
> :WideReceiver a s:SportsPosition;
>   s:title "Wide Receiver";
>   s:sameAs <http://dbpedia.org/resource/Wide_receiver> .
>  
> Gregg
> 
> 
> 
> Dan
>  
>