Re: schema.org Roles design

See comments inline


On Wed, Mar 26, 2014 at 12:15 PM, Gregg Kellogg <gregg@greggkellogg.net>wrote:

> On Mar 26, 2014, at 9:37 AM, Dan Brickley <danbri@google.com> wrote:
>
> > At schema.org we have been working on a design for describing roles
> > and contributions.
> >
> > I've just posted a discussion draft in the WebSchemas wiki. Please take
> a look:
> >
> > Roles in Schema.org
> > https://www.w3.org/wiki/WebSchemas/RolesPattern ->
> > https://www.w3.org/wiki/images/b/b5/RolesinSchema.org.pdf
>
> Some comments on the draft:
>
> I think this is a really useful abstraction, but I do see some room for
> improvement.
>
> I think adding date ranges to the role is conflating the role with an
> event. Better to say that the Joe Montana is the quarterback during the
> 1992 season of the 49ers by defining an event for the 1992 season. Jason
> and Jean-Pierre made similar points, and I think that models better.
>
> One could look at anything with a temporal extent (including a
proposition) as an event. It is not clear that buys us much. In fact,
experience with Cyc shows that this can be confusing.  If you want, you can
look at Role as a subclass of Event.


> A Role seems to use different properties to describe the kind of role
> ("position", "characterName", "graduationYear"). It might be possible to
> simply subclass Role so that it's known the kind of role that's being
> played, but a single property which defines this (ideally an entity, but
> allowing a string) would be less ambiguous and would avoid falling into the
> trap of not having considered all of the kinds of roles played. Similarly,
> settling on a single property to reference the "agent" performing the role
> might be better than using arbitrary properties from different classes
> depending on where the role is referenced from. (In fact, you reference the
> same role from different entities, so context can't really be used either).
>
> We don't want to be at either extreme. We don't want overly general slots
like 'agent, 'performer' and 'object' as the only slots. Similarly, we
don't want slots like quarterback, runningback, etc.


> The schema for hasRole has domainIncludes and rangeIncludes reversed.
>
> In the appendix, you site the use of @context as a (temporary) means of
> describing the range of hasRole to be an entity, not a literal. You could
> eliminate the context by using an expanded form:
>
> {
>   "@context": "http://schema.org/",
>   "@type": "Movie",
>   "name": "Ghostbusters", "hasRole": {
>     "@type": "MovieRole",
>     "@id": "movierole_678",
>     "characterName": "Dr. Peter Venkman",
>     "actor": {
>       "@type": "Person",
>       "name": "Bill Murray",
>       "hasRole": {"@id": "movierole_678"}
>     }
>   }
> }
>
> But, I prefer to use a different property, as "hasRole" does not seem to
> me to be symetric. Better than defining inverses of every property is to
> define an inverse alias in the (forthcoming) context. For example:
>
>
Agree.


> {
>   "@context": ["http://schema.org/", {
>     "inRole": {"@reverse": "hasRole"}
>   },
>   "@type": "Movie",
>   "name": "Ghostbusters", "hasRole": {
>     "@type": "MovieRole",
>     "@id": "movierole_678",
>     "characterName": "Dr. Peter Venkman",
>     "actor": {
>       "@type": "Person",
>       "name": "Bill Murray",
>       "inRole": "movierole_678"
>     }
>   }
> }
>
> This uses the same property "hasRole", but defines a reverse term which
> will expand, flatten or transform to RDF using the inRole property.
>
> Great to see progress on this issue!
>
> Gregg
>
> >> From the wiki, "For example, when we say that a Person was an actor in
> > a Movie, we might want to mention their characterName too. When we say
> > that a SportsTeam has a Person as an athlete, we might want to mention
> > the position that they play, or the time period in which they
> > fulfilled that role.".
> >
> > I freely acknowledge that PDF isn't the best way to share markup/code
> > snippets and will copy those into Wiki. However we wanted to get the
> > draft out asap.
> >
> > Here's a quick example extracted from the doc, expressed in JSON-LD.
> > We want to elaborate on a basic description, so here is the mostasic
> > version first, followed by the Role-based richer version:
> >
> > {
> > "@context": "http://schema.org/",
> > "@type": "AmericanFootballTeam",
> > "name": "San Francisco 49ers",
> > "athlete": {
> >   "@type": "Person",
> >   "name": "Joe Montana"
> > }
> > }
> >
> > Extended version using Role:
> >
> > {
> >   "@context": "http://schema.org/",
> >   "@type": "AmericanFootballTeam",
> >   "name": "San Francisco 49ers",
> >   "hasRole": {
> >       "@type": "AmericanFootballRole",
> >       "@id": "role321",
> >       "startDate": "1979",
> >       "endDate": "1992",
> >       "position": "Quarterback",
> >       "athlete": {
> >               "@type": "Person",
> >               "name": "Joe Montana",
> >               "hasRole": "role321"
> >       }
> >   }
> > }
> >
> > Effectively we interpose a new node in the graph. Instead of
> >
> > SanFrancisco49ers ---athlete---> JoeMontana
> >
> > We have
> >
> > SanFrancisco49ers --hasRole---> [role321] --athlete---> JoeMontana.
> >
> > There are a few nearby designs that may be worth discussion here. If
> > we wanted to make things simpler for publishers, we could remove the
> > hasRole reference from JoeMontana back to the Role. However this also
> > makes it harder for consuming applications to understand Role-based
> > modeling across all domains. Another approach would be to use
> > different property names for relating the 'subject' and 'predicate'
> > entities. The appendix in the full proposal document elaborates on
> > some of these options. I should also note for those of you using the
> > JSON-LD playground or other generic tools that the above markup needs
> > some tweaks, since schema.org doesn't yet publish a @context file.
> > Again, the document has details of a workaround.
> >
> > Please take a look. This is quite an important spec for schema.org as
> > it has impact across all domains, so it is important to find the right
> > balance between ease of adoption for publishers, expressivity, ease of
> > processing etc.
> >
> > cheers,
> >
> > Dan
> >
>
>
>