W3C home > Mailing lists > Public > public-vocabs@w3.org > March 2014

Re: schema.org Roles design

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Wed, 26 Mar 2014 17:29:46 -0700
Cc: Aaron Bradley <aaranged@gmail.com>, Jarno van Driel <jarno@quantumspork.nl>, Jason Douglas <jasondouglas@google.com>, Guha <guha@google.com>, W3C Web Schemas Task Force <public-vocabs@w3.org>
Message-Id: <A7E62544-4F06-4A7D-B1CF-BE603E86BF6A@greggkellogg.net>
To: Dan Brickley <danbri@google.com>
On Mar 26, 2014, at 3:22 PM, Dan Brickley <danbri@google.com> wrote:

> On 26 March 2014 21:55, Aaron Bradley <aaranged@gmail.com> wrote:
>> I'm baffled by @id as well.  Forget the RDFa/microdata/JSON-LD syntax
>> differences for a moment, I've read the proposal but still don't know from
>> whence the the @id values arise.
>> 
>> In the PDF where does...
>> @id "role321" come from? (e.g.1)
>> @id "movierole_678" come from? (e.g. 2)
>> @id "edurole25151" come from? (e.g. 3)
>> 
>> Are these arbitrarily assigned by the coder?  Are these serial?  And are
>> they resolvable to an IRI?
>> 
>> And are they integral to the Role/hasRole proposal - that is, does
>> everything break if they're not employed?  Am I correct in reading @ID in
>> e.g. 1 ("role321") is the necessary entity referred to in order to have the
>> "athlete property applied to the Role, instead of to a Team"?
> 
> They're arbitrary (in this example anyway), and serve only to allow a
> reference from a subtree of the json markup back to something
> described 'higher up'.
> Nothing stops them being more widely used IDs, or randomly generated.
> As you say it is all about tying together the entity references.
> 
> I believe it can also be achieved with a @reverse. But I tried and I
> figured it was more confusing to introduce the idea at this stage. I
> am also not expert in all the representational subtleties of JSON-LD,
> so I went for something 'simple' to start with. It may be we can find
> a cleaner alternative.

@reverse is best used in a term definition for the opposite of a property which is generally one directional. For example reverse of parent could be isParentOf, reverse of review could be isReviewedIn. This avoid what I consider to be an anti-pattern of defining an inverse property for each property as a first class citizen in the vocabulary definition. But not best for the primary modeling of a representation.

> Here is as far as I got with removing the need for an @id on the
> MovieRole so that an inRole property of the Bill Murray Person could
> point to the Role:
> 
> 1. We imagine inRole as a link from a Thing (e.g. Person) *to* the Role.
> 2. We define a @reverse of that called roleIn (an ad hoc name, but
> just testing here).
> 3. We replace write "roleIn" where "actor" was previously.
> 4. Yes, we now have a problem for how to represent the "actor"
> relationship. Possibly JSON-LD has a way.
> 
> {
>    "@context": [
>        "http://schema.org/",
>        {
>            "roleIn": {
>              "@reverse":"http://schema.org/inRole"
>            }
>        }
>    ],
>    "@type": "Movie",
>    "name": "Ghostbusters",
>    "hasRole": {
>        "@type": "MovieRole",
>        "characterName": "Dr. Peter Venkman",
>        "roleIn": {
>            "@type": "Person",
>            "name": "Bill Murray"
>        }
>    }
> }

This markup does what you want, and in Turtle might look like the following:

[ a :Movie; :name "GhostBusters"; hasRole _:role ] .
_:role a :MovieRole; :characterName "Dr. Peter Venkman" .
[a :Person; :name "Bill Murray"; :roleIn _:role ].

I'm just not sure we want to rely on reversed properties for an important relationship.

IMO, the problem with this is that there's no way to define the chained relationships without relying upon this reversal. I think it's great to say the Bill Murray appears in a role when I'm primarily talking about Bill Murray. But, when I'm talking about a role in a movie, I want to reference the person directly from the role. The advantage of using something like an "actor" relationship (in the generic meaning of actor), is that it can preserve that natural linking:

[
  a :Movie;
  :name "GhostBusters";
  :hasRole [
    a :MovieRole;
    :characterName "Dr. Peter Venkman";
    :actor [
      a :Person;
      :name "Bill Murray"
    ]
  ]
] .

> I'll look into markup examples (rdfa/microdata) tomorrow. If there is
> a way in JSON-LD to give a list of properties between two entities
> this would be simpler (Gregg?). For e.g. I think in RDF we can just
> write something like,
> 
> <span ...ghostbusters here
> <span property="actor roleIn">
>   <span ...billmurray here">
> 
> or
> 
> <span ...ghostbusters here
> <span property="actor" rev="inRole">
>   <span ...billmurray here

Well, this is getting pretty confusing! But, if you wanted to use the hasRole/inRole mechanism in RDFa, it might look like the following:

<div vocab="http://schema.org/" typeof="Movie">
  <span property="name">Ghostbusters</span>
  <div property="hasRole" typeof="MovieRole">
    <span property="characterName">Dr. Peter Venkman</span>
    <div rev="inRole" typeof="Person">
      <span property="name">Bill Murray</span>
    </div>
  </div>
</div>

You can't do this in Microdata without adding in @id and @href links.

> Gregg, can you help untangle this?
> 
> Dan
Received on Thursday, 27 March 2014 00:30:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:38 UTC