Re: Understanding 'chaining'

Hi Ben,

I agree with all of your interpretations--I just hope that other  
people find these cases comprehensible, too.


On 21 Nov 2007, at 23:39, Ben Adida wrote:
> Okay, let's explore how this chaining approach will work, in  
> detail. For
> everyone else, I want to highlight two important points:
>
> 1) Mark's proposal is a *significant* change from what we've been
> discussing over the last few weeks. A lot of simple cases work the  
> same
> way, but a number of more complex cases change fairly radically.
>
> 2) If it works, I'm not going to fight it :)
>
> The main issue is that you're reintroducing a form of predicate
> inheritance, which is the key thing that made chaining awfully
> complicated the first time around. Can we get around the complexity  
> this
> time? Let's see.

I agree with you, and after looking at this in great detail over the  
last few months, I definitely agree with you that we can explain this  
whole area much more clearly than it was in the past.

I've given this a shot below, but I'm sure that you can refine it  
further. (And of course other people should feel free to chime in,  
too.) We probably agree that to a great extent, the key to making  
these things easier to comprehend lies in finding a phrase or word  
that captures the concept; so below I've experimented with some terms  
that might help, like 'hanging @rel', 'incomplete triple', and such  
like. Of course, there are probably better terms, and as the person  
who coined the phrase 'bridging the clickable and semantic webs' I'm  
hoping you'll come up with one. :) (That will be on your tombstone. :))


> The difference between having the object of the parent set the subject
> of the child (the existing rules) and having the subject of the child
> set the object of the parent (the new/old rule you're proposing) is  
> that
> elements have a single parent, but they often have many children.

That's right, although the 'old rule' coped with this because the  
rule was applied at the child, not the parent, which I'll show below.


> Every example you've given shows chaining where there is only one  
> child.
> What happens when there's more than one?
>
> Let's look at some examples:
>
> 1) Multiple Children
>
> ====
> <div about="#me" rel="foaf:knows">
>
>   <span about="#ivan" property="foaf:name" content="Ivan"></span>
>
>   <span about="#ralph" property="foaf:name" content="Ralph"></span>
>
> </div>
> ====
>
> I suppose this means:
>
> <#me> foaf:knows <#ivan> ;
>       foaf:knows <#ralph> .
>
> <#ivan> foaf:name "Ivan" .
> <#ralph> foaf:name "Ralph" .
>
> Note the significant change: one @rel now generated two triples,  
> whereas
> one @rel used to be exactly one triple. Is this the behavior we  
> want? No
> real issue on my end, but note the change.

This is very well put, and I'm very keen to hear what others think,  
too, on how intuitive this is.

In my 'mental model', the key thing is the idea of a 'hanging @rel',  
by which I mean that you have a @rel with no object. As I've said in  
other posts, this is not something that ever occurs in 'normal' HTML/ 
XHTML, so it's a handy way for human readers of a document to spot  
that something is up, and that you now have to look somewhere else  
for the object.

The current rules effectively say that 'when the parser sees the @rel  
it should then go and find the object', and this is of course why you  
say "one @rel used to be exactly one triple". I think the current  
rules are slightly wrong anyway, regardless of whether we adopt the  
'new/old' chaining rules I'm proposing, since the current rules will  
generate a triple in the following circumstances:

   <div rel="foaf:knows" />

which is pointless. In my view we shouldn't really be saying 'one  
@rel always generates one triple'; the triple shouldn't get generated  
until the next subject is found, which is essentially what I'm  
proposing here.

In the 'old rules' a @rel on its own did not generate anything. But  
when the parser got to the next set of mark-up--in your example the  
lines with @about on--it would effectively say 'are we in a hanging  
@rel...if so generate the trailing triple'.

In other words, when this line was parsed:

> <div about="#me" rel="foaf:knows">

the parser would store 'two thirds' of a triple, i.e.,

   <#me> foaf:knows ?o .

as well as storing the generated bnode, just in case once is needed.  
So the major difference between this behaviour and what we have in  
the current parsing model is that instead of unconditionally  
generating this triple:

   <#me> foaf:knows <bnode> .

