SPARQL Extractor - problems with settings error handler + extract only triples without error

[tomas-knap]

Please test pipeline Copy of Extractor test on http://odcs.xrg.cz:8080/odcleanstore-test/#!ExecutionList/exec=106&page=1&owner.username=admin

As you can see, the settings of the extractor involve - use error handler, continue when errors are revealed:

By the extraction reveals error when certain part is loaded and the whole extraction fails.

Correct behaviour: Extraction should skip ONLY the problematical triples

[tomas-knap]

Further, the log says: Expected an RDF value here, found '§' [line 4125]

But this is not useful. Please provide also the particular triple which cause the problem

[tomesj]

Parser má problém konkrétně v této trojici (vadí mu použití znaku §, což vede k fatal erroru, který okamžitě končí parsování) : ns295:§ rdf:type lex:Act .

Pro definované prefixy prefix ns295:http://linked.opendata.cz/resource/legislation/cz/act/0/ prefix rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# prefix lex: http://purl.org/lex#

Hledám způsob, jak tento fatal error převést na klasický error, který by se zachytil pomocí error handler poznamenal a reportoval na konci - parser by přitom mohl běžet dál až do konce:-)

Nevím, jestli to půjde zařídit, nicméně se o to pokusím :-) Jde o to, že je-li error pro parser fatální (jako v tomto případě, ani nic už nereportuje a rovnou skončí s exception)

[tomesj]

Tak jsem nakonec zjistil, že formát N3, který jsme původně používali pro stream z endpointu už není v nabíce formátu - změnil jsem jej tedy na NTriples a vše je nyní OK.

Bylo tam špatně nastavené též baseURI, ale to nezpůsobovalo ty problémy - i tak jsem to opravil na správné :-)

Zkoušel jsem a všech 5000 triplů se již extrahuje úspěšně :-)

[tomas-knap]

Pockej, to je divne, tedy ns295:§ uz projde, kdyz to parsujes jako NTriples? Nebo cim si to vysvetlujes, ze to potom uz nehazi Fatal exception?

[tomesj]

Jo, je to přesně tak...Já jsem totiž ještě předtím udělal to, že jsem výsledek toho dotazu uložil jako data do souboru a zkusil parsovat ten soubor - tam to bylo vše OK :-) A pak jsem zjistil, že když tohle nastavení, tak je to už taky OK .

[tomas-knap]

Nechapu. ns295:§ rdf:type lex:Act Tahle trojice by nemela projit v zadnem pripade. Rozdil je tedy ten, ze v pripade N-triples tu chybu odchyti error handler, ale v pripade N-triples fatal error handler? Potrebuju nejake logicke vysvetleni proc ta tvoje uprava pomohla. At vime, ze to nepomohlo jen v tomhle jednom konkretnim pripade, napr.

Zkus si vratit to baseURI jak bylo a zkusit N-Triples misto predchoziho N3. Hadam, ze to dopadne stejne.

[tomas-knap]

Jirko, jeste nechapu "sem výsledek toho dotazu uložil jako data do souboru". Kde se tam vytvari ten soubor u SPARQL extraktoru?

[tomesj]

U SPARQL extractoru se konkrétně nevytváří žádný soubor. Já chtěl konkrétně zkusit, zda je chyba v datech a nebo někde jinde - tak jsem ty data nahrál do souboru a zkusil File Extractor - tam extrakce dopadla OK...Tak jsem zkoumal proč, když oboje je stejný stream a používá se stejný parser....

[tomas-knap]

Ok, ale porad jeste nechapu, viz jak jsem psal:

Rozdil je tedy ten, ze v pripade N-triples tu chybu odchyti error handler, ale v pripade N-triples fatal error handler? Potrebuju nejake logicke vysvetleni proc ta tvoje uprava pomohla. At vime, ze to nepomohlo jen v tomhle jednom konkretnim pripade, napr. Vzdy musi existovat logicke zduvodneni, jinak se stava software nerizenou strelou. Pristup, ze se to zkusilo a ono to vyslo je spatny.

[tomesj]

