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

Hi Ivan,

> adding questions, instead of answering them:-)

Still useful...thanks. ;)


> Where does
>
> <> xh:img <s> .
>
> come from your example <img src="s" alt="alt">?
>
> Do we have a rule that all XHTML elements that are used are somehow
> reflected in the generated triplets with this special 'xh:' namespace? I
> do not see a reason to do that implicitly.

Not in this version of RDFa. :) I have absolutely no problem with
excluding those triples, however, I thought it might be useful to
indicate that the URL being referred to was an image, rather than
losing it. But at the same time, it's not crucial and discussion on
that can be postponed to some future version (or not).

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?


> Also, are we sure that
>
> <s> rdfs:label "alt".
>
> is the best representation for this? I am afraid of finding ourselves in
> some endless discussion with, say, WAI people on the meaning of the
> 'alt' attribute; one could also say that
>
> <s> rdfs:seeAlso "alt".
>
> makes more sense in the way they are referring to "alt". Let alone your
> choice of dc:description for longdesc; should we hardwire a specific
> namespace into RDFa (ie, dc)?

Again, I don't have a strong view here. I was working on the
assumption that we might as well preserve semantic information rather
than discard it, but obviously that hinges on us agreeing on exactly
what semantics are represented, and I'm sure there are other
interpretations.

I'd forgotten about rdfs:seeAlso, though, and that strikes me as a
better choice for @longdesc than dc:description. What do you think? If
we did that we'd have all the 'extra' triples in the RDF/RDFS
namespaces.


> I am a little bit afraid of adding 'extra' semantics to a number of
> other xhtml attributes this way. If we do that, should we also assign an
> explicit triplet to @title in an 'a' element? After all, that could also
> be interpreted as an rdf:label... Where do we stop?

Again, I don't have a problem with taking the 'minimal for now',
approach, and leaving to the future an examination of other patterns.
Just one quick point on 'where to stop', though; I went through all of
the elements and attributes in HTML to see if there were any
constructs that might be useful, and I've documented the ones I could
find here, with some suggestions as to what they might 'mean':

  <http://www.w3.org/2006/07/SWD/wiki/RDFa/ProposedStructure>

I'm not at all proposing that we use them now, but it does at least
give us a sense of the 'known universe' from the point of view of what
we might consider generating from the semantics that HTML already has.


> Obviously,
>
> >  <div about="#me" class="foaf:Person">
> >    <span property="foaf:name">Mark Birbeck</span>
> >    <img rel="foaf:img" src="mark-birbeck.jpg" alt="Mugshot of Mark
> > Birbeck" />
> >  </div>
> >
> > which would yield:
> >
> >  <#me>
> >    a foaf:Person;
> >    foaf:name "Mark Birbeck";
> >    foaf:img <mark-birbeck.jpg> .
>
>
>
> makes a lot of sense and reusing the src attribute to denote the object
> (or the subject with @rev) is probably a clear and good idea. I wonder
> whether this is where we should stop...

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.

So could you cast a vote for whether you think the rdf:type generated
from an appropriate @class value would apply to @src or to any @about
that is present? I know it probably appears obvious that it should
apply to @src--especially since there might not be an @about
value--but that would mean that it behaves differently to the way
@href operates. I actually think that is a good thing, because I think
presenting @src as just the same as @href would be confusing, and
instead we should just define img/@src in its own terms. But it still
needs agreeing on. :)

Regards,

Mark

-- 
  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 Thursday, 21 June 2007 16:53:46 UTC