[whatwg] inverse property mechanism for Microdata?

[Dan Brickley]

Hi Ian, HTML people,

On 31 January 2014 23:45, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 31 Jan 2014, Dan Brickley wrote:
>>
>> We'd (schema.org 'we') like to make a public proposal to update
>> Microdata with a syntax for expressing inverse properties/relationships.
>> [...]
>>
>> Here's an example with 'containedIn'. The idea is that we want to
>> express that the LocalBusiness (i.e. Place) Entity B is 'containedIn'
>> Entity A. The example I show here expresses the reverse, incorrectly. So
>> we're looking for a change to the markup that would turn this example
>> into one that said "The LocalBusiness Entity B is containedIn the
>> LocalBusiness Entity A":
>>
>> <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 itemprop="containedIn" itemscope
>>        itemtype="http://schema.org/LocalBusiness">
>>     <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>
>
> This is actually possible today:
>
>  <div itemscope itemtype="http://schema.org/LocalBusiness"
>       id=a itemprop="containedIn">
>    <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 itemref=a itemtype="http://schema.org/LocalBusiness">
>      <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>
>
> The trick here is to turn the inner item into the top-level microdata
> item, and use itemref="" to have that inner item point to the outer item.

You're right; it is indeed possible. However it is perhaps a little
too clever. I've tried it on a few colleagues, and it didn't 'click'
with anyone yet.

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.


> (This works great unless you want two items to refer to the same third
> item using different properties, but that's something microdata can't do
> in general, since it's based on a tree structure, not a graph structure.
> To address that particular problem, you need a vocabulary that defines
> how itemid="" works; at that point, you can just have the same underlying
> item represented as multiple microdata items in the document by having all
> the items share the same ID. But how exactly that is to be interpreted is
> something the vocabulary has to define.)
>
>> One response is that the markup could be reorganized.
>
> That's basically what the above does, but without moving the elements
> around in the DOM. (itemref="" is basically all about making the microdata
> model work around constraints coming from the author's preferred DOM.)

(Yup.)


>> Another reasonable response to this is 'well, perhaps you should have a
>> property (instead or in addition) called "geospatiallyContains", or
>> "containerOf" or "contains", or "rev_containedIn" for this usage
>> scenario'?
>
> 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. That would make the above look like:
>
>  <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 itemprop="containedIn-inv"
>         itemscope itemtype="http://schema.org/LocalBusiness">
>      <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>

This is easier to understand than itemref, but still involves creating
100s of additional properties instead of just one new piece of syntax.

>> We have tried this and in a few cases we have included pairs of inverse
>> properties in schema.org, e.g. we have "alumni" and an inverse,
>> "alumniOf".  In designing schemas we have found it consistently hard to
>> get even a single natural/intuitive name for each property, and finding
>> a good name for the inverse of each makes the task even heavier.
>> Appending "Of" (or other fixed suffix) doesn't always work well; e.g.
>> "containedIn" / "containedInOf" barely makes sense.
>
> Yeah, you'd have to just pick a suffix like "-inv" or a prefix like "rev-"
> or something that doesn't attempt to give a good English meaning. The
> advantage of doing that is that you could then define this for the
> vocabulary generically, and process it generically, rather than having to
> actually define and support each individual property.

That's the motivation for asking for an inverse itemprop syntax; it
could be used to process data for all vocabularies generically without
introducing hundreds of unwanted new properties. We'd like to avoid
things like "alumni-inv" leaking into JSON-LD usage, since JSON-LD has
an inverse property notation that can be used directly with the
"alumni" property.

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" ...

Dan

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