Ivan wrote:
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.
Mark wrote:
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.)
eRDF also generates rdfs:label triples for img and anchor elements, and
I've had problems with this generation of triples that I'm not in
authorial control over.
What I was doing was taking the triples generated from a php template
marked up with eRDF, and using that to generate SPARQL queries. So the
extra triples were a nuisance because it would add conditions I didn't
want to my generated queries, which made them return different results.
So I wrote my own parser that made the generation of these extra triples
optional.
To be fair, that's a fringe use of RDF-in-HTML, but you could take it as
an example of unintended negative consequences when you try to do too much
and don't give the author control. As I've said before, I think
RDF-in-HTML is an interesting space, and I reckon there are lots of uses
for it still waiting to be discovered, so it's worth bearing in mind that
magical automation can often be more annoying than helpful (like the
paperclip in MS Word ;) ).
On the other hand, when trying to write software that displays RDF,
rdfs:labels are very nice to have. Exhibit (from Simile) now allows you to
use any RDF on the web to power your exhibit (on the fly), but if the
resources don't have rdfs:label properties, then the software falls back
to these long, unfriendly-looking, generated id strings. So I can also see
that it makes your RDF more useful if the resources are nicely labelled,
and it's definitely easier to write software if you can rely on labels
being present.
However, on balance, I think it's better to leave the author in full
control over the triples generated as default behaviour.
Cheers
Keith
ps: I'd also chime in agreement with what Dan was saying about not
assuming anything that you can parse into some triples /is intended/ to
parse into those triples. For example, since the RDFa syntax is still
being finalised, it doesn't seem improbable that there might be RDFa out
there that wouldn't now parse into the triples that the author intended
when s/he wrote the html.
Authorial intention is key.
