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

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.)

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 19:33:51 UTC