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

On 18 Jun 2012, at 21:33, Ivan Herman <ivan@w3.org> wrote:

> Egor,
> 
> I wonder whether you did not make the same mistake as I did when the this idea came up at a workshop in Mountain View last year. My understanding of the proposal is do to something like:
> 
> <... itemtype="http://schema.org/SomeType">
>  <link itemprop="additonalType" href="http://someuriforatype">
> <...>
> 
> Ie, there is no 'fork' of the microdata syntax. It is one more property in the schema.org space. (Dan or Guha, please correct me if my understanding is wrong.)

Yes, you describe this option accurately.

By staying within current Microdata syntax rules we can rely on the Microdata Dom api. My concern about making a syntax-level deviation from standard Microdata we put ourselves in a situation where API access behaviour   Would be undefined, and might vary between browsers/tools.

Dan


> Cheers
> 
> Ivan
> 
> ---
> Ivan Herman
> Tel:+31 641044153
> http://www.ivan-herman.net
> 
> (Written on mobile, sorry for brevity and misspellings...)
> 
> 
> 
> On 18 Jun 2012, at 20:31, Egor Antonov <elderos@yandex-team.ru> wrote:
> 
>> Using this property we do break microdata compatibility, because it's no longer microdata standard, but already such unofficial and undescribed fork.
>> No parser will parse it without some coding work, no verifier tool can verify schema match, because it won't be microdata anymore.
>> You propose to say "if you use microdata and want multiple itemtypes, use microdata with some hack"
>> I propose the same thing, but naming it direct. 
>> It's just a superset of microdata features, and it can be implemented in a prettier way than "additionalType" property IMHO
>> Or my logic is wrong?
>> 
>> 18.06.2012, 21:46, "Dan Brickley" <danbri@danbri.org>:
>>> 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
>> 
>> -- 
>> Egor Antonov
>> http://staff.yandex-team.ru/elderos

Received on Monday, 18 June 2012 20:07:24 UTC