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

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

From: Adrian Giurca <giurca@tu-cottbus.de>
Date: Mon, 18 Jun 2012 17:24:55 +0200
Message-ID: <4FDF4847.2050501@tu-cottbus.de>
To: Egor Antonov <elderos@yandex-team.ru>
CC: Peter Mika <pmika@yahoo-inc.com>, Dan Brickley <danbri@danbri.org>, Ivan Herman <ivan@w3.org>, "public-vocabs@w3.org" <public-vocabs@w3.org>, "Martin Hepp (UniBW)" <martin.hepp@ebusiness-unibw.org>, Ramanathan Guha <guha@google.com>, Jeni Tennison <jeni@jenitennison.com>
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 ">
  <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 ...


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>:
>> 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
>>     <mailto: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
Received on Monday, 18 June 2012 15:25:27 UTC

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