W3C home > Mailing lists > Public > public-vocabs@w3.org > September 2013

Re: Proposal: Audiobook

From: Dan Scott <dan@coffeecode.net>
Date: Tue, 24 Sep 2013 08:55:05 -0400
To: Martin Hepp <martin.hepp@ebusiness-unibw.org>
Cc: Niklas Lindström <lindstream@gmail.com>, Aaron Bradley <aaranged@gmail.com>, "Wallis,Richard" <Richard.Wallis@oclc.org>, "public-vocabs@w3.org" <public-vocabs@w3.org>
Message-ID: <20130924125504.GA10396@denials>
On Mon, Sep 23, 2013 at 05:11:22PM +0200, Martin Hepp wrote:
>This may be a bit off-topic, but for the commercial aspects of AudioBooks, I would strongly prefer to use / reuse http://schema.org/Offer. There should be no need for major extensions for typical commercial patterns. One minor thing: In GoodRelations (and hence schema.org), 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.

Hmm. What I've been doing to date is your approach #3. I confess to
generally being willing to trade off a bit of additional conceptual
complexity for a clean implementation. And it's not only relevant for
commerce scenarios!

http://stuff.coffeecode.net/schema.org/evergreen/eg_15.html is an
example that I took back in August and marked up in RDFa with
typeof="MusicAlbum Product". The Evergreen and Koha library systems
adopted this approach and are set to publish this kind of RDFa by
default in their next major releases.
Received on Tuesday, 24 September 2013 12:55:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:31 UTC