Re: Proposal: Audiobook

I am also perfectly fine with the "two type approach". My main position is that the new, enhanced "Offer" type provides all structural elements for describing commercial offers on places, audio books, creative works, labor, etc., and we should rather encourage the broader use of this core commercial type than to define new "offer" derivatives for a variety of types of objects or services.

For illustrating my approach:

If we want to offer an AudioBook for sale, this could look as follows:

<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
    <title>An offer to sell a / some Hammer</title>
</head>
<body>
<div itemscope itemtype="http://schema.org/Product http://schema.org/AudioBook" itemid="#product">

    <span itemprop="name">.. a short name for the object ...</span>
    Product description: 
    <span itemprop="description">... a longer description ...</span>
    <div itemprop="offers" itemscope itemtype="http://schema.org/Offer" itemid="#offer">
        <span itemprop="price">$19.99</span> 
        <link itemprop="availability" href="http://schema.org/InStock" />In stock
    </div>
</div>
</body>
</html>


The important line in here is

<div itemscope itemtype="http://schema.org/Product http://schema.org/AudioBook" itemid="#product">

As long as the types stem from the same vocabulary, it is valid to use multiple types as a space-separated list in the itemtype attribute, as per

    http://www.w3.org/html/wg/drafts/microdata/master/#typed-items

In RDFa, this is always possible.

Alternatively, we could use

<div itemscope itemtype="http://schema.org/Product" itemid="#product">
    <link itemprop="additionalType" href="http://schema.org/AudioBook" />

But then it would not be valid to use AudioBook-specific properties. So the former is better.

As a general guideline, I would recommend to combine the two types for specific objects used as products *at markup time* and not by making all possible types for products a subtype of Product in the vocabulary.

But again, the most important aspect is that we do *not* add redundant properties for commercial aspects of offers of objects to the new object types like AudioBook. So price etc. should never be a property of a product.

Martin


On Sep 24, 2013, at 2:55 PM, Dan Scott wrote:

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

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

e-mail:  hepp@ebusiness-unibw.org
phone:   +49-(0)89-6004-4217
fax:     +49-(0)89-6004-4620
www:     http://www.unibw.de/ebusiness/ (group)
         http://www.heppnetz.de/ (personal)
skype:   mfhepp 
twitter: mfhepp

Check out GoodRelations for E-Commerce on the Web of Linked Data!
=================================================================
* Project Main Page: http://purl.org/goodrelations/

Received on Tuesday, 24 September 2013 15:16:03 UTC