W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > June 2010

on the error mechanism

From: Ivan Herman <ivan@w3.org>
Date: Sun, 20 Jun 2010 11:57:13 -0700
Message-Id: <BEF50A61-106E-4484-B1BD-B679A8F91A9F@w3.org>
To: W3C RDFa WG <public-rdfa-wg@w3.org>
Hi guys,

my apologies to have gone silence, but it is difficult to keep up with things while on a trip with a busy schedule...

Anyway. I looked at the minutes of the last telco and the way I understand it there is a principal agreement on having some sort of an error mechanism. I also saw discussions on whether it should be event or graph based, and whether we should use a default graph or not for these. Just some thoughts that came to my mind while flying to San Francisco from Seattle this morning...

- Default vs. non-default graph.

We have this formulation in the current document about a default graph. I guess the idea is that if errors are in triples, they should go to another graph. While this sounds like an elegant approach, I see some complications

First of all, at this moment there is no standard way to express several graphs, ie, named graphs. Although SPARQL tip-toes around this, the fact of the matter is that we do not have a standard named graph formalism. That may be handled soon with a new RDF WG (that is one of the issues that we have on board for the workshop in a week), _at this moment_ we have no standard reference. Ie, I am not sure how we would define the 'error' graph.

The named graph mechanism, as is used by the community, is based on the idea that one can give a URI to a collection of triples, that is the 'named graph', and take it from there. Ie, a URI can also identify a graph. But... is that o.k. for an error graph? Well, no, unless the named graph mechanism allows the usage of blank nodes to identify a named graph (where 'named' becomes a misnomer, actually...). Otherwise the question is: if we define a separate error graph for an RDFa processor, what is its URI? Do we require the processor to use, say, a UUID URN for that purpose, for example?

I sense a bit of a rathole here. I wonder whether it is not simpler not to go there and simply add the error graphs into the default graph. While slightly less elegant, I am not sure I see the dangers of doing so...

- Event vs. graphs

My reading of the minutes is to say: fine to use triples for errors in RDFa Core, but events seem to be better for an API. Which might be fine but my question is: what triples will an rdfa parser put into the store? Will it put the error triples there, too? I would stipulate the answer is yes. In which case, having both events and error triples around is a duplication of the functionality which is not a really nice practice...



Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Sunday, 20 June 2010 18:55:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:47 UTC