SPARQL Transformer -

[tomas-knap]

Please modify the core tab as in SPARQL transformer, so that it does not have one textarea for SPARQL query, but there is "+" and "-" button to add more textareas, so that one text area could be one query.

In short, the solution should be for the query textarea the same as for textfields for default graphs for SPARQL extractor.

[tomas-knap]

Validation of the SPARQL query is done for every such textarea. If some textarea has invalid query, such textarea is emphasized with exclamation mark

[tomas-knap]

When done with "+","-" buttons, assign to Jirka to finish the validation of the query.

[kukharm]

I added new functionality to the SPARQLTransformerDialog.java and tred to modify SPARQLTransformerConfig.java. @tomesj please modify the SPARQLTransformer.java (and maybe some other classes:) accordingly to this changes

[janvojt]

@kukharm Please do not break build! Also, if I try to add more than 2 SPARQL queries, save button is below the window, and there is no scrollbar so it cannot be saved.

@tomesj Please fix the SPARQL, I changed it to use only the first query, so it is compilable.

@tomas-knap I thought in December we said no more new features...this can be easily achieved with multiple transformers in serial setup.

[tomas-knap]

Yes, scrollbar must automatically appear if needed. By default, there should be only one textarea with the possibility to add more.

@tomesj All the queries must be validated separately, so when there is an error, user should know from the error message where the problem was (in which query). Please test the +,- functionality, test more queries (e.g. using construct with limit and offset)

@janvojt Thought this is a minor change already tested on other DPUs

[tomesj]

SPARQLTransformerConfig class is just only one boolean isContructType.

If we can support more queries , we need pairs (query,isContructType)....So, please @kukharm Maria to prepare it first. I can not update funkcionality without that :-)

isContructType

• is necesary when we use "special" contruct query where we can replace DPU names to graph names

[tomas-knap]

Jirka, I think it should be easy for you to replace one boolean with list of booleans? Maria could not test what she prepares.

[tomas-knap]

Jirko, udelej to prosim tak, aby stavajici SPARQL transformery fungovali i v te verzi s vice textareas.

Ostatne ikdyz bude existovat vice textarea, obecne predpokladej, ze do jedne textarea nekdo muze narvat vice dotazu.

Tohle issue mi staci klidne do konce tydne, hlavne prosim davej pozor, abys commitoval jen kod, ktery je uplny a funguje mi s existujicimi extraktory. Dokud takovy kod nemas, pripravuj si to prosim ve vlastni branch.

[tomas-knap]

Jirko, taky kdyz pustim sparql transformer v defaultni konfiguraci (prazdna query), tak mi to pri behu zahlasi:

Takova chyba se nesmi objevit, musi tam byt smysluplna chyba ve stylu "Neni definovano query"

[tomesj]

Tome, tu chybu, kterou tu uvadíš dostaneš proto, že to Honza dočasně změnil, abychom měli stabilní build, neboť Marie to nechala rozdělané při předání tohoto issues. Já si udělám vlastní branch a až to budu mít, commitnu do mastera.

Jestli to chápu správně tak, při ukládání - provede se validace pro všechny dotazy, které jsou v těch textboxech při execution - 1x provede se merge dat a na něm se provedou postupně všechny dotazy, jsou-li tam někde ty speciální contructy, tak mají přednost, tj. merge, (volitelně) contrustructy a pak nad výsledek všechny dotazy...

Abych zajistil dobrou funkcionalitu, nechal bych poměr 1 dotaz - 1textbox...Jednak nemám obecný způsob jak dotazy mezi sebou parsovat, jinak by to bylo i z hlediska nastavení konfigurace dost nepřehledné.

Souhlas ?

[tomas-knap]

Jirko, tohle jeste promyslim a napisu

[tomas-knap]

Jirko, melo by se to chovat takto:

Jednotlive textareas s dotazy se zpracovavaji postupne v poradi, v jakem jsou ty textarea v konfiguraci. Poradi je nutne dodrzet. Postupne se tedy od prvniho vyhodnocuji dotazy a pro kazdy se:

• pokud je to CONSTRUCT query, tak se dotaz proste provede (dle principu pro CONSTRUCT query), do vystupni data unit se prisypou nova data (tedy pripadna jiz existujici data v output data unit se nesmi prepsat)
• pokud je to SPARQL update query, tak:
  • Pokud je to prvni SPARQL update query, pred kterym nebyl zadny CONSTRUCT query, tak se pred timto dotazem vstupni data zmergujou na vystup (tedy provede se vlastne implicitni CONSTRUCT query co vezme vsechna data). Nasledne se SPARQL update provede dle standardnich principu primo nad vystupni data unit.
  • Pokud je to prvni SPARQL update query, pred kterym se ale jiz provedl nejaky CONSTRUCT query, tak se zadny merge vstupu na vystup neprovadi a proste se jen provede SPARQL update query dle standardnich principu primo nad vystupni data unit (nad vysledkem predchozich dotazu.
  • Pokud to neni prvni SPARQL update query, tak se proste provede dle standardnich principu primo nad vystupni data unit nad pripadnym vysledkem predchozich dotazu

Poznamka: V pripade jedine textarea by se to melo chovat jako ted.

Poznamka: Zadne explicitni merge se tedy na zacatku nedela. Udela se jen tehdy, kdyz se jako prvni objevi SPARQL update query pred kterym nebyl zadny CONSTRUCT query. Jinak se v zasade provadi dle stavajicich principu.

Urcite predpokladej, ze jedna textarea ma jen dotazy jednoho typu. A asi je rozumne predpokladat i co textarea to jeden dotaz.

Precti si to prosim a pis jestli se ti neco nezda

[tomesj]

Jo, z toho, jak jsi to popsal, tak je mi to jasné, tak díky :-) Budu to tedy aplikovat postupně výše uvedených pravidel s tím, že 1 textarea = 1 dotaz. Budu tohle issue řešit až nakonec a udělám si na to vlastní branch.

[tomesj]

Tak SPARQL transformer je hotový a odzkoušený. Podporuje více dotazů, správně validuje. Co 1 text area, to 1 dotaz. Text areu jsem i trochu zmenšil. Větev ve které jsem to dělal přimergovaná do mastera :-)