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

That's not just a token list... it's an ordered token list.
 You're privileging the first token as the "frame" as Martin calls it.  In
the case of a token list for itemprop there's no order dependance (and I'm
guessing that's the reason itemtype is the way it is in the spec).


On Mon, Jun 18, 2012 at 8:24 AM, Adrian Giurca <giurca@tu-cottbus.de> wrote:

>  Hi Egor,
>
> Indeed, it would be enough to allow a list of URLs  as  value of Microdata
> @itemtype. This is similar with the token list value of @itemprop.
> Such extension will solve many of actual annotations miss-understandings
> and will not add more verbosity to the markup.
>
> <section itemscope itemtype="http://schema.org/CreativeWork http://purl.org/goodrelations/v1#Brand " <http://schema.org/CreativeWorkhttp://purl.org/goodrelations/v1#Brand>>
>  <h1 itemprop="name http://example.com/fn">Hedral</h1>
>  <p itemprop="description http://purl.org/goodrelations/v1#description">Hedral is a male american domestic
>  shorthair, with ...
>  </p>
>  </section>
>
>
> Regards,
> Adrian
>
>
> On 6/18/2012 12:11 PM, Egor Antonov wrote:
>
> 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><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
>
>
>
>