W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > April 2012

Re: Processing "incomplete triples" when direction is "none"

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Mon, 9 Apr 2012 00:21:30 -0400
To: Grant Robertson <grantsr@gmail.com>
CC: RDFa Working Group <public-rdfa-wg@w3.org>
Message-ID: <413E27D8-CF9F-4557-90A2-82941D0B7B7B@greggkellogg.net>
On Apr 8, 2012, at 7:45 PM, Grant Robertson wrote:

> In RDFa Core 1.1, Section 7.5, Step 12 (completing "incomplete triples" passed down from the parent element):
> There is a statement that say's: "If direction is ’none’, the new subject is added to the list from the iterated incomplete triple." I cannot figure out what that means.  OK, I know the direction would have been set to "none" if the incomplete triple was originally created in an element containing @inlist (per Step 10). However:

So, basically in Step 12, we have saved information to be used later when we have an object to use to generate a triple. In the forward and reverse case, this is because a subject and predicate were set, and we're using that when we discover an object to generate that triple (or having object and predicate discover a subject, if direction is reverse).

Because hanging @rel can also be used for creating lists, we use the same mechanism to add a new member to a list instead. Because a list is implemented using a linked list with BNodes, we can't actually generate anything, but we do keep track of a new object to add to the list.

In step 9 we create a local list mapping when we see @inlist. This is the mapping to which we add objects in step 12 when direction is "none".

When we've come back to the place where the list was defined, in step 14, we actually create the list.

> A) I don't get the point of the whole procedure.
> B) Which list are you talking about?

The list is defined in step 9 in the "local list mapping". When we see a property from @rel or @rev, this creates an entry in the local list mapping for each property. Basically, the list is an array to which objects will be appended until we get to the end of processing at the same level where the list was defined, which then allows us to generate the list.

> C) By "iterated incomplete triple" do you mean the incomplete triple you are processing right now?

Probably poor wording. Basically, the incomplete triple saves a direction and an predicate. We're using the predicate to identify the list within local list mapping to which new subject will be added.

> C.1) If so: how can an "incomplete triple" - which is actually just a predicate with a direction - even have a "list"?

The incomplete triple identifies the predicate, used to find the list from local list mapping to which new subject is added.

> C.2) How would it ever be appropriate to put a "resource IRI" into a list for "predicate IRIs"?
> Unless ...  
> Do you mean that the predicate from the "incomplete triple" should be added to what you folks call the "local list mapping" (if it isn't already there) and then the [new subject] should be added to the list associated with that triple, as per the normal processing for @inlist list items?

The entry in the local list mapping will already have been created in step 9. But, basically, that's correct.

> Is the point of this whole process to defer actually adding to the "list associated with the predicate" until you have a [new subject] from a child element that can be treated as an object for that "incomplete @inlist list item" from that child's parent?


Hope that helps,

Received on Monday, 9 April 2012 04:22:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:56 UTC