Re: additionalType property, vs extending Microdata syntax for multiple types

On 17 June 2012 00:41, Guha <guha@google.com> wrote:

> My personal preference is to just add an attribute called type (or
> additionalType) which is samePropertyAs rdfs:type and be done with it.

I've come to the same view; see proposal below.

I've just spent a little while trying to answer my "What would break?"
question, ... if we went the other way and extended Microdata. My
conclusion is that the safest and most responsible option is to define
http://schema.org/additionalType as a convenience alias for W3C's
http://www.w3.org/1999/02-22-rdf-syntax-ns#type property. If Microdata
was purely a syntax, maybe we'd be ok. But there is also another spec,
the Microdata DOM API. Some software, e.g. Opera-based browsers, have
been shipping with Microdata DOM API for a while. Others, like
Firefox, have just added support.

http://my.opera.com/ODIN/blog/2011/12/06/hello-opera-11-60
http://dev.opera.com/articles/view/microdata-and-the-microdata-dom-api/
https://twitter.com/FirefoxNightly/statuses/210300933056380928
https://bugzilla.mozilla.org/show_bug.cgi?id=591467

I made some tests with Opera 12, using

<section itemscope itemtype="http://schema.org/CreativeWork
http://schema.org/Cat">
<h1 itemprop="name http://example.com/fn">Hedral</h1>
<p itemprop="description
http://purl.org/goodrelations/v1#description">Hedral is a male
american domesticshorthair, with ...</p>
</section>

...but couldn't retrieve the DOM node when multiple types (of any
kind) were present. Looking at the Firefox Bugzilla entry, there is
also active discussion there of multiple item types - not clear even
if basic multi-typing is supported yet.

While we could choose to read this as "microdata API implementations
are still catching up with the current html spec, so more changes
wouldn't matter", I think the correct lesson is that we shouldn't
casually mess with markup design that could have complex and
un-analyzed impact on associated APIs. Browser makers will not
appreciate changes at this time, and it will be costly and
unproductive to try to persuade them. Any changes to Microdata would
have to include not only rules for the syntax, but a corresponding API
redesign, including failure conditions, new test cases etc., not to
mention the energy and engagement needed to persuade all relevant
stakeholders to accept the new model.

I just don't think it's feasible, so let's try to do the best we can
with 'additionalType'.

A concrete proposal:

Property: additionalType
samePropertyAs: rdf:type
description: "An alias for the rdf:type relationship between something
and a class that the thing is in. It is generally preferable to use
syntax-native typing mechanisms. The additionalType construct can be
useful in constrained syntaxes - e.g. microdata - where multiple types
from
independent vocabularies cannot be easily expressed. In such
situations, care should be taken to assign the most relevant
schema.org type using
the primary (e.g. 'itemtype') typing syntax. Schema.org tools may have
only weaker understanding of extra types, in particular those defined
externally."

Peter & co. - can you live with that?

Dan

Received on Monday, 18 June 2012 17:47:13 UTC