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

Re: schema.org Roles design

From: Stéphane Corlosquet <scorlosquet@gmail.com>
Date: Thu, 3 Apr 2014 02:00:39 -0400
Message-ID: <CAGR+nnEhz_bKusNkyZ2TtgZZCiDt9HFOFmc=Hwq=9MkdwO+fLA@mail.gmail.com>
To: Dan Scott <dan@coffeecode.net>
Cc: Dan Brickley <danbri@google.com>, Gregg Kellogg <gregg@greggkellogg.net>, Jarno van Driel <jarno@quantumspork.nl>, Jason Douglas <jasondouglas@google.com>, Guha <guha@google.com>, W3C Web Schemas Task Force <public-vocabs@w3.org>
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


> 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 06:01:07 UTC

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