Re: on the error mechanism

Hi Ivan,

I think there are some points that aren't completely clear in the
minutes, so it's good that you've raised your issues, and it should
help us clarify a few things.


RDFA API

First, my main argument on the call was that the primary mechanism for
the RDFa API should be to either fire an event or call a callback
function when an error is found.

This could be implemented as easily as adding an extra parameter to
the parse() function, and this would be the callback function to be
called every time something goes wrong.

Once this mechanism is in place, you can use the callback to add
triples to a graph if you want -- or you could do something else that
no-one has thought of yet. But the key thing is that this is actually
the simplest technique you could have when dealing with the RDFa API;
certainly your proposal that extra triples are added somewhere is far
more elaborate than a simple notification mechanism. (And I didn't get
the impression that there was much appetite for it on the telecon,
although obviously people can say otherwise.)


RDFA CORE

However, that still leaves the question of what to do with errors in
RDFa Core. My personal preference is that we do nothing, and define
this in the API. However, if we have to do something in Core, then the
next best option is to create a *new* graph that contains whatever
triples will designate the errors and warnings.

I think it's absolutely crucial that these triples are not in the same
graph as the data that was provided by the page; to be honest, I'm
amazed that time after time we have discussions about adding more
stuff to the default graph, such as @rel="profile", prefix mappings,
and now errors. This is pretty fundamental when it comes to RDF -- we
should keep the data in one place, and the metadata in another.

However, even if you agreed with this principle, I'm getting the
impression that your view is that since there is no standard way to
identify graphs, then we have no choice but to pollute the default
graph. I disagree with that.

First, RDFa Core doesn't actually have to say anything on this matter;
all it has to do is:

(a) define the 'error and warning vocabulary' (or better still, use an
existing one -- EARL might work, for example);

(b) stipulate that these triples must not go into the default graph.

That's it.

Since RDFa Core doesn't currently define how to get at triples that
are in the default graph it can hardly be regarded as a weakness that
we now don't say how to get at errors. Both of these things are up to
the implementation.

Of course, we want people to define these things in a standard way,
and that's exactly why we're pursuing the API -- which is why I say
that's the natural home for error reporting. So if we flip back to the
API, we also find that it makes no difference that there is no agreed
upon way to access named graphs because all we have to do is specify a
way to get the 'error graph'.

For example, if we wanted to, we could simply declare an additional
store on the 'data' interface, which contains the errors for the
default store:

  document.data.errors

Or we could make the parse() method take *two* stores as its parameters:

  parser.parse(store, errorStore);

All triples go in 'store' and all errors go in 'errorStore'.

And if we really want to mix 'em up and put the errors in with the data:

  parser.parse(store, store);

;)

I realise that I've covered a lot of ground here, and although I'm not
expecting you to immediately agree with me, I'm hoping that this extra
context will show a bit more clearly some of the thinking that's going
on behind this.

Regards,

Mark

On Sun, Jun 20, 2010 at 7:57 PM, Ivan Herman <ivan@w3.org> wrote:
> 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...
>
> Cheers
>
> Ivan
>
>
> ----
> 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 Monday, 21 June 2010 01:16:01 UTC