Není to tak, v prvním případě šlo o fatal error, ale ve druhém případě už k žádnému erroru vůbec nedošlo....Původně jsem myslel, že fatal error zmírním pouze na error, ale v případě použití N-Triples místo N3 už pro parsování nebyl error vůbec žádný :-)

[tomas-knap]

Tak to je dobre, ale co pomohlo? Zkus prosim vratit to baseURI na moment tak jak bylo a zkus jak se to bude chovat. Bo to baseURI by mohlo byt duvodem. Jinak nechapu proc ns295:§ je fatal error v N3 a ok v N-Triples

[tomesj]

Tak jsem ti přidal test přímo do SPARQL extractoru - SPARQLExtractorVirtuosoTest test, na kterém si to sám můžeš zkusit. Je tam nastavený formát na N-Triples a test projde...Když formát změníš na N3 (jak bylo dříve) dostaneš původní chybu :-) Schválně si to zkus :-)

[tomas-knap]

to ja ti verim, ale zajima me ten duvod. Tedy proc v N-triples je to ok, ale N3 ne.

[tomas-knap]

Btw. je potreba ten test upravit, aby pouzival lokalni virtuoso, nemuze sahat do cizi db. Muze se kdykolv stat, ze tam nebude

[tomesj]

Tak to opravdu nevím - zkoušel jsem i vrátit tu hodnotu baseURI, jak jsi psal, ale to výsledek vůbec neovlivňuje :-) Prostě mám pocit, že je potřeba používat jen formáty endpointu - tedy spolehlivé jsou RDF/XML a N-Triples.

[tomas-knap]

Dnes uz to nech, ale zitra popremyslej nad tim duvodem, at to muzem zavrit

[tomesj]

Ten test je z kategorie integračních, takže se normálně nepustí :-) Takových testů tam máme víc :-) No zkusím popřemýšlet, ale do parseru nevidím, tak nevím....Logicky to moc smysl nedává :-)

[tomas-knap]

Mno, s tim endpointem to nesouvisi, pokud by ten endpoint nepodporoval N3, tak by ti nevratil zadne trojice a rovnou chybu, ne? Tedy ten endpoint N3 podporuje.

[tomas-knap]

Proste tomu N3 formatu z nejakeho duvodu vadi ns295:§

[tomas-knap]

Tzn. chtelo by to kouknou do specifikace formatu N3 a N-Triples - proc jednomu vadi ns295:§ a druhemu ne.

[tomesj]

No na tom něco bude :-)

[tomas-knap]

Co je vlastne za tim namespacem ns295?

[tomesj]

To už jsem psal hned u toho - jde o prefix ns295:http://linked.opendata.cz/resource/legislation/cz/act/0/

[tomas-knap]

Mozna tusim. V N-triples se vubec prefixy nepouzivaji, ne? Tedy v N-triples nebude nikdy zapis ns295:x. Na druhou stranu v N3 se prefixy pouzivaji. Mno, a kdyz se to prefixuje, tak se mu nelibi ten paragraf

[tomas-knap]

ale stale jeste nevime proc se mu nelibi ten paragraf

[tomas-knap]

http://www.w3.org/TeamSubmission/turtle/#qname

[tomas-knap]

http://www.w3.org/TeamSubmission/turtle/#nameStartChar

[tomas-knap]

Paragraf mezi povolenymi starting chars nebude, proto ta chyba. Zvlastni, ze je rovnou fatalni

[tomas-knap]

Tedy zkus Jirko jeste zjistit, jestli se da ten parser nastavit tak, aby nevyhazoval fatalni chyby, ale jen chyby. Protoze protentokrat se to vyresilo, ale v jinych pripadech ti N-triples nepomuzou

[tomesj]

Je to tak, bohužel...Ale je to zajímavé zjištění celkem :-)

[tomas-knap]

musis obecne pocitat s falal errors

[tomas-knap]

Co to vyhodi za exception v pripade fatal? Ta se taky da odchytit normalne, ne?

[tomesj]

Jedna možnost tam je - jde nastavit množina atributů, pro které se fatální chyby mají brát jen jako chyby (my např. používáme VERIFY_DATA_VALUES)

