RE: schema.org Roles design

Hello Dan,

I agree it is important and also not easy to solve as the problem is more complex that it seems. I actually came across a similar issue in a different context.

a) The current proposal says that each role within a team is being held for a period of time by an athlete - fine.

b) But a role could also be the role within a team during an event (in soccer or rugby roles can change) for which the use of a time period is possible but probably not best.

c) A role could also associated with an individual during a period of life or an event if not different roles associated with different sub-events of the same event.

I would think the proposal below covers a), possibly b) but not super elegant and not c).

Best, Jean-Pierre

-----Original Message-----
From: Dan Brickley [mailto:danbri@google.com] 
Sent: mercredi, 26. mars 2014 17:38
To: W3C Web Schemas Task Force
Subject: schema.org Roles design

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


>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

------------------------------------------------------------------------------

**************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error, please notify the system manager. This footnote also confirms that this email message has been swept by the mailgateway
**************************************************

Received on Wednesday, 26 March 2014 16:57:57 UTC