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

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

From: Dan Brickley <danbri@danbri.org>
Date: Mon, 18 Jun 2012 18:46:15 +0200
Message-ID: <CAFfrAFpgQE2b3zUrE6RiH2cCZKY1zfFn7pTdhHa-LdL=7HGa=g@mail.gmail.com>
To: Jason Douglas <jasondouglas@google.com>
Cc: Adrian Giurca <giurca@tu-cottbus.de>, Egor Antonov <elderos@yandex-team.ru>, Peter Mika <pmika@yahoo-inc.com>, 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>
On 18 June 2012 17:44, Jason Douglas <jasondouglas@google.com> wrote:
> 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).

I'm ok with having a privileged role for the first token; Microdata
needs something like this, since it thinks of the properties as being
set by types, in contrast to RDF's more statement-oriented model.
There's also a sense in which schema.org descriptions prioritize
schema.org types that suits this constraint. We don't mind
things-that-look-like-types from other namespaces being mentioned but
currently the schema.org partners only collectively say that they
"understand" stuff from schema.org's own namespace. The
'additionalType' design + phrasing, and the 'add it to end of
space-separated list' approach, both work from that perspective.

So - if we went for the 'tweak Microdata' approach, what if anything
might break in practice?

Received on Monday, 18 June 2012 16:46:45 UTC

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