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 12:20:32 +0000
Message-ID: <a707f8300801080420g3f23d910ia38681053fae01f6@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'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.

Right. Your reference to the 'new chaining rules' made me think that
the proposal was to support _both_ this:

  <img src="a" />

_and_ this:

  <img rel="p" src="a" />

But now that I realise that the latter is no longer supported, I don't
support the change.

> So dissociating the two is probably a bad idea.

The reason for separating the two issues is that regardless of the
outcome of the discussion around this mark-up (which is at the heart
of the other discussion):

  <div about="A">
    <div rel="p1">
      <div resource="B">
        <div rel="p2">
          <div resource="C" />

I still don't think we should lose support for this:

  <img rel="p" src="a" />

> >> 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.

That's true, but my point is that this wasn't in the original
discussion, it came up later.

> >   <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" />
>    </div>
> 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.

Ok, but why have you snipped my entire second comment, which is along
similar lines:

> [...]

I'll reinstate it, and ask the question again:

> Second, if a @rel is now added to the mark-up I just gave:
>  <div about="#ben" rel="foaf:depiction">
>    <img
>      src="foo.jpg" rel="a:b" resource="foo2.jpg"
>      instanceof="foaf:Image"
>    />
>  </div>
> we get the following triples:
>  <#ben> foaf:depiction <foo.jpg> .
>  <foo.jpg> rdf:type foaf:Image .
>  <foo.jpg> a:b <foo2.jpg> .
> If we are saying that @src behaves like @about (which you have), then
> this formulation is now supported and we're entitled to ask what the
> justification is; is the expression of a relationship between an
> external image and some further, external document really that common
> a use-case? Is it really so common that it warrants removing the
> ability to qualify the relationship between the *current* document and
> the external image? (I.e., using @rel with @src.)

As I said, do we really want to establish relationships between
external documents? Obviously there will be times we want to, but that
is easily achieved with <link> or other constructs, by using @about --
it certainly doesn't need @src to make it possible.

> > 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.

No...I think I grasp the proposal. Unfortunately, I assumed too much
when it was originally made; I heard the words 'based on the new
chaining rules', and assumed that it would support two types of
layout. I didn't for a moment imagine that we would lose the ability
to enrich the relationship between the current document (or some item)
and external images.

> [...]
> > 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.

I didn't say that @rel applied to @src before. I said that an author
was already able to establish a relationship between the current
document and an image, just as they can establish a relationship
between the current document and a stylesheet, a script, and various
other documents. It just so happens that in existing HTML, the
relationship between documents can be further refined by adding @rel
to qualify @href on <link> and <a>; we simply replicated that ability
to further refine the link that is established via <img>.

> 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 think that goes against general notions of linking, as well as
relationships between documents. All that happens with an 'inline
object', is that the link is actuated automatically by the browser,
probably during document load time. A clickable link, on the other
hand, is generally actuated by the user. All that is changing is the
'time' at which retrieval occurs, but the (high-level) semantics of
there being a relationship between two documents is the same.

But note that these are just conventions generally used in the
browser. If the GoogleBot gets hold of our document, for example, it
will no doubt follow every navigable link; in other words, it will
'actuate' the links when it chooses, rather than waiting for a user to
click. And similarly, a browser might choose to prefetch the external
documents, rather than waiting for the user to click on them. And
further, in the past, browsers would show images in separate windows,
rather than rendering them 'inline'. (And anyway, the image is not
actually 'inline', i.e., it is not in the DOM, just rendered in
document order.)

In short, any of the following 'links' establishes a relationship
between two documents:

  <link rel="stylesheet" href="xyz.css" />
  <link rel="next" href="next.html" />
  <a href="#ivan">Ivan</a>
  <a href="ivan.html">Ivan</a>
  <img src="ivan.jpg" />

and what action is actually carried out with the referenced document,
and when, is determined by the notion of actuation, and various

> 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.

In relation to @rel + @src, you are of course right that it was not
defined. But the idea that an author is establishing a relationship
between the current document and an image document when they use <img>
is pretty obvious; it just so happens that in the past HTML did not
allow us to provide a richer description of that relationship, whilst
RDFa does.

> > 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.

I'm not sure which part doesn't make sense, but either way, I'm
intrigued to see XHTML 2 being used to defend an argument! You're
always saying that it has no place in our discussions on XHTML 1.x. ;)

> 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.

I don't understand what that means. What is the "inline version"? Are
you suggesting that we generate a bnode to identify the 'img' element,
and then wire the image up to that? This would be the first time that
we've established a relationship between generated triples and the
document structure itself, and whilst it is something that we do need
to look at in the future, is a very big can of worms, and something
we've carefully avoided up until now. (That's why we ensured that @id
doesn't do anything at the moment, for example.)

> > 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.

You'll need to back that up. Reasoning from example mark-up has been
an incredibly poweful technique, at least so far.

> 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.

A use-case can be pretty much anything you want it to be, if you are
going to split hairs.

> > 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?

Right here:

  <img src="foo.jpg" />

Are you saying there is no relationship between the current document
and the external image? So Google Images, for example, shouldn't allow
you to view an image 'in context'?

> >   <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.

The fact that <img> nowadays represents an inline object is a
conceptual thing. True the external image, once retrieved, can be
placed into the 'flow' of the document, but it is not actually
inserted into the DOM or anything like that. And anyway, a user agent
could open separate windows for images, as they did in the early days
of browser technology, so there is nothing about <img> that says it
must go into the main flow. (And a user agent might ignore images
altogether, like a voice browser, or retrieve them at a later time,
like GoogleBot.)

What is important is the link between the document and the image, and
all that happens to make it an 'inline object' (from the point of view
of the rendering) is that the browser 'actuates' the link and loads
the image without waiting to be told to do so by a user. But like it
or not, *all* URIs in HTML are references.

> 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.

I think there are many ways to approach this, all of them way beyond
the scope of our current discussions. There are many desirable
features that our current model doesn't support, such as Dan
Brickley's recently raised image map question. They can be solved, but
I think we need to wait for RDFa 2.0.

> > 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.

Of course. And if I saw adding rdf:type to external images as a more
useful or common  requirement than qualifying the link between a
document and that image, I would definitely join you in interpreting
things differently. But at the moment I'm not seeing it.

> > 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.

Well, it is a big deal, I think. The idea of solving every problem by
wrapping some extra mark-up around it goes against the grain,
especially when the only reason for having to do this is to support a
feature that has not (yet) been completely justified. Recall that this
whole thing originates from Ivan quite reasonably asking how rdf:type
could be set on images; but whilst we agreed to look at how it might
be done, we definitely did not agree that in order to make it possible
we should shunt out other features.

> > 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.

I don't think so. What I did was to try to qualify the relationship
between an item and an external image. I don't think that is an
unusual requirement. And by a "little more verbose" you mean:

  <div about="#me">
    <span rel="foaf:img">
      <img src="me.jpg" alt="Me" />
    <span rel="foaf:depiction">
      <img src="me-and-ben.jpg" alt="Me and Ben" />
    <span rel="foaf:depiction">
      <img src="me-and-ivan.jpg" alt="Me and Ivan" />

That's a 'lot of verbose', I think, and at the moment it is looking
wholly unnecessary.



  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 12:20:39 UTC

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