- From: Adrian Giurca <giurca@tu-cottbus.de>
- Date: Mon, 18 Jun 2012 17:24:55 +0200
- 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>
- Message-ID: <4FDF4847.2050501@tu-cottbus.de>
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 ... </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>: >> >> 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