Re: Proposal: Audiobook

This may be a bit off-topic, but for the commercial aspects of AudioBooks, I would strongly prefer to use / reuse There should be no need for major extensions for typical commercial patterns. One minor thing: In GoodRelations (and hence, Product is not disjoint to any other core class, which makes it possible to offer also Places, Corporations, and accordingly AudioBooks.

While this is conceptually no problem, we will have to point users to this fact once other types than Product become relevant for commerce scenarios.

There are several solutions for that:

1. A simple solution would be to change the range of schema:itemOffered from schema:Product to schema:Product OR schema:Thing (this is of course semantically equivalent to just schema:Thing but would point developers to the fact that it is valid to use other types for the objects an offer refers to).

2. Even simpler would be to change the definition of schema:itemOffered  and add "Other types than Product can also be used where appropriate, e.g. Place or Corporation).

3. We could encourage the use of multiple types in such cases, like schema:Product and schema:AudioBook. The nice thing is that many properties of schema:Product are useful once an entity serves as a product, like the product IDs. However, this clean approach is conceptually a bit more complex.

I am in favor of #2 (or #1), which will also valid in RDFS semantics, since as soon as you use an entity this way, it is implicit that this entity is also a schema:Product.


On Sep 21, 2013, at 2:53 AM, Niklas Lindström wrote:

> Hi Dan,
> On Fri, Sep 20, 2013 at 3:59 PM, Dan Scott <> wrote:
> On Thu, Sep 19, 2013 at 07:47:54AM -0700, 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.
> 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]).
> I am sympathetic to this perspective. There is a vast set of potential
> types of contributions to creative works that the current
> vocabulary does not capture. For example, the long list of credits in
> any given movie contains many different roles such as gaffer, key grip,
> dressmaker, etc ( for
> example). Distinguishing these various types of contribution
> is worthwhile, but I'm sure we don't want to expand
> or its children to have named properties
> for all of these possibilities.
> So, to kick an idea around, what if the range of "contributor" and
> "performer" included a new type, "Contributor", which would consist of
> two new properties:
> * participant (range: Organization, Person)
> * contribution (range: (new type with an
>   external enumeration)
> For the external enumeration, we could point to an existing vocabulary
> like; this list includes many
> types of contributions beyond what currently details, but it
> is also missing a number just from the one film credit example above.
> Alternately, we could go the ProductOntology route and use wikipedia
> types like and
> -- I suppose these
> contribution types fall under "services", which explains why they're
> mapped and enumerated. That said,
> redirects to "Narrative" (per
> wikipedia), so PTO isn't a perfect option either. Would a union of both
> external enumerations be possible (or does someone have a better
> existing vocab in mind)?
> I'm not keen on "participant" as the property name for the new type, but
> "contributor" is already taken--heh. Having a "contributor" property and
> "Contributor" type might be bad form, as well. This is far from a full
> proposal!
> In the specific case of satisfying the desire for an Audiobook "readBy"
> property, the RDFa would look like:
> <p property="contributor" typeof="Contributor">Read by:   <span property="participant" typeof="Person">Simon Prebble</span>
>   <meta property="contribution" content="">
> </p>
> I believe this is a direction worth exploring, but would not be
> surprised if it had already been discussed and dismissed...  if the
> latter, then my apologies for wasting bandwidth.
> Surely worth considering. So you didn't waste my bandwidth at least. :)
> I would prefer a direct description using multiple properties though. Like:
>     <p vocab="" prefix="lcrel:"
>        typeof="Audiobook">
>       Read by:
>       <span property="contributor lcrel:nrt" typeof="Person">
>         <span property="name">Simon Prebble</span>
>       </span>
>     </p>
> (Of course, I also would like a future when using only lcrel:nrt was possible, due to having it declared as rdfs:subPropertyOf sdo:contributor. And by possible I mean the search engines using such information. Today, lcrel:nrt is already declared as rdfs:subPropertyOf dc11:contributor. Which at least could have a formal relation to sdo:contributor (today there is [1]).)
> Though if you'd like to investigate corresponding qualified associations, I recommend looking at the PROV vocabulary, especially prov:qualifiedAssociation [2]. (Well, glancing at it and pondering if there are portions that could fit the scope of
> Cheers,
> Niklas
> [1]:
> [2]:
> Dan

martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

phone:   +49-(0)89-6004-4217
fax:     +49-(0)89-6004-4620
www: (group) (personal)
skype:   mfhepp 
twitter: mfhepp

Check out GoodRelations for E-Commerce on the Web of Linked Data!
* Project Main Page:

Received on Monday, 23 September 2013 15:11:54 UTC