W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2014

Re: [whatwg] inverse property mechanism for Microdata?

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 31 Jan 2014 23:45:15 +0000 (UTC)
To: Dan Brickley <danbri@google.com>
Message-ID: <alpine.DEB.2.00.1401312334310.26647@ps20323.dreamhostps.com>
Cc: whatwg@lists.whatwg.org
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.

(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.)


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


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

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 31 January 2014 23:45:40 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:15 UTC