Re: schema.org Roles design

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.

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

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:

{
  "@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
>

Received on Wednesday, 26 March 2014 19:16:09 UTC