W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > January 2008

Re: Summary of @href/@resource completing triples issue

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Wed, 9 Jan 2008 21:49:24 +0000
Message-ID: <a707f8300801091349n5cedb51fyab442bb68aada3ab@mail.gmail.com>
To: "Ben Adida" <ben@adida.net>
Cc: "Manu Sporny" <msporny@digitalbazaar.com>, RDFa <public-rdf-in-xhtml-tf@w3.org>

HI Ben,

> Thanks for these summaries, which are very helpful, although I think
> this time you've got two big bugs in your main example. See the bottom
> of this email.
> Mark, I haven't changed my mind recently on @href causing chaining...

When I said that you have changed your mind, it wasn't in reference to
hanging rels at all, it was in reference to whether a @resource or
@href should set the subject on nested statements, even when there was
no @rel on the line it was on. In other words, whether it should set
the subject when there is no chaining:

  <div resource="A">
    <div rel="p" resource="B" />

You put mark-up like this into the category of a "contrived example"
before, so I believe that you have changed your mind. ;)

Anyway...excuse my flippancy...if we agree on this, then that's fine,
and I think it means that we've further reduced the problem range.

> ...remember I'm the one who introduced the idea in the first place, back
> when only a hanging @rel produced chaining.

Well...you *reintroduced* it. :)

But the whole point of the (very long) discussion we recently had
about chaining was that I felt that your proposal was incomplete, and
that if we were going to reintroduce chaining, we needed to do it
thoroughly. In my opinion doing that required going back to my
original drafts, and restoring the idea that a subject could
'complete' triples that lacked an object in parent statements.

> Also, Mark, you're confusing the situation thoroughly by using the
> generic formulation "@resource can play the role of subject, and @about
> can play the role of object." Of course they can, with chaining.

But I've tried to explain this umpteen times... These attributes can
play that role *without* chaining. You argue that the way that the
@about becomes an object (for example) is by connecting a sub-graph,
and I've said repeatedly that this is not true. An RDF graph is made
up of a collection of triples, so if you only have one triple, how can
you be connecting two graphs? To have two graphs you need two triples
at least, so this is only one graph:

  <div about="A" rel="p">
    <div about="B" />

Yet although there are NOT two graphs here, @about is indeed 'playing
the role of an object'. So how is my formulation "confusing the
situation"? In fact, I've been flagging up for quite a while now that
people should not get too attached to fixed notions that "@about is
the subject" or "@resource is the object", since they are very fluid.

(Of course, when teaching people about RDFa, I would explain it
exactly like that. But we are discussing the syntax and parsing rules,
not the primer.)

> The
> question is, to *which* predicate? How much are you willing to
> "collapse" the triple structure to connect a @rel with an object?
> In your model, collapsing happens where one likely wouldn't expect it,
> which is what gives Ivan's important counter-example. You've ignored
> this issue so far, yet it's the biggest one!

I've not ignored it because I'm scared of it, though. :) It's just
that I'd prefer to take one issue at a time, since there is a lot of

In my proposal on a vote, I ended with an outline of two issues; one
concerned whether @resource and @href could be subjects, and the other
concerned whether @resource and @href could complete 'incomplete
triples' in the way that other subjects do. I suggested that we didn't
bother taking the two questions separately, but thanks to Manu's
emails focusing in on the issues, it turned out that there was some
agreement with the first proposition. This means we can talk about the
'hanging rel' question separately.

I'll leave my arguments for now though, since they come up below
during a look at your idea of 'collapsing statements'.

> When we have a standalone @href that isn't related to anything above:
>   <div href="#foo">
>     <span property="dc:title">Foo</span>
>   </div>
> We're not collapsing anything: it's just that <#foo> is not related to
> any subject above, it only has properties of its own. We can relate it
> to subjects above using @rel on the DIV, and the triple structure stays
> the same.

So you mean that the graph remains the same if it is combined with
another graph? Agreed. That was the main problem with your original
proposal on @instanceof, if you recall; if you brought a graph that
contained @instanceof into contact with another graph via @rel, in
your proposal the @instanceof would 'jump' from one graph to the

> Similarly, an @about with no properties:
>   <div rel="foaf:knows">
>      <span about="#mark">Mark</span>
>   </div>
> doesn't "collapse" any of the triple structure: it's just that <#mark>
> has no properties hanging off of it, but it still completes the hanging
> @rel.

Right. One might even say that @about is playing the role of an
object, here. ;) The rule is simply that if you find a subject, see if
you can use it to complete some ancestor statements.

