Re: Proposal: Audiobook

Right,

More specific Types will and are needed in Schema.org, no question.  The
question is that of reuse and using a top down approach (rather than bottom
up).  I am trying to teach many of us on here, of thinking GENERICALLY to
allow a natural reuse to happen and evolve.

To that end, I would rather see a higher type evolve from this discussion,
where I do not know WHAT that higher type is yet.  But know that it is
definitely, a http://schema.org/Product :

CreativeWork -> Book -> bookFormat -> AudioBook (a new BookFormatType)

http://schema.org/BookFormatType -> AudioBook

Other ideas (from a bottom up approach):

AudioBook <- Recording
AudioBook <- Book

etc...



On Thu, Sep 19, 2013 at 12:32 PM, Aaron Bradley <aaranged@gmail.com> wrote:

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


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