Re: Proposal: Audiobook

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<http://schema.org/> specification.

+1

1. to promote the use of multiple types at markup time rather than blowing up the schema.org<http://schema.org/> specification with explicitly defined types for these cases

+1


~Richard

On 26 Sep 2013, at 13:26, Martin Hepp <martin.hepp@ebusiness-unibw.org<mailto:martin.hepp@ebusiness-unibw.org>> wrote:

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<http://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<http://schema.org/> data model. In essence, it drives schema.org<http://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<http://schema.org/> is not strictly following the RDF model, as one can see from the definition of the schema.org<http://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<http://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<http://schema.org/> specification with explicitly defined types for these cases