Re: Multiple itemtypes in microdata

On Wed, 12 Oct 2011, Jeni Tennison wrote:
> 
> It's good to see you addressing the requirement for multiple itemtypes 
> in microdata.

I'm happy to consider any use cases people provide. Please file bugs or 
send mail to the whatwg@whatwg.org list describing them to make sure they 
are properly considered.


> One of the assumptions we're making within the HTML Data TF is that 
> publishers will need to publish in multiple formats (rather than 
> consumers understanding multiple formats)

That sounds like a horrible authoring experience. :-)

My assumption is that authors will typically use zero vocabularies. I 
think we have to consider ourselves lucky if they actually use any at all.

I certainly wouldn't encourage people to use more than one. So long as 
they always use multivendor, well-documented vocabularies, they'll always 
be able to trivially move to other vocabularies by applying mechanical 
transformations later. No need to expose two. (There's rarely a need to 
expose any!)


> so that when/if there is eventual convergence on a single format, 
> consumers aren't stuck having to be able to maintain a massive legacy. 

I don't understand what you mean. Surely if authors only provide data in 
one vocabulary, it's less of a legacy to maintain than if they provide the 
data in two vocabularies?


> If people are using multiple vocabularies they will very probably want 
> to use types from each of those vocabularies.

I'm not sure what you mean. What's the difference between "type" and 
"vocabulary" here?


> An example of the kind of workaround that's currently being recommended 
> is shown with the use of GoodRelations with schema.org where the ugly 
> http://www.w3.org/1999/02/22-rdf-syntax-ns#type property is used to 
> provide the GoodRelations type for the item while the itemtype holds the 
> schema.org type. As you know, I've also blogged about this from the 
> perspective of a publisher targeting both browsers and search engines.

If you've got two different vocabularies, just provide the data twice, 
e.g.:

   <div itemscope itemtype="http://example.org/feline">
    <meta itemprop="name" content="Cat Adorable Pillar">
    <meta itemprop="species" content="American Shorthair">
    <meta itemprop="color" content="White">
   </div>
   <div itemscope itemtype="http://example.com/cat">
    <meta itemprop="common-name" content="Pillar">
    <meta itemprop="name" content="ASH"> <!-- American Shorthair code -->
    <meta itemprop="color" content="#FFFFFF">
   </div>

There's no sane way to use both vocabularies in parallel, since the 
vocabularies will almost certainly have different requirements (e.g. in 
this example, one has its colour as a string and the other as a hex code).


Note that the property "name" in the vocabulary "http://example.org/feline"
and the property "http://example.org/feline#name" have absolutely not 
relationship in microdata. They are different properties and cannot be 
mechanically considered to be equivalent in any way. Any use of microdata 
that claims that a full URL property name is the same property as a short 
name in a specific vocabulary is wrong. It's two properties. They might 
have the same semantics and can be used as equivalent, but they are 
different properties and any specification that defines or uses both would 
need to define how to handle clashes.


> You've put a NEEDSINFO status on the bug which makes me wonder if you're 
> still thinking about this requirement and whether there's any 
> information we could provide you with?

I'm always looking for more information. Use cases, primarily. Marking the 
bug as NEEDSINFO was accidental, though.


> If support for multiple types from different vocabularies is definitely 
> out of scope for microdata, it would be really helpful to understand the 
> rationale so that we can document it for users.

Nobody has asked for it in an actionable manner (giving concrete use cases 
that demonstrate real need, e.g. showing real Web pages where there really 
are two incompatible vocabularies that are nonetheless compatible enough 
that it actually makes sense to have some sort of special syntax for 
mixing the vocabularies).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 12 October 2011 22:34:44 UTC