Re: Rethinking @src in the context of chaining rules

Hi Ben,

I've split my response into two emails. The response in this email
concerns the way that @src works, and I'd like to discuss it
separately from the way that chaining is being dealt with -- which is
the subject of my second email.


> We might be using slightly different meanings when we each say
> "subject." (I know, what is "is", right?) So let me try to get at the
> core of the issue here:
>
> > remove the ability for @src to express an object, and replace it with
> > being a subject.
>
> That's not what I'm suggesting. I'm suggesting that @src behave like
> @about: it can be an object when a chaining rule is used.

Ok. Although just so that we are clear, 'what you are suggesting' is
supposed to reflect what we agreed on a telecon, and as I've tried to
point out, I assumed from that particular call that all that was
changing was that @src would *additionally* be allowed to act as a
'primary' subject, not that it would *only* act as a 'primary'
subject.

Obviously it was a misunderstanding, and I accept that. But since all
that your suggestion does is to replace one use-case with another, we
have to weigh up which of the use-cases is more useful. And if we are
forced to have only one of them, I think we have to go back to the one
we had before; first, it is more useful, and second -- and more
importantly -- it is more consistent with HTML practice. (More on this
below.)


> 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; in the following mark-up @src now keeps priority since
@resource no longer overrides it:

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

We never discussed removing this use-case, and we have to now agree
that we want to lose that. That takes us a step away from our initial
discussion, since it was only about setting type on images.

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

And if we don't want this formulation then we have to add an
exception, and say that @src doesn't actually behave like @about, but
acts like something else.

All of this seems to take us yet another step further away from our
initial discussion, since we didn't agree or even discuss any of these
kinds of use-cases -- all we discussed was a desire to add type to
image URIs.


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. My initial support for the
application of @instanceof to @src was because I thought it was going
to be achieved by allowing our parsing rules to support _both_ the
subject _and_ the object scenarios that I have outlined. But now that
I see this is not the case, I can't support a 'subject only' approach.


> but the following does *not* work:
>
> >   <img about="#me" rel="foaf:img" src="foo.jpg" />
>
> I think if you step back and forget that we had @src define an object
> before...

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.

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

But we added the ability to use @rel to qualify that relationship, and
in so doing we empowered authors to make that relationship richer, in
just the same way that HTML already supported the use of @rel to make
the relationship defined by a navigable link richer.

So @src as an object resource, combined with @rel as a predicate, is a
very important use-case, and certainly far more important than using
@instanceof to set the type of the remote document. 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, and we should be trying to leverage that; setting the type
of some remote image file has no corollary in existing HTML. (That
doesn't mean we shouldn't support setting the type if we can, but if
it's at the expense of enriching the relationship between the two
documents then it goes completely against the grain.)

Now, if this:

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


> ...you wouldn't write that markup anyways. It can easily be written as:
>
> <span about="#me" rel="foaf:img">
>   <img src="foo.jpg" />
> </span>
>
> and I think that makes a *lot* more sense.

It may or may not...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. 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>

This is not possible in the 'subject only' world; all I would be able
to express in the 'subject only' world is something like 'each of
these images is...well...an image':

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

Big deal...I knew that already, since I just added a whole load of
'img' tags! :)

So once again I have to argue that if we can only have one option or
the other (subject only, or object only), then we should go back to
our original approach (@src remains the object, and as a consequence
@instanceof does not apply to it).

Regards,

Mark

-- 
  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 Monday, 7 January 2008 22:02:00 UTC