itemproperty-reverse questions

[sesuncedu]

1. Is the mechanism for finding the reverse properties of an item precisely the same as that for finding the properties of an item, with the attribute name "itemprop-reverse" used in place of "itemprop"?
   The definitions in §A.1 seem wrong or incomplete- they seem to suggest that the reverse properties of an item are those found by splitting the attribute on the top-level item, which is obviously wrong; using the approach above passes the unit tests, but since the tests do not address a number of issues that leaves me with some open questions- e.g. are itemrefs followed when finding the reverse properties?
2. Should reverse item properties that have sub/equivalent properties defined in the active registry entry generate extra triples? The algorithm says no, so I'm not, but there doesn't seem to be an obvious reason why.
3. Is the definition of top level item changed to be elements with @itemscope but with neither @itemprop nor @itemprop-reverse present?

[gkellogg]

Is the mechanism for finding the reverse properties of an item precisely the same as that for finding the properties of an item, with the attribute name "itemprop-reverse" used in place of "itemprop"?

The mechanism is pretty much equivalent to finding the properties of an item, except that @itemprop-reverse is used instead of @itemprop. The main difference is that item properties is defined using the Microdata DOM API element.properties, while reverse item properties cannot use this API definition.

The definitions in §A.1 seem wrong or incomplete- they seem to suggest that the reverse properties of an item are those found by splitting the attribute on the top-level item, which is obviously wrong; using the approach above passes the unit tests, but since the tests do not address a number of issues that leaves me with some open questions- e.g. are itemrefs followed when finding the reverse properties?

The processing steps for @itemprop-reverse are almost exactly the same as for @itemprop. As the mechanism for dealing with @itemprop is defined in the Microdata spec, this means that @itemprop-reverse is indeed under-specified. The properties of an item is defined in the Microdata spec using @itemprop. The reverse properties term in Microdata to RDF should better reference the properties of an item substituting @itemprop-reverse for @itemprop. And, it is not an item's @itemprop-reverse attribute, but rather those from the descendent elements of an item.

My own implementation has an #item_properties method, which can be used for either @itemprop or @itemprop-reverse, so the processing decisions are pretty much equivalent.

Additional test cases exposing corner cases would be welcome; consider making a pull-request with additional tests.

Should reverse item properties that have sub/equivalent properties defined in the active registry entry generate extra triples? The algorithm says no, so I'm not, but there doesn't seem to be an obvious reason why.

No, there is no motivating use-case to support doing this, so the added complexity is not required.

Is the definition of top level item changed to be elements with @itemscope but with neither @itemprop nor @itemprop-reverse present?

top-level item's definition hasn't changed, and defers to the Microdata document.getItems API. If the non-normative appendix were incorporated into the document, it could be updated as you say, but then it couldn't use the Microdata definition as it presently does. Ideally, with implementation, @itemprop-reverse will be incorporated into Microdata, and this will obviated. As a practical matter, if a top-level item were found with @itemprop-reverse, it should properly generate triples, as that item would define a subject, which would be used as the object for the value of the @itemprop-reverse, so no change may be necessary. This would be a useful corner-case.

Ideally, a future Rec-track spec will re-merge both Microdata and Microdata to RDF, so all of these things can be defined in one place. Until then, this document is not likely to be re-published for some time.