Re: Proposal: Audiobook

Hi Guha:

The generic issue (and cause for the request for your comment) was:

schema.org has certain types that represent *roles*, which are typically non-rigid in OntoClean terms. (For the majority of people on this list who are not into OntoClean: Non-rigid essentially means an entity can loose a certain type without ceasing to exist - e.g. a person can stop being a student by other means than death etc.).

Types representing roles are typically not disjoint with other types, and can thus usefully combined with other types. 

Now, we have many use cases in which we want to assign more than one type to an entity, in particular for being able to describe both the rigid properties of an entity (e.g. the date of birth of a person) and the types and properties of a role that the entity has in a certain context (e.g. the enrollment date forbeing a student or a professor, or a brand of book being offered as a product, ...).

In such cases, we often want to achieve two things:

a) signal multiple types to the consumer of the data (e.g. for triggering all relevant processing)
b) use properties from multiple types (e.g. attaching a manufacturer part number from http://schema.org/Product to an AudioBook).

Now, we can take at least two approaches for handling this:

1. We can use multiple supertypes, i.e. materialize a multiple inheritance relation (e.g. make AudioBook a subtype of both CreativeWorks and Product)
2. We can encourage the use of multiple types at markup time.

I strongly recommend option #2, because

- it waives the need to define relevant combinations ex ante,
- it avoids the irritating listing of properties that are not relevant for most use cases, and
- it decouples the evolution of type combinations from the evolution of the schema.org specification.

From the syntax, it is clear that Microdata and RDFa support multiple types in the aforementioned ways. 

However, this decision touches the basis of the schema.org data model. In essence, it drives schema.org towards a collection of facets instead of a single, dominating type per each entity.

Thus, I asked for your review.

Some issues:
- If a property used in such a multiple type scenario, which type perspective on the entity does it refer to?
- If a property is defined differently for two types, which definition applies?
- Is the entity an instance of the union of both types or the intersection (I am not stupid: In RDF terms, it is clearly an instance of the union of both classes. But schema.org is not strictly following the RDF model, as one can see from the definition of the schema.org-specific domain and range semantics).

I do not think that these problems introduce actual problems for you as a consumer of the data, but they may introduce conceptual inconsistencies that could irritate adopters of schema.org.

So for the moment, I suggest

1. to promote the use of multiple types at markup time rather than blowing up the schema.org specification with explicitly defined types for these cases 
and 
2. to document it somewhere in the data model part of the schema.org specification.

Martin



On Sep 25, 2013, at 6:12 PM, Guha wrote:

> I completely agree that there isn't a single solution that will work in all cases. I think we should just use a pragmatic (i.e., case by case) analysis.
> 
> guha
> 
> 
> On Wed, Sep 25, 2013 at 7:59 AM, Karen Coyle <kcoyle@kcoyle.net> wrote:
> Guha,
> 
> The discussion is about the difference between ontology definition and instance creation. When is it appropriate to define multiple types in the ontology definition vs. assigning multiple types to an instance?
> 
> To librarians this is the "pre-coordinated vs. post-coordinated" issue, but for non-librarians it probably makes more sense to talk about comparing complex and "complete" concepts vs. modular and combinable concepts.
> 
> I don't think there is a single answer because it is contextual, but I can see some advantages in creating simple ontology definitions that can be combined in various ways at the time of instance creation.
> 
> kc
> 
> 
> 
> 
> On 9/25/13 6:50 AM, Guha wrote:
> Clearly, the syntax needs to support multiple types for an object. We
> already do that ... not sure I see the issue.
> 
> Sorry for being slow ...
> 
> guha
> 
> 
> On Wed, Sep 25, 2013 at 12:40 AM, Martin Hepp
> <martin.hepp@ebusiness-unibw.org
> <mailto:martin.hepp@ebusiness-unibw.org>> wrote:
> 
>     Hi Karen,
>     good that we have consensus.
> 
>     Dan, Guha: I think the issue of whether multi-type entities should
>     be solved
> 
>     a) at markup time or
>     b) in the vocabulary
> 
>     is of generic relevance - do you have an opinion on that?
> 
>     I think that for types that are not disjoint but also only loosely
>     related (like an AudioBook used as a Product), it is much cleaner
>     and flexible to recommend using both types at markup time.
> 
>     This also decouples the evolution of such needs / use cases from the
>     evolution of the schema.org <http://schema.org> spec - site owners
>     do not have to wait for an update to schema.org <http://schema.org>,
> 
>     and search engines can learn from the appearance of new patterns.
> 
>     Martin
> 
>     On Sep 24, 2013, at 9:07 PM, Karen Coyle wrote:
> 
>      >
>      >
>      > On 9/24/13 11:40 AM, Martin Hepp wrote:
>      >> Hi Karen,
>      >> as already posted earlier today:
>      >
>      >>
>      >> 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.
>      >
>      > Yes, thanks, Martin. I saw that on your reply to Dan and that
>     seems to be exactly what we need.
>      >
>      > kc
>      >
>      > --
>      > Karen Coyle
>      > kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net
>      > m: 1-510-435-8234 <tel:1-510-435-8234>
> 
>      > skype: kcoylenet
>      >
> 
>     --------------------------------------------------------
>     martin hepp
>     e-business & web science research group
>     universitaet der bundeswehr muenchen
> 
>     e-mail: hepp@ebusiness-unibw.org <mailto:hepp@ebusiness-unibw.org>
>     phone: +49-(0)89-6004-4217 <tel:%2B49-%280%2989-6004-4217>
>     fax: +49-(0)89-6004-4620 <tel:%2B49-%280%2989-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 Thursday, 26 September 2013 12:26:39 UTC