Re: Understanding 'chaining'

Ben, Mark,

I have played with the 'alternative' approach in my mind yesterday for a
good while. Thanks to Mark's email and his 'hanging @rel' explanation I
think (I hope...) I do understand the alternative. And my current
conclusion is... I just do not see any compelling reasons to change our
current model (let us put @instanceof aside for a moment, see below).
Sorry Mark...;-)

What made me tip the balance is one of Ben's example, namely:

<div about="#me" rel="foaf:knows">
  <span property="foaf:firstname" content="Ivan"></span>
  <span property="foaf:lastname" content="Herman"></span>
</div>

yielding (in his mail)

<#me> foaf:knows [foaf:firstname "Ivan" ; foaf:lastname "Herman"] .

I am sorry, but I find it highly inconsistent. I know that it can be
explained process-wise (see Mark's mail) but for a user I still find it
extremely disturbing. As far as I am concerned, the natural
interpretation of the code above would be

<#me> foaf:knows [foaf:firstname "Ivan"], [foaf:lastname "Herman"] .

Which, I presume, is really not what we want. The inconsistency becomes
even more appearent for me if I write

<div about="#me" rel="foaf:knows">
  <span property="foaf:firstname" content="Ivan"></span>
  <span property="foaf:lastname" content="Herman"></span>
  <span about="#mark" property="foaf:lastname" content="Birbeck"></span>
</div>

That would yield, in the new model:

<#me> foaf:knows
 [foaf:firstname "Ivan" ; foaf:lastname "Herman"], <#mark> .
<#mark> foaf:lastname "Birbeck".

Ie, some of the span-s are merged for one subject, the third is not. A
huge source of confusion, imho.

We do have a model that works, that seems to be accepted by those in the
community who have cared to look at it (and there are a lot of those in
the past weeks, yey!), we have some larger use cases (like my foaf.html)
that can be used to encode things one wants, has already been
implemented by a number of implementations... I do not see _any_ reason
to change it. And, as Ben said, this _is_ a radical change both in the
processing model and in the 'mental' model, so to say, for the user and
the implementors.

Yes but, you will say, what happens to @instanceof? Well, I came up
yesterday evening with a slightly different solution. It may raise some
eyebrows; bear with me:-) But let us see if it makes some sense.

The issue we have with the current @instanceof is to properly define
what the subject of the rdf:type triple is. Depending on the use cases,
it seems that we need to flip/flop among various candidates and that
makes it, well, confusing. Also, I think we all agree that @instanceof
should be some sort of a shorthand with very little change on the core
processing model.

Well, we already have a way to 'flip/flop' the subject of triples
through the @rel/@rev duality. In my mental model, the way I can
characterize is that:

- @rel's subject is either @about or the 'inherited' resource coming
from the parent
- @rev's subject is the resource sent 'down' to through the chaining
(and taken into account, via inheritance, by the children)

Well, why don't we take the exact analogy and define _two_ shorthands
for typing. Bye bye @instanceof, let us have two of these instead; for
the time being I call them @trel and @trev (we can have happy discussion
for the right name). The semantics is

- @trel's subject is either @about or the 'inherited' resource coming
from the parent
- @trev's subject is the resource sent 'down' to through the chaining
(and taken into account, via inheritance, by the children)

Ie, _exactly_ like @ref/@rev. In other words, I just bring our issue of
finding the right subject for rdf:type into the open and leave it to the
user. I think that @trel/@trev should however _not_ start to chaining in
contrast to the current processing description. They just assign type(s)
to whatever is defined. This is the _only_ difference in behaviour
between @rel/@rev and @trel/@trev.

This means that

<span about="#a" trel="a:b" href="http:tra.la.la" rel="bla:bla">

yields

<#a> bla:bla <http:tra.la.la>;
     rdf:type a:b.

whereas

<span about="#a" trev="a:b" href="http:tra.la.la" rel="bla:bla">

yields

<#a> bla:bla <http:tra.la.la>.
<http:tra.la.la> rdf:type a:b.


<span about"#a" trel="a:b">

yields

<#a> rdf:type a:b.

<span about="#a" rel="foaf:knows" trev="foaf:Person">

yields

<#a> foaf:knows [ rdf:type foaf:Person ].

Note that

<span about="#a" trel="a:b">

and

<span about="#a" trev="a:b">

yield, actually, the same triples because, according our rules, <#a>
will be sent 'down' to the children. I do not think it is a problem. Also

<span trel="a:b">

will assign a "a:b" type to the 'inherited' resource (ie, possibly to
the base URI) which is again fine with me.

At the moment at least, this approach works for me and may break the
@instanceof deadlock...

Comments, issues, big NO-NO-s?

Ivan


Ben Adida wrote:
> 
> 
> Mark,
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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?
> 
> 
> 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'll stop here and see what Mark thinks. Maybe this is consistent and
> everyone is happy, or maybe it begins to reveal some issues that need
> addressing.
> 
> -Ben
> 

-- 

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