W3C home > Mailing lists > Public > public-vocabs@w3.org > September 2013

Re: Proposal: Audiobook

From: Niklas Lindström <lindstream@gmail.com>
Date: Sat, 21 Sep 2013 02:53:58 +0200
Message-ID: <CADjV5jcJgktH73eJJomuRr-NVk=UDVBvr4ArqKDxsovN916HhA@mail.gmail.com>
To: Dan Scott <dan@coffeecode.net>
Cc: Aaron Bradley <aaranged@gmail.com>, "Wallis,Richard" <Richard.Wallis@oclc.org>, "public-vocabs@w3.org" <public-vocabs@w3.org>
Hi Dan,

On Fri, Sep 20, 2013 at 3:59 PM, Dan Scott <dan@coffeecode.net> wrote:

> On Thu, Sep 19, 2013 at 07:47:54AM -0700, Aaron Bradley wrote:
>> I think this is a type whose time has come.
>> I wonder, though, whether an "Audiobook" type should encompass - or at
>> least try to account for - audio dramas.  That is a dramatization rather
>> than a reading of a book, or an original audio drama, such as one commonly
>> encounters on public radio broadcasters like the BBC.
>> Really the only property that would need to be re-examined in this light
>> is
>> "readBy", because of the difference between a "reading" and a
>> "performance."
>> For both audio books and audio dramas, the existing property performer [1]
>> seems well-suited to the task.  And even looking just at the type
>> "AudioBook" it seems that "readBy" is an unnecessarily more specific
>> version of "performer" (for example, there is no "actor" property for
>> TheatreEvent [2]).
> I am sympathetic to this perspective. There is a vast set of potential
> types of contributions to creative works that the current schema.org
> vocabulary does not capture. For example, the long list of credits in
> any given movie contains many different roles such as gaffer, key grip,
> dressmaker, etc (http://www.imdb.com/title/**tt0111161/fullcredits<http://www.imdb.com/title/tt0111161/fullcredits>for
> example). Distinguishing these various types of contribution
> is worthwhile, but I'm sure we don't want to expand
> http://schema.org/CreativeWork or its children to have named properties
> for all of these possibilities.
> So, to kick an idea around, what if the range of "contributor" and
> "performer" included a new type, "Contributor", which would consist of
> two new properties:
> * participant (range: Organization, Person)
> * contribution (range: http://schema.org/Contribution (new type with an
>   external enumeration)
> For the external enumeration, we could point to an existing vocabulary
> like http://id.loc.gov/vocabulary/**relators.html<http://id.loc.gov/vocabulary/relators.html>;
> this list includes many
> types of contributions beyond what schema.org currently details, but it
> is also missing a number just from the one film credit example above.
> Alternately, we could go the ProductOntology route and use wikipedia
> types like http://www.productontology.**org/id/Dressmaker<http://www.productontology.org/id/Dressmaker>and
> http://www.productontology.**org/id/Gaffer_(filmmaking)<http://www.productontology.org/id/Gaffer_(filmmaking)>-- I suppose these
> contribution types fall under "services", which explains why they're
> mapped and enumerated. That said,
> http://www.productontology.**org/id/Narrator<http://www.productontology.org/id/Narrator>redirects to "Narrative" (per
> wikipedia), so PTO isn't a perfect option either. Would a union of both
> external enumerations be possible (or does someone have a better
> existing vocab in mind)?
> I'm not keen on "participant" as the property name for the new type, but
> "contributor" is already taken--heh. Having a "contributor" property and
> "Contributor" type might be bad form, as well. This is far from a full
> proposal!
> In the specific case of satisfying the desire for an Audiobook "readBy"
> property, the RDFa would look like:
> <p property="contributor" typeof="Contributor">Read by:   <span
> property="participant" typeof="Person">Simon Prebble</span>
>   <meta property="contribution" content="http://id.loc.gov/**
> vocabulary/relators/nrt <http://id.loc.gov/vocabulary/relators/nrt>">
> </p>
> I believe this is a direction worth exploring, but would not be
> surprised if it had already been discussed and dismissed...  if the
> latter, then my apologies for wasting bandwidth.

Surely worth considering. So you didn't waste my bandwidth at least. :)

I would prefer a direct description using multiple properties though. Like:

    <p vocab="http://schema.org/" prefix="lcrel:
      Read by:
      <span property="contributor lcrel:nrt" typeof="Person">
        <span property="name">Simon Prebble</span>

(Of course, I also would like a future when using only lcrel:nrt was
possible, due to having it declared as rdfs:subPropertyOf sdo:contributor.
And by possible I mean the search engines using such information. Today,
lcrel:nrt is already declared as rdfs:subPropertyOf dc11:contributor. Which
at least could have a formal relation to sdo:contributor (today there is

Though if you'd like to investigate corresponding qualified associations, I
recommend looking at the PROV vocabulary, especially
prov:qualifiedAssociation [2]. (Well, glancing at it and pondering if there
are portions that could fit the scope of schema.org.)


[1]: https://raw.github.com/dcmi/schema.org/master/mappings_schema.org.xml
[2]: http://www.w3.org/TR/prov-o/#qualifiedAssociation

> Dan
Received on Saturday, 21 September 2013 00:54:56 UTC

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