Feedback 0.3.3-SNAPSHOT
Toto jsou poznámky ke stavu vývoje před přípravou release 0.3.4.
Graphs in error
- jaké oprávnění by mělo být vyžadováno pro manipulaci? Stejné jako u pipelines (tj. manipulovat může autor a administrátor), nebo jinak?
- TK: jj, to zni rozumne. Koneckoncu autor pipeline/admin vi nejlepe co s tim.
lepší by bylo vypisovat grafy i s prefixem (http://.../uuid), aby se dal snadno zkopírovat a použít třeba ve SPARQL dotazu nebo dotazu přes Output WS
- kde se tenhle prefix veme?
- engine.data_graph_uri_prefix v odcs.ini; ale teď mě napadá, že se to rozbije, pokud se jeho hodnota změní; zkonzultuji s PJ
- změněno, prefix data grafu je ODCSInternal#dataGraphUriPrefix
- TK: Melo by to byt konfigurovatelne, mozna bych umoznil nastaveni pri instalaci a pak zmenu i v budoucnu, ale s tim, ze si admin po zmene prefixu v konfiguraku (presunu dat na jinou domenu napr.) musi sam shodit enginu, sparql updatnout prefixy a spustit engine. Je v tom pak nejaky problem (tedy krom pripadu, ze to admin zvora)?
- JM: po dohodě s PJ jsme to změnili, tuhle část konfigurovat nepůjde; je to z toho důvodu, že změna konfigurace na existující instanci ODCS by rozbila tabulky Engine
- PJ: nerozbije to přímo tabulky Engine, ale již jejich obsah velice snadno, např. obsah seznamu attached grafů nelze principiálně hlídat, jakákoli část programu (včetně custom transformerů) může z těchto prefixů odvodit cokoli a uložit do DB ve změněné podobě a změna prefixů pak může způsobit neopravitelné chyby
- TK: Ok, kdyz to pujde nastavit na zacatku v instalatoru, tak se to myslim prezije. A ted tam prosim do releasu davejte prefix http://ld.opendata.cz/... misto toho http://opendata.cz/...
- PJ: Za Engine je to ok, jestli je to takhle mozne, je potreba vsak rozhodnout celym tymem.
Tohle uz se v kodu menilo tam a zpatky nekolikrat a navazuje na to jiz asi dalsi funkcionalita.
(btw: do predchoziho vikendu byl Engine sam o sobe proti zmenam prefixu imunni, ted jsem tam dal kod ktery uz s pevnymi prefixy pocita, stoji mi to obecne docela praci, to menit furt dokola).
Debugging
- debugging může trvat dlouho (u OI určitě) - nebude problém s timeoutem ve frontendu?
- TS: Zatím jsem s tím problém neměl, ale velká data jsem nezkoušel.
- do budoucna se pokusit nahrazovat dlouhá URI prefixed names? (pokud to nebude moc pomalé)
QA
sloupec Description přejmenovat na Rule
- asi by bylo vhodné udělat Description povinnou -> asi z toho udělat Label; otázka je, jestli by label měl být unikátní, nebo ne (low priority)
- když jdu na detail pravidla, chybí tlačítko pro přechod zpět (?pokud něco takového vůbec lze udělat)
Templates
- DR: skupina se v některých případech neoznačuje jako uncommitted (např. při deletu template jiné než replace)
- navrhoval bych schovat vytváření CompiledDNRule přímo do TemplateInstanceDao#save/update a zrušit CompiledDNRuleDao
- -> umožní to uzavřít vytváření do transakce (což by určitě mělo být)
- -> při ukládání komponent by se měla volat existující Dao místo CompiledDNRuleDao - nebude duplikovaný kód
- -> a navíc nebude nutné všude hlídat, že se vola markUncommitted, v existujících dao už to je
Ostatní
- Kluci, vsechna tahle rozhodnuti co tu delate, tak prosim napiste bud do dokumentace technicke k proj (pokud je to dulezite), pripadne aspon do kodu k prislusne tride/rozhrani (vcetne moznych alternativ a proc jste se rozhodli to udelat takhle a ne jinak). A udelejte to radsi vzdy hned jak to doresite, je to par minut..kdyz to neudelate, tak se na to zapomene a bude to treba lovit z wiki
Fixed
Import dat
- import dat přímo (tj. bez ukládání do dočasného souboru)
- zřejmě funguje přes jdbcTemplate, ale ne přes VirtuosoConnectionWrapper (viz chyba, co jsem posílal v mailu)
- selhává na větších datech (řešilo se v Engine, ověřeno v FE)
- blbla mi diakritika, ale to může být nějaká snadno opravitelná blbost
- import přes dočasný soubor
- otestovaný přes VirtuosoConnectionWrapper, funguje spolehlivě i pro velké soubory
- Otázka: Jak to tedy u debugu/onto uděláme? Možnosti jsou:
- použít přímý import (jako je to teď u ontologií) -> (-)muselo by se udělat omezení na velikost souborů
- použít MultipleFormatLoader -> ten je (+) implementovaný, (+) funguje, podporuje i (+) TriG; na druhou stranu je (-) pomalejší než ostatní a taky zřejmě bude (-) omezení na velikost
- použít import přes dočasné soubory -> (+) je robustní, používá se v Engine, (+) zvládne i velké soubory, (-) nutnost vytvářet dočasné soubory
TS: Za mě za c), jen nevím, jestli Kuba Trig nepotřebuje...
JD: Od doby kdy QA nepotrebuje publishera z metadat (coz uz je dlouho) na TriGu nelpim, protoze nepotrebuju mit potrebu vkladat vic grafu. Takze, ja se priklanim k tomu, co bude fungovat lepe a spolehliveji.
RESOLVED JM: ok, schválena možnost C); v repo jsou dvě nové třídy GraphLoader a TemporaryGraphLoader; v OntologyDao už jsem to nahradil (tam jsem testoval GraphLoader), doplňte to prosím do debuggingu - k tomu je TemporaryGraphLoader, aby šlo graf zase smazat.
- doplneno do QA/DN debuggingu, snad to funguje, alespon to tak vypada :)
Graphs in error
bude tlačítko Accept i u jednotlivých grafů?
- je u grafu ktere jsou v cleanDB (musi tak byt oznaceny v EN_INPUT_GRAPHS)
- JM: nj vlastně, to mi nedošlo, v pořádku
chtělo by to možnost zobrazit detail, aby byla vidět celá chybová hláška
JD: bylo by hezká modifikace GraphInErroDao, víc info pošlu v mailu
Debugging
DNDebugResultPage - jsou tam modifikace typu INSERT a DELETE, ale přibyl ještě MODIFY REJECTED
pošlete mi prosím pro všechny typy debugování soubory s testovacími daty, na kterých to funguje
- TS: OI jsem zkoušel na těch 2 trojicích, co jsou v test_data_OI.sql
- RESOLVED z jakých tabulek se berou debugovací pravidla? Předpokládám, že z těch oficiálních. Pokud jsou ale uncommitted změny, debuguje se na jiných pravidel, než která vidí autor. To znamená, že buď by debugging musel být povolený jenom na committed skupině, nebo by se při debugování musela předávat informace o tom, jaká verze tabulek se má použít
- TS: Ano, berou se z těch oficiálních. Transformerům se předá v konstruktoru id skupiny a ty si je pak sami načtou (obdobně, jako v pipeline).
OI
- RESOLVED pokud teď lze debugovat pouze TTL, do budoucna by to mělo umět i RDF/XML; kód pro rozlišení můžu dodat
- TS: Když dodáš rozpoznání, přepínání je otázka nastavení 2 konstant.
- JM: FileUtils#guessLanguage()
- TS: Nebylo by lepší místo TTL dát N3? Je to obecnější formát a Jena i Silk si s ním poradí. A když tu hodnotu pro RDF/XML pojmenuješ "RDF/XML", tak to nebudu muset převádět :)
- TK: urcite kluci aspon to TTL a RDF/XML. Jen pro moje objasneni, teoreticky by mel jit jakykoliv format, ktery JENA podporuje, ne?
- TS: Uz mame N3 (nadmnozina TTL) a RDF/XML
QA
- nezobrazovat název debuggovaného grafu (je vždy stejný)
- Zatim, je mozne mit vstup v TriGu a v takovem pripade nemusi byt na vstupu 1 graf a jmena grafu mohou byt ruzna, pokud TriG nebude, muzeme graphName skryt/zrusit
- přestože se pokaždé zobrazuje stejný název grafu, v db se data ukládají do unikátních grafů, že? - ANO
zaokrouhlovat číslo výsledného skóre a koeficientů
- špatně se mi zobrazuje nadpis tabulky (je moc dlouhý a zalomení se nevejde do buňky)
DN
sloupec Descrtiption - viz QA
modifikace jsou zřejmě seřazené jako napřed INSERTs, pak DELETEs; přehlednější by bylo mít je seřazené jako Subject-Predicate-Object, aby bylo zřejmé, jaká hodnota se nahradila jakou.
- bylo by asi hezci mit razeni podle: subject predicate type object; aby jak je v diffu bezne byly nejdrive smazane hodnoty
- JM: může být
Templates
literály (regexy, replacement) by měly být excapované proti apostrofu (podobně jako v qa trace; implementovat asi uvnit *Compiler třídy)
u URI by se mělo rozlišovat (viz metody v Utils), zda jde o prefixed name a jde použít přímo, nebo ne a potom je ho potřeba obklopit < a >
- zvazoval sem to a nemyslim si, ze to jde spravne! cokoli:neco muze byt jak prefix tak iri pokud se nepletu ne?! jak teda rozeznas, ze to ma byt obklopeno nebo ne?! prefix muze a nemusi byt v dobe vkladani pravidla v tabulkach ulozeny
- No, udělal bych to tak, že pokud Utils#isPrefixedName() vrací true, tak se to nechá, jinak se to obklopí < >
- navíc by se URI asi měla validovat
- DR: Doplnil jsem IRI validator ke vsem polim do kterych se zadava property name. Jestli to melo byt jinak, tak to prosim fixnete nekdo, kdo tomu rozumite. Diky
Ontologie
kam se generují pravidla? pokud do oficiálních tabulek, měla by se vložit i do uncommitted verze
- generuji se uz do obou sad tabulek
Ostatní
- proč musí být QAImpl a DNImpl Serializable?
- nevim co to zpusobuje ale jinak frontend hazel chybu, nevim kde se tam potrebuje DN serializovat, asi protoze se instanciuje v tom button onclick a je potreba ten objekt znovu nacist kdyz prijde request z ajaxu.. nevim, proste se ale nedal rozumne cist log, protoze tam tech erroru skocilo 2-3... je to nejaky problem?