Já už ale projel všechny možnosti, co jsou k dispozici (nastavil) už v prvním případě, ale nepomohlo to (není to dělané úplně na vše)

Jinak když nastane fatální chyba - vyhodí to RDFParseException.

[tomas-knap]

Jirko, co bys mohl, je predefinovat chovani metod reportFatalError na RDFParseru, viz http://openrdf.callimachus.net/sesame/2.7/apidocs/index.html

Tedy ze by se tvuj parser choval jako ten jejich, jen by predefinovaval fatalError.

Nicmene to neni pekne reseni. Hezci reseni by bylo pohrat si s nastavenim toho jejich openRDF parseru, tedy pouzit ParserConfing http://openrdf.callimachus.net/sesame/2.7/apidocs/index.html Koukam, ze defaultne se rada normalnich chyb bere jako fatal. Tedy kdyz je pridas mezi non-fatal, tak to nebude vyhazovat tu vyjimkou ParserException. Akorat nikde neni seznam moznych chyb.

V nejhorsim muzes chytat tu vyjimku RDFParseException u parser.parse(), ne? S tim, ze tedy reknes, ze to byla chyba fatalni, tedy cely extrahovany chunk je v pytli a pokracujes dal (tedy pokud si to uzivatel tak nastavil v conf)

[tomesj]

No ten ParserConfig my už ale dávno používáme, s tím že tam nastavujeme ty non-fatal exception (je to ten případ jak jsem psal - používáme VERIFY_DATA_VALUES, ale já pro tento případ zkoušel nastavit i ostatní a i tak došlo k fatal erroru, tedy to nepomohlo :-)

[tomesj]

Navíc když bych zachytil výjimku RDFParseException v případě fatal erroru, tak pro pokračování parsování se musí metodě parse předat zase inputStream

• a ten nevím, jak by se "nerozdělil", aby to pokračovalo tam, kde skončil ten předchozí.
• tedy si asi vůbec nepomůžeme

[tomas-knap]

Jo tak. Jasne. tedy kdyz to shrnu, problem je, ze kdyz to vyhodi fatal error a uzivatel ma nastaveno: extract only triples with no errors, tak mu to skonci po prvni (fatal) chybe.

Muzem udelat to, ze kdyz ma uzivatel nastaveno "extract triples with no errors", tak v pripade fatal error publikujeme DPU event ve stylu "Fatal error discovered, only triples occured before the fatal error occurrence were extracted", v detailu pak jsou podrobnosti, idealne jaka trojice zpusobila problem - fatal error.

[tomesj]

Je to přesně tak, jak píšeš :-)

Můžeme ale zjistit pouze číslo řádku a popis problému - konkrétní trojici, ve které jsou problémy by bylo možné zjistit až v dalším kroku - ve chvilce, kdy se používá handler (ale k díky tomu, že to vyhodí RDFParseException, tak se k tomu už nedostaneme). Tedy budeme se muset spokojit aspoň s tím, co víme :-)

[tomas-knap]

To nemusi byt pravda, muzes napsat vlastni handler tech fatalErrors, ne? A ten muzes nasetovat tomu parseru. Viz http://openrdf.callimachus.net/sesame/2.7/apidocs/index.html

2013/12/23 Jiří Tomeš notifications@github.com

Je to přesně tak, jak píšeš :-)

Můžeme ale zjistit pouze číslo řádku a popis problému - konkrétní trojici, ve které jsou problémy by bylo možné zjistit až v dalším kroku - ve chvilce, kdy se používá handler (ale k díky tomu, že to vyhodí RDFParseException, tak se k tomu už nedostaneme). Tedy budeme se muset spokojit aspoň s tím, co víme :-)

Reply to this email directly or view it on GitHubhttps://github.com/mff-uk/ODCS/issues/967#issuecomment-31115184 .

[tomesj]

No ale my přece používáme vlastní handler a ten nastavujeme :-) Ale je to tak, jak jsem psal...Nepíšu to tady jen tak do větru :-)

[tomas-knap]