we simply store the 'components' of the triple (the subject/predicate  
as one unit, and the generated bnode as the other).

Now, with these pieces stored in the context, processing continues to  
the next couple of lines:

>   <span about="#ivan" property="foaf:name" content="Ivan"></span>
>
>   <span about="#ralph" property="foaf:name" content="Ralph"></span>

In the @about processing the parser now checks the context for the  
'hanging triple' situation (i.e., the presence of the subject/ 
predicate unit) and if there is one, the 'incomplete triple' gets  
completed. Note that this happens twice--once for each subject  
resolution step:

   <#me> foaf:knows <#ivan> .
   <#me> foaf:knows <#ralph> .

Although we stored the generated bnode in the prior processing step,  
since both elements use @about the bnode was not needed; this is  
exactly the same as current processing rules, and in fact, all other  
processing is as normal, so you still get Ivan and Ralph's names, as  
you showed above.


> 2) Let's remove the URIs
>
> ====
> <div about="#me" rel="foaf:knows">
>
>   <span property="foaf:firstname" content="Ivan"></span>
>
>   <span property="foaf:lastname" content="Herman"></span>
>
> </div>
> ====
>
> Is that the same bnode with the two properties firstname and lastname?
> Or are those two separate bnodes? From the way we've been doing  
> chaining
> the last few months, it should be *one* bnode, I think:
>
> <#me> foaf:knows [foaf:firstname "Ivan" ; foaf:lastname "Herman"] .
>
> Is that consistent with #1, where we had two resources?

I think this generates the same set of triples as our current  
processing rules do, although how we achieve the result is via a  
slightly different sequence of logic.

So as we currently do, the presence of the 'hanging @rel' causes the  
parser to generate a bnode. But in addition, the 'new rules' suggest  
that we also store the subject/predicate of the 'incomplete triple',  
triggered by the 'hanging @rel'. Now, when we get to the subject  
resolution point on the two lines below, the current rules say that  
we should simply use the previously generated bnode, and that is what  
we do:

   <bnode> foaf:firstname "Ivan" .
   <bnode> foaf:lastname "Herman" .

But in addition, the 'new' rules say that if there is a 'hanging  
@rel' value (i.e., a subject/predicate unit has been stored,  
representing an 'incomplete triple') then we should also 'complete  
the triple', and generate this:

   <#me> foaf:knows <bnode> .

As I said, this gives us exactly the same set of triples as our  
current parsing rules, but via a slightly different route.


> 3) Let's add @instanceof to one of the elements
>
> ====
> <div about="#me" rel="foaf:knows">
>
>   <span property="foaf:firstname" content="Ivan"
> instanceof="foaf:Person"></span>
>
>   <span property="foaf:lastname" content="Herman"></span>
>
> </div>
> ====
>
> I think we're back to two bnodes?
>
> <#me> foaf:knows [foaf:firstname "Ivan" ; rdf:type foaf:Person] ;
>       foaf:knows [foaf:lastname "Herman"] .

I agree with your approach...although if other people think this is  
not intuitive then they should shout. :)

I would constuct the triples, as follows. I read the presence of  
@instanceof as saying 'this element carries an object of type x and  
all other properties belong to it'. As we know from current rules, if  
there is no 'name' for this object (i.e., there is no @about) then we  
generate one.

Once this bnode has been generated, then from this point on the  
behaviour is exactly the same as that described above for @about, in  
that not only do we generate the triples described by the element  
itself:

   <bnode> foaf:firstname "Ivan" .
   <bnode> rdf:type foaf:Person .

but also we spot the 'incomplete triple' caused by the 'hanging  
@rel', and so we complete it:

   <#me> foaf:knows <bnode> .


As a postscript I would say that the key thing about these examples  
is that what jumps out at you to indicate that you have a self- 
contained unit is the presence of @about, or the presence of  
@instanceof. When reading mark-up it is easy to see that you have a  
unit of information that can be picked up and moved around, when you  
spot these attributes on an element, and this holds true regardless  
of what other attributes are present.

Thanks for laying this out so clearly Ben, since I know that's a lot  
of work.

Regards,

Mark

-- 
   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, 22 November 2007 12:04:38 UTC