Obrázek 12: Seznam slovníků projektu otevřených v aplikaci TermIt. Většina problémů, které nastaly při změně architektury spočívaly v tom, že standalone verze TermIta pracuje nad živou databází, zatímco nová architektura umožňuje pracovat s kanonickým slovníkem a libovolným počtem jeho draft verzí. Tím pádem může dojít k situaci, že jeden pojem má několik reprezentací – verzí. Tato komplikace může nastat na několika místech, ale vždy se jedná o propojení mezi pojmy. Při každém výskytu tohoto problému bylo potřeba pojem vybírat nejen podle identifikátoru, ale i podle slovníkového kontextu, ve kterém se pojem nachází. To částečně zkomplikovalo implementaci, ale problém je vyřešen. Nové funkce Mezi nové funkce patří všechny funkce, které jsou obsaženy ve sjednoceném backendu a které nebyly omezeny novou architekturou nebo frontendem. Jedná se především o: ● podporu komentářů včetně přehledu komentovaných pojmů a odpovědí na komentáře, ● historii změn, ● validaci úplnosti pojmů, ● stav pojmu (rozpracovaný nebo schválený). V současné verzi chybí podpora uložených dokumentů a textové analýzy. Důvodem je nutnost řešení správy dokumentů v rámci celé výrobní linky, tedy nejen aplikace TermIt. Dokumenty, které se objevují ve výrobní lince by měly mít vlastní správu, ať už se jedná o textové nebo jiné dokumenty přiřazené ke slovníkům nebo například diagramy z aplikace OntoG rapher.
Obrázek 13: Detail pojmu v aplikaci TermIt.
Uživatelské prostředí
Nová verze uživatelského prostředí odpovídá frontendové verzi standalone aplikace TermIt s
několika výjimkami.
● Standalone TermIt pracuje živě nad všemi slovníky v databázi. Nový TermIt pracuje
pouze se slovníky, které jsou mu předány a pouze ty vypisuje v seznamu slováků.
Nicméně statistiky jsou zobrazovány nad celou SSP cache.
● Byla odstraněna karta Dokument. Je to způsobeno absencí vazby mezi slovníkem a
dokumentem v architektuře výrobní linky.
● Bylo odstraněno tlačítko Analyzovat u jednotlivých slovníků. Analýza definic probíhá
automaticky a s absencí vazby mezi slovníky a dokumenty nedává zatím smysl
analyzovat dokumenty.
● Změnila se barevná identita aplikace TermIt ze světle modré na zeleno černou.
Ukázka nového uživatelského prostředí je na obrázcích 12 a 13.
Aplikace OntoGrapher - Nová verze
Od verze OntoGrapheru vydanou pro výstup C5V3 se s dalším vývojem nástroj vylepšil v
několika aspektech - kromě podpory již zmíněné upravené architektury nebo oprav chyb
hlášených uživateli v průběhu používání nástroje se také podařilo obohatit nástroj o další
uživateli
žádané
funkce,
zvýšit
stabilitu,
a
upravit
uživatelské
prostředí.
Obrázek 14: Ukázka nového uživatelského prostředí aplikace OntoGrapher. Nové funkce OntoGrapher s pomocí úpravy architektury SSP nyní při publikaci navíc i ukládá a načítá diagramy a další informace (úplné kardinality, zobrazované jméno). Uživatel tedy může pokračovat v práci na slovníku/slovnících i po publikaci ve stejném stavu, jako předtím. Samotné diagramy se mohou exportovat jako obrázek, tj. buď rastrovou verzi jako soubor PNG nebo vektorovou verzi jako soubor SVG. Snímek má podle verze bílý/průhledný podklad, aby se dal jednoduše zakomponovat do dalších pr ací, například článků, zpráv, či prezentací. Uživatel si může zvolit, zda-li do SVG exportu přidat i další informace o diagramu - jmenovitě IRI pojmů a forma zobrazení diagramu (více viz Uživatelské prostředí). Uživatelské prostředí Vzhled a průběh používá ní nástroje prošly významnou evolucí. Cílem je zpříjemnění zkušenosti uživatelů i navržení rozhraní tak, aby některé elementární chyby uživatele, které by vedly k nevalidnímu modelu, nešly provést. Přidaly se animace a popisky, a zjednodušily se některé interakce, aby bylo jednoznačnější, pro co která část uživatelského prostředí slouží. Pro práci se samotnými diagramy a jejich metadaty vznikla nová “domovská karta”. Je reakcí na zpětnou vazbu uživatelů v důsledku funkce ukládání do a načítání diagramů z SS P, kde velmi rychle vzniklo velké množství diagramů, které nešlo jednoduše spravovat. V této kartě může uživatel ● Otevírat a zavírat diagramy, tj. zobrazovat/schovávat je na liště s diagramy, ● vytvářet a mazat diagramy, ● upravovat metadata diagramů (název, popis, asociované slovníky).
Při prvním otevření draft verzí slovníků si tedy uživatel otevře/vytvoří jen ty diagramy, se
kterými chce pracovat bez toho, aby mu zbylé diagramy plnily lištu.
Práce v samotných diagramech ( tj. na “plátně”) se upravila – interakce s myší jsou lehce
pozměněné; byla zavedena podpora multi-touch touchpadů (např. u MacBooků) a přidala se
funkce multi -selekce – možnost vybrat více pojmů/vztahů a vykonávání některých akcí
najednou.
OntoGrapher poskytuje uživatelům dva způsoby zobrazení diagramu: Úplný pohled, ve kterém
jsou vidět všechny pojmy (včetně vlastností a vztahů) a spojení na základní úrovni, a
Kompaktní pohled, ve kterém se vlastnosti zobrazují pod pojmy a vztahy se místo přesné
reprezentace zobrazují jako jednoduché “čáry”.
V nynější verzi uživatelského prostředí se Kompaktní mód vyzdvihuje jako primární mód
zobrazení modelu. V tomto módu je již možné dělat všechny úpravy, které předtím šly provádět
pouze v Úplném pohledu - tj. plná manipu lace s vlastnostmi, spojení s matčiným pojmem
včetně kardinalit, a mazání vztahů.
Další vývoj
V současné verzi OntoGrapheru se při každé změně ukládá do metadat slovníku informace o
poslední změně - datum a čas změny s jejich autorem, ale ještě ne povaha samotné změny.
V budoucnosti by se tato funkce mohla rozšířit o ukládání i této změny a dále i všech
předchozích změn v době mezi vytvořením draft verze a publikací slovníku. Tato podrobnější
data by se dala využít pro další vylepšení, např. “cestování v čase” mezi změnami
pojmů/vztahů/diagramů apod. pro o vrácení nechtěných změn nebo lepší pochopení, jací
autoři dělali jaké změny.
Očekávají se i další úpravy uživatelského prostředí na základě následných zkušeností
uživatelů. Kromě toho se plánuje i rozšíření “domovské karty”, např. o sekci pro diskuzi práce
na draft verzi slovníku či prohlížení výše zmíněných změn.
Dále je ve vývoji funkce pro export diagramu i do výpisu pojmů v něm - nyní se uvažuje o
formátech TXT a CSV, kde by každý formát měl jiný způsob a jiné množství informací o daných
pojmů. U TXT by šlo o jednoduchý výpis napodobující ten z výstupu C2V11, sekce Odvození
evidence údajů agendy, příklad z bodu 4. S formátem CSV (nebo XLSX) se export kromě
názvu pojmu obohatí o definici, zdroj (tj. reference na původ pojmu) a typ - stejným způsobem
budou popsány i vlastnosti a vztahy.
Současně v OntoGrapheru chybí podpora pro Registr práv a povinností, jednak ve formě výše
zmíněného exportu pojmů, ale především v možnosti používat jinou sadu stereotypů - základní
slovník pro tyto účely nestačí. Pojmosloví pro modelování RPP (vycházející z metodiky
C2V11) a základního slovníku (vycházejícího z UFO) se také někdy překrývá, což je matoucí
pro uživatele. Ideálně by OntoGrapher měl podporovat vyměnitelné top -level ontologie, ve
kterém mají stereotypy i vlastní pravidla, které upřesňují jejich použití a podle kterých se mohl
tvořený model validovat.
- Nástroj pro kontrolu a publikaci
slovníků
Jak bylo řečeno výše, při zaměření se na slovník jako first class citiz en dochází k nutnosti
rozlišovat mezi různými draft verzemi stejného kanonického slovníku. Po změně architektury
je dalším krokem usnadnění publikace slovníků uživatelsky přívětivým způsobem a to včetně
řešení případných konfliktů. Návrhem a tvorbou protot ypu řešení se v rámci své diplomové
práce zabývají Bc. Filip Kopecký a Bc. Michal Švagr.
Popis současného stavu
Současný proces publikace draftů slovníků začíná stisknutím tlačítka “Publikovat” v Kontrolním
panelu. Po stisknutí tlačítka se spustí sada akti vit, které převedou draft slovníku do podoby
struktury kanonického slovníku a nahraje se do GitHub repozitáře SSP ve formě takzvaného
Pull Requestu. Podobná akce se stane také s drafty příloh slovníku. GitHub notifikuje uživatele
zodpovědné za revize změn o novém Pull Requestu, kde mohou vidět změny provedené v
draftu od aktuálního kanonického slovníku v podobě textových rozdílů RDF. Mohou se tedy
pak rozhodnout, zda změny zamítnou a zašlou autorovi připomínky nebo změny schválí a tím
se propíšou do SSP repozitáře nedlouho poté do SSP cache.
Tento proces má v sobě několik úskalí. Jak jste si mohli všimnout zahrnuje využití nástroje
GitHub třetí strany. Tento nástroj využívá jiné přihlášení než Výrobní linka, je tedy zapotřebí,
aby byli uživatelům zodpovědným za revize změn vytvořeny účty a přidělena patřičná práva.
Propojení účtů mezi těmito dvěma autorizačními službami v současné době také neexistuje,
což zhoršuje přehlednost a dohledateln ost komunikace vztažené k provedeným změnám.
Přesto že GitHub podporuj e v Pull Requestech komentování i na úrovni jednotlivých řádků
RDF ne všichni uživatelé Výrobní linky mají zapnuté oznámení z GitHub je tedy aktuální praxí
zasílat dotazy na změny nebo vysvětlením zamítnutí změn pomocí emailu. Tím se komunikace
úplně odpou tává od Výrobní linky a je tedy dohledatelná pouze v emailových klientech
uživatelů. Zasílané emaily jsou navíc psány ručně s tím, že je zapotřebí specifikovat o jaké
části modelu a změně se komunikuje.
To nás dostává k dalšímu problému revize změn, které uživatelé vidí v podobě RDF. Kvůli faktu, že RDF serializace do Trig (aktuálně používané pro reprezentaci kanonických slovníků) není normalizovaná i malá změna může způsobit velké množství přesunů, které jsou pak v textové reprezentaci GitHubem zvýrazňování jako změny. Je tedy zapotřebí aby se uživatelé zodpovědní za revize změn orientovali nejen v modelování slovníků a nástroji GitHub, ale aby také dobře znali syntax RDF, rozpoznali změny od přesunů a pochopili význam dopadu změn na celý slovník i bez vizuální reprezentace propojení jednotlivých pojmů. Návrh nástroje Je tedy navrhován nový nástroj jménem CheckIt, který má za cíl tyto problémy vyřešit. Bude se tedy jednat o nástroj umožňující správu rolí uživatelů zodpovědných za revize slovníků (z pohledu této revize), komunikaci ohledně jednotlivých změn v podobě komentářů v samotné
aplikace a zobrazování změn ve formě diagramů (pro změnu vztahů) a barevného odlišení nových/změněných/smazaných parametrů pojmů. Byl navrhnut nový proces opět začínající stisk nutím tlačítka v Kontrolním panelu, který však notifikuje uživatele Výrobní linky zodpovědné za revizi (Gestory) slovníku/ů určených k publikaci. Ty v nástroji CheckIt zrevidují a následně schválí nebo zamítnou každou změnu (např. nový název a popis pojmu). Když bude mít k jakékoliv změně dotaz napíše k ní komentář a uživatelé Výrobní linky zodpovědní za vytvoření změny budou notifikování. Na komentář mohou odpovědět nebo v případě nutnosti upravit svůj model a aktualizovat verzi k publikaci. Ve chvíli, kdy budou všechny změny schváleny, může je Gestor publikovat. Publikace znamená promítnutí změn do kanonických slovníků v SSP. V případě, že Gestor se změnou nesouhlasí a zamítne ji, může revizi ukončit s udáním důvodu zamítnutí. Tyto důvody jsou následně zaslány autorům změn, kteří se mohou rozhodnout, zda chtějí draft slovníku smazat a začít se změnami od začátku nebo pokračovat v úpravách. Procesní diagram nástroje CheckIt je zobrazen na obrázku 15. Pro popis změn byla vytvořena nová ontologie pro popis změ n dostupná na https://github.com/kbss-cvut/popis-zmen-ontology a její schéma je na obrázku 16. Hlavní entitou je Publikační kontext, ve kterém jsou sdruženy všechny změny. Jednotlivé změny mají přiřazen jeden z následujících typů: vytvořeno, odstraněno, upraveno nebo vráceno. Změny jsou reprezentovány jako RDF trojice (triply). V případě změny (tedy ne vzniku nového triplu) mohou obsahovat volitelný odkaz na nový objekt. Změny odkazují na k ontext (např. slovník) ze kterého jsou. Schvalovací proces provádí uživatel s rolí Gestora pro daný slovník, tedy s přiřazeným slovníkovým kontextem.
Obrázek 15: Procesní diagram zpracování změn v nástroji CheckIt. Znázorňující zaslání projektu k revizi editorem, revizi změn gestory a následné schválení/zamítnutí projektu s příslušnými notifikacemi o akcích. Diagram také znázorňuje možnost diskuze nad jednotlivými změnami
a možnost zaslání upraveného projektu v průběhu revize.
Evropska unie Evropsky socialni fond Operacni program Zaméstnanost
erd Ontology relationship diagram J J —™~
pp:odkazuje-na-kontext
sioc:read_at
pd:ma-datum-a-éas- sioc:content
vytvoreni
pd:ma-datum-a-éas- sioc:about
vytvoyeni
pp:odkazuje-na- prilohovy-kontext
pd:ma-datum-a-éas- vytvoreni
schvaleno zamitnuto pd:ma-datum-a-éas-posledni-
modifikace
sioc:content
v contextu ¢ / /
Ww 1 1 4 rdfs:label 4 Z 7 / 1% 1." MW 4 7
7 4 7 4 / / ma nowy objekt Z o * 7 YY A . ‘ 7 y 7 / We
rdf:subject rdf:predicate rdf:object
ma zménu 2 projektu 0.1 ed 1
odpovidajici Pull Request
je-poéitatelna- do- statistiky
ma-popis-typu- subjektu
pd:ma-datum-a-éas- vytvoreni
pd:ma-datum-a-¢as-posledni- modifikace
Prefixy (Pojmy bez prefixt jsou vytvorené pojmy v ontologii) rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns# rdfs: http://www.w3.org/2000/01/rdf-schema# sioc: http://rdfs.org/sioc/ns#
sioct: http://rdfs.org/sioc/types#