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

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