Re: ISSUE-26: We don't need any RDFS vocabulary for error triples!

Benjamin,

this comes back to the discussion we had before on the errors on the API and on the 'RDFa processor' level.

What you propose, if my understanding is correct, is to have an error vocabulary in XML and return that to the caller as an XML Literal. If I am an RDF application and use a remove RDFa service to extract RDF from an RDFa file that means that I would have to include into my application an XML parser (even if it is a simple one) just to understand the Error message, whereas if I get the results in the form of triples then, well, I use whatever I use for my application already. I just do not believe that would be acceptable.

I am less qualified on the API level but... the user of an API surely has to be prepared to handle RDF graphs. That should include the handling of a processor graph. If the order of the statements is a problem for the API user than we have much bigger problems on our hands because the order of RDF triples extracted from the RDFa content is also random! I would hope that is not a real issue...

Cheers

ivan



On Jul 19, 2010, at 13:38 , Benjamin Adrian wrote:

> Hi,
> 
> I say we don't need any RDFS vocabulary for error triples!
> 
> Read why:
> 
> The spec sais: 
> 
> "SAX-based processors or processors that utilize function or method callbacks
> to report the generation of triples are classified as event-based RDFa Processors."
> 
> That means, the callback function is called  for every generated RDF triple. 
> Parsing error triples with these callbacks can be extremely difficult, when
> the ordering of the generated triples inside the processor graph are unsorted
> (as it may occur -- it's RDF not XML!). 
> 
> So searching the stream for triples with patterns like:
> rdf:type rdfa:ProfileReferenceError
> 
> 
> is nice when the generated triples' ordering is like this:
> 
>      _:1 a rdfa:ProfileReferenceError ;
>      _:1 dc:description "The @profile value could not be deferenced" ;
>      _:1 dc:date "2010-06-30T13:40"^^xsd:dateTime ;
> 
> But what if they are generated like this?
>      _:1 dc:date "2010-06-30T13:40"^^xsd:dateTime ;
>      _:1 dc:description "The @profile value could not be deferenced" ;
>      _:1 a rdfa:ProfileReferenceError ;
> 
> 
> Then you have to puffer and search the whole stream, which means you should better use the
> model based approaches of error reporting. 
> 
> --> NEITHER EARL NOR ANOTHER RDFS  it should be really simple.
> 
> I don't think that the intention of EARL matches the use case of our error vocabulary.
> The used RDF vocabulary must be as simple as possible. 
> That means it should use as few properties as possible. 
> Nobody will ever reason on an error graph. So why not 
> summarizing all information about a single error in a single triple describing a stack trace.
> 
> [] c:description "ProfileReferenceError: The @profile value <http://www.example.org/profile> could not be deferenced. \n
>                             Line <http://www.example.org>: 564 \n
>                             HTTP GET: ....\ n
>                             HTTP RESPONSE ".
> 
> If you say, well, a string is not not enough, try an XMLLiteral:
> 
> [] c:description "<ProfileReferenceError>: The @profile value <http://www.example.org/profile> could not be deferenced. \n
>                            <POSITION>
>                            <URL>http://www.example.org</URL>
>                            <LINE>564</LINE>
>                            </POSITION>
>                            <REQUEST> GET: ....</REQUEST>
>                             <RESPONSE>HTTP RESPONSE ... </RESPONSE> 
>                             </ProfileReferenceError>".
> 
> 
> That's it :) I'm fine with XML or plain Literals as objects for error triples. 
> 
> Best regards,
> 
> Benjamin
> 
> 
> 
>  
> -- 
> __________________________________________
> Benjamin Adrian
> Email : 
> benjamin.adrian@dfki.de
> 
> WWW : 
> http://www.dfki.uni-kl.de/~adrian/
> 
> Tel.: +49631 20575 145
> __________________________________________
> Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
> Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
> Geschäftsführung:
> Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats:
> Prof. Dr. h.c. Hans A. Aukes
> Amtsgericht Kaiserslautern, HRB 2313
> __________________________________________
> 


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