Re: Proposal: Audiobook

Thad, BookFormatType is an enumeration not a class. To use that (and I'm 
not sure that enumerations in are getting much use), we would 
have to add "readBy" or "performer" to Book. It also would 
make AudioBook a type of book rather than a sound recording. It is a 
combination of the two, of course, with the sound part being, IMO, equal 
to the book part.


On 9/19/13 11:05 AM, Thad Guidry wrote:
> Right,
> More specific Types will and are needed in, 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 :
> CreativeWork -> Book -> bookFormat -> AudioBook (a new 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 <
> <>> 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
>     <> 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]
>     On Thu, Sep 19, 2013 at 8:20 AM, Niklas Lindström
>     < <>> wrote:
>         Hi Aaron,
>         On Thu, Sep 19, 2013 at 4:47 PM, 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.
>         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]
>             [2]
>             [3]
>             On Thu, Sep 19, 2013 at 4:30 AM, Wallis,Richard
>             < <>>
>             wrote:
>                 This is a proposal from the Schema Bib Extend Group
>                 <>, consisting
>                 of 80+ people from a broad cross section of publishers,
>                 libraries, and others interested in enhancing
>                 <>'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 <> and 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 <>
>                 Richard Wallis
>                 Technology Evangelist, OCLC
>        <>
> --
> -Thad
> Thad on <>
> Thad on LinkedIn <>

Karen Coyle
m: 1-510-435-8234
skype: kcoylenet

Received on Thursday, 19 September 2013 18:31:53 UTC