Mno, tak kdyz mame vlastni handler tak uz se neda dostat k informaci o trojici?

[tomesj]

K té informaci se lze dostat jen v případě warningu/normálního erroru. Je potřeba, aby se při chybě předalo řízení parseru tomu handleru, ale když parser nalezne fatal error, do handleru se to už nedostane a rovnou to skončí RDFParseException. A to je ten důvod proč nemůžeme zjistit tu trojici - to se zjišťuje až v handleru a tam už se to bohužel nedostane....

[tomas-knap]

To je divne, proc by tedy to rozhrani (errorListener) umoznovalo definovat si fatal error handler? To by pak nedavalo smysl, bo se to tam nikde nedostane. Koukni prosim jeste do openrdf doc, musi jit nejak zajistit, aby se ta chyba dala odchytit

[tomas-knap]

Kdyztak prosim napis na podproru, tam uz jsi psal, vid?

[tomesj]

Tak jsem napsal dotaz na oficiální podporu openRDF ohledně toho, zda se dá nějakým způsobem dostat konkrétní trojici v případě, že dojde k fatal erroru. Uvidíme, co odpoví :-)

[tomesj]

Tak jsem dostal email s vyjádřením přímo z openRDF podpory

• jde-li získání informací o trojici v případě fatal erroru zatím není možné - mám to přidat do jejich BUG trackeru a budou se tím zabývat v další verzi.

Přikládám obdržený email:

Hi Mr Tomes,

The current ParseErrorListener interface doesn't allow for this case. It isn't always possible to recover from parse errors and return what the statement could have been for a variety of reasons. However as you point out if the error is non-fatal in some cases a statement is sent to the RDFHandler so it seems reasonable the it could also be sent to the ParseErrorListener in those cases.

Could you file this on our Jira tracker as an Improvement and I will add it to the list of new features for our next major version that is still in the planning stage ( it will be version 4 to distinguish it from the ill fated version3 alpha that was released in the past but not developed to a release )

[tomas-knap]

Ok, diky. Tak prosim misto "Extract only triples with no error" dej "Extract only triples with no error. If fatal error is discovered, pipeline is stopped"

A tohle si dame do future work. Jeste sem prosim hod mail, kam jsi psal na tu podporu. A take jim prosim zaloz to JIRA issue (viz jak ti psali)

[tomesj]

Zde je mail:

Hello, I used openRDF version 2.7.7.

If I use RDFParser + ParseErrorListener + handler where I can add RDF triples.

But when I call method

parser.parse(inputStream,baseURI)

and it stops on fatal error event, I can give concrete probleme triple (subject, predicate, object) - not only message, line and column. Is it possible ?

If parser stop on warning or error event, I can get probleme triple thanks method handleStatements (on set handler), but if there is the fatal error, parsing is stoped and RDFParseException is thrown (I have no access to probleme statement yet).

Note: I know about setting (add) nonFatalErrors thanks using ParserConfig. It goes only about how to find out statement contains this fatal error.

Thank you for your answer.

[tomas-knap]

Diky, jeste prosim napis tu emailovou adresu, kam jsi to posilal

On Sat, Jan 4, 2014 at 9:49 AM, Jiří Tomeš notifications@github.com wrote:

Zde je mail:

Hello, I used openRDF version 2.7.7.

If I use RDFParser + ParseErrorListener + handler where I can add RDF triples.

But when I call method

parser.parse(inputStream,baseURI)

and it stops on fatal error event, I can give concrete probleme triple (subject, predicate, object) - not only message, line and column. Is it possible ?

If parser stop on warning or error event, I can get probleme triple thanks method handleStatements (on set handler), but if there is the fatal error, parsing is stoped and RDFParseException is thrown (I have no access to probleme statement yet).

Note: I know about setting (add) nonFatalErrors thanks using ParserConfig. It goes only about how to find out statement contains this fatal error.

Thank you for your answer.

— Reply to this email directly or view it on GitHubhttps://github.com/mff-uk/ODCS/issues/967#issuecomment-31574365 .

[tomesj]

Posílal jsem to na: sesame-general@lists.sourceforge.net