> I know we agree on the outcome of the above two examples, but I wanted
> to explain them to contrast with another chunk of markup that shows the
> unexpected triple collapse with your model:
>   <div rel="foaf:knows">
>     <span about="#mark" rel="foaf:knows" resource="#ben">
>       <span property="foaf:name">Ben</span>
>     </span>
>     <span about="#ivan" />
>   </div>
> I think we all agree that this gives:
>   <> foaf:knows <#mark> .
>   <#mark> foaf:knows <#ben> .
>   <#ben> foaf:name "Ben" .
>   <> foaf:knows <#ivan> .


> Now remove the @rel on the inner SPAN, which one should take as meaning
> that "Mark no longer knows Ben:"
>   <div rel="foaf:knows">
>     <span about="#mark" resource="#ben">
>       <span property="foaf:name">Ben</span>
>     </span>
>     <span about="#ivan" />
>   </div>
> I'm pretty sure we agree that this yields:
>   <> foaf:knows <#mark> .
>   <#ben> foaf:name "Ben" .
>   <> foaf:knows <#ivan> .

Definitely not. There is nothing novel here, and normal processing
rules apply, i.e., the subject for any contained statements is @about,
just like it always was. The 'stray' @resource attribute is
effectively redundant.

> Effectively, we removed the relationship between <#mark> and <#ben>, but
> we didn't change the overall triple structure, we just removed an edge
> from the graph.

We did though, because the rules have *always* been that @about takes
priority. In this situation, why are you suggesting that @resource now
sets the subject for the nested property?:

  <span about="#mark" resource="#ben">
    <span property="foaf:name">Ben</span>

This yields:

  <#mark> foaf:name "Ben" .

just like it's always done.

> Now, what happens if we remove the @about, which should be interpreted
> as "<#mark> is no longer an object of foaf:knows."
>   <div rel="foaf:knows">
>     <span resource="#ben">
>       <span property="foaf:name">Ben</span>
>     </span>
>     <span about="#ivan" />
>   </div>
> In my model, there's only one object to foaf:knows remaining, and so the
> first triple goes away completely, leaving only:
>   <#ben> foaf:name "Ben" .
>   <> foaf:knows <#ivan> .
> But in Mark's model, a triple structure collapse happens, where suddenly
> @rel connects to @resource, only because we removed @about:
>   <> foaf:knows <#ben> .
>   <#ben> foaf:name "Ben" .
>   <> foaf:knows <#ivan> .
> So now the current page knows <#ben>, which is really odd since that was
> never expressed earlier.

This is a bit illogical Ben. You've removed two attributes and you are
surprised that we're now talking about something different to what we
were before?

Let's just assume for a moment that the @resource and @href attributes
are allowed to complete triples. (This is not part of the argument on
that, this is merely to give me a simple syntax to explain something
to you.) With this functionality I can now 'stretch' your original
mark-up in the following way (i.e., put each part of a statement on a
separate line):

  <div rel="foaf:knows">
    <span about="#mark">
      <span rel="foaf:knows">
        <span resource="#ben">
          <span property="foaf:name">Ben</span>

    <span about="#ivan" />

I know you don't like the @resource completing the 'incomplete
triple', but let's use this just for the purposes of this
illustration. Now, in your scenario above, you effectively removed the
@about for "#mark", and the second @rel (lines 2 and 3):

  <div rel="foaf:knows">
    <span resource="#ben">
      <span property="foaf:name">Ben</span>

    <span about="#ivan" />

Why is it shocking that we now have:

  <> foaf:knows <#ben> .

You say:

> So now the current page knows <#ben>, which is really odd since that was
> never expressed earlier.

but you've just altered the entire collection of statements!

The only reason I can think of that you are surprised by this, is
because of the mistaken assumption in the middle that removing the
@rel="foaf:knows" would leave us with a subject set by @resource
instead of @about:

  <span about="#mark" resource="#ben">
    <span property="foaf:name">Ben</span>

As I say, there is no reason that this shouldn't follow all of our
normal rules, and @about takes priority as usual.

> This is a *big* change, because it means that whether you declare a
> subject with @about or not suddenly changes the *structure* of the
> triples. Note how the collapse somehow brings <#ben> and <#ivan> to the
> same level, and *all because we removed @about*.

No...it has happened all because you removed an entire statement and
dramatically changed the triples!

