- From: Ben Adida <ben@adida.net>
- Date: Tue, 08 Jan 2008 07:43:52 -0800
- 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 productive. 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. -Ben
Received on Tuesday, 8 January 2008 15:44:14 UTC