Re: New processing rules

Hi Ivan,

Am I glad that I sent this out in advance. :)

You are exactly right on the first point, and I'll rectify that now.

The @src question you are also right on, but that was intentional.
Perhaps I've jumped the gun in assuming that is the way things have
gone. I'll look at this too.

Thanks for taking a look at it.

Regards,

Mark

On 13/12/2007, Ivan Herman <ivan@w3.org> wrote:
> 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
>
>


-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Thursday, 13 December 2007 15:51:58 UTC