Re: schema.org Roles design

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 Thursday, 3 April 2014 05:11:46 UTC