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 23:01:06 +0200
Message-ID: <CAFfrAFqLzVE8RP6YYGRpYXSQwLmAuS4AwenE7pYhT7+fSEt05Q@mail.gmail.com>
To: Martin Hepp <martin.hepp@ebusiness-unibw.org>
Cc: "public-vocabs@w3.org Vocabs" <public-vocabs@w3.org>, Egor Antonov <elderos@yandex-team.ru>, Guha Guha <guha@google.com>, Peter Mika <pmika@yahoo-inc.com>, Ivan Herman <ivan@w3.org>, Jeni Tennison <jeni@jenitennison.com>
On 18 June 2012 22:51, Martin Hepp <martin.hepp@ebusiness-unibw.org> wrote:
> My addition 2 cents:
> We can specify in the schema.org vocabulary that a client MAY safely ignore the additional type information. It is just an additional hint that a client may follow or may not.
> For correct markup, it is safe to assume the property to be equivalent to rdf:type, but whether or not a parser handles it that way is up to the client.
> And for the ergonomics: I find a space-separated list of itemtypes like
> <section itemscope itemtype="http://schema.org/CreativeWork http://purl.org/goodrelations/v1#Brand ">
> ...
> very error-prone, and, to be frank, ugly, from a coder's perspective.
> And if special role of the first itemtype to set the scope for the properties is hidden in the first position in the list, things get even worse.
> A brief summary of the current situation from my perspective:
> 1. We need the ability to indicate additional type information to schema.org in Microdata syntax, for GoodRelations and many other scenarios.
> 2. The pattern must preserve the special role of the primary itemtype for setting the context for Microdata properties.
> 3. We need the solution quickly, i.e. within a few weeks or so, the faster the better.
> 4. Any changes to the Microdata spec are unlikely to happen within a reasonable time-frame.
> 5. The proposal does not break any parsers and is fully compliant with the current Microdata spec and, afaiks, typical Microdata implementations.
> 6. The proposal is upwards-compatible to a future mechanism in a future Microdata spec.
> 7. The proposal can be easily handled in an RDF environment for consuming respective data.

I'm with you until here...

> 8. Developers may use a broader range of lexical forms for identifiers of secondary types, e.g. Wikipedia URIs instead of www.productontology.org IDs, prefixed identifiers ("unspsc:11001123"),private URN schemes etc., which means we may need additional cleansing before translating respective markup into additional rdf:type statements.

Not sure I buy this bit. Well, in general schema.org tolerates mess in
lots of places, but I don't see a particular need to invite it here...
 Private URN schemes can still be legitimate URIs/IRIs here, and
someone could make a unspsc scheme....


Received on Monday, 18 June 2012 21:01:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:23 UTC