Re: New processing rules

Mark,

in trying to understand your description, I stumbled into two
questions... (although, I suppose, I should wait for the final write-up,
but you asked for it:-)

- how does your description account for

<div about="#a" rel="a:b">
  <span property="q:r">bla</span>
  <span property="w:e">another bla</span>
</div>

In my understanding of the previous mails is that the following triples
should be generated

<#a> a:b [
   q:r "bla";
   w:e "another bla"
].

whereas my reading of your rules yields:

<#a> a:b [ q:r "bla" ];
     a:b [ w:e "another bla" ].

do I miss something?

- an old use case for @instanceof was the

<div about="#a" >
   <img rel="a:b" src="http://a.b.c" instanceof="w:p"/>
</div>

where we wanted rdf:type to apply on <http://a.b.c>. My reading from
these rules is that this will not happen...

again, do I miss something?

Ivan

Mark Birbeck wrote:
> Dear all,
> 
> I'm behind schedule with updates to the draft, mainly because I've
> been implementing the new rules as a prelude to writing them up. I've
> now got the code as compact as I think it will go, and it's turned out
> to be much simpler than I thought it would. So I thought it worthwhile
> to send the rules as I see them, to the list, so that people can look
> at them and comment if they want. I'm thinking that this can go on in
> parallel with me continuing with the syntax document, but might save a
> little time.
> 
> Essentially the changes are to the processing of @rel/@rev, which
> stores the incomplete triples when there is no object rather than
> creating a bnode. There is also a new step that 'completes' the
> incomplete triples.
> 
> However, during the course of working on this I've restructured the
> part that establishes the subject, which I think ends up being easier
> to follow.
> 
> Anything I don't mention, such as setting language or @base, is unchanged.
> 
> 
> SETTING THE SUBJECT
> 
> The first step is to create a 'new subject' value, which is not yet
> written into the context:
> 
> ===
>   If @about is present that always sets the subject;
> 
>   otherwise, if we have an inherited subject, that sets the subject;
> 
>   otherwise, if (
>     @instanceof is present
>     OR
>     (there are 'incomplete triples' AND one of @rel, @rev or @property
> is present)
>   )
>     set the subject to a bnode.
> ===
> 
> This seems to me a little easier than our old processing description.
> It essentially amounts to @about always setting a new 'subject', no
> matter what. (This is something that Ivan drew attention to when
> looking at the new chaining approach.)
> 
> It also emphasises that if there is an object resource coming from the
> parent statement, then it is always used as the subject, no matter
> what the predicates are that appear on the statement currently being
> processed.
> 
> The final step is only reached if there is no @about, and we have no
> 'inherited subject', which seems to me to be a useful clarification,
> making it much easier to remember and read. In this situation we will
> ALWAYS create a bnode if @instanceof is present, but we won't
> necessarily create a bnode if one of @rel, @rev or @property is
> present; in the latter situation we only create a bnode if there are
> 'incomplete triples'.
> 
> This combination provides a further useful clarification which is that
> if there are no RDFa attributes present on an element then no bnode is
> created.
> 
> 
> COMPLETING TRIPLES
> 
> If a 'new subject' is established it is then used to complete any of
> the incomplete triples that may have been stored. Once this has been
> done the list is cleared, and the subject in the context is set to the
> 'new subject'.
> 
> There are three reasons I've done it this way; the first is that it
> means we can get rid of the chaining flag, since we're now passing a
> value down, when necessary. The second is that it allows us to
> distinguish between a subject set by normal inheritance, and a subject
> set via @resource, @href or @src, which is important for the proper
> working of @instanceof. And finally, doing it this way means that when
> we store 'incomplete triples' we only need to store the predicates,
> rather than the subject as well. (We also need to store the
> 'direction', i.e., @rel or @rev.)
> 
> In the implementation of the code I've saved having to create an extra
> flag in the context object, by simply doing a 'for' loop based on the
> size of the array, which could of course be zero. If no-one
> anticipates a problem, I'll also use the same technique in the
> pseudo-code for describing the processing rules.
> 
> 
> SETTING OBJECT RESOURCES
> 
> If there is an @href, @resource, or @src then processing is the same
> as it is now, i.e., create the triples. However, instead of setting a
> chaining flag on the context, we just pass the object down as an
> inherited value, and this is then used to set the subject after a few
> other things have happened (see above).
> 
> However, if none of these attributes are present, we no longer need to
> create a bnode since that will be created in the subject-setting phase
> (as described above) when processing is applied to any nested
> statements. Instead, we store an 'incomplete triple' for each of the
> predicates that is present. (Actually we need only store the
> predicates.) The location of this array is the context object, which
> means that it will be pushed and popped from the stack as processing
> continues.
> 
> 
> SETTING OBJECT LITERALS
> 
> As we have it now.
> 
> 
> CHAINING FLAG
> 
> This is no longer needed.
> 
> 
> NEXT STEPS
> 
> I'll endeavour to have these rules incorporated into the document for
> tomorrow's meeting, but I'm getting a lot of things trying to steal my
> time from me...so hopefully, even if I don't quite make it, this short
> description should give everyone enough to go on, to see if everything
> is starting to hang together.
> 
> Regards,
> 
> Mark
> 

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf