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 09:14:01 +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: <4ED4BD7A-699C-4153-BFCC-8661732F01CF@w3.org>
To: Dan Brickley <danbri@danbri.org>

On Jun 16, 2012, at 07:48 , Dan Brickley wrote:

> On 16 June 2012 06:55, Ivan Herman <ivan@w3.org> wrote:
>> 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.
> Yes. I think it is well appreciated that RDFa 1.1 handles this better.
> I don't think anyone expects Microdata to change a lot more, and I
> don't see anyone with the energy/interest to keep pushing for these
> kinds of changes/improvements in Microdata. As you say, it wouldn't be
> easy. The "main type comes first" design was all I could think of,
> too.
>> 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...
> The question is then, what do we say for all those publishers who are
> on board the Microdata train? A lot of people have worked hard to get
> colleagues/stakeholds (and tools!) adopting Microdata, over the last
> year.

Absolutely, and...

> While RDFa is a good thing, we want to be careful to support
> early adopters too, and have sensible advice for them (other than
> 're-do everything with a new syntax').

... I fully agree. 

> Which is what makes 'additionalType' attractive.
> But the concern there is ... if we go
> that route, validators/checkers will need to understand the attribute
> since it is almost an extension of the underlying syntax...

As a a consequence, I think that having that additionalType stuff be part of schema makes sense, but this also means that schema-aware tools that use RDF vocabularies should know that this is a synonym to rdf:type. Which is not a nice design but, that being said, this may be to only way ahead for microdata users.

So I guess schema:additionalType should be used for microdata to keep the current investments in time and energy; people who jump on the bandwagon today or tomorrow and who need this feature should be proposed to consider using RDFa Lite instead in future and they should also advised _not_ to use that property when using RDFa (although it cannot be forbidden). To make the interoperability complete, this makes it even more important to have, at the http://schema.org/ URI, an RDF (RDFa, Turtle, RDF/XML, whatever...) file available, say, through conneg, to make those property (and class) equivalences and/or subproperty/subclass relationships clearly defined. This would also be of a major help for other vocabularies mapped to schema.org. More demanding RDF(a) processors could then make use of that to make the necessary mapping (yes, I know, I am again looking at it through the RDF integration goggle...)


Note that there is a 4th option, that Martin referred to in Mountain View, and that is to use something like

<link itemprop="http://www.w3.org/1999/02/22-rdf-syntax-ns#type" href="URI_OF_THE_TYPE" />

for each additional types. This is in line with the microdata philosophy that rejects any form of URI abbreviation, is perfectly valid microdata, but is also incredibly user-unfriendly. The advantage is that it works out of the box today... I presume the user-unfriendliness is why you did not consider it...

> cheers,
> Dan

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 07:14:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:48:46 UTC