> Manu Sporny wrote:
> > and this is where the two models differ (note that @rel was moved up to
> > the containing element):
> >
> > -----------------------------------------------------------------
> > <div href="#me" rel="foaf:knows">
> >    <span href="#ivan">
> >    <span href="#shane">
> > </div>
> > -------- Approach A triples (Mark)
> > <#me> foaf:knows <#ivan> .
> > <#me> foaf:knows <#shane> .
> > -------- Approach B triples (Ben)
> > <> foaf:knows <#ivan> .
> > <> foaf:knows <#shane> .
> > -----------------------------------------------------------------
> First, a bug: use @about on the top-level DIV, otherwise @href becomes
> the object of the @rel when you move it to the top-level DIV. I think
> Mark and I agree on this,

Yes, agreed.

> There's also a big bug with Approach B's triples: in my and Ivan's
> model, there are no triples generated, because @href on its own never
> completes a triple. Why? Because non-RDFa authors write <a href=""> all
> the time, and to have that automatically connect to a hanging @rel when
> the anchor contains *no* RDFa attributes... very odd.

I don't see how it's odd. I don't have a problem with you and Ivan
saying you don't like it -- I can certainly see situations where you'd
prefer the alternative. But it is certainly not odd; if you have just
added a 'hanging rel' to your XHTML document, and then placed some
links inside it, are you really going to get something 'by accident'?
You're surely not using RDFa 'by accident', are you?

But even if the specificity of <a> with @href is accepted, why do you
and Ivan want to apply the same logic to @resource? In this example,
what exactly are we protecting the author from, if we say that
@resource does not complete the 'hanging rel'?:

  <div rel="foaf:knows">
    <span resource="#ben">
      <span property="foaf:name">Ben</span>

    <span about="#ivan" />

And also, what about the use of @href when it appears on non-<a>
elements? If an author writes this, are we really unsure of what they

  <div rel="foaf:knows">
    <span href="#ben">
      <span property="foaf:name">Ben</span>

    <span about="#ivan" />

So the only formulation that you should really be arguing against is this:

  <div rel="foaf:knows">
    <a href="#ben">Ben</a>

And the only consistent solution to this problem is to either <a> out
of RDFa altogether. This is because the argument that you and Ivan are
presenting -- that there is no way to use <a> in the "good old way",
as Ivan described it -- applies equally to this scenario:

  <div about="A">
    <a rel="p" href="B">link</a>

If you think that <a> should be preserved for its 'standard' use, and
you regard triples that are generated from it to be 'spurious' then
that's fair enough, but you really have to be consistent and accept
that the only formulation that uses <a>, that is guaranteed to be
unambiguous is this one:

  <a about="A" rel="p" href="B">link</a>

> And there's one more issue: what happens to @instanceof? Does it then
> apply to @resource in Mark's markup? That would be the natural
> consequence of Mark's proposal...

This is why I have stopped working on the syntax document. :( Only
recently you said that you were happy with this:

  <div resource="A">
    <div rel="p" resource="B" />

but now you seem to be implying that you would not be happy with this:

  <div resource="A" instanceof="t">
    <div rel="p" resource="B" />

You seem to think this to be strange, whilst I see it as consistent
with the idea that 'the subject' can be set in various ways, and
@instanceof always applies to 'the subject' of the current context.

> ... which I find quite ironic, given that my
> earlier proposal that @instanceof would apply to @resource was so
> untenable :)

You keep referring to this, and I keep explaining that it has nothing
to do with the attribute names.

The untenable part of your proposal was that @instanceof could one
minute apply to one statement and the next minute apply to another,
depending on whether the two statements were in relation to each
other. It was a bit like a charge jumping across two metal plates as
they were brought closer to each other.

So if you had this:

  <div about="A" instanceof="t1">
    <span property="p1">literal</span>

  <div about="B">
    <span property="p2">literal</span>

all one had to do was to establish a relationship between the two
statements with @rel and @resource:

  <div about="A" instanceof="t1" rel="p2" resource="B">
    <span property="p1">literal</span>

and suddenly the charge leaps across the plates! 'A' is no longer of
type 't1', and instead 'B' is. (I.e., the @instanceof becomes part of
the second sub-graph, instead of the first, because it now applies to
@resource and not @about.)

I admit that there were many situations where your approach was
useful, but ultimately the behaviour was just too inconsistent to be
workable. My proposal was to simply say that @instanceof should
*always* apply to the subject of the current context, regardless of
how that subject was obtained...via @about, the bnode on @instanceof,
and yes, even a lone @resource.

Of course that too had a limitation -- that's the way things go -- in
that it didn't allow us to easily specify the type of an _image_. It's
a pretty small limitation, and I would have been happy to have left it
to a future time, but anyway...here we are. But either way, despite
this limitation, the behaviour of applying @instanceof to 'the
subject' is consistent, and there are no jumping charges.



  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 Wednesday, 9 January 2008 21:49:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:26 UTC