Monday, June 16, 2014

Introducing 'Role'

To date, has supported relatively simple relations between entities.  For example, if we wanted to describe Joe Montana as an athlete on the San Francisco 49ers team, we might represent this using the newly proposed "athlete" property of a SportsTeam. 

This is a pretty clear structure, but it doesn't offer anywhere to attach further information about the relationship.  Building on our example, let's say we wanted to also indicate that Joe Montana only played for the San Francisco 49ers from 1979 to 1992 and that his position was "Quarterback".

To accomplish this, we introduce a new type called Role.  The new Role type serves to elaborate or qualify these more simple relationships. We have been motivated by concrete problems around organizational affiliations such as those occurring in music and sports. In both cases it is important to specify time periods in a sporting or musical career.

To specify the role being played, the Role entity reuses the initial property from, and then extends the semantics of the relationship by way of additional properties like "startDate".

In essence, we are replacing the "athlete" property's original value (a Person node) with an intermediary node (Role). The original node is moved one hop away and becomes the value of the re-used "athlete" property. After considering several designs, we chose this approach as the simplest.

The Role schema allows algorithms to collapse down to the simple graph from a more complicated Role-based description. In the example above, we can assume Joe Montana is a valid value for the "athlete" property on the 49ers SportsTeam. More formally, if some Role R has incoming property P from entity A, and A also has an outgoing occurrence of property P to entity B, we can assume it is reasonable to describe A as having a 'P' property whose value is B.

These details are more important to consumers of than publishers, as they allow for backwards compatibility, while also permitting any property to be used with roles.

The Role type (much like URL) can be used with any types. We will not clutter the site with statements emphasizing this, except in cases (e.g. around sports and music) where the Role mechanism is particularly useful. We have added examples of Role usage in Microdata, RDFa and JSON-LD notation to the site, and look forward to seeing more detailed descriptions using this mechanism.

As we continue to evolve the site we expect to add more properties and sub-types that have been designed to work with the Role type. For now, we introduce two kinds of Role: OrganizationRole and PerformanceRole. In the sporting example shown above, the Role node (the red circle) would be an OrganizationRole and in addition to defining the "startDate" and "endDate" for that role, we might also define indicate Joe Montana was a quarterback by using the "namesPosition" property. Similarly, the PerformanceRole type provides a characterName property that might be used to describe Bill Murray's role in Ghostbusters. The Role pattern works here too. See the site for full RDFa, Microdata and JSON-LD markup, including the Ghostbusters example shown here:

Vicki Tardif Holland (Google)
Jason Johnson (Microsoft)