Re: schema.org Roles design

Note that there are other classes that are similar to hasRole/Role in this regard. For example, UserLikes is a kind of Event, that ties together a Thing with a Person (agent) to express an interest. It's also useful to express that a Person likes something by using the reverse direction. Markup for this might look like the following:

<div vocab="http://schema.org/" typeof="Movie">
 <span property="name">Ghostbusters</span>
 <div rel="interaction" rev="interactedWith" typeof="UserLikes">
   <div rel="actor" rev="actorIn" typeof="Person">
     <span property="name">Bill Murray</span>
   </div>
 </div>
</div>

Any time there is some entity which might be accessed from multiple directions, a way to reverse the direction is really useful. The same basic data could also be defined as follows:

<div vocab="http://schema.org/" typeof="Person">
  <span property="name">Bill Murray</span>
  <div rel="actorIn" rev="actor" typeof="UserLikes">
    <div rel="interactedWith" rev="interaction" typeof="Movie">
      <span property="name">Ghostbusters</span>
    </div>
  </div>
</div>

Gregg Kellogg
gregg@greggkellogg.net

On Apr 2, 2014, at 10:10 PM, Dan Scott <dan@coffeecode.net> wrote:

> On Thu, Mar 27, 2014 at 10:47 AM, Dan Brickley <danbri@google.com> wrote:
>> 
>> Given that doing this is hard in both Microdata and JSON-LD, my guess
>> is that we can't be too demanding in terms of wanting a relation
>> _from_ the Person _to_ the Role. And semantics-wise, an appropriately
>> backwards-named relation from the Role to the Person (alongside the
>> domain-specific 'actor' property) would tell us much the same thing.
>> For example, trying that with 'roleFor' as the name (assumed to be
>> inverse of inRole):
>> 
>> <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 rel="actor roleFor" typeof="Person">
>>      <span property="name">Bill Murray</span>
>>    </div>
>>  </div>
>> </div>
> 
> I'm primarily interested in resolution of the hasRole pattern in the
> context of the existing Comics proposal at
> https://www.w3.org/community/schemabibex/wiki/Periodicals_and_Comics_synthesis
> which currently wants to add properties for various relatively
> comic-specific roles such as "colorist", "inker", "letterer",
> "penciler", so I've been encouraged to see some progress on this front
> (and the consideration given to media as well as sports contexts).
> 
> A couple of questions:
> 
> 1. My understanding was that the schema.org partners had said they
> would parse RDFa Lite, giving the impression that RDFa full was _not_
> going to be accepted. But this thread is using RDFa full attributes
> such as @about, @rel, and @rev. We may want to keep these constraints
> in mind given schema.org's original raison d'être.
> 
> 2. Rather than creating a new "hasRole" property, or perhaps in
> addition to, why not add "rangeIncludes Role" to existing properties
> like actor, athlete, and contributor? Assuming the generic "Role" has
> the properties "roleName" and "rolePlayer" (come on, you have to love
> that!), we could mark up the original Quarterback example from the
> proposal document as follows:
> 
> {
> "@context": "http://schema.org/",
> "@type": "AmericanFootballTeam",
> "name": "San Francisco 49ers",
> "athlete": {
>  "@type": "Role",
>  "roleName": "Quarterback",
>  "startDate": "1979",
>  "endDate": "1992",
>  "rolePlayer": {
>    "@type": "Person",
>    "name": "Joe Montana"
>   }
> }
> }
> 
> or for the RDFa Lite version:
> 
> <div vocab="http://schema.org/" type="AmericanFootballTeam">
>  <span property="name">San Francisco 49ers</span>
>  <div property="athlete" typeof="Role">
>    <span property="roleName">Quarterback</span>,
>    <span property="startDate">1979</span>-<span property="endDate">1992</span>:
>    <span property="rolePlayer" typeof="Person">
>        <span property="name">Joe Montana</span>
>    </span>
>  </div>
> </div>
> 
> One could add in explicit IDs to provide resolvable URIs, of course,
> and sameAs properties to link out to richer sources of external linked
> data, etc.
> 
> But I think this pattern would work well for the Comics proposal and
> for marking up the crazy-long lists of movie credits with all of the
> fine-grained contribution types such as gaffer, best boy, etc. In
> fact, taking an existing section from the Comics proposal, what was
> originally mocked up as (requiring four new schema.org properties in
> this case):
> 
> <div vocab="http://schema.org/" typeof="ComicIssue">Issue <span
> property="issueNumber">13</span>
>  <div property="author" typeof="Person">Author: <span
> property="name">Michael McMillian</span></div>
>  <div property="artist" typeof="Person">Art by: <span
> property="name">Beni Lobel</span></div>
>  <div property="colorist" typeof="Person">Colors by: <span
> property="name">Esther Sanz</span></div>
>  <div property="coverArtist" typeof="Person">Cover by: <span
> property="name">Michael Gaydos</span></div>
>  <div property="letterer" typeof="Person">Letters by: <span
> property="name">Neil Uyetake</span></div>
> </div>
> 
> could now be marked up as the following, requiring no new properties
> beyond those supplied by the generic Role:
> 
> <div vocab="http://schema.org/" typeof="ComicIssue">Issue <span
> property="issueNumber">13</span>
>  <div property="author" typeof="Person">Author: <span
> property="name">Michael McMillian</span></div>
>  <div property="contributor" typeof="Role"><meta property="roleName"
> content="artist">Art by: <span property="rolePlayer"
> typeof="Person"><span property="name">Beni Lobel</span></span></div>
>  <div property="contributor" typeof="Role"><meta property="roleName"
> content="colorist">Colors by: <span property="rolePlayer"
> typeof="Person"><span property="name">Esther Sanz</span></span></div>
>  <div property="contributor" typeof="Role"><meta property="roleName"
> content="coverArtist">Cover by: <span property="rolePlayer"
> typeof="Person"><span property="name">Michael
> Gaydos</span></span></div>
>  <div property="contributor" typeof="Role"><meta property="roleName"
> content="letterer">Letters by: <span property="rolePlayer"
> typeof="Person"><span property="name">Neil Uyetake</span></span></div>
> </div>
> 
> While Guha mentioned a desire to walk a fine line between overly
> general slots and overly specific slots, I think we should ensure the
> general slots work before defining more context-specific slots.
> 
> 3. With any of these proposals, what would be the best way to attach
> URIs that draw from external vocabularies? For example, in Comics we
> might want to link to http://id.loc.gov/vocabulary/relators/clr in
> addition to supplying the literal value "colorist" for the roleName.
> Add the URI to "typeof='Role'"?
> 
> 4. I'd like to see more explicit information in the proposal about the
> properties that the base Role type would have. I guess that goes back
> to ensuring that the generic type works first, before diving into
> specializations.
> 
> 5. "<hasRole> a <Property>; domainIncludes <Role>; rangeIncludes
> <Thing>." in the proposal has range and domain reversed, no? (Looking
> back, Gregg caught this too... I think it's okay to update the draft
> doc for straightforward mistakes!)
> 
> Thanks, Dan, for getting this ball rolling, and to all the
> participants in the thread thus far for their contributions.
> 
> Dan Scott

Received on Monday, 14 April 2014 17:53:33 UTC