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

Re: Proposal: Audiobook

From: Martin Hepp <martin.hepp@ebusiness-unibw.org>
Date: Tue, 24 Sep 2013 20:40:05 +0200
Cc: public-vocabs@w3.org
Message-Id: <B6A34D93-6C40-475A-BFAF-FCFCEDCDB56A@ebusiness-unibw.org>
To: kcoyle@kcoyle.net
Hi Karen,
as already posted earlier today:

On Sep 23, 2013, at 6:31 PM, Karen Coyle wrote:

> 
> 
> Martin, I'm not fully grasping your point here, but looking at Product it does not appear to have any way to connect it to descriptions of CreativeWorks that are being offered. (And vice versa, from CWs to Product) Am I understanding that correctly?
> 
Simply use two types for the entity, then you can treat it as a Product and CreativeWorks and use properties from both types.

> I think what we would want would be more than an additional type on an offer,

No, please not. That would spoil the clean conceptual model for offers in schema.org. 

> since we do want the description of the CreativeWork and the Product Offer to be connected.

Simply use the offers property from Product or the itemOffered property from offer and make the AudioBook (or other object) of type AudioBook AND Product.

> I note that the examples that we did for AudioBook have a librarian bias, so they don't include information from Product. Should we add a subclass to Product to correct this?
> 

There is no need to add commercial properties of the offer to the object being offered. One core distinction that GoodRelations makes (and that has also been in schema.org from day 1) is the separation between a product (the object being offered for sale, lease, disposal, ...) and the offer (i.e. the promise to grant someone some rights on the object for some compensation (e.g. dollars).

This actually simplifies the lives of everybody suggesting new types for schema.org, since you do not need to cater for properties that refer to the offer; solely such that are relevant for describing the object itself.

Martin

> kc
> 
>> 
>> 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.
>> 
>> Martin
>> 
>> 
>> 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 <dan@coffeecode.net>
>>> 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
>>> schema.org 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
>>> (http://www.imdb.com/title/tt0111161/fullcredits for example).
>>> Distinguishing these various types of contribution is worthwhile,
>>> but I'm sure we don't want to expand http://schema.org/CreativeWork
>>> 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:
>>> http://schema.org/Contribution (new type with an external
>>> enumeration)
>>> 
>>> For the external enumeration, we could point to an existing
>>> vocabulary like http://id.loc.gov/vocabulary/relators.html; this
>>> list includes many types of contributions beyond what schema.org
>>> 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
>>> http://www.productontology.org/id/Dressmaker and
>>> http://www.productontology.org/id/Gaffer_(filmmaking) -- I suppose
>>> these contribution types fall under "services", which explains why
>>> they're mapped and enumerated. That said,
>>> http://www.productontology.org/id/Narrator 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="http://id.loc.gov/vocabulary/relators/nrt"> </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="http://schema.org/" prefix="lcrel:
>>> http://id.loc.gov/vocabulary/relators/" 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
>>> schema.org.)
>>> 
>>> Cheers, Niklas
>>> 
>>> [1]:
>>> https://raw.github.com/dcmi/schema.org/master/mappings_schema.org.xml
>>> 
>>> 
> [2]: http://www.w3.org/TR/prov-o/#qualifiedAssociation
>>> 
>>> 
>>> 
>>> 
>>> Dan
>>> 
>>> 
>> 
>> -------------------------------------------------------- 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/
>> 
>> 
>> 
>> 
>> 
> 
> -- 
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet
> 

--------------------------------------------------------
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 18:40:32 UTC

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