Re: Finalizing Schema.org "Roles" design

I think that

1. the sponsors of schema.org should clearly say that the Roles proposal is just for cases that do not fit in the straightforward patterns and

2. the Google Structured Data Testing Tool should have a rule that warns if Roles nodes are used additional properties (like startDate or endDate), i.e. if the reification is useless.

On the other hand, it should be relatively easy for consumers of data to translate such simple cases (an unconstrained role) to the direct pattern.

One thing I do not understand from the proposal is whether the additional properties like startDate and endDate will be added to http://schema.org/Role or whether the idea is that arbitrary local property names can be used.

Martin


On 08 May 2014, at 21:20, Jarno van Driel <jarnovandriel@gmail.com> wrote:

> I like it but was wondering what you think chances are people will abuse it to express for example:
> 
> { 
>     "@context": "http://schema.org", 
>      "@type": "Role", 
>      "roleSubject": {  
>             "@type": "Product", 
>             "name": "Explosive tennis balls" 
>      }, 
>      "roleProperty": { 
>          "http://schema.org/seller" 
>     }, 
>     "roleObject": { 
>         "@type": "Store", 
>         "name": "Acme inc." 
>     } 
> }
> 
> as opposed to:
> 
> <div vocab="http://schema.org" typeof="Product">
>     <span property="name">Explosive tennis balls</span>
> 
>     <span property="offers" typeof="Offer">
>         <span property="seller" typeof="Store">
>             <span property="name">Acme inc.</span>
>         </span>
>     </span>
> </div>
> 
> Because it's one of the first things that came to mind when I tried to imagine how people might use this in ways outside the scope of the proposal. Now I like the idea of @roleProperty being an URL because it's easy to use but also wonder if it doesn't run the risk of being used to create 'triples' in ways that go against already established constructs.
> 
> And I also wonder, can @roleProperty be an URL to a property of another vocab as well?
> 
> 
> 2014-05-08 18:58 GMT+02:00 Dan Brickley <danbri@google.com>:
> I've just updated https://www.w3.org/wiki/WebSchemas/RolesPattern with
> a link to a 'final draft' PDF of the schema.org "Roles" design. The
> main examples are also lifted into the Wiki page and copied below;
> there's also a link to the original google doc url, for those who
> prefer to comment that way.
> 
> 
> For a motivating example, when we say that a Person was anactor 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.
> 
> The basic approach should be clear from the examples. It is similar to
> classic W3C RDF "reification", in that it takes a
> property/relationship and treats that as a thing (a "Role", in our
> terminology) that can be further described and annotated.
> 
> Here is an example sports-related description:
> 
> {
>     "@context": "http://schema.org/",
>      "@type": "AmericanFootballRole",
>      "roleSubject": {
>             "@type": "AmericanFootballTeam",
>             "name": "San Francisco 49ers"
>      },
>      "roleProperty": {
>          "http://schema.org/athlete"
>     },
>     "roleObject": {
>         "@type": "Person",
>         "name": "Joe Montana"
>     },
>     "startDate": "1979",
>     "endDate": "1992",
>     "position": "Quarterback"
> }
> 
> Here is a movie:
> 
> {
>     "@context": "http://schema.org/",
>      "@type": "MovieRole",
>      "roleSubject": {
>             "@type": "Movie",
>             "name": "GhostBusters"
>      },
>      "roleProperty": {
>          "http://schema.org/actor"
>     },
>     "roleObject": {
>         "@type": "Person",
>         "name": "Bill Murray"
>     },
>     "characterName": "Dr. Peter Venkman"
> }
> 
> 
> This approach differs from the original draft (circulated at
> http://lists.w3.org/Archives/Public/public-vocabs/2014Mar/0111.html),
> based on feedback and discussion here on the earlier approach. This
> time we think we're done, but as always welcome comments and alternate
> perspectives.
> 
> cheers,
> 
> Dan
> 
>

Received on Thursday, 8 May 2014 19:35:59 UTC