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

Re: Rethinking @src in the context of chaining rules

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Tue, 8 Jan 2008 10:45:13 +0000
Message-ID: <a707f8300801080245u63a42536r47e0176e81307182@mail.gmail.com>
To: "Ben Adida" <ben@adida.net>
Cc: RDFa <public-rdf-in-xhtml-tf@w3.org>

Hi Ben,

On 07/01/2008, Ben Adida <ben@adida.net> wrote:
> Mark Birbeck wrote:
> > I think you've missed some of the key examples I've been trying to
> > convey -- the roles are far from 'static'. Take this example:
> >
> >   <div about="A" rel="p">
> >     <div about="B" />
> >   </div>
> Do we really want to argue about a contrived example? What's the point
> of this markup? Would anyone ever write this in a practical situation?

Now I am even more confused than before...I thought at least that this
example was agreed upon. Are you saying that you believe this should
not generate a triple?

I only used this example -- which I thought everyone accepted -- to
illustrate that there is no hard and fast rule for which attributes
play the role of subjects, and which play the role of objects. In your
argument you said that the key was whether two sub-graphs were linked
together, and I gave this example to show that this is not the case,
since there is only one sub-graph.

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

> I would write:
>   <div about="A" rel="p" resource="B" />
> or, if I had things to say about "B", I would do what you did above but
> with actual properties hanging off of B.

Great. And?

The reason for that snippet of mark-up was to show that subject and
object were not 'static' things (a word you used to describe this). I
wasn't saying that it might be a common idiom, and in fact that point
seems to be repeatedly being missed; I'm not saying you can't find
other ways of expressing things, only why should certain structures be

> We really shouldn't be arguing based on contrived markup.

We're not. Up until your post I didn't suspect that this example was
contrived...I thought it was well accepted. As I said, I only gave it
to illustrate the incorrectness of the view that whether an attribute
is a subject or an object is not based on the connection of
sub-graphs. (It's actually based on its relationship to @rel.)

> > :) Today's newspapers are tomorrow's chip wrappers, as they say. Only
> > the other day compliments were being handed out on how the spec was
> > readable, clear, precise, and whatever else;
> Saying that the spec is well written and that a small piece of it will
> make things more complicated are not incompatible. Your contributions
> have been fantastic, but I don't have to agree with all of your
> proposals to think so!

I didn't say you should agree with me, at all! :) I was only hinting
at the fact that I thought it was a little over the top for you to
imagine that the same approach that enabled us to arrive at a document
that is 'clear and consistent' should overnight become "dangerous",
with a potential for "serious consequences" and "high costs" (all of
which are words that you used).

It was obviously a bad joke, so I withdraw it, if I can. ;)

> > As I said before, I do actually think the parsing is much simpler.
> Mark, we need to look at some facts: I pointed out how the chaining
> model I (and others) understood means that you just *delete* two rules
> from your proposed spec. Factually speaking, that makes the spec simpler.

But you are talking about your understanding of the model that I
proposed, which seems to be slightly out of sync with the _actual_
model I proposed. It's true that all of the examples I gave when
motivating the idea of 'incomplete triples' used @about, but that was
only to justify and illustrate the argument. I hadn't meant that to be
the only way things would be done.

> More subjectively, your proposal gives many different ways of expressing
> exactly the same thing with the same DOM skeleton (@resource and @about
> become interchangeable in many cases). That makes things more
> complicated. Multiple ways of doing exactly the same thing generally
> leads to confusion, in my opinion.

And I disagree. Like any language, you begin with simple ways of
expressing things, but that does not mean you rule out alternatives.
This discussion repeatedly confuses the application of common idioms,
with what is allowed by the syntax. I have no problem with saying that
this is the favoured mark-up:

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

But what I'm trying to get to the bottom of, is what is to be gained
by *preventing* the author from moving the @rel up to the parent

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

We do not gain 'clarity' or 'simplicity' by preventing this mark-up,
since it is no more complicated to allow it than to prevent it. But we
do lose consistency.

> > That's not true. The use-cases that I've outlined a few times now
> > relate to consistency when moving items around, so that things that
> > work in one context have the same behaviour in another. I don't
> > believe that there are "high costs" to this, or that I am risking the
> > simplicity of the spec -- quite the contrary.
> There's no *need* to make things consistent with infinite moving around
> of attributes if there's no good use case to justify it. So far, the
> task force seems to think it makes things more difficult to describe and
> implement, and "shuffling attributes around" is not a use case.

Those who have expressed an opinion on this don't seem to be getting
to the heart of the issue, as far as I can see.

> > What I'm finding a little frustrating in this part of the discussion
> > is that no-one has responded to the very first question I asked, which
> > I'll paste here again:
> >
> > --- STARTS ---
> >
> > On the issue raised, there are two important aspects to it, but the
> > one I'll focus on here concerns consistency in chaining triples
> > together. What would you see as being the parsed triples from this:
> >
> >  <div about="A">
> >    <div rel="p1" resource="B">
> >      <div rel="p2" resource="C" />
> >    </div>
> >  </div>
> >
> > I'm assuming we're happy with:
> >
> >  <A> <p1> <B> .
> >  <B> <p2> <C> .
> >
> > What if we split the @rel's and @resource's:
> >
> >  <div about="A">
> >    <div rel="p1">
> >      <div resource="B">
> >        <div rel="p2">
> >          <div resource="C" />
> >        </div>
> >      </div>
> >    </div>
> >  </div>
> >
> > Any reason why this should not yield the same triples? I'm hoping not.
> >
> > --- ENDS ---
> You're wrong, I did answer this:

Apologies, but I can't see an explicit answer in the thread that
contains that example. You do offer an alternative mark-up, but as I
say, that's not the point. The question is why prevent this seemingly
obvious layout, not 'how would you mark this up'.

> ... the reason they should not yield the
> same triples is because, to enable this feature, we have to have
> additional rules in the parsers, and we now have to explain to users why
> we have two different ways of expressing the exact same thing: in your
> second example above, just replace resource="B" with about="B" and
> resource="C" with about="C": do we need to have those two ways of doing
> the same thing? I think not.

That (again) is not the question. The question is why prevent that
mark-up, not how would you write this.

> "Moving stuff around", when you originally motivated it, was about
> taking a chunk of markup:
> <div about="#foo">
>   ... lots of triples ...
> </div>
> and putting it inside a rel:
> <div rel="a:b">
>    <div about="#foo">
>      ... lots of triples ...
>    </div>
> </div>
> and having that "do the right thing." That argument completely convinced
> me regarding your chaining approach, because that's how data publishers
> will think: let me mark up a bunch of triple, and oh that now has to
> become the object of that, so I'll move that block over there.
> But will a data publisher suddenly feel the need to break up his @rel
> and @resource? That doesn't fall under the category of "moving stuff
> around" in the same way at all. I just don't see it, and no use case is
> enabled by this.

It's very much the same. I might have this:

  <div about="#ben">
    <div rel="foaf:knows" resource="#ivan" />

Then I add a few other people that you know:

  <div about="#ben">
    <div rel="foaf:knows" resource="#ivan" />
    <div rel="foaf:knows" resource="#manu" />
    <div rel="foaf:knows" resource="#mark" />

Then, based on the power of the 'hanging rel' feature, I could move
the @rel to the containing element:

  <div about="#ben" rel="foaf:knows">
    <div resource="#ivan" />
    <div resource="#manu" />
    <div resource="#mark" />

You will say "but now you need to change all @resource's to @about's",
and all I am saying is why force an author to do that? What is the big
deal here? (You'll probably say that this mark-up is 'confusing', but
I think it's pretty obvious.)

And further, what if the @resource values were actually @href's;
changing them to @about's would then not be possible:

  <div about="#ben" rel="foaf:knows">
    <a href="#ivan">Ivan</a>
    <a href="#manu">Manu</a>
    <a href="#mark">Mark</a>

> So I'm still very much against this.
> > Can anyone answer that last question? I.e., explain why this mark-up
> > should yield exactly *zero* triples? I've never said that we should
> > *promote* this mark-up, merely that we should support it if we come
> > across it.
> I disagree with that argument. Supporting more markup has costs, and in
> this case there are no benefits other than "supporting more markup."

You still haven't explained what the cost is. And the benefit is
firstly consistency, secondly, if an author has chosen to write this,
why not generate some triples for it, and thirdly, the ability to
apply a single @rel to a number of @href's and @resource's.



  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 Tuesday, 8 January 2008 10:45:28 UTC

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