Re: Understanding 'chaining'

Hi Ivan,

I'm a little bemused by phrases like "extremely disturbing", "highly
inconsistent", "a huge source of confusion", etc. Anyone skim-reading
posts to this list would think that RDFa is about to collapse under
the weight of its own illogicalities, rather than being one issue away
from completeness.

But worse is that on a couple of occasions in your post, you use these
kinds of emotive phrases to describe something that is supported in
RDFa now. This will no doubt be very confusing for anyone trying to
follow this debate, so it's these points that I'd like to focus on.


> 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...;-)

Perhaps it didn't come across very clearly, but in my 'version' of
chaining the only thing that changes is that we establish a symmetry
between omitting an object and omitting a subject. So it's not really
an 'alternative', but rather the addition of a rule to complete the
symmetry. Without it, in our current parsing rules, the following does
not do anything useful:

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

I believe that this is not intuitive, and could even get raised as a
Last Call question.



MISSING PERMUTATION

To illustrate where the missing permutation lies, let's say we that we
have a 'chain' like this:

  A -> B -> C

which might be represented by the following triples:

  <A> p:p1 <B> .
  <B> p:p2 "C" .

With our current rules we can mark this up either in this way (where B
is explicit):

  <div about="A" rel="p:p1" resource="B">
    <span property="p:p2">C</span>
  </div>

or this way (with B being anonymous):

  <div about="A" rel="p:p1">
    <span property="p:p2">C</span>
  </div>

There is no proposal to change that in any way. The *only* thing I am
proposing is that we complete the symmetry, and add the missing
permutation, by supporting this:

  <div about="A" rel="p:p1">
    <span about="B" property="p:p2">C</span>
  </div>

I did say before that I'll not lose sleep if we don't support this
extra permutation, since it doesn't affect @instanceof. But I do
believe that we'll reap the benefits of ensuring consistency in the
language, and if we don't do it now, it will either come up in Last
Call comments, or in a future version of RDFa.



WHY ADD THE SYMMETRY?

So, whilst I can go with leaving the chaining question for now, I
would still prefer that we add the symmetry I mention, for three
reasons:

The first is that this additional rule was actually already in RDFa
years ago. Chaining was removed at the same time that we dropped a few
other things under the general category of being 'too complicated'.
Unfortunately, what we've done now is 'reintroduce' chaining without
doing it thoroughly. (In fact, when Ben proposed it, there was
actually no discussion over it.)

Following on from this, the second reason is that if we accept the
following mark-up (which we currently do):

  <div about="#me" rel="foaf:knows">
    <span property="foaf:lastname">Birbeck</span>
  </div>

which will create a connection with an unnamed item, it seems to be an
arbitrary limitation to prevent the author from naming that unnamed
item, like this:

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

We seem to be saying that bnodes are more important than named nodes,
and I think anyone looking at the language would be justified in
asking why they cannot name the nested item.

So...to return to the main point, I'm not changing any of the current
formulations, merely adding an additional one--the missing
permutation.



BEING CLEAR ON WHAT IS IN THE CURRENT APPROACH

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

With respect Ivan, it's a little late in the day to be saying this.
This formulation has been agreed on for a long time now. This is Ben's
version of chaining, and as I've said before, it is incredibly close
to our 'old' version of chaining...but not quite. But either way,
we've been using it for a long time now.


> I know that it can be
> explained process-wise (see Mark's mail)...

It's also explained 'process-wise' in the *current* draft of the
syntax document. All I did was to give a slightly different way of
arriving at the same triples, with the express purpose of having rules
that make our attributes behave more consistently. So although my
'process' may differ from the current processing steps, the end result
of parsing this formulation is _already_ in RDFa.


> ...but for a user I still find it
> extremely disturbing.

You might need to get out more. :) There are lots of things that are
"extremely disturbing" in the world, but I'm having trouble seeing the
use of RDFa attributes in that list. ;)



'NATURAL INTERPRETATIONS' AND FIRST PRINCIPLES

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

I have to disagree with your "natural interpretation" here. Given all
of the rules that we have been discussing (for years), why do you now
see that the presence of a single property on an element is enough to
create a new item, with its own unique bnode? We've never had that
kind of approach before. If we remove @about and @rel, you surely
don't think that this:

  <div>
    <span property="foaf:firstname" content="Ivan"></span>
    <span property="foaf:lastname" content="Herman"></span>
  </div>

gives this:

  [foaf:firstname "Ivan"], [foaf:lastname "Herman"] .


The reason it doesn't is because @property mirrors @rel and @rev in
ordinary HTML, in that:

  <a rel="x" href="y">z</a>

applies to the current document.

So the mark-up above will give us this:

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

If we then add an @about, we get this:

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

Hopefully you still agree that this doesn't generate two unnamed
items, but rather gives us the fairly obvious:

  <#me> foaf:firstname "Ivan" .
  <#me> foaf:lastname "Herman" .

Now, let's continue the progression and add @rel:

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

Again, why should we suddenly get unnamed items? Why do you think the
spans should suddenly give us this?:

  _:x foaf:firstname "Ivan" .
  _:NOTx foaf:lastname "Herman" .

as opposed to this:

  _:x foaf:firstname "Ivan" .
  _:x foaf:lastname "Herman" .



MOVING ITEMS AROUND

I've made this point before, but I think it is important; items should
be able to be moved around in a document and retain their coherence,
even if their 'name' changes.

So in this case, all that has happened is that one moment we had an
item with two predicates (firstname and lastname), that went by the
name of "#me", and now that item has been 'pushed down' a level, and
has 'no name'. In other words, we went from this:

  <#me> foaf:firstname "Ivan" .
  <#me> foaf:lastname "Herman" .

to this:

  <#me> foaf:knows _:x .
  _:x foaf:firstname "Ivan" .
  _:x foaf:lastname "Herman" .

If you concentrate only on the two predicates, in the three different
scenarios we've gone from this (no @about, so statements are about the
document):

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

to this (an @about, so statements are about this new subject):

  <#me> foaf:firstname "Ivan" .
  <#me> foaf:lastname "Herman" .

to this (@about with @rel, so statements are about an anonymous item):

  _:x foaf:firstname "Ivan" .
  _:x foaf:lastname "Herman" .

I don't think you could get more consistent.


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

I don't know what to say here, Ivan...this set of triples is also
yielded by the current model. See section 6.2.2.4 of the *current*
draft of the RDFa syntax document, for example.


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

How is this a source of confusion? Is it not clear that @about is
changing the statement context? @about is probably RDFa's key addition
to HTML, and so seeing it on an element should signal to an author
that context is changing.



WHY IS @ABOUT RDFA'S KEY ADDITION TO HTML?

If you begin with what HTML can already do, we know it allows us to
make statements about a document, through <link> and <meta>, and it
also allows us to put resource-related metadata in the <body> of a
document through the use of @rel and @rev on <a>.

This means that the addition by RDFa of @property and @content is not
really that special, because these attributes merely provide us with a
<body> version of <meta> to match the <body> version of <link>; in
other words, @property/@content is just the plain literal version of
@rel/@rev/@href.

The big difference between HTML with RDFa in, and HTML with no RDFa,
is that we are able to make statements about resources other than the
current document. In other words, @about is the attribute in RDFa that
has the most impact. So how can its presence be a "huge source of
confusion"? It's right at the heart of RDFa.

We can effectively say that @about causes everything to be 'merged' (I
like your term) unless something tells us otherwise--and putting aside
@instanceof, the only thing that can 'tell us otherwise' is @about.

This means that when you look at the mark-up you gave above:

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

it's the @about attributes that catch the eye, because we're dealing
with RDFa. And they should tell us that we're seeing 'groups' of
'merged' statements about two different items, "#me" and "#mark".

This is completely consistent with how HTML already works, in that all
predicates are attached to the current document--with the addition of
@about we're merely saying that predicates are always attached to the
'current subject', rather than simply the 'current document'.


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

I'm not quite sure which bit you are referring to here, because most
of the comments you have made to this point have concerned the current
behaviour of RDFa, rather than anything particular to 'my model'. I'm
losing track of what you are for or against!



(NOT SO) RADICAL CHANGE

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

I don't think it is that big a change. At the moment, when we see a
@rel with no object we generate a triple, and then store a bnode for
the object, to be used in further triples. The 'new/old' rule is
almost exactly the same; it still says store a bnode, but instead of
creating the triple straight away, it merely says defer this until
it's needed.

It therefore amounts to adding a flag to indicate that there is a
'deferred' or 'pending' triple, and then moving the code that adds
that triple, down a bit.



OTHERWISE WE GET MEANINGLESS TRIPLES

As I said in another post, if we don't take the 'defer' approach, then
we get meaningless triples from mark-up like this:

 <div about="A" rel="p:p1" />

Generating a triple here goes against the whole point of bnodes!

But there is worse; in this situation:

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

we will get a meaningless triple, as follows:

  <#me> foaf:knows _:div0 .
  <#mark> foaf:lastname "Birbeck" .

This seems purposefully pointless. People would quite rightly ask us
if we are going out of our way to avoid generating useful triples!
Reading this mark-up I think it would surprise people that we don't
generate the following:

  <#me> foaf:knows <#mark> .
  <#mark> foaf:lastname "Birbeck" .


As I said at the top, I won't go into the remainder of your post here,
since I see having two rdf:type attributes, rather than one, as a
separate issue.

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, 29 November 2007 14:08:00 UTC