Re: Proposal: Audiobook

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