Re: [Proposal] ISSUE-42: How does RDFa deal with @src

Hi Ben,

I've just taken another look at why you are suggesting that @class
applies to the bnode when using striping and I see what you are
driving at now...so I take that comment back. I think it does leave us
having to say what should happen when both an @about and a @rel are
present on an element though--which should @class apply to? But I'm
with you now on your main point.

However, I still don't think that the object/subject/flip-flop effect
that happens with striping is so generalisable that we can make use of
the concept when defining @src on <img>. Of course if you think it's
useful to link the two ideas together then it's worth a try.

Regards,

Mark

On 21/06/07, Mark Birbeck <mark.birbeck@x-port.net> wrote:
> Hi Ben,
>
> There are two problems with this. The first is that you might not have
> a @rel value on your <img>. So for example, there may be use cases for
> the following construct:
>
>   <img src="my-photo.jpg" class="foaf:Image" />
>
> (Especially since everyone is against the idea of generating a triple
> for xh:img.)
>
> This means that we can't rely on the presence of @rel or @rev to tell
> us how to interpret @class.
>
> The second problem is that as things stand I can't find a
> justification for applying @class to @href in the way that you seem to
> be suggesting. The only thing I can find that proposes what @class
> actually means is in the first link [1] that appears in the page for
> the issue itself [2]. The post says:
>
> --- STARTS ---
>
>   <div role="wai:toolbar">
>       ...
>     </div>
>
>   is equivalent to this:
>
>     <div>
>       <link rel="xh:role" href="[wai:toolbar]" />
>       ...
>     </div>
>
>   To clarify what @class should do, I'm also suggesting that this:
>
>     <div class="foaf:Person">
>       ...
>     </div>
>
>   should be equivalent to this:
>
>     <div>
>       <link rel="rdf:type" href="[foaf:Person]" />
>       ...
>     </div>
>
> --- ENDS ---
>
> Obviously things have changed in relation to '<link> everywhere',
> since then, but the general point seems relevant. So to use your
> example:
>
>   <a rel="dc:creator" href="http://ben.adida.net/#me"
>     class="foaf:Person">Ben</a>
>
> the proposal above would have it be equivalent to the following
> (pretending for a moment that you can have multiple instances of the
> same attribute, just to make it easier to write):
>
>   <a
>     rel="dc:creator" href="http://ben.adida.net/#me"
>     rel="rdf:type" href="[foaf:Person]"
>   >Ben</a>
>
> I see from your example in a separate thread that when using striping
> you've suggested that the @class attribute applies to the 'child'
> bnode, but I find that counterintuitive, and don't recall it being
> discussed. But either way, I don't see how that applies here, since
> striping is for when we have a predicate with no @href, and it would
> obviously be meaningless to have an <img> with no @src (which is what
> you'd have if you say that @src is the same as @href).
>
> I'm not saying by the way that @src on <img> (and <object>) is a
> 'special case'. I'm simply saying that it has its own defined rules,
> just like <link>, <meta>, @rel and lots of other things have their own
> defined rules. The main point I'm driving at is that there doesn't
> seem much to generalise between @src and @href.
>
> Regards,
>
> Mark
>
> [1] <http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2006Jun/0009>
> [2] <http://www.w3.org/2006/07/SWD/track/issues/3>
>
> On 21/06/07, Ben Adida <ben@adida.net> wrote:
> >
> > Mark Birbeck wrote:
> > > Anyone else have a view? In particular are there any use cases for
> > > knowing that something is an image, independent of a value in @rel or
> > > @rev?
> >
> > On this issue, I think I agree with Ivan regarding the xh:img triple: it
> > will seem inconsistent. Why IMG and not OBJECT, TABLE (gasp, tables?),
> > LINK, SCRIPT, etc..?
> >
> > >> Also, are we sure that
> > >>
> > >> <s> rdfs:label "alt".
> > >>
> > >> is the best representation for this?
> >
> > I don't have a strong opinion on this one.
> >
> > > Right. That's fine, and I can go either way. The only thing that I
> > > think we do have to discuss though, is @class. My other proposals are
> > > about generating 'extra' triples (like 'xyz is an image'), the use of
> > > @class on an <img> is something that is already allowed, and we
> > > therefore need to provide an interpretation.
> >
> > I agree that we need to provide an interpretation for class="xy:zz" on
> > an img. I think it's clear that this applies to the IMG, but I think we
> > don't need to special-case it too much. We've already set the precedent
> > that @REL automatically sets the subject of all contained triples,
> > including any triple generated by @CLASS, to be the OBJECT (in that case
> > a bnode, but the OBJECT nevertheless). I think we can carry this rule
> > over. If there's a REL on an IMG, then @SRC acts like @HREF and becomes
> > the subject for all triples generated by contained elements. Thus @CLASS
> > is the rdf:type of the @SRC attribute.
> >
> > I believe this carries over to the following situation involving an
> > anchor rather than an IMG:
> >
> > <a rel="dc:creator" href="http://ben.adida.net/#me"
> > class="foaf:Person">Ben</a>
> >
> > I'm pretty sure that should be interpreted as:
> >
> > <http://ben.adida.net/#me> rdf:type foaf:Person .
> >
> > right?
> >
> > Now, what to do if there is a @REV? I think the same thing applies,
> > actually, meaning that @SRC is the subject of the @REV predicate, but
> > *also* of the @CLASS rdf:type and all contained elements.
> >
> > One last thing: I think all of above should apply to OBJECT/@SRC.
> >
> >
> > -Ben
> >
> >
>
>
> --
>   Mark Birbeck, formsPlayer
>
>   mark.birbeck@x-port.net | +44 (0) 20 7689 9232
>   http://www.formsPlayer.com | http://internet-apps.blogspot.com
>
>   standards. innovation.
>


-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Friday, 22 June 2007 11:53:55 UTC