[whatwg] inverse property mechanism for Microdata?

Hi folks. I'm relaying this from the schema.org collaboration,
probably the main user of HTML's Microdata mechanism.

We'd (schema.org 'we') like to make a public proposal to update
Microdata with a syntax for expressing inverse
properties/relationships. FWIW other notations that schema.org
supports (JSON-LD and RDFa) have such mechanisms ([1],[2]).

At schema.org we are repeatedly running into situations where we have
a need for properties to be used in reverse direction. There are 630
or so properties defined currently (and a similar number of types);
see listing at http://schema.org/docs/full.html. Inverse properties
are relatively a cornercase, but a persistent one.

By inverse, I refer to scenarios where there are any pair of
properties (relationship types) e.g. "foo" and "bar", such that
whenever some entity-1 has a foo relationship to an entity-2, then by
definition, entity-2 will have a "bar" relationship to entity-1. We'd
like to avoid the need to give "bar" a specific name, and instead be
able to in effect just say "the inverse of foo".

e.g. perhaps entity-1 is a shop, entity-2 is another shop, and "foo" =
"containedIn", "bar" = "containsWithin", indicating that the one shop
is inside the other. Or perhaps entity-1 is a school, entity-2 is a
celebrity, and foo="alumni", bar="alumniOf". Schema.org would like
Microdata syntax to be extended somehow, to allow a single property
name to be used regardless of whether the markup nesting structure
emphasises entity-1 or entity-2.

For more example topics, here are some of the properties we define.

http://schema.org/containedIn (which relates a smaller place to a
larger containing place);
http://schema.org/member http://schema.org/alumni
http://schema.org/author http://schema.org/performerIn
http://schema.org/worksFor http://schema.org/employee
http://schema.org/founder http://schema.org/member ... and various others,
often role-related or where two independent entities have a
relationship that is being described, and where neither entity is
necessarily the primary focus in all markup.

For a property like "alumni" it could reasonably be used either in a
paragraph that was describing the educational institution, or
describing a (famous) person who attended it.  We would like to have a
standard markup convention for using a single named property, i.e.
being able to indicate sometimes that it is to be read in reversed
direction. In other words we want to avoid having to come up with two
different names for each of these situations; and more importantly, to
avoid publishers/authors having to remember two names for one
situation.


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>


One response is that the markup could be reorganized. For example,

  <div 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 itemprop="containedIn"  itemscope
itemtype="http://schema.org/LocalBusiness">
     <h2><span itemprop="name">(Entity A) Beachwalk Beachwear &
Giftware</span></h2>
     <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>
  </div>

We're not so optimistic about this approach, especially when multiple
entities are described. Schema.org is widely used but seems generally
to be added to existing pages with relatively fixed structure.

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

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.

In recent work on sports schemas and schemas for reservations there
has been pressure to
have relationship types work in both directions. Rather than make
dozens of arbitrary pairs of named relationships, which each need to
be carefully named, remembered, and translated, ... we'd prefer to
make the case to the HTML community for a single new mechanism in the
Microdata spec, so that each relationship only needs to be named once.

It would be good to be clear on the problem before jumping into
potential solutions for microdata. I can provide more examples if
needed but hope this is enough to get discussion started.

cheers,

Dan

[1] http://www.w3.org/TR/json-ld/#reverse-properties
[2] http://www.w3.org/TR/rdfa-core/#A-rev

Received on Friday, 31 January 2014 18:43:27 UTC