[whatwg] inverse property mechanism for Microdata?

[Ian Hickson]

On Mon, 17 Mar 2014, Dan Brickley wrote:
> 
> We discussed this (and the -inv suggestion) at schema.org again, and the 
> consensus there was that we'd like to have the search engines proceed 
> with accepting an experimental/proposed 'inverse itemprop' attribute, 
> rather than work around its absence.

So the idea here that the itemprop-up (or whatever -- it would be good to 
get a more intuitive name, not sure what to call it though) would have to 
be specified in conjunction with the itemscope="" attribute on a top-level 
microdata item whose element had an ancestor that itself creates an item, 
and would actually specify a property on the inner item, whose value was 
the outer item?

This is what the example would look like if I'm understanding this right:

  <div itemscope itemtype="http://schema.org/LocalBusiness">
    <h1><span itemprop="name">(Entity A) Beachwalk Beachwear &
    Giftware</span></h1>
    <span itemprop="description"> A superb collection of fine gifts and clothing
    to accent your stay in Mexico Beach.</span>
    Phone: <span itemprop="telephone">850-648-4200</span>

    <div itemscope itemtype="http://schema.org/LocalBusiness"
         itemprop-up="containedIn">
      <h2><span itemprop="name">(Entity B) The tiny store within a
      store</span></h2>
      <span itemprop="description"> A superb collection of tiny clothes,
      from the store within the store.</span>
      Phone: <span itemprop="telephone">123-456-7890</span>
    </div>

  </div>

It's not too bad, I guess. My main concern is that this seems to solve a 
very narrow use case for non-tree structures, but doesn't take into 
account the many, many other non-tree structures. For example, consider 
the case of a TV Episode with an Actor:

   <div itemscope itemtype="http://schema.org/Episode">
    ...
    <div itemprop="actor"
         itemscope itemtype="http://schema.org/Person"> 
     ...
    </div>
   </div>

...now suppose it's marked up the other way around:

   <div itemscope itemtype="http://schema.org/Person">
    ...
    <div itemprop-up="actor"
         itemscope itemtype="http://schema.org/Episode"> 
     ...
    </div>
   </div>

So far so good. But what if there's two episodes with two actors, and the 
page just lists both episodes and both actors, and wants to 
cross-reference both episodes to both actors?

itemprop-up (or whatever we call it) can't help there. itemref="" can help 
in some simple cases, but as you pointed out, it soon gets out of hand.

Microdata actually already has a solution to this. The vocabulary can 
define an ID for each item using itemid="", and can define multiple items 
having the same ID as being the same conceptual item. Thus:

   <!-- first episode -->
   <div itemscope itemtype="http://schema.org/Episode">
    ...
    <div itemprop="actor"
         itemscope itemtype="http://schema.org/Person" 
         itemid="http://.../person/123"></div>
    <div itemprop="actor"
         itemscope itemtype="http://schema.org/Person" 
         itemid="http://.../person/456"></div>
   </div>

   <!-- second episode -->
   <div itemscope itemtype="http://schema.org/Episode">
    ...
    <div itemprop="actor"
         itemscope itemtype="http://schema.org/Person" 
         itemid="http://.../person/123"></div>
    <div itemprop="actor"
         itemscope itemtype="http://schema.org/Person" 
         itemid="http://.../person/456"></div>
   </div>

   <!-- actors -->
   <div itemscope itemtype="http://schema.org/Person"
        itemid="http://.../person/123">
    ...
   </div>
   <div itemscope itemtype="http://schema.org/Person"
        itemid="http://.../person/456">
    ...
   </div>

This also enables the data to be spread across multiple pages without 
confusion. (This is similar to how RDF uses identifiers for everything -- 
essentially, in RDF terms, this turns the microdata item from a bnode into 
a node with a global identifier.)

Your example would become:

  <div itemscope itemtype="http://schema.org/LocalBusiness"
       itemid="...">
    <h1><span itemprop="name">(Entity A) Beachwalk Beachwear &
    Giftware</span></h1>
    <span itemprop="description"> A superb collection of fine gifts and clothing
    to accent your stay in Mexico Beach.</span>
    Phone: <span itemprop="telephone">850-648-4200</span>

    <div itemscope itemtype="http://schema.org/LocalBusiness">
      <div itemprop="containedIn"
           itemscope itemtype="http://schema.org/LocalBusiness" 
           itemid="..."></div>
      <h2><span itemprop="name">(Entity B) The tiny store within a
      store</span></h2>
      <span itemprop="description"> A superb collection of tiny clothes,
      from the store within the store.</span>
      Phone: <span itemprop="telephone">123-456-7890</span>
    </div>

  </div>

Is this not suitable for schema.org? Or is it just too much markup?


> > That is another option, similar to the parenthetical itemid="" note 
> > above -- you could just have the vocabulary define that for every 
> > property whose value is an item, the item type that that property can 
> > point to has another property with the same name plus a fixed suffix, 
> > like "-inv", that inverses the relationship. [...]
> 
> This is easier to understand than itemref, but still involves creating 
> 100s of additional properties instead of just one new piece of syntax.

What do you mean by "creating additional properties" here? It's relatively 
trivial to define these with one sentence, you don't need to actually list 
them or anything. Implementing support is similarly easy, as far as I can 
tell -- you just check for the suffix or prefix and handle it accordingly.

I don't really understand why 'itemprop-foo="bar"' would be any better 
than 'itemprop="bar-foo"'. Can you elaborate on this? It seems like it 
would essentially be identical in practice. There are significant costs to 
introducing a new language feature here, I think, so we should definitely 
consider this alternative carefully before dismissing it.


> Would a data- attribute be an appropriate way to indicate an 
> experimental/proposed attribute? And then if it works out well perhaps a 
> real microdata attribute could be added later? e.g. 
> data-itemprop-inverse="alumni" ...

If you do want to go with a new property, just use the name you would want 
in the spec. I weakly recommend "itemprop-up", which is the most intuitive 
name I've seen so far for this, but if you find a better name just use 
that. I guarantee that I won't make the spec conflict with whatever you 
use, as long as you tell me what it is. :-) Assuming that it works well, 
then we would just update the spec to use that term directly, 
retroactively making the experimental content conforming.

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