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

Re: Rethinking @src in the context of chaining rules

From: Ben Adida <ben@adida.net>
Date: Tue, 08 Jan 2008 07:43:52 -0800
Message-ID: <47839A38.2050808@adida.net>
To: Mark Birbeck <mark.birbeck@x-port.net>
CC: RDFa <public-rdf-in-xhtml-tf@w3.org>

Mark Birbeck wrote:
>>>   <div about="A" rel="p">
>>>     <div about="B" />
>>>   </div>

> Now I am even more confused than before...I thought at least that this
> example was agreed upon.

Let me be clear so that this doesn't hold up work on the spec: of course
the example above works as we agreed. I'm just saying that it's an edge
case of the chaining rules, and drawing deep conclusions from it is not

So yes, the above example yields

  A p B .

But that doesn't mean that your other arguments follow: to me, this is
still about hooking up two subgraphs, only the contained one happens to
only have one vertex and no edges. It's an edge case (hah, no pun intended.)

To your point here:
> I've stopped working on the syntax document for now, because no-one
> seems to know precisely what it is that they want here.

Actually, I think a number of folks are in agreement with me right now!
At least that's the impression I got from the last telecon.

And, as I've said, the *only* difference in the spec is taking out those
two rules on the setting of the current_subject.

I also think Ivan's latest point is tremendously important:

> how can the user *avoid* the appearance of certain triples?

What Ivan is hinting at here is that we may be going down the rabbit's
hole we had 2 years ago, where far more triples were being generated
than we wanted.

Indeed, if I have a hanging @rel, then it seems that any contained link
will generate a triple, and I only get to control *what* that triple
says, not whether or not it appears.

Mark, yes, this is probably not what you originally proposed. But what
you originally proposed was understood a certain way by me, Manu, and
Ivan (and probably a few more people), and we ran with it. And it turns
out that, looking back at the additional properties we didn't originally
understand, there are notable downsides and very little upside.

Maybe what we mistakenly understood turns out to be slightly better?

> the ability to apply a single @rel to a number of @href's and @resource's.

That's the one small advantage I see, but it comes at a large cost as
shown by Ivan, and it can be written differently, simply by repeating
the @rel.

I think we're going to have to bring this to a vote.

Received on Tuesday, 8 January 2008 15:44:14 UTC

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