Re: Reproducing Gregg/Niklas' thoughts (@itemref issue) (ISSUE-144)

I'm adding Martin to the conversation, as he is one of the main proponents of an @itemref like feature in RDFa.

On Dec 8, 2012, at 11:54 AM, Dan Brickley <danbri@danbri.org> wrote:

> I'm afraid I'm getting lost amongst the design options and detail. Would it be possible to have a high level summary of the current design candidates? Ideally something self-contained enough that I can fwd around to interested parties. For my part I will try to collect some microdata itemref use cases to share here.

Well, it's probably too soon to know exactly where this is going, but this is my understanding:

Microdata users tout the important of @itemref for a variety of reasons, some less useful than others. The @itemref feature is similar to the Microformats "include pattern" [1], and operates at a syntactic level within the DOM. This means that when referencing an element, the state of the processor at the time the reference is made is significant. The only practical use for this is when multiple vocabularies are used within a document, and the property used should take on the vocabulary of the @itemtype in the referencing element. Given that microdata is pretty much just about schema.org, this is not very likely; certainly not for the schema.org members who don't look at any other vocabularies anyway.

Ivan put forth a proposal some time ago [2] which takes a similar approach; basically, it copies elements within the DOM in order to have them within the referencing scope. The problem with this, unless you use a shadow DOM, is that it ends up changing the document that is being processed, which would look odd on the screen.

The second proposal put forward [3] is based on work by Niklas, Ivan and myself, which uses a SPARQL 1.1 INSERT/DELETE expression operating on RDFa-specific terms to copy statements made about a prototypical element to a referencing element. The idea is that we introduce an rdfa:ref property, which references an entity of type rdfa:Prototype, and copies over relevant statements into the referring subject. For example:

<div resource="#p" typeof="rdfa:Prototype">
  <span property="foo">bar</span>
</div>
...
...

<div resource="#A">
  <span property="yep">Yep Yep</span>
  <span property="rdfa:ref" resource="#p"/>
</div>

This would yeild the following Turtle:

<#p> a rdfa:Prototype; <foo> "bar" .
<#A> <yep> "Yep Yep"; rdfa:ref <#p> .

You then run the following SPARQL (or equivalent):

INSERT DATA {?x ?p ?y .}
DELETE DATA {
  ?x rdfa:ref ?PR .
  ?x rdf:type rdfa:Prototype .
  ?PR ?p ?y .
}
WHERE {
  ?x rdfa:ref ?PR .
  ?PR ?p ?y.
  ?PR a rdfa:Prototype .
}

and out the other side comes the following:

<#A> <yep> "Yep Yep"; <foo> "bar".

The achieves semantically, the essence of what microdata does syntactically: it allows common statements to be made in a single location and referenced from multiple other locations within the document without requiring repetition.

It's important to note that may uses of @itemref in microdata do not require this feature in RDFa:

* the same subject can be repeated in multiple locations using @resource.
* the @rev feature (not in Lite, of course) can be used to assert a relation on multiple subjects (although there is no equivalent solution for literals; Niklas has proposed something though).
* some of the uses sited for Good Relations could be solved instead using Product and ProductModel together.

Note that the rdfa:ref/Prototype do not affect the core RDFa processing rules, but are done in a post-processing phase, similar to the optional vocabulary expansion step. We'd need to decide if reference folding is an optional or mandatory step; presumably it would not be as useful unless it were mandatory.

Gregg

> Dan

[1] http://microformats.org/wiki/include-pattern
[2] http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Nov/0003.html
[3] http://lists.w3.org/Archives/Public/public-rdfa-wg/2012Dec/0007.html

Received on Monday, 10 December 2012 02:39:47 UTC