W3C home > Mailing lists > Public > public-vocabs@w3.org > June 2012

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

From: Ivan Herman <ivan@w3.org>
Date: Sat, 16 Jun 2012 06:55:47 +0200
Cc: public-vocabs@w3.org, "Martin Hepp (UniBW)" <martin.hepp@ebusiness-unibw.org>, Peter Mika <pmika@yahoo-inc.com>, Ramanathan Guha <guha@google.com>, Jeni Tennison <jeni@jenitennison.com>
Message-Id: <22D28B79-2C07-42CA-B528-80068F603696@w3.org>
To: Dan Brickley <danbri@danbri.org>
Hi Dan,

On Jun 15, 2012, at 20:26 , Dan Brickley wrote:

> HTML5 Microdata, as defined in
> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#encoding-microdata
> 
> ... has only limited support for describing multiple types that
> something belongs to. In particular it requires they are described
> using a single schema.
> 
> 
> For Good Relations integration (and other scenarios) people have asked
> for a way of listing more types within schema.org markup.
> 
> * One model is to use RDFa 1.1 (Lite), where this is quite natural.
> * Another is to add (as a workaround) a new property, e.g. called
> 'type' or 'additionalType', to schema.org's vocab (Martin requests
> this in http://www.w3.org/wiki/WebSchemas/GoodRelations )
> * A 3rd is to stretch
> http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#items
> to allow different namespaces to be used.

I think that the third option is not obvious. The issue is that, in microdata, two notions, namely the typing of an item and the vocabulary used in that item, are conflated. The vocabulary information (hence the interpretation of the terms in the item) is deduced from the itemtype value(s). Hence the restriction in the current spec to restrict multiple types to be in the same vocabulary. Technically, it would be possible to declare that the order in the attribute's value counts, ie, the first type value determines the vocabulary, but that would be terribly error-prone and I hence do not believe it would be a good idea.

It would require a more substantial change in the microdata spec (essentially introducing the equivalent of RDFa's @vocab) to solve that properly. I do not see that happening.

Which leaves us with the first or the second option. I am obviously biased here, but I think the first option is clearly better in this respect...

Ivan


> 
> The note at http://www.w3.org/TR/html-data-guide/#multiple-types-microdata
> discusses just this issue.
> 
> I'm sending this as followup from discussion amongst schema.org
> partners, who welcome community advise on this point. Should we add a
> 'type' property to schema.org, try to change or stretch microdata
> syntax, ... or encourage people who want multiple diverse types to use
> RDFa Lite instead?
> 
> Dan
> 
> 
> 
> Copied below is the current Microdata / HTML5 spec text,
> 
> "The item types of an item are the tokens obtained by splitting the
> element's itemtype attribute's value on spaces. If the itemtype
> attribute is missing or parsing it in this way finds no tokens, the
> item is said to have no item types.
> 
> The item types must all be types defined in applicable specifications
> and must all be defined to use the same vocabulary.
> 
> Except if otherwise specified by that specification, the URLs given as
> the item types should not be automatically dereferenced.
> 
> A specification could define that its item type can be derefenced to
> provide the user with help information, for example. In fact,
> vocabulary authors are encouraged to provide useful information at the
> given URL.
> 
> Item types are opaque identifiers, and user agents must not
> dereference unknown item types, or otherwise deconstruct them, in
> order to determine how to process items that use them.
> 
> The itemtype attribute must not be specified on elements that do not
> have an itemscope attribute specified."
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Saturday, 16 June 2012 04:56:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 16 June 2012 04:56:19 GMT