Re: Proposal: Audiobook

On 9/19/13 7:47 AM, 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.

Audio dramas are a separate product, if we are looking at this from a
product point of view. As you mention, they are often the result of a
broadcast, and that may be the more important aspect, "product-wise."
Audiobooks are a major product of their own, as witnessed by the
purchase of Audible.com by Amazon. Given the general thrust of
schema.org, I believe it should be in a category of its own.

>
> 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]).

Actually, audiobooks refer variously to "reader" "read by" "narrator"
and "narrated by". There is a significant difference between reading
every word (albeit with some actorly inflection and differentiation of
voices) and "performing." I do wish there were someone here from the
audiobook business, but I suspect that "performer" would not be seen as
appropriate for audiobooks.



>
> Looking at the example I also wonder about the use of "datePublished",
> "publisher", "copyrightYear" and "copyrightHolder" in this context.  In
> the World War Z example the values for the these properties reference
> the published book on which the audiobook is based.  To indicate year of
> recording and recording copyright (which is typically an additional
> copyright - i.e. a copyright on the performance), would one declare
> additional instances of these properties, or is the addition of a
> property or properties required?

Audiobooks have their own copyrights and their own copyright holders,
and these are separate from the copyrights on the printed book. The
bibliographic data should represent the audiobook, not the print book it
is read from. The publisher of the print book does not hold the
copyright in the audiobook, but they have a contract with the audiobook
producer that allows them to create the audiobook product. This is not
unlike the licensing of a book to be made into a movie. The movie
copyright is separate from the book copyright.

BTW, the copyright designation for sound recordings is (p), not (c).
You'll see this in library data:

Imprint 	New York : Listening Library, p2007




>
> In the former case, of course, data consumers would not be able to
> distinguish between date of publication and date of recording which
> would be an issue.  And I think that providing the recording date in a
> structured format is at least as important (and arguably more important
> n the context of the type "Audiobook") as the book publication date.
> Without that the data encoded for a reading of "Moby Dick," for example,
> would only indicate that the book was published in 1851, and not that it
> was recorded in 2013.


This is also true for all re-publications of books, as you see if you do
a search in any large bibliographic database. The date of publication is
... the date of publication. There are hundreds of publications of Moby
Dick after 1851, and the metadata for each one contains *solely* the
date of publication of the "re-publication." I would love for
bibliographic data to contain an "original date of the work" (which,
BTW, you can find in Wikipedia entries for creative works), but in
bibliographic metadata that information is not included since it
requires some research on the part of the metadata creator.

>
> Thinking out loud, all of this could be handled if the property values
> for "AudioBook" all pertained to the recording, rather than the book,
> and a property "isBasedOnBook" (like isBasedOnUrl [3]) with expected
> type "Book" could be used to mark up all the properties related to the
> book on which the recording is based.
>
> [1] http://schema.org/performer
> [2] http://schema.org/TheaterEvent
> [3] http://schema.org/isBasedOnUrl
>

I can understand the desire to connect the audiobook and the print book
which is being read. In most catalogs and databases they "connect"
because they have the same author, title and subjects, so they are
retrieved with the same query and may be merged in display (cf. Amazon
displays). I'm not sure that the data that exists will lend itself to
providing the information to support isBasedOnUrl. This becomes a
question of goals, therefore: to provide schema.org properties for
current data, or to make schema.org into a schema that allows new
metadata to be created. I admit that at the moment I'm more interested
in the former, since I see a first use case for schema to mark up
existing data. I'm not seeing it as a metadata creation schema. Perhaps
others are aiming at the latter?

kc


>
>
> On Thu, Sep 19, 2013 at 4:30 AM, Wallis,Richard <Richard.Wallis@oclc.org
> <mailto:Richard.Wallis@oclc.org>> wrote:
>
>     This is a proposal from the Schema Bib Extend Group
>     <http://www.w3.org/community/schemabibex/>, consisting of 80+
>     people from a broad cross section of publishers, libraries, and
>     others interested in enhancing Schema.org <http://Schema.org>'s
>     capabilities in the area of bibliographic and associated resources.
>
>     Proposal:
>     To create a new Type: 'Audiobook'
>
>     An audiobook is sufficiently different to other book types to
>     warrant the proposal for another type.
>
>     The proposal is that Audiobook is a sub-type of /both/ Book
>     <http://schema.org/Book> and AudioObject
>     <http://schema.org/AudioObject>.  I am not sure if I have seen a
>     Type in Schema that has more than one super-type before, so I am
>     wondering if this is a valid approach.
>
>     Detailed proposal posted on the WebSchemas wiki: Audiobook
>     <http://www.w3.org/wiki/WebSchemas/Audiobook>
>
>
>     Richard Wallis
>     Technology Evangelist, OCLC
>     richard.wallis@oclc.org <mailto:richard.wallis@oclc.org>
>
>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet

Received on Thursday, 19 September 2013 18:27:32 UTC