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

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

From: Benjamin Adrian <benjamin.adrian@dfki.de>
Date: Wed, 21 Jul 2010 14:23:26 +0200
Message-ID: <4C46E6BE.3050609@dfki.de>
To: Ivan Herman <ivan@w3.org>
CC: RDFa WG <public-rdfa-wg@w3.org>
Hi Ivan,

My main concern about an RDFS vocabulary for error triples about RDFa 
Parser errors is,
that (if we want to do a good job) it has to be extensible for all kind 
of RDF parser errors.
And this a real big issue and means a lot of communication efforts!

> 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 don't see the real use case here. I never wrote any program logic on 
error messages or info messages.
I just use grep to see what went wrong. Inside an application logic I 
also catch exceptions and check what type they are.
> 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...
>
>    
Well it's not a problem, but an issue the application developer has to 
be aware of.
The ordering of RDF triples is random. That means using the 
RDFTripleIterator
for complex queries is nearly impossible on a large dataset.

It also means that filtering error triples with triple-events is very 
difficult and error-prone.
Multiple randomly ordered RDF triples about errors are completely 
useless when using the
event based mechanism.

That's why I recommend describing each error in a single RDF triple.
Other solutions might look like:
  - error events contain a property group instead of a single triple.
  - the returned triple order of the processor graph is fixed

Cheers,

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


-- 
__________________________________________
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
__________________________________________
Received on Wednesday, 21 July 2010 12:24:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:07 GMT