- From: Benjamin Adrian <benjamin.adrian@dfki.de>
- Date: Wed, 21 Jul 2010 17:04:02 +0200
- To: Ivan Herman <ivan@w3.org>, RDFa WG <public-rdfa-wg@w3.org>
Hi Ivan My point is, we need error handling, we can do this with RDF triples, but we should not build ontologies about error triples. Small notifications are all we need. More Comments are inline. >> 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. >> > Hm. Grep may not be an option is I run a (remote) distiller on a (remove) HTML file that refers to a (remove) @profile file... And, in the case of a remote service, there is no such thing as an exception. > Yes, I see the point. > So... what would you expect a remote service like a distiller to return if a @profile file is not reachable? Just return whatever triples that are generated and leave it at that? > > I would like to get informed if an error occurs. But I am absolutely happy with a small message. _:abc dc:subject "A ProfileReferenceError occurred on line 45, column 65" > > I do not understand that. In rough RDFLib parlance > > for s in processor_graph.triples((None, rdf:type, rdfa:ProfileReferenceError)) : > for c in processor_graph.triples((s, rdfa:context, None)) : > print c > > will print out all the @profile values that cannot be dereferenced. I do not see that to be any more difficult than managing triples in general... > > But in an event based API, each error triple is thrown online. What if you get 3 instances of rdfa:ProfileReferenceError? You cannot query for more triples about them, because these triple might be ordered before the rdf:type declaration. -->Here, you are working on a stream of RDF triples. That's the difference! >> 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. >> > We have not specified the error mechanism on the API. But isn't it possible to ask for a property group using the rdf:type of the error? I would then get hold of the subjects for errors and then I can get hold of the error descriptions for each of those. I really do not see why this is much more complicated than processing RDFa triples in general. > The SPEC sais one error message is one RDF triple. > Note that, I presume, the order in a property group is not fixed either... > > You are right, it's not. But all triples are STORED inside the property group. That's the difference to the stream of error triples above. >> - the returned triple order of the processor graph is fixed >> > I do not think this is feasible. What this means is that an implementation cannot use an underlying triple store or environment to generate and store error triples. That seems to be prohibitive to me... > > I agree! > I guess the real issue that does come and did come up in the past is whether an error mechanism is necessary at all. We seemed to have a working group consensus on this, and I begin to wonder whether this is still true... > > I believe an error mechanism is necessary. But it has to be easy to use and to specify. > >> 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 >> __________________________________________ >> >> > > ---- > 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 15:04:34 UTC