Agreed with Peter. "additionalType" is not a part of the (ontology) schema, but a hack for microdata.
We cannot save compatibility with microdata anyway, because all the parsers need to be rewritten to understand schema.org.
If so, why do we handle it as ontology schema addition and not as new markup standard?
Let's just make a microdata extension for schema.org.
š
PS
It will be strange to have "additionalType" property while "mainType" doesn't exist.
--
Egor
š
16.06.2012, 19:28, "Peter Mika" <pmika@yahoo-inc.com>:

Let me add my $0.02...

My main concern is that schema.org is and should be about the schema,
not the syntax. The reason of adding this property is to patch
microdata, but if schema.org defines this term, it will be available for
all syntaxes (microdata, RDFa, possibly soon OData). In both microdata
and RDFa, we would end up with two ways of defining types (using
typeof/itemtype vs. additionalType). Standard parsers however will only
see one type (the one expressed using the standard mechanism).

A minor concern is that the name additionalType implies that somehow one
type is more important than the other.

Cheers,
Peter







On 6/16/12 7:48 AM, 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. 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'). 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...

šcheers,

šDan

š

--
Egor Antonov
http://staff.yandex-team.ru/elderos