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

Hi Ivan,

That's fine...I don't _disagree_ with you, and there's no problem with
putting these off to the future. As you say, we could certainly take a
leisurely run through all of the mark-up in HTML/XHTML in the future
and get input from various communities.

So to recap where this issue is at, so that those who haven't voted
yet can state their preference, the sentiment is that the attributes
with triple-generating potential on <img> are:

  <img about="s" rel="p" src="o" class="t">

and that 'type' applies to the object, 'o', rather than to the subject 's'.

As pointed out by Ben, in the sense that we have an element that
contains an object that is also a subject, then this construct echoes
striping. There may be scope for linking the two concepts in our
documentation, or at the very least--which may be what Ben is
saying--scope for showing that this isn't such a unique construct.

As for other attributes, such as @alt and @longdesc, we may or may not
revisit those in the future, when we've learned a bit more about real
life use-cases.

If I haven't captured the discussion so far, please say so,
otherwise...vote now! :)

Regards,

Mark

On 22/06/07, Ivan Herman <ivan@w3.org> wrote:
>
>
> Mark Birbeck wrote:
> > Hi Ivan,
> >
> > Fair comments, but I'd like to follow this through a bit more.
> >
> > First, what is the downside of adding extra triples, as long as they
> > are consistent? You don't need to use them, after all. (I'm not saying
> > there isn't a downside, just asking if anyone can think of one.)
> >
>
> Yeah. That is also true...
>
> > I ask because I often find when trying to make use of the triples to
> > enhance a document, that you invariably need a label for the things
> > that you find in the document. Take a simple example, like a semantic
> > web browser that parses the RDF in a document (whether RDFa,
> > microformats, links to RDF/XML, etc.), places the triples in a data
> > store, and then provides options to the user on things they can do
> > with that data. Now, with data like a foaf:Person it's probably quite
> > easy, since you can display a menu option like "Add Ivan Herman's
> > details to your address book." But it becomes more difficult when you
> > want to display a menu option like "Upload 'portrait photo for Ivan'
> > to Flickr" or "Add tags to 'portrait photo for Ivan' to Flickr", if
> > you don't actually have some text to use.
> >
> > The problem I keep coming up against is that the software I'm working
> > on constantly needs to go back to the original document to get
> > information that it can make use of, which feels wrong to me. I should
> > be able to 'act' on the data regardless of its source--or to put it a
> > different way, I should have everything I need in the triple store.
> >
> > You could extend this logic to cover accessibility too; in the future
> > I'd imagine that accessibility software could make use of the triples
> > generated, just as much as it makes use of the source document.
> >
>
> We may get close to something ugly, namely some sort of an RDFa
> profiling (do _not_ eat me alive!). What I mean is that there may be
> different of RDFa processors that either do a minimal triple extraction,
> or do some extra work extracting extra semantics from the HTML content.
> I am not sure how to control that... Yes, I know it is ugly!:-)
>
>
> > But.... :)
> >
> > As long as we don't rule this out for the future it's not a problem to
> > me if we leave it to one side for now. If you still disagree with
> > processing @alt and/or @longdesc I don't have a problem with marking
> > this as something we come back to in a future iteration.
> >
>
> I think that, at the moment, we should try to do the minimum, ie, no
> extra triplets, and see how the application(s) of RDFa evolve in the
> community. This is also a question of consistency: you have a list of
> other elements where the issue may come up, and, again, where do we
> stop? I do not feel really comfortable on what exactly such extra
> HTML->RDF mappings should be. I am not even sure that different
> communities would opt for the same mapping, we may have different
> approaches around and spend _lot_ of time sorting that out...
>
> I know I am a bit vague, nothing mathematically precise here...
>
> Cheers
>
> Ivan
>
> > Regards,
> >
> > Mark
> >
> > On 22/06/07, Ivan Herman <ivan@w3.org> wrote:
> >>
> >>
> >> Mark Birbeck wrote:
> >> > Hi Ivan,
> >> >
> >> >> B.t.w., I realized yesterday evening (under the shower, the best place
> >> >> for these things:-) that this is wrong.
> >> >
> >> > :)
> >> >
> >> >> The range of rdfs:seeAlso is
> >> >> defined to be rdf:Resource by the RDF Semantics, ie, it should not be
> >> >> used with a Literal as an object.
> >> >
> >> > Right. That's why I was wondering if rdfs:seeAlso was a better choice
> >> > for @longdesc than dc:description, since @longdesc takes a URI. I'd
> >> > forgotten about rdfs:seeAlso until I saw your post.
> >> >
> >> >
> >> >> But there is also rdfs:comment, for
> >> >> example, that could be used instead of rdfs:label, so the original
> >> >> argument holds...
> >> >
> >> > Sure...I think you are right that there are better choices than
> >> > rdfs:label. We just need to alight on one and go with it. (And I
> >> > assume that your comment is a +1 for the idea that @alt should
> >> > actually be represented in triples, even if we're not yet sure what
> >> > triples?)
> >> >
> >>
> >> Actually, I am not convinced of that. I guess It is a question of
> >> general approach: I'd somehow prefer, as an author, _to be in control_
> >> over _all_ triples that are generated, and avoid any automatism. I may
> >> put in the 'alt' tag into my HTML file for reasons of accessibility, for
> >> example; I may _not_ want that information to appear in the triples.
> >>
> >> As a simple example: if I use an HTML file for my foaf file, too, I may
> >> have an image in that HTML file. As an HTML file I might put there an
> >> alt text with a pretty uninformative text like "portrait photo for Ivan"
> >> which is there so that screen readers would convey an information to a
> >> blind reader that, in fact, this photo is without an further info and is
> >> put there to make seeing people happy. While the photo reference would
> >> go into the foaf file as a depiction, and that is fine, generating an
> >> extra rdf:comment or rdf:label or anything else _automatically_ is a
> >> side effect of the mechanism that I may not want at all.
> >>
> >> Bottom line: no, I am not convinced.
> >>
> >> Ivan
> >>
> >>
> >> > Regards,
> >> >
> >> > Mark
> >> >
> >>
> >> --
> >>
> >> Ivan Herman, W3C Semantic Web Activity Lead
> >> URL: http://www.w3.org/People/Ivan/
> >> PGP Key: http://www.cwi.nl/%7Eivan/AboutMe/pgpkey.html
> >> FOAF: http://www.ivan-herman.net/foaf.rdf
> >>
> >>
> >
> >
>
> --
>
> Ivan Herman, W3C Semantic Web Activity Lead
> URL: http://www.w3.org/People/Ivan/
> PGP Key: http://www.cwi.nl/%7Eivan/AboutMe/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
>
>


-- 
  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 12:31:03 UTC