- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Thu, 19 Sep 2013 11:31:23 -0700
- To: public-vocabs@w3.org
Thad, BookFormatType is an enumeration not a class. To use that (and I'm
not sure that enumerations in schema.org are getting much use), we would
have to add "readBy" or "performer" to schema.org 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.
kc
On 9/19/13 11:05 AM, Thad Guidry wrote:
> 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
> <mailto: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
> <http://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 <mailto:lindstream@gmail.com>> wrote:
>
> Hi Aaron,
>
> On Thu, Sep 19, 2013 at 4:47 PM, Aaron Bradley
> <aaranged@gmail.com <mailto: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 <mailto: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
> <http://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 <mailto: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/>
--
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet
Received on Thursday, 19 September 2013 18:31:53 UTC