Re: Proposal: Audiobook

Aaron,

Many things are recorded or encoded... we should probably use the term
"encoding" very loosely for effective reuse of cases such as this.

Images, Moving Images, Sound Waves... they are all "recorded" or "encoded"
in some form... not just Books encoded in Audiio.

So does the existing Schema work well enough ? where does it leave you
wanting more ?  Take a further look...



On Thu, Sep 19, 2013 at 9:47 AM, 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.
>
> 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]).
>
> 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.
>
> [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
>>
>>
>>
>>
>


-- 
-Thad
Thad on Freebase.com <http://www.freebase.com/view/en/thad_guidry>
Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>