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

Re: [whatwg] inverse property mechanism for Microdata?

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 2 Apr 2014 18:09:15 +0000 (UTC)
To: Dan Brickley <danbri@google.com>
Message-ID: <alpine.DEB.2.00.1404021759091.11249@ps20323.dreamhostps.com>
Cc: whatwg@lists.whatwg.org
On Wed, 19 Mar 2014, Dan Brickley wrote:
> >
> > 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.
> 
> Yes. I notice that the words we were playing with at schema.org relate 
> to the underlying graph data model itemprop-inverse, -reverse etc., 
> whereas your draft name, itemprop-up is about the markup hierarchy.

Yeah. I think most authors think in terms of what they see (their markup), 
not in terms of the data model. (I have had a _lot_ of conversations with 
authors where it was clear that they had no idea there was an underlying 
data model for the microdata that was separate from the markup.)


> Yup, there are some cases where this can be addressed through the 
> rigorous use of entity IDs in itemid, as you sketch below. That would be 
> relatively new territory for schema.org and for publishers. Perhaps 
> there is an attribute name we can find that would leave the door open to 
> more use cases, e.g. "itemprop-backwards" rather than "itemprop-up". It 
> seems reasonable to try to address relationships between sibling 
> elements too.

Well you'd been a new attribute to do that, unless I'm misunderstanding 
your proposal. Maybe you mean this attribute wouldn't point to a relative 
place in the markup, but would point to an identified element given by 
another attribute? I think that would be quite confusing.


> Something like (trying out -backwards instead of -up, to allow for
> non-hierarchical usage):
> 
> <div itemid="bigshop" itemscope itemtype="http://schema.org/LocalBusiness">
>     <h1><span itemprop="name">(Entity A) Beachwalk Beachwear &
> Giftware</span></h1>
> </div>
> <div itemscope itemtype="http://schema.org/Pharmacy">
>       <meta itemprop-backwards="containedIn" itemid="bigshop" />
>       <h2><span itemprop="name">Tiny pharmacy store within a store</span></h2>
> </div>
> 
> ?
> 
> Can we use itemid in that way, to give a property value too? I don't
> see itemid used much in the wild and the spec only mentions its use
> for the item having the property, rather than using when supplying the
> value of a property.

itemid="" is a URL that gives the identifier of the item. We'd want to use 
a new attribute to do something like this; e.g.: itemrelation="containedIn 
bigshop" where "itemrelation" takes just two keywords, a property name and 
the ID (not itemid) of the target element.

But that's pretty elaborate. Is there a need for this? Or is the 
relationship to the parent all that's needed? In your original e-mail you 
only suggested wanting to go up.


> > 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.)
> 
> Yes, it succeeds or fails to the extent people agree on these global 
> identifiers.

Do people not agree on them, typically?


> > 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?
> 
> It's in the clever-but-fragile category, I'd say. So yes, a bit too
> much markup. In English this is saying something like
> 
> "We're describing a LocalBusiness whose global ID is [xyz]; it has
> certain name, description, telephone properties given here.
> There is also a LocalBusiness that is containedIn a LocalBusiness
> whose global ID is [xyz]; this [other] LocalBusiness has the following
> name, description, telephone etc properties...."
> 
> Just as in the English, it is rather easy to lose track of which
> LocalBusiness we're talking about.

I think you overstate the complexity, but ok.


> >> > 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.
> 
> Re "you don't need to actually list them", this effectively creates two 
> classes of property. Real ones, and fake/pseudo properties which we're 
> pretending exist so that we can re-use a piece of syntax that expects a 
> property name. Once these pseudo properties are released into the wild, 
> they'll show up as if they were real.

They would be real, I'm just saying that documenting them and implementing 
them is somewhat trivial.


> What we want to avoid is saying things like:
> 
> "You can use itemprop='containedIn-rev' to indicate a property that
> means the inverse of containedIn. However this is not a first class
> schema.org property, and should not be used other syntaxes (JSON etc),
> data dumps, APIs etc. You should canonicalize x containedIn-rev y
> into: y containedIn x., ..."

Why wouldn't it be a first-class property? It could trivially be so. The 
implementation is easy, whatever the vocabulary it's used in.


> > 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.
> 
> Thanks! I'll discuss this thread with the schema.org team. My guess is 
> that there's still a strong preference for a new property, and we'd be 
> happy to avoid using data-*.
> 
> If I understand right, the outstanding area of discussion/confusion is 
> whether there are cases beyond simple DOM element containment where we 
> might want to use an inverse itemprop construction (even though we can 
> see how itemid everywhere might also be used). If we're only using 
> element hierarchy then itemprop-up could work.

Did you reach any conclusions in these discussions?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 2 April 2014 18:09:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:28 UTC