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

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