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

My addition 2 cents:

We can specify in the schema.org vocabulary that a client MAY safely ignore the additional type information. It is just an additional hint that a client may follow or may not.

For correct markup, it is safe to assume the property to be equivalent to rdf:type, but whether or not a parser handles it that way is up to the client. 

And for the ergonomics: I find a space-separated list of itemtypes like

<section itemscope itemtype="http://schema.org/CreativeWork http://purl.org/goodrelations/v1#Brand ">
...

very error-prone, and, to be frank, ugly, from a coder's perspective.

And if special role of the first itemtype to set the scope for the properties is hidden in the first position in the list, things get even worse. 

A brief summary of the current situation from my perspective:

1. We need the ability to indicate additional type information to schema.org in Microdata syntax, for GoodRelations and many other scenarios.
2. The pattern must preserve the special role of the primary itemtype for setting the context for Microdata properties.
3. We need the solution quickly, i.e. within a few weeks or so, the faster the better.
4. Any changes to the Microdata spec are unlikely to happen within a reasonable time-frame.
5. The proposal does not break any parsers and is fully compliant with the current Microdata spec and, afaiks, typical Microdata implementations.
6. The proposal is upwards-compatible to a future mechanism in a future Microdata spec.
7. The proposal can be easily handled in an RDF environment for consuming respective data.
8. Developers may use a broader range of lexical forms for identifiers of secondary types, e.g. Wikipedia URIs instead of www.productontology.org IDs, prefixed identifiers ("unspsc:11001123"),private URN schemes etc., which means we may need additional cleansing before translating respective markup into additional rdf:type statements.

Martin




On Jun 18, 2012, at 10:12 PM, Dan Brickley wrote:

> 
> 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.
> 
> It is entirely ok w.r.t. the Microformat spec.
> 
>> 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"
> 
> The very idea that things come with multiple independent types is new to Microdata.
> 
> 
>> I propose the same thing, but naming it direct.
> 
> The difference is that it is not ours to redesign, and there are API implementations already shipping that would be affected.
> 
>> 
>> 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?
> 
> Rather than logic, I guess you might underestimate the work involved in changing the Microdata spec. It would take a lot of someone's time -- and I don't see any volunteers.
> 
> Cheers,
> 
> Dan
> 
> 
>> 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

--------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  hepp@ebusiness-unibw.org
phone:   +49-(0)89-6004-4217
fax:     +49-(0)89-6004-4620
www:     http://www.unibw.de/ebusiness/ (group)
         http://www.heppnetz.de/ (personal)
skype:   mfhepp 
twitter: mfhepp

Check out GoodRelations for E-Commerce on the Web of Linked Data!
=================================================================
* Project Main Page: http://purl.org/goodrelations/

Received on Monday, 18 June 2012 20:52:26 UTC