Support @itemprop-reverse

[gkellogg]

There is general consensus around adding support for a new @itemprop-reverse attribute. This would work similarly to @rev in RDFa: it must be used on an element taking a URI value (such as link), and has the effect of generating a triple with the property value as the subject, and the current item as the object.

<div itemscope itemtype="http://schema.org/Offer">
    <span itemprop="name">Book offer blabla</name>
    <!-- other offer properties here -->
    <!-- the offer is made by Amazon -->
    <link itemprop-reverse="makesOffer" href="http://www.freebase.com/m/0mgkg">
</div>

@itemprop-reverse might also be used along with @itemscope to link back from the contained item. The following example shows simultaneous use of both @itemprop and @itemprop-reverse to create both forward and reverse links:

<div itemscope itemtype="http://schema.org/Organization">
   <span itemprop="name">Cryptography Users</span>
   <div itemprop-reverse="memberOf" itemprop="member" itemscope
         itemtype="http://schema.org/OrganizationRole">
     <div itemprop-reverse="memberOf" itemprop="member" itemscope
             itemtype="http://schema.org/Person">
       <span itemprop="name">Alice</span>
     </div>
     <span itemprop="startDate">1977</span>
   </div>
</div>

[iherman]

I am a little bit uneasy adding a feature like that which is not defined by the microdata specification. The only proper way of doing this would be to update the microdata specification, too, but we should not do that without the participation of Ian.

Is this feature now introduced and used in schema.org?

Ivan

On 31 Oct 2014, at 16:28 , Gregg Kellogg notifications@github.com wrote:

There is general consensus around adding support for a new @itemprop-reverse attribute. This would work similarly to @Rev in RDFa: it must be used on an element taking a URI value (such as link), and has the effect of generating a triple with the property value as the subject, and the current item as the object.

Book offer blabla

@itemprop-reverse might also be used along with @itemscope to link back from the contained item. The following example shows simultaneous use of both @itemprop and @itemprop-reverse to create both forward and reverse links:

Cryptography Users

Alice

1977

—
Reply to this email directly or view it on GitHub.

---

Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
GPG: 0x343F1A3D
WebID: http://www.ivan-herman.net/foaf#me

[gkellogg]

I believe @danbri cleared the way for it, and there is a real need. I have it implemented in my processor. The key is that we are clear to use the attribute, not that there is a processing model in Microdata, IMO.

The community must decide.

[iherman]

On 31 Oct 2014, at 20:30 , Gregg Kellogg notifications@github.com wrote:

I believe @danbri cleared the way for it, and there is a real need. I have it implemented in my processor. The key is that we are clear to use the attribute, not that there is a processing model in Microdata, IMO.

The community must decide.

Well... at the end of the day, of course. But I am still uneasy about this. It is not the role of the serialization document to get ahead of the core specification, ie, which is the microdata spec. I think it becomes a dangerous precedent if the mdata->RDF spec goes ahead and, in some sense, specifies an attribute itself.

This is maybe something to see with danbri. If he thinks this is really important, he should get Ian to update the official microdata specification in this respect. Until that is done, I think we should hold back...

Ivan

—
Reply to this email directly or view it on GitHub.

---

Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
GPG: 0x343F1A3D
WebID: http://www.ivan-herman.net/foaf#me

[danbri]

There's a thread in html whatwg list where Hixie says he'll reserve the
attribute pending a proposal. I think similar feasible re w3c flavour.

I believe appropriate focus now is experimental implementation (eg also
Apache any23) rather than worrying about making "it" 100% official. We need
a stronger writeup of proposal and a place to collect unit tests.
On 1 Nov 2014 05:44, "Ivan Herman" notifications@github.com wrote:

On 31 Oct 2014, at 20:30 , Gregg Kellogg notifications@github.com
wrote:

I believe @danbri cleared the way for it, and there is a real need. I
have it implemented in my processor. The key is that we are clear to use
the attribute, not that there is a processing model in Microdata, IMO.

The community must decide.

Well... at the end of the day, of course. But I am still uneasy about
this. It is not the role of the serialization document to get ahead of the
core specification, ie, which is the microdata spec. I think it becomes a
dangerous precedent if the mdata->RDF spec goes ahead and, in some sense,
specifies an attribute itself.

This is maybe something to see with danbri. If he thinks this is really
important, he should get Ian to update the official microdata specification
in this respect. Until that is done, I think we should hold back...

Ivan

—
Reply to this email directly or view it on GitHub.

---

Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
GPG: 0x343F1A3D
WebID: http://www.ivan-herman.net/foaf#me

—
Reply to this email directly or view it on GitHub
#5 (comment).

[gkellogg]

That's consistent with putting it in the spec as an issue (possibly "at-risk") and creating test cases.

I don't think it's possible to create in the Microdata-JSON serialization, without resorting to something like JSON-LD's @reverse keyword, which seems very unlikely, so just making sure that the meaning of the attribute is reserved is about as much as we can hope for.

[iherman]

On 01 Nov 2014, at 23:48 , Gregg Kellogg notifications@github.com wrote:

That's consistent with putting it in the spec as an issue (possibly "at-risk") and creating test cases.

I know this is a minor issue, but even at-risk is something too strong at this point because it gives the impression that implementers are, sort of, required to do this even if it may disappear in future. Maybe flagging it as 'experimental' or 'optional' is a slightly better approach.

Ivan

I don't think it's possible to create in the Microdata-JSON serialization, without resorting to something like JSON-LD's @reverse keyword, which seems very unlikely, so just making sure that the meaning of the attribute is reserved is about as much as we can hope for.

—
Reply to this email directly or view it on GitHub.

---

Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
GPG: 0x343F1A3D
WebID: http://www.ivan-herman.net/foaf#me

[iherman]

The feature is now part of the second edition as an 'experimental' one. I mark this issue as postponed.