Re: Proposal: Audiobook

Thad, I see your point about MediaObject which would, for example, allow
one to declare properties about the *recording* made of a Book (or of
another CreativeWork), such as "publisher" or "copyrightDate".  This would
only work, though, if the recording was itself a property ("encoding") of
the CreativeWork encoded - that is, if the AudioBook item was not available.

However, I think an audio book is a discreet enough entity that it is
useful to classify it as a separate type, with some properties that are
unique to it in comparison to other CreativeWork propeties (even if only
"performer") - so it does leave me wanting, yes.  A recorded song is "just"
an audio recording of a CreativeWork, but nonetheless we have
MusicRecording.  And an audio book (or, especially, audio performance) need
not be derivative of another creative work, but may be an original creative
work in its own right, like other more specific types of creative works
like Movie or TVSeries.  So, for example, under the existing schemas, an
original BBC radio drama could only be marked up as CreativeWork, with
certain properties accessible via "encoding", but without access to
obviously relevant properties like "director", "actor" and "startDate" that
fall under TVSeries (audio books, at least theoretically share these same
properties).

Perhaps in the interest of reuse, and so that we're not iteratively
building out more an more specific types, the world could live without
"AudioBook" and/or an equivalent for an audio dramatization.  I'd say
there's value in a new type or type here.

I confess that only after writing the above did I encounter the
additions/modifications to TV and radio part of schema.org proposed by Yves
Raimond and Jean-Pierre Evain [1] which would indeed rework CreativeWork to
accomodate things like RadioSeries - which at least shows that others see
the utility of a separate type for audio dramatizations (though which I
wouldn't frame as "radio" as its quite possible to deliver audio through
another mechanism, just as "TVSeries" is - somewhat along the lines of
Thad's thinking - is an increasingly anachronistic framing of a
CreativeWork by its delivery mechanism.  Netflix's "House of Cards" is
undoubtedly a TVSeries, even though it has never been broadcast on a
television network nor requires a television to watch it ... so perhaps
that's not problematic.)

Niklas, to the broader point you make about derivative works, I LOVE the
idea of an "isBasedOn" property for creative works.

In the context of an AudioBook (were that type to be introduced) it would
immediately solve the ambiguity of things like "copyrightDate":  the value
of  copyrightDate for the item AudioBook would be for the recording, with
the property isBasedOn allowing for properties about the Book on which it
is based to be declared - including the copyrightDate of the book.

More generally, I think isBasedOn is both an elegant and useful way of
providing information about the relationship between creative works.  A
Movie may be based on a Book or a Book on Movie, for example; there's
schemas for these, of course, but no way of connecting the items.

[1] http://www.w3.org/wiki/WebSchemas/TVRadioSchema



On Thu, Sep 19, 2013 at 8:20 AM, Niklas Lindström <lindstream@gmail.com>wrote:

> Hi Aaron,
>
> On Thu, Sep 19, 2013 at 4:47 PM, Aaron Bradley <aaranged@gmail.com> 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.
>>
>
> Perhaps though, the dramatization would be considered as another kind of
> creative work? Of course, more to the point, would such a distinction be
> important for users in general? (If I look for an audiobook, would I be
> surprised by an audio drama?)
>
> 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]).
>>
>
> This sounds reasonable. The type should determine its specific contextual
> meaning readily enough.
>
>
>> 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?
>>
>> 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.
>>
>> 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.
>>
>
> I definitely think that an "isBasedOn" property – with a range of
> CreativeWork – could be a useful addition! (It would be rather like
> dc:source or prov:wasDerivedFrom in meaning).
>
> In the SchemaBibEx group, we've been discussing similar properties
> (exampleOfWork, isVersionOf, editionOf etc.) in relation to levels of
> abstractions or generalizations as well (for that difference, compare the
> FRBR exclusive abstraction levels with the
> ProductModel/Product/IndividualProduct levels of specificity). I think
> "isBasedOn" could be a valuable start. (Also in relation to the suggested
> "adaptationOf", figuring in the accessibility topic recently discussed
> here.)
>
> Especially since, in comparison, the "isBasedOnUrl" property is very
> strange from a linked data perspective (with its range of URL instead of
> CreativeWork).
>
> Cheers,
> Niklas
>
>
>
>>
>> [1] http://schema.org/performer
>> [2] http://schema.org/TheaterEvent
>> [3] http://schema.org/isBasedOnUrl
>>
>>
>>
>> On Thu, Sep 19, 2013 at 4:30 AM, Wallis,Richard <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'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
>>>
>>>
>>>
>>>
>>
>