RDFa output incorrect when not using entity template (Views, Panels, etc) or when render array is altered

Problem/Motivation

The RDFa generated by core's RDF module relies on the structure of the HTML—the nesting of theme_field's output inside node.tpl.php's output—to associate the property with its subject entity. This works when an entity is viewed using the entity template, as on the node page.

However, in other cases such as Views, Panels (and I presume D8's Blocks Everywhere), you can't assume that rendering will happen this way. The HTML for a field might sit within the entity's div... or it might be off in a sidebar by itself, or inside a different entity's div. This is also true if a site developer alters the render array to move field's out of their containing divs (a use case JohnAlbin brought up at DrupalCon London).

The problem here is that we depend on an implicit relationship between the field and the entity which is inferred from HTML structure... we don't explicitly state that relationship.

This leads to metacrap when using RDFa and Views/Panels. It has been documented in an issue in the Views queue.

An example

There is a View that shows a list of events, including the location of the event. Locations can be reused across events, so they are handled as their own entity, which has a street address field. The fields used for the view are Event name, Location name, and Location street address. (For the sake of argument, the title is a real field handled by the field system)

Here are the two objects that you should get from the RDFa:

example.org/event/1

• type = schema.org/Event
• schema.org:name = Black Mark release party
• schema.org:location = example.org/location/1

example.org/location/1

• type = schema.org/PostalAddress
• schema.org:name = Brillobox
• schema.org:streetAddress = 4401 Penn Ave.

Instead, what you get is:

example.org/views-page

• schema.org:name = Black Mark release party
• schema.org:name = Brillobox
• schema.org:streetAddress = 4401 Penn Ave.

Proposed resolution

Explicitly state that the field is a property of the entity.

I've done this in Microdata module using the itemref attribute which the microdata syntax provides. While this doesn't add the relationship between the event and it's location, it does ensure that the properties of the two objects don't get mashed up into metacrap.

For example, the location looks as follows in Microdata:

<meta itemscope="" itemtype="http://schema.org/PostalAddress" itemref="md2 md3" />
...
    <div class="field">
      <div class="field-items" id="md2">
        <div class="field-item" itemprop="name">
          Brillobox
        </div>
      </div>
    </div>
...
    <div class="field">
      <div class="field-items" id="md3">
        <div class="field-item" itemprop="streetAddress">
          4104 Penn Avenue
        </div>
      </div>
    </div>
...

While RDFa has no support for itemref (and the editor had no intention of introducing it the last time we discussed it), we could use a different feature of RDFa to do approximately the same thing. We could add the about attribute to each field.

<meta typeof="http://schema.org/PostalAddress" about="http://example.org/location/1" />
...
    <div class="field" about="http://example.org/location/1">
      <div class="field-items">
        <div class="field-item" property="schema:name">
          Brillobox
        </div>
      </div>
    </div>
...  
...
    <div class="field" about="http://example.org/location/1">
      <div class="field-items">
        <div class="field-item" property="schema:streetAddress">
          4104 Penn Avenue
        </div>
      </div>
    </div>
...

Downside

The downside of this is that we pepper our source code with the full URI of the entity, once for each field. I do believe this will lead the frontend performance folks to chuck tomatos at us.

Remaining tasks

Discuss ramifications / devise plan