Re: on the error mechanism

tracker, this is on ISSUE-26

Hey Mark,

based on the time of your reply, I have the impression that we are on the same time zone again:-)

comments below.

On Jun 20, 2010, at 18:15 , Mark Birbeck wrote:

> 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.
> 

I skip the RDFa API part. The event handling mechanism for RDFa API obviously works, and I do not really have an issue with it (except that the devil may be in the details:-)

> 
> 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.

And I do not agree with this, see below...:-(

> 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.


I do not think is a right criticism. The @rel profile or the prefix mappings do _not_ add any new triples to the default graph. The mechanism itself is described in terms of RDF, but that is different. The error triples are the _first_ case of adding triples to this graph.

I do not see this separation of data and metadata as being so fundamental as you write. RDF is a bunch of triples, each of them stand on their own right. There is no reason why not mashing up all kinds of triples in one place as long as it is clear what they are. 

Following your principle, for example, I should never have, in the same RDF file, facts in the form of triples and, for example, RDFS statements on the predicates I use for those facts. But there is no fundamental reason to do that (and this merge is often done) and, actually, the RDFS semantics works on the merge of all triples put into the same bin, regardless of whether they are facts or 'metadata', as you call it.

Don't take me wrong: _if_ we had a standard for named graph, with standard semantics, serialization(s), etc, then it might be a nice design approach to use them. True. But I do not see that as being fundamental.

> 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.

That is correct, though I do not like the word 'pollute'... For me, the default graph is whatever triples that are clearly defined in the standard.

> 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.
> 

Well, I disagree with (b)... (and agree with (a))

> 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'.

I think our issue is that we have to reconcile the requirements of two classes of RDFa usages. One is the "app-in-browser" type thingy, making use of the RDFa data in the HTML file, and the other is "retrieve-RDF-from-HTML" type, for which RDFa is simply a serialization. There are obviously many shades to these, but I guess these two characterize the situation well. And both application classes are equally important, obviously.

For app-in-browser things the API plus the event mechanism you describe below just works fine. No argument there, even if the details are still to be worked out. That is also the reason why I skipped those parts for now.

The problem I have or the retrieve-RDF things is: what would an application expect? The goal of the application is to get to the RDF data, similarly to the way it uses GRDDL, some sort of an RDF<->SQL bridge, etc. No reference or usage of an API; in many cases the usage of RDFa simpy means a HTTP GET on some weird URI. The RDFa API is simply irrelevant for this RDFa usage, so 'flipping back' does not help... 

With your approach RDF-from-RDFa services, as distiller or other, will have to have extra flags that make them merge the error triples to what is returned as part of the service. That is obviously a workable option, but it adds a non-standard 'flag' to each implementation which I do not think is healthy.  


> [skipping again the RDFa API specific issues

Cheers, see you around I guess...

Ivan


> 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
>> 
>> 
>> 
>> 
>> 
>> 


----
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