Re: schema.org Roles design

On Thu, Apr 3, 2014 at 1:10 AM, 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.
>

Note there is no such thing as "RDFa Lite parser" (there is no parser spec
for RDFa Lite), all parsers should support RDFa full. RDFa Lite is a subset
designed for authors to use the most popular parts of RDFa which are
sufficient in 95% of the use cases. Then there are the other 5% which are
needed for more advance use cases such as the ones highlighted by Dan
Brickley.

Steph.


>
> 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
>
>


-- 
Steph.