- From: Martin Hepp <martin.hepp@ebusiness-unibw.org>
- Date: Wed, 11 Sep 2013 10:27:44 +0200
- To: Jarno van Driel <jarno@quantumspork.nl>
- Cc: Justin Boyan <jaboyan@google.com>, Dan Brickley <danbri@google.com>, Guha Guha <guha@google.com>, TallyFy <hello@tallyfy.com>, Jason Douglas <jasondouglas@google.com>, PublicVocabs <public-vocabs@w3.org>, Vicki Tardif Holland <vtardif@google.com>, Sam Goto <goto@google.com>
On Sep 10, 2013, at 10:05 PM, Jarno van Driel wrote: > To compensate this Martin suggests that, with the addition of the 'ListItem' type, declaration of an additionalType could resolve this. Now correct if I'm wrong here, but isn't the 'additionalType' property typically used to declare a (more specific) type from a different vocabulary instead of declaring a second schema.org type? > You can use it for both. In RDFa, you can anyway use multiple types per entity. In microdata, things are a bit more complicated (see the discussion on the additionalType property earlier in this forum). I think (not entirely sure from the top of my head) that microdata allows multiple types as long as the types stem from the same vocabulary. additionalType was designed as a quick fix for providing additional type information from an external vocabulary (like http://www.productontology.org) without breaking the microdata spec and without the need for changing the microdata spec. But for the reasons explained this morning, I am now in favor of an extra property "represents" and for properly nesting the entity inside the list item, which removes the need for a multi-typed entity. It is a bit more complicated from a mark-up perspective, but in contrast generally usable for any kind of ordered lists of items. Martin
Received on Wednesday, 11 September 2013 08:28:11 UTC