Re: Understanding 'chaining'

Hi guys,

This is just a note that I am back from China:-), with a bit of jet-lag...

Mark, thanks for this 'hanging @rel' explanation, this helps in
understanding the intentions of what is happening. I am not sure how
exactly the processing model of @instanceof fits into the picture, I
still have to think about this... Do you have a similar description for
that part?

My first, initial reaction is that the parsing/generation process might
become somewhat more complex (putting my implementor's hat on). The
current scheme is certainly simple and that is the plus. But maybe I am
wrong.

On the other hand Ben's example:

<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>

is actually a nice use case, in the sense that expressing

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

succinctly in the current scheme is not that easy...

I will play with this thing in my head!

Ivan


Mark Birbeck wrote:
> 
> 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
> 

-- 

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