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: Mon, 07 Jan 2008 14:29:23 -0800
Message-ID: <4782A7C3.2090501@adida.net>
To: Mark Birbeck <mark.birbeck@x-port.net>
CC: RDFa <public-rdf-in-xhtml-tf@w3.org>

Mark Birbeck wrote:
> I'd like to discuss it
> separately from the way that chaining is being dealt with

But... the whole point of my proposal, as I explained clearly, was that
we could make this more natural change *thanks* to the chaining rules.
So dissociating the two is probably a bad idea.

>> Thus, in my proposal, this works:
>>>   <div about="#ben" rel="foaf:depiction">
>>>     <img src="foo.jpg" instanceof="foaf:Image" />
>>>   </div>
> No arguments there. But note a few consequences to this. First, the
> idea of @resource and @href being used as an 'alternative' URI for
> @src, is gone;

It's gone, but it's replaced by @about overriding @src, as I mentioned
during my telecon proposal and in the followup email.

>   <div about="#ben" rel="foaf:depiction">
>     <img src="foo.jpg" resource="foo2.jpg" instanceof="foaf:Image" />
>   </div>

Right, that wouldn't work anymore, but this would:

   <div about="#ben" rel="foaf:depiction">
     <img src="foo.jpg" about="foo2.jpg" instanceof="foaf:Image" />

and it would match nicely with @instanceof applying only to the subject
attributes, @src and @about, with @about overriding @src.

So @about is to @src as @resource is to @href.

> We never discussed removing this use-case,

Indeed, I don't want to remove any use cases, that would be bad. I hope
the point above shows that I didn't remove a use case, I only changed
the way it would be expressed.


> As far as I can see, what has happened here is that an understandable
> desire for the ability to apply @instanceof to images is being
> railroaded through, and causing changes to happen in other areas that
> have not been discussed or agreed.

That's incorrect. No one is railroading anything. I made a proposal that
happens to resonate with a few folks in the task force, and right now
you're disagreeing with it, so we're discussing it. Plus, it seems from
above that you have misunderstood the proposal, so it might end up being
more agreeable to you than you think right now.


> That would be to forget how we arrived at @src being an object
> resource though, which was not an accident -- it was because the
> feature was essentially already in HTML anyway.

No, the feature was not in HTML. @rel doesn't apply to IMG right now
except with RDFa. We've chosen to extend HTML's @rel in various ways,
and there are different ways of interpreting that.

After thinking about Ivan's point about how inline objects are somewhat
different than remote links, and being inspired by your chaining
proposal, I realized that there was a good reason for interpreting @src
as @about, because the image is *in* the page, not remote, so making
@src a subject definition attribute feels right.

I understand how it may feel differently to you, but I don't think we
can say that HTML was one way or another before we came along: it was
just undefined on this front.

> When an author uses <img> they are expressing a relationship between
> the current document and some other, external document. Admittedly
> that relationship is fairly basic, and in triple form would be little
> more than this:
>   <> hasAnImage <foo.jpg> .

Sure, but that doesn't mean that @rel in IMG modifies *that*
relationship. What about XHTML2, where @href appears anywhere? What
happens when an IMG has @src and @href on the same element? Does one
really override the other even though they both have user-viewable
roles? That doesn't make sense to me.

It would make more sense to think of @src as a subject, and @rel in IMG
as the relationship between the image's inline version and its remote link.

> So @src as an object resource, combined with @rel as a predicate, is a
> very important use-case,

No, that's not a use case, it's example markup. We can't reason entirely
from example markup, because that leads to extreme complications.

A use case would be: "I want to declare a type on my image, or a
relationship between the current document and the image." Both those use
cases are supported using my proposal or yours.

> Even if the
> use-case weren't more important, the point is that HTML already allows
> a relationship to be established between the current document and an
> image file,

No, it doesn't! Where do you see that defined in HTML?

>   <img rel="foaf:img" src="foo.jpg" />
> is about qualifying a relationship between the current document and
> some other document, and of course so is this:
>   <a rel="foaf:knows" href="ben.html#">Ben</a>
> then it follows that this:
>   <img about="#mark" rel="foaf:img" src="foo.jpg" />
> should be just as valid as this:
>   <a about="#mark" rel="foaf:knows" href="ben.html#">Ben</a>

No, that's where we differ. An IMG is an inline object, a link is a
reference. I think that is an important difference that justifies the
slightly different interpretation of @src.

Again, how would you interpret the following, where @href becomes
user-navigable in a future version of XHTML?

  <img src="foo.jpg" rel="a:b" href="foo-big.jpg" />

Having @href override @src (or the other way around) would be
counter-intuitive, I think, since they both have human-navigable value.
They should both have meaningful RDF roles, and that's where the
"inline" vs. "remote link" distinction is clear.

> but the original use-cases for having @rel on @src
> were to qualify already existing references to images by adding a
> predicate -- the idea is, after all, to leverage existing mark-up.

That's right, and my proposal is that it would be better if we
interpreted it differently. We've made changes to past ideas before, and
many of them (including chaining) have been good.

> In
> other words, something like this on my home-page:
>   <div>
>     <img src="me.jpg" alt="Me" />
>     <img src="me-and-ben.jpg" alt="Me and Ben" />
>     <img src="me-and-ivan.jpg" alt="Me and Ivan" />
>   </div>
> could be turned into this:
>   <div about="#me">
>     <img rel="foaf:img" src="me.jpg" alt="Me" />
>     <img rel="foaf:depiction" src="me-and-ben.jpg" alt="Me and Ben" />
>     <img rel="foaf:depiction" src="me-and-ivan.jpg" alt="Me and Ivan" />
>   </div>

You've picked an example that favors your approach in markup brevity,
but it can still easily be written with my rules, just adding <span
rel=""> around each img. Not a big deal.

> This is not possible in the 'subject only' world;

It *is* possible, you just picked an example where the markup becomes a
little more verbose.

Received on Monday, 7 January 2008 22:29:33 UTC

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