KUPNÍ SMLOUVA
KUPNÍ SMLOUVA
(dále jen „Smlouva“)
Obchodní firma: IQengineering s.r.o.
Se sídlem: Žirovnická 3133/6, Záběhlice, 106 00 Praha 10
Zapsaná: v obchodním rejstříku vedeném Městským soudem v Praze, oddíl C, vložka 180426
Statutární orgán: Xxx. Xxxx Xxxxxxx, jednatel
IČ: 28137264
DIČ: CZ28137264
Bankovní spojení a číslo účtu: Raiffeisen Bank, č.ú. 5597555/5500
(dále jen „Prodávající“)
a
Obchodní firma: REMMARK, a.s.
Se sídlem: Křemencova 178, 110 00 Praha 1
Zapsaná: v obchodním rejstříku vedeném Městským soudem v Praze, oddíl B, vložka 5258
Statutární orgán: Xxx. Xxxxx Xxxxxx, předseda správní rady
IČ: 25652869
DIČ: CZ25652869
(dále jen „Kupující“)
(dále též společně jako „Smluvní strany“)
uzavřely níže uvedeného dne, měsíce a roku tuto kupní smlouvu dle § 2079 a násl. zákona č. 89/2012 Sb., občanského zákoníku (dále jen „občanský zákoník“).
strana 1 z 12
PROHLÁŠENÍ STRAN
Uvedené Smluvní strany prohlašují, že se samy přesvědčily o identitě druhé Smluvní strany, taktéž že její označení uvedené v záhlaví této Smlouvy odpovídá aktuálnímu stavu, že je jim známa nesporná totožnost a řádné oprávnění osob jednajících za druhou Smluvní stranu k tomuto jednání a zároveň si vzájemně prohlásily, že tyto údaje nejsou dotčeny změnami již uskutečněnými, avšak ještě nezapsanými v obchodním rejstříku. Zároveň prohlašují, že uzavření této Smlouvy je v souladu se zákonem předepsanými či interně stanovenými pravidly, jakož i v plném zájmu jimi zastupovaných Smluvních stran.
1. ÚVODNÍ USTANOVENÍ
1.1. Tato Smlouva je uzavírána na základě výběrového řízení veřejné zakázky s názvem „Dodávka pro NEST BIG DATA ARENA, část 2 – Dodávka software“, zadávané Kupujícím jako zadavatelem dle Pravidel pro žadatele a příjemce Operačního programu Praha – pól růstu ČR (verze 4.7), účinnost od 13. 7. 2021 (dále jen „Pravidla OP PPR“). Na základě tohoto výběrového řízení byla pro plnění veřejné zakázky vybrána nabídka Prodávajícího.
1.2. Kupující má dle § 2587 Občanského zákoníku zájem na realizaci předmětu Smlouvy, který souvisí s realizací projektu „NEST BIG DATA ARENA“, registrační číslo CZ.07.1.02/0.0/0.0/17_056/0001340, který je spolufinancován ze zdrojů EU (OP Praha – pól růstu ČR, výzvy OPPPR_39. výzva SC 1.2 - Zvyšování kvality a efektivity fungování podpůrné inovační infrastruktury III).
1.3. Prodávající se zavazuje, že Kupujícímu odevzdá předmět plnění, který je předmětem této Smlouvy, a umožní mu nabýt vlastnické právo k němu, a Kupující se zavazuje, že předmět plnění převezme a zaplatí Prodávajícímu kupní cenu.
1.4. Prodávající prohlašuje, že se seznámil s rozsahem a povahou předmětu Xxxxxxx. Jsou mu známy veškeré technické, kvalitativní a jiné podmínky nezbytné k řádnému užívání předmětu Smlouvy.
1.5. Prodávající se zavazuje, že předmět Xxxxxxx je v souladu s právními předpisy, jakož i v souladu se všemi normami obsahujícími technické specifikace a technická řešení, technické a technologické postupy nebo jiná určující kritéria k zajištění, že materiály, výrobky, postupy a poskytované služby vyhovují požadavkům na předmět plnění a veškerým podmínkám a požadavkům uvedeným v zadávacích podmínkách k veřejné zakázce.
1.6. Prodávající prohlašuje, že předmět Smlouvy není plněním nemožným a pečlivě zvážil všechny možné důsledky uzavření této Smlouvy.
1.7. Účelem této Smlouvy je úprava práv a povinností mezi Smluvními stranami souvisejících s plněním předmětu Smlouvy.
2. PŘEDMĚT SMLOUVY
2.1. Předmětem Smlouvy je dodávka a implementace Datové a analytické platformy (dále jen „DAP“) pro účely projektu. Podrobný popis předmětu koupě je blíže vymezen v příloze č. 1 této Smlouvy. Součástí dodávky je také servis a záruční doba:
a. implementace na hardware zadavatele,
b. záruka 12 měsíců,
c. požadavek na odstranění závady (podrobněji v čl. 12 této Smlouvy): NBD, dostupnost servisu 8/5 v místě instalace (on site).
2.2. Předmětem této Smlouvy je taktéž doprava na místo plnění a veškeré další činnosti podmiňující uvedení předmětu plnění do provozu a jeho řádnou funkčnost.
strana 2 z 12
2.3. Předmět plnění musí nejpozději ke dni akceptace kompletního řešení splňovat veškeré požadavky právních předpisů platných na území České republiky a veškeré požadavky Kupujícího uvedené v zadávacích podmínkách k veřejné zakázce.
3. DOBA A MÍSTO DODÁNÍ
3.1. Prodávající se zavazuje provést dodávku dle článku 2 Smlouvy nejpozději do 16 týdnů od nabytí účinnosti smlouvy.
3.2. Místem plnění je pobočka Kupujícího na adrese Xxxxxxxxxx 000, 000 00 Xxxxx 0.
3.3. Pokud to povaha předmětu plnění umožňuje, je Prodávající oprávněn poskytovat plnění také vzdáleným přístupem, není-li nezbytné nebo vhodné výkon takového plnění zajistit on-site (tj. u Kupujícího).
3.4. Povinnost Prodávajícího odevzdat předmět Xxxxxxx je splněna jeho včasným a řádným předáním Kupujícímu.
3.5. Nebezpečí za škodu na předmět plnění a vlastnické právo k předmětu plnění přechází na Kupujícího okamžikem převzetí předmětu plnění Kupujícím.
3.6. Převzetím se pro účely této Smlouvy rozumí okamžik podpisu akceptačního protokolu oprávněnými zástupci obou Smluvních stran. Za Kupujícího podepisuje protokol pověřený zaměstnanec uvedený v článku 11 této smlouvy. Pokud bude předmět plnění předáván po částech, podepíší Smluvní strany protokol na každou předávanou část. V takovém případě se úplným splněním dodávky rozumí podpis protokolu na poslední část dodávky předmětu plnění.
3.7. Kupující je oprávněn nepřevzít předmět plnění, pokud neodpovídá požadavkům uvedeným
v zadávacích podmínkách veřejné zakázky, nebo pokud je poškozený nebo rozbitý.
3.8. Zdržení dodávky předmětu plnění zapříčiněné vyšší mocí, mezi což se počítá např. porucha strojů, nezaviněný výpadek dodávek energie a surovin nebo zdržení na straně výrobců a dodavatelů Prodávajícího, a vlivy, které Prodávající nemohl ovlivnit bez neúměrného finančního zatížení, nejsou pro Kupujícího důvodem k odstoupení od této smlouvy.
4. KUPNÍ CENA
4.1. Kupující se za předmět plnění uvedený v článku 2 této Smlouvy zavazuje Prodávajícímu zaplatit celkovou kupní cenu ve výši:
10 087 500,– Kč bez DPH (slovy deset milionů osmdesát sedm tisíc pět set korun českých)
2 118 375,– Kč DPH v zákonné výši (slovy dva miliony sto osmnáct tisíc tři sta sedmdesát pět korun českých)
12 205 875,– Kč včetně DPH (slovy dvanáct milionů dvě stě pět tisíc osm set sedmdesát pět korun českých)
4.2. Jednotkové položkové ceny jsou uvedeny v příloze č. 1 této Smlouvy.
4.3. Cena plnění je cenou nepřekročitelnou a nejvýše přípustnou.
4.4. Prodávající nese odpovědnost za to, že sazba daně z přidané hodnoty je stanovena v souladu s platnými právními předpisy.
4.5. Součástí ceny předmětu koupě jsou veškerá plnění a náklady Prodávajícího související s předmětem plnění. Dále jsou součástí ceny i služby a dodávky, které nejsou výslovně uvedeny, ale Prodávající, jakožto odborník o nich ví nebo vědět musel, neboť jsou nezbytné a s předmětem koupě bezpodmínečně souvisí.
strana 3 z 12
5. PLATEBNÍ PODMÍNKY
5.1. Právo fakturovat vzniká Prodávajícímu pouze po akceptaci řádně dodaného předmětu Smlouvy (příp. dílčího předmětu plnění) na základě příslušného akceptačního protokolu dle článku 3.6. a článku 6.9.
5.2. Vyúčtování odměny za dodání předmětu Xxxxxxx provede Prodávající na základě daňového dokladu – faktury splňující veškeré podstatné náležitosti dle zvláštních právních předpisů, zejména náležitosti uvedené v § 28 odst. 2 zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů, zákona č. 563/1991 Sb., o účetnictví, ve znění pozdějších předpisů a náležitosti obchodní listiny ve smyslu ustanovení § 435 Občanského zákoníku. Faktura musí dále obsahovat název a datum podpisu Smlouvy, číslo účtu Prodávajícího a specifikaci plnění tak, aby byla v souladu s platnými účetními a daňovými předpisy, a to za účelem řádného vedení evidence majetku Kupujícího v souladu s těmito právními předpisy.
5.3. Společně s fakturou Prodávající poskytne kopii akceptačního protokolu podepsaného pověřenými zástupci obou Smluvních stran.
5.4. Faktura je splatná do 30 kalendářních dnů ode dne jejího doručení Kupujícímu.
5.5. Kupující je oprávněn do data splatnosti vrátit fakturu, která neobsahuje požadované náležitosti nebo není doložena kopií potvrzeného příslušného akceptačního protokolu, a která obsahuje jiné cenové údaje nebo jiný druh plnění než dohodnuté ve Xxxxxxx s tím, že doba splatnosti nové (opravené) faktury začíná znovu běžet ode dne jejího doručení Kupujícímu.
5.6. Faktura je považována za proplacenou okamžikem odepsání příslušné částky z účtu Kupujícího ve prospěch účtu Prodávajícího.
5.7. Kupující neposkytuje zálohové platby.
6. PRÁVA A POVINNOSTI STRAN
6.1. Smluvní strany se zavazují vzájemně spolupracovat a poskytovat si veškeré informace potřebné pro řádné plnění svých závazků. Smluvní strany jsou povinny informovat druhou Smluvní stranu o veškerých skutečnostech, které jsou nebo mohou být důležité pro řádné plnění této Smlouvy.
6.2. Smluvní strany jsou povinny plnit své závazky vyplývající z této Smlouvy takovým způsobem, aby nedocházelo k prodlení s plněním jednotlivých termínů a k prodlení splatnosti jednotlivých peněžních závazků.
6.3. Veškerá komunikace mezi Smluvními stranami bude probíhat prostřednictvím oprávněných osob, nebo jimi pověřených osob, nebo statutárního orgánu Smluvních stran.
6.4. Všechna oznámení mezi Smluvními stranami, která se vztahují k této Smlouvě, nebo která mají být učiněna na základě této Smlouvy, musí být učiněna v písemné podobě a druhé straně doručena buď osobně, nebo doporučeným dopisem či jinou formou prostřednictvím doručovatelských a kurýrních společností na adresu sídla Smluvních stran, není-li stanoveno, nebo mezi Smluvními stranami dohodnuto jinak.
6.5. Ukládá-li Smlouva doručit některý dokument v písemné podobě, může být doručen buď v papírové formě, nebo v elektronické (digitální) formě jako dokument textového procesoru MS Word verze 2007 a vyšší nebo ve formátu *.pdf na dohodnutém médiu.
6.6. Smluvní strany se zavazují, že v případě změny svého sídla, pracoviště a svých zástupců budou o této změně druhou Smluvní stranu informovat nejpozději do 15 kalendářních dnů.
6.7. Prodávající se zavazuje, že odevzdá předmět plnění, jakož i dokumenty, které se k nim vztahují, řádně a včas Prodávajícímu v ujednaném množství, jakosti a provedení.
6.8. Prodávající bude postupovat při plnění předmětu Xxxxxxx s odbornou péčí, podle nejlepších znalostí a schopností, sledovat a chránit oprávněné zájmy Kupujícího a postupovat v souladu s
strana 4 z 12
jeho pokyny a interními předpisy souvisejícími s předmětem plnění Smlouvy, které Kupující Prodávajícímu poskytne nebo s pokyny jím pověřených osob.
6.9. Prodávající je povinen provést kompletní instalaci a konfiguraci předmětu Smlouvy v místě plnění. Prodávající je povinen provést zaškolení obsluhy dodávaného plnění a především ověřit před pověřeným zástupcem Kupujícího plnou funkčnost dodávaného plnění. Po provedení těchto činností a úspěšném ověření plné funkčnosti sepíší Kupující s Prodávajícím akceptační protokol, který bude podepsán pověřenými osobami obou Smluvních stran.
6.10. Kupující poskytne Prodávajícímu veškerou nezbytnou součinnost k naplnění účelu Smlouvy.
6.11. Kupující uděluje Prodávajícímu souhlas s použitím základních informací o této Smlouvě (název společnosti, předmět a místo realizace plnění a cena) pro účely doložení referencí Prodávajícího.
6.12. Prodávající bude specifikovat rozsah částí předmětu koupě, které budou prováděny poddodavatelem. Prodávající musí v souladu se zákonem poddodavatele identifikovat. Dále se Prodávající zavazuje, že plnění dodané prostřednictvím poddodavatele bude v souladu se všemi podmínkami této Smlouvy. Tímto není dotčena výlučná odpovědnost Prodávajícího za poskytování řádného plnění dle této Smlouvy.
6.13. Prodávající se v souladu s § 2 písm. e) zákona č. 320/2001 Sb., o finanční kontrole ve veřejné správě a o změně některých zákonů ve znění pozdějších právních předpisů stane osobou povinnou spolupůsobit při výkonu finanční kontroly a plnit veškeré povinnosti, které mu jsou tímto zákonem uloženy. Tímto nejsou dotčeny ostatní povinnosti Prodávajícího vyplývající ze Smlouvy.
6.14. Prodávající je povinen řádně uchovávat veškerou dokumentaci související s realizací předmětu Smlouvy, včetně účetních dokladů v souladu s čl. 140 Nařízení Evropského parlamentu a Rady (EU) č. 1303/2013 po dobu stanovenou v Rozhodnutí o poskytnutí dotace, tj. minimálně po dobu deseti let následujících po roce, v němž byla vyplacena poslední část dotace, zároveň však nejméně do doby uplynutí 3 let od uzávěrky OP PPR. Prodávající je dále povinen označovat veškeré účetní doklady týkající se plnění dle Smlouvy informací, že se jedná o projekt s názvem
„NEST BIG DATA ARENA“, a číslem projektu CZ.07.1.02/0.0/0.0/17_056/0001340.
6.15. Prodávající je povinen dodržovat pravidla publicity Operačního programu Praha – pól růstu ČR.
6.16. Kupující se zavazuje, že bude na žádost Prodávajícího spolupracovat či poskytne součinnost případným dalším dodavatelům Prodávajícího.
6.17. Kupující má povinnost převzít předmět koupě v termínu uvedeném v článku 3 této Smlouvy.
6.18. Kupující je povinen zaplatit Prodávajícímu cenu za předmět plnění v souladu s ustanovením článku
4 této Smlouvy.
7. ZÁRUČNÍ DOBA
7.2. Prodávající je povinen odstranit vady předmětu plnění v záruční době na základě doručené reklamace do 30 dnů. Reklamace může být uplatněna telefonicky nebo elektronickou formou prostřednictvím e-mailové zprávy. V případě, že charakter, závažnost a rozsah vady neumožní stanovenou lhůtu k odstranění vady ze strany Prodávajícího splnit, může být dohodnuta přiměřená delší lhůta. Ukáže-li se, že vada je neodstranitelná, zavazuje se Prodávající dodat Kupujícímu bez zbytečného odkladu bezplatně náhradní předmět plnění a převést vlastnické právo k němu na Kupujícího.
7.3. Cestovní náklady, náklady na materiál a jiné náklady, které Prodávajícímu vzniknou v souvislosti
s odstraněním vad předmětu plnění dle předchozího odstavce, nese v plné výši Prodávající.
7.4. Není-li mezi Smluvními stranami sjednáno jinak, je Prodávající povinen jakékoliv vady na předmětu plnění, které vzniknou v době trvání záruky, odstranit na své náklady bez zbytečného odkladu, nejpozději do:
strana 5 z 12
Kategorie vady | Definice vady | Lhůta pro odstranění vady |
A | Vážné vady s nejvyšší prioritou, které mají kritický dopad na funkčnost či užití předmětu plnění dle této Smlouvy nebo jeho části a dále vady, které znemožňují užívání předmětu plnění dle této Smlouvy nebo jeho části Kupujícím nebo způsobují vážné provozní problémy. | 2 pracovní dny |
B | Vada, která svým charakterem nespadá do kategorie A. Vážné vady způsobující zhoršení výkonnosti a funkčnosti či užití předmětu plnění dle této Smlouvy nebo jeho části. Předmět plnění dle této Smlouvy nebo jeho část má omezení nebo je částečně nefunkční. Jedná se o odstranitelné vady, které způsobují problémy při užívání či provozování plnění předmětu dle této Smlouvy nebo jeho části Kupujícím, ale umožňují provoz či částečné využití. | 5 pracovních dnů |
C | Vada, která svým charakterem nespadá do kategorie A nebo kategorie B. Vady snadno odstranitelné s minimálním dopadem na funkcionality, funkčnost či užití předmětu plnění dle této Smlouvy nebo jeho části. | 15 pracovních dnů |
7.5. Hlášení závad a reklamací přijímá Prodávající prostřednictvím kontaktních osob a údajů schválených při předání předmětu Smlouvy.
7.6. Při neoprávněné reklamaci nebo vadě způsobené neodborným zásahem je Prodávající oprávněn účtovat Kupujícímu servisní zásah dle platného ceníku Prodávajícího.
8. SANKČNÍ UJEDNÁNÍ
8.2. Nedodrží-li Kupující lhůtu splatnosti kupní ceny uvedenou v článku 5, je povinen uhradit
Prodávajícímu smluvní pokutu ve výši 0,05 % fakturované částky za každý den prodlení.
8.3. Nedodrží-li Prodávající lhůty pro odstranění vad dle článku 7 této Smlouvy, je povinen uhradit Kupujícímu následující smluvní pokuty:
Kategorie vady | Výše smluvní pokuty |
A | 25.000,– Kč za každý i započatý den prodlení a jednotlivou vadu |
B | 10.000,– Kč za každý i započatý den prodlení a jednotlivou vadu |
C | 2.000,– Kč za každý i započatý den prodlení a jednotlivou vadu |
8.4. Nedodrží-li Prodávající podmínky poskytovaného servisu a souvisejících služeb dle článku 12 této Smlouvy, je povinen uhradit Kupujícímu následující smluvní pokuty:
Způsob porušení podmínek poskytovaného servisu | Výše smluvní pokuty |
Nedodržení dostupnosti servisu 8×5 | 10.000,– Kč za každý započatý kalendářní den prodlení |
Nedodržení reakční doby 1 hod na potvrzení od ohlášení poruchy Kupujícím | 10.000,– Kč za každou započatou hodinu prodlení |
strana 6 z 12
Nedodržení lhůty pro provedení servisních prací | 10.000,– Kč za každou započatou jednotku prodlení: • Lhůty stanovené v hodinách – jednotkou prodlení je 1 hodina • Lhůty stanovené v pracovních dnech („dále jen NBD“) = jednotkou prodlení je 1 pracovní den • Lhůty stanovení v kalendářních dnech – jednotkou prodlení je 1 kalendářní den |
8.5. Smluvní strany sjednávají, že výši smluvních pokut uvedených v této smlouvě považují za přiměřenou.
8.6. Výše uvedené smluvní pokuty je možné v případě závažného porušení povinností Prodávajícího
sčítat.
8.7. Splatnost smluvních pokut činí 30 kalendářních dnů od doručení nároku na její uhrazení druhé Smluvní straně.
9. NÁHRADA ÚJMY
9.1. Zaplacením smluvní pokuty není dotčeno právo Smluvních stran na úhradu způsobené újmy vzniklé v souvislosti s plněním předmětu Smlouvy v plné výši.
9.2. Prodávající odpovídá za způsobenou újmu porušením povinnosti dle této Smlouvy, opomenutím nebo zásadně nekvalitním dodáním předmětu koupě v plné výši.
9.3. Náhrada újmy se řídí platnými ustanoveními vztahujícími se k náhradě majetkové a nemajetkové újmy stanovené zákonem č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů.
9.4. Jakákoliv ustanovení týkající se omezení výše či druhu škody se nepřipouští.
10. ODSTOUPENÍ OD SMLOUVY
10.1. Závazky Smluvních stran vyplývající z této Smlouvy zanikají splněním, vzájemnou dohodou Smluvních stran nebo ze zákona.
10.2. Smlouva zaniká odstoupením jedné ze Smluvních stran. Právo na odstoupení může vzniknout na základě ustanovení Kupní smlouvy nebo ze zákona.
10.3. Odstoupení od Xxxxxxx musí být provedeno písemně a prokazatelně doručeno druhé Smluvní straně. Doručením písemného oznámení o odstoupení se Kupní smlouva ruší.
10.4. Smluvní strany považují za podstatné porušení Smlouvy nedodání předmětu plnění ani do 30 dnů po uplynutí dodací lhůty; nedodržení záručních podmínek o více než 14 dnů.
10.5. Prodávající má právo od této Smlouvy odstoupit, jestliže se Kupující dostane do prodlení s převzetím předmětu plnění o více než 30 dnů ode dne sjednaného terminu převzetí předmětu plnění a/nebo pokud okolnosti vzniklé na straně výrobce, importéra nebo poddodavatele předmětu plnění brání řádnému a včasnému splněni této Smlouvy. Právo Smluvních stran odstoupit od této Smlouvy z důvodů stanovených obecnou právní úpravou zůstává nedotčeno.
11. OSTATNÍ UJEDNÁNÍ A KONTAKTNÍ ÚDAJE
11.1. Právní vztahy touto Smlouvou výslovně neupravené se budou řídit českými, obecně závaznými právními předpisy, zejména zákonem č. 89/2012 Sb., občanský zákoník, v platném znění.
strana 7 z 12
11.2. Smluvní strany se zavazují vyvinout maximální úsilí k odstranění vzájemných sporů, vzniklých na základě této Smlouvy nebo v souvislosti s touto Smlouvou, a k jejich vyřešení zejména prostřednictvím jednání kontaktních osob nebo pověřených zástupců.
11.3. Smluvní strany mají zájem především na smírném řešení sporu. Nebude-li možné vyřešit spor smírnou cestou, je dána příslušnost věcně a místně příslušného soudu v České republice dle zákona č. 99/1963 Sb., občanský soudní řád, v platném znění.
11.4. Prodávající odpovídá za dodržování předpisů BOZP vyplývajících z povahy jeho prací.
11.5. Dojde-li ke změně statutu Prodávajícího, je Smluvní strana povinna písemně oznámit tuto skutečnost Kupujícímu ve lhůtě 15 kalendářní dnů od zápisu této změny v obchodním rejstříku. Kupující je v tomto případě oprávněn písemně vypovědět Smlouvu z důvodu změny statutu druhé Smluvní strany. Výpovědní lhůta činí 15 kalendářních dnů a počíná běžet následujícím dnem po doručení výpovědi druhé Smluvní straně.
11.6. Kontaktními osobami Smluvních stran jsou:
za Prodávajícího:
jméno a příjmení: Xxx. Xxxx Xxxxxxx telefon: x000 000 000 000
za Kupujícího:
jméno a příjmení: Xxxxx Xxxxxx
telefon: x000 000 000 000
e-mail: xxxxx.xxxxxx@xxxxxxxxxx.xx
11.7. Odpovědnými osobami k podpisu akceptačního protokolu jsou:
za Prodávajícího:
jméno a příjmení: Xxx. Xxxx Xxxxxxx telefon: x000 000 000 000
za Kupujícího:
jméno a příjmení: Xxxxx Xxxxxx
telefon: x000 000 000 000
e-mail: xxxxx.xxxxxx@xxxxxxxxxx.xx
11.8. Odpovědné osoby jsou oprávněny v souladu s článkem 3.6. a článkem 6.9. této Smlouvy předávat a přebírat předmět Xxxxxxx a podepisovat za tím účelem akceptační protokol. Odpovědné osoby nejsou oprávněny měnit či rušit smluvní vztahy vyplývající z této Smlouvy.
11.9. V případě změny odpovědných osob je Smluvní strana povinna tuto skutečnost neprodleně písemně ohlásit druhé Smluvní straně na adresu uvedenou v záhlaví této Smlouvy.
11.10. Kupující je oprávněn uveřejnit na svém profilu celý text Smlouvy (§ 219 zákona č. 134/2016 Sb., o zadávání veřejných zakázek), za předpokladu, že uveřejnění nebrání zvláštní právní předpis.
12. SERVISNÍ ČINNOSTI (SLA)
12.1. Účelem této části Smlouvy je stanovení rozsahu podmínek provádění servisní činnosti Prodávajícím, a to na celém předmětu plnění dle článku 2 této Smlouvy a v místě provedení instalace dle článku a (tzv. servis on-site) nebo pomocí zabezpečeného vzdáleného přístupu.
12.2. Poruchou se rozumí jakákoliv technická závada na plnění dodaném Prodávajícím dle článku 2.
12.3. Provedením servisních činností se rozumí např. odpovídající softwarový zásah (např. aktualizace operačního a aplikačního software nebo jakýkoliv jiný odborný způsob provedení a to tak, aby bylo zajištěno znovu obnovení plné funkčnosti a dostupnosti daného zboží. Součástí zajištění servisních
strana 8 z 12
12.4. Servisní činnost popsanou v tomto článku provádí Prodávající vždy na základě hlášení poruchy Kupujícím. Pro tyto potřeby musí být Prodávající dostupný v režimu 8/5. Kupující je oprávněn provádět hlášení telefonicky, emailem či v informačním systému Prodávajícího (konkrétní telefonický a emailový kontakt, či vstupní údaje do informačního systému Prodávajícího, budou sděleny písemně Prodávajícím spolu s předáním plnění článku a). Prodávající potvrdí požadavek na provedení servisní činnosti Kupujícímu nejpozději do jedné hodiny (60 minut) od provedeného hlášení, a to zasláním vyplněného formuláře „Hlášení poruchy“ na email Kupujícího.
12.5. Níže uvedené lhůty pro provedení servisní činnosti začínají běžet od okamžiku potvrzení přijetí požadavku na provedení servisní činnosti Prodávajícím.
12.6. Prodávající určuje a plně zodpovídá za stanovení způsobu odstranění poruchy, za stanovení posloupnosti jednotlivých činností a za stanovení doby, kdy tyto činnosti budou prováděny. K tomu je Kupující povinen poskytnout potřebnou součinnost. V případě, kdy Kupující nezabezpečí Prodávajícímu požadovanou součinnost, dochází k odpovídajícímu prodloužení doby pro odstranění poruchy.
12.8. Servisní činnost poskytuje Prodávající v tomto rozsahu:
Předmět plnění | Rozsah poskytovaných servisních služeb |
Datové a analytické platformy | Prodávající je povinen v rámci této garance provádět i všechny obvyklé činnosti související s údržbou či správou daného předmětu plnění. |
Prodávající je povinen zajistit dostupnost servisu tohoto předmětu plnění v režimu 8/5 | |
Prodávající je povinen zajistit servisní činnost do 4 hodin, a to po dobu záruky uvedené v článku 7 (tzv. fix time) |
12.9. Po provedení servisní činnosti bude pověřenými zástupci Kupujícího a Prodávajícího sepsán
„Protokol o provedení servisní činnosti“.
13. DODRŽOVÁNÍ DŮSTOJNÝCH PRACOVNÍCH PODMÍNEK
13.1. Prodávající prohlašuje, že si je vědom skutečnosti, že Kupující má zájem na realizaci veřejné zakázky v souladu se zásadami společensky odpovědného zadávání veřejných zakázek.
13.2. Prodávající se zavazuje po celou dobu trvání Smlouvy zajistit dodržování veškerých právních předpisů, zejména pak pracovněprávních (odměňování, pracovní doba, doba odpočinku mezi směnami, placené přesčasy), dále předpisů týkajících se oblasti zaměstnanosti a bezpečnosti a ochrany zdraví při práci, tj. zejména zákona č. 435/2004 Sb., o zaměstnanosti, ve znění pozdějších předpisů, a Zákoníku práce, a to vůči všem osobám, které se na plnění zakázky podílejí a bez ohledu na to, zda bude dle této smlouvy plněno Prodávajícím či jeho poddodavatelem.
strana 9 z 12
13.3. Prodávající se dále zavazuje po celou dobu trvání smlouvy zajistit u sebe a svých poddodavatelů dodržování zákona č. 198/2009 Sb., o rovném zacházení a o právních prostředcích ochrany před diskriminací a o změně některých zákonů (antidiskriminační zákon), ve znění pozdějších předpisů.
13.4. Prodávající je povinen před zahájením plnění a po jeho ukončení předložit čestné prohlášení, v němž uvede, že všechny osoby podílející se na předmětu Smlouvy jsou či byly vedeny v příslušných registrech, zejména živnostenském rejstříku, registru pojištěnců ČSSZ a mají příslušná povolení k pobytu v ČR a k výkonu pracovní činnosti. Dále zde bude uvedeno, že byly proškoleny z problematiky BOZP a že jsou vybaveny osobními ochrannými pracovními prostředky dle účinné legislativy (je-li relevantní). Prodávající bere na vědomí, že tato prohlášení je Kupující oprávněn poskytnout příslušným orgánům veřejné moci ČR. Tato povinnost platí bez ohledu na to, zda bude plnění dle této Smlouvy prováděno Prodávajícím či jeho poddodavatelem.
13.5. Kupující je oprávněn průběžně kontrolovat dodržování povinností Prodávajícího dle odst. 1 a odst. 2 tohoto článku, a to i přímo u pracovníků vykonávajících předmět plnění, přičemž Prodávající je povinen tuto kontrolu umožnit, strpět a poskytnout Kupujícímu veškerou nezbytnou součinnost k jejímu provedení.
14. DODRŽOVÁNÍ DŮSTOJNÝCH PRACOVNÍCH PODMÍNEK
14.1. Prodávající prohlašuje, že si je vědom skutečnosti, že Kupující má zájem na realizaci veřejné zakázky v souladu se zásadami společensky odpovědného zadávání veřejných zakázek.
14.2. Prodávající se zavazuje po celou dobu trvání Smlouvy zajistit dodržování veškerých právních předpisů, zejména pak pracovněprávních (odměňování, pracovní doba, doba odpočinku mezi směnami, placené přesčasy), dále předpisů týkajících se oblasti zaměstnanosti a bezpečnosti a ochrany zdraví při práci, tj. zejména zákona č. 435/2004 Sb., o zaměstnanosti, ve znění pozdějších předpisů, a Zákoníku práce, a to vůči všem osobám, které se na plnění zakázky podílejí a bez ohledu na to, zda bude dle této smlouvy plněno Prodávajícím či jeho poddodavatelem.
14.3. Prodávající se dále zavazuje po celou dobu trvání smlouvy zajistit u sebe a svých poddodavatelů dodržování zákona č. 198/2009 Sb., o rovném zacházení a o právních prostředcích ochrany před diskriminací a o změně některých zákonů (antidiskriminační zákon).
14.4. Prodávající je povinen před zahájením plnění a po jeho ukončení předložit čestné prohlášení, v němž uvede, že všechny osoby podílející se na předmětu smlouvy jsou či byly vedeny v příslušných registrech, zejména živnostenském rejstříku, registru pojištěnců ČSSZ a mají příslušná povolení k pobytu v ČR a k výkonu pracovní činnosti. Dále zde bude uvedeno, že byly proškoleny z problematiky BOZP a že jsou vybaveny osobními ochrannými pracovními prostředky dle účinné legislativy (je-li relevantní). Prodávající bere na vědomí, že tato prohlášení je Kupující oprávněn poskytnout příslušným orgánům veřejné moci ČR. Tato povinnost platí bez ohledu na to, zda bude plnění dle této Smlouvy prováděno Prodávajícím či jeho poddodavatelem.
14.5. Kupující je oprávněn průběžně kontrolovat dodržování povinností Prodávajícího dle odst. 1 a odst. 2 tohoto článku, a to i přímo u pracovníků vykonávajících předmět plnění, přičemž Prodávající je povinen tuto kontrolu umožnit, strpět a poskytnout Kupujícímu veškerou nezbytnou součinnost k jejímu provedení.
15. ZÁVĚREČNÁ USTANOVENÍ
15.1. Všechna oznámení mezi Smluvními stranami, která se vztahují k této Smlouvě nebo která mají být učiněna na základě této Smlouvy, musí být učiněna v písemné formě a opačné straně doručena buď osobně, nebo doporučeným dopisem, či jinou formou registrovaného poštovního styku, na adresu uvedenou na titulní stránce této Smlouvy, nebude-li stanoveno nebo mezi Smluvními
strana 10 z 12
stranami dohodnuto jinak. Oznámení se považují za doručená uplynutím desátého (10.) dne po
jejich prokazatelném odeslání.
15.2. Změny a doplňky této Smlouvy musí mít písemnou formu, přičemž každá ze Stran se zavazuje
spravedlivě zvážit návrhy Strany druhé.
15.3. Smlouva je vyhotovena v elektronické podobě, přičemž obě Smluvní strany obdrží její elektronický originál opatřený elektronickými podpisy.
15.4. Tato Xxxxxxx nabývá platnosti a účinnosti dnem jejího podpisu oprávněnými zástupci obou smluvních stran.
15.5. Nedílnou součástí této Smlouvy je příloha č. 1 - položková technická a cenová specifikace
předmětu plnění.
15.6. Stane-li se některé ustanovení této Smlouvy neplatné, nebo neúčinné, nedotýká se to ostatních ustanovení této Smlouvy, která zůstávají v platnosti a účinnosti. Smluvní strany se v tomto případě zavazují dohodou nahradit ustanovení neplatné (neúčinné) novým ustanovením platným (účinným), které nejlépe odpovídá původně zamýšlenému ekonomickému účelu ustanovení neplatného (neúčinného). Do té doby platí odpovídající úprava obecně závazných právních předpisů České republiky.
15.7. Smluvní strany, vědomy svých závazků vyplývajících z této Smlouvy a v úmyslu být touto Smlouvou plně vázány, potvrzují tímto její pravost podpisy osob řádně oprávněných jednat za příslušnou Stranu a současně prohlašují, že tato Smlouva byla sepsána po vzájemné shodě o jejích náležitostech. Dále potvrzují, že si tuto Smlouvu přečetly, rozumí jejímu obsahu, souhlasí s ní a nemají proti ní výhrad. Svými podpisy potvrzují, že Xxxxxxx je jejich projevem pravé, svobodné a vážné vůle a že ji neuzavřely v omylu ani pod pohrůžkou násilí. Na důkaz pravosti Smluvní strany opatřují tuto Smlouvu podpisy oprávněných osob, které garantují, že jsou plně oprávněny tuto Smlouvu za Smluvní strany platně uzavřít.
Přílohy:
• Příloha č. 1 – Položková technická a cenová specifikace
V Praze dne V Praze dne
Digitálně podepsal Xxx. Xxxxx Xxxxxx Datum: 2022.07.15
14:27:33 +02'00'
Xxx. Xxxx Xxxxxxx
Digitálně podepsal Xxx. Xxxx Xxxxxxx DN: c=CZ, ou=P650965, cn=Xxx. Xxxx Xxxxxxx, sn=Xxxxxxx, givenName=Xxxx, serialNumber=P650965
Datum: 2022.06.21 15:25:31 +02'00'
Kupující Prodávající
Xxx. Xxxxx Xxxxxx Xxx. Xxxx Xxxxxxx
předseda správní rady jednatel
REMMARK, a.s. IQengineering s.r.o.
strana 11 z 12
Příloha č. 1 - POLOŽKOVÁ TECHNICKÁ A CENOVÁ SPECIFIKACE
strana 12 z 12
Příloha č. 9b – Nabízený předmět plnění vč. technické specifikace (část 2)
Nabízené řešení
Pro níže uvedené moduly nabízíme řešení odpovídající zadání a stručně popisujeme naše návrhy (číslování odpovídá číslům kapitol v zadání – Příloha č. 2 – Minimální technická specifikace software)
3.1. Konfigurace cloudové platformy a vytvoření resourců IaaS, PaaS
Jako cloudovou platformu použijeme nativní cloud od Microsoft Azure. Zdroje IaaS, PaaS a SaaS bude konfigurovat a navrhovat certifikovaný cloud architekt s ohledem na účelnost a ekonomickou efektivitu. Blíže specikované architektonické prvky jsou námi uvedené v kritérium B1.
3.2. Ontologické konceptuální modely
Vytvoříme ontologické konceptuální modely v notaci Unified Foundational Ontology a notaci OntoUML, kterou vhodně rozšíříme o mapování na datové sady. Pro vytvoření modelů použijeme nástroj OpenPonk (xxxxx://xxxxxxxx.xxx), který je k dispozici pod otevřenou (open-source licencí). Nástroj disponuje pokročilými funkcemi pro modelování a zajištění kvality modelů (syntaktickou verifikaci a sémantickou validaci). Do nástroje doprogramujeme exportní funkce, které umožní získat strojově čitelnou reprezentaci ve formátu JSON, která bude použita pro sémantické propojování datových sad.
Pro zajištění efektivního modelování předpokládaného většího množství datových sad vyvineme rozšíření nástroje OpenPonk umožující modularizaci modelů a budování knihovny modelů a znovupoužívání částí modelů v modelech jiných. Dále doprogramujeme implementaci podpory vlastních stereotypů entit, aby bylo možno metamodel dále rozšiřovat dle potřeb.
Dále nástroj OpenPonk rozšíříme o funkce volání REST API pro integraci s modulem Sémantického grafu domény, kdy bude kromě souborové výměny dat možné i přímé nahrání a též zpětné získání podnětů od umělé inteligence k vylepšení modelů a evidenci těchto podnětů. Očekáváme též implementaci drobných vylepšení modelovacího nástroje dle identifikovaných potřeb v průběhu řešení.
3.3. Automatizace integrace datových sad
Ukázka námi navrhovaného modulu pro integraci datových sad je znázorněna v kritériu B2. Interaktivní průvodce integrací bude implementován jako vícekrokový wizard splňující požadavky na podporované formáty datových sad .csv a .xlsx. Integrace map bude možné provést také v .csv, .xlsx a shapefilu.
Přičemž bude možné vytvořit pouze bodovou mapovou vrstvu z bodů s GPS souřadnicemi. Podpora integrace map bude implementována na základě cloudového řešení od ESRI ArcGIS a budou použita rozhraní ArcGIS for JavaScript a REST API ArcGIS.
3.4. Datový katalog
Datový katalog bude implementován jako přehledná tabulka datových sad. Uživatel bude moci jednoduše vyhledávat ve fuzzy full-text vyhledávačí, abecedně řadit či filtrovat podle kategorií a tagů. Datový katalog a změny v něm budou sledovány v auditu změn. Potřebné detaily a popisy podle zadání budou zobrazovány včetně náhledu tabulky a exportu popisu datové sady do .xlsx souboru. Datový katalog bude take synchronizován s ostatními moduly dle zadání jako sémantický graf, ontologický model, aktualizace a dotazovací jazyk.
3.5. Dotazovací jazyk
Dotazovací jazyk nabídne jednoduchou formu “question-answering” a vyhledávače. Využity budou sémantické entity jako klíčová slova ve vyhledávači. Systém bude umět identifikovat propojenost oblasti
1
ontologického grafu, identifikovat sémantická propojení, či automatické návrhy na propojení na základě korelační analýzy, entropie apod. Výsledky budou vizualizovány v tabulkách, embedded mapách a grafech (liniových, koláčových). Pro náročnější uživatele bude poskytnuto propojení do specializovaného vizualizační aplikace např. Power BI apod.
3.6. Sémantický graf domény
Vizualizace grafu domény bude znázorněna uzly a spojeními i s odpovídajícími labely dle zadání. Implementovány budou grafové algoritmy pro vyhledávání nejkratší cesty mezi uzly a také rankovací algoritmus. Uživatel bude mít možnost si customizovat vlastní propojení a takto profilovat jeho využití dat a závislostí, které bude pro něj specifické.
3.7. Harvesting otevřených dat z webu
Vytvoříme nástroje pro harvesting otevřených dat z webu, a to pro různé formáty a s uvážením právních aspektů možnosti využití. Navrhované řešení je založené na sadě přístupů podle úrovně dostupných strojových informací. Pro účely existujících katalogů a podobných aplikací je možné pro získání datových sad využít jejich API a tím získat přístup k sadám obsaženým v katalogu. V případě informací dostupných pouze v podobě webových stránek apod. je plánováno využití existujících nebo pro tento účel připravených nástrojů (robotů, crawlerů) určených pro procházení struktury daného webu a extrakci informací.
Obecně mohou být všechny sady v různých formátech a strukturách. Pro zajištění co největší jednotnosti a dalšího použití v rámci návazných akcí, jako je modelování těchto sad, bude potřeba zajistit jejich transformaci. Pro tyto účely je plánováno využít principy ETL a poskytnout modul zajišťující transformace a normalizace datových sad. Podobně je plánováno využít i automatizačních nástrojů pro pravidelné spouštění úloh zajišťující aktualizace.
Pro zajištění pravidelné aktualizace bude provedena analýza charakteru těchto aktualizací pro různé datové zdroje (např. změny struktury či reprezentace dat v rámci aktualizace) a naimplmentovány algoritmy pro automatické či poloautomatické (podle charakteru změn) aktualizace.
3.8. Integrace Národního katalogu otevřených dat (NKOD)
Národní katalog otevřených dat je ve své podstatě typem otevřeného katalogu dat, platí tedy pro něj vše, co bylo napsáno v sekci 3.7.
3.9. Mapové a vektorové analýzy
Dle zadání použijeme ArcGIS for JavaScript a jeho funkce pro výpočet vzdálenosti, obalovou vzdálenost, analýzu sousedství, navigaci atd.. Také budeme implementovat kombinaci tabulkových a geografických informací, které bude umisťovat k bodům na mapě.
3.10. Identity management
Komplexní identity management nabídne víceúrovňové role a spravování rolí administrátorem, přehledovou tabulku správu účtu, změnu přístupu. Standardní workflow pro přihlašování, zapomenutá hesla a zasílání potvrzovacích e-mailů. Administrátor bude také moci flexibilně konfigurovat přístupové sekce a vytvářet tak flexibilně nové role podle vlastních definovaných přidělených kompetencí. V rámci autorizací bude také administrovány jednotlivé přístupy k veřejným, placeným a vlastním datovým sadám. Integrujeme také platební bránu dle zadání. Implementace v prostředí Azure umožní připojování dalších B2B a B2C federovaných služeb.
3.11. Analytika, statistika a kontrola kvality systému
Vytvoříme nástroje a reporty, které umožní sledovat a hlídat kvalitu dat a práci s daty v rámci systému.
2
Bude se jednat o:
Prediktivní analytiku, která dokáže předvídat způsob práce s daty v rámci platformy. Segmentací pomůžeme lépe poznat typy uživatelů a tím navrhnout rozsah služeb, které jim platforma poskytne.
Textovou analytiku, využijeme pro jednodušší identifikaci entit, které pak snadněji zařadíme do modelů pro zkvalitnění a vyšší přesnost dotazů v přirozeném jazyce.
Další kategorií analýz bude tzv. Data science: Big data analýza, která pomůže porozumět chování uživatelů ve chvíli, kdy to uživatelé potřebují. Zjednodušíme tím přístup i informacím, zkrátíme čas při zpracování dat a zvýšíme produktivitu systému.
3
Návrh architektury IaaS, PaaS, SaaS cloudového řešení
B1
Návrh softwarové architektury datové platformy si klade za účel zpracování rozsáhlých objemných heterogenních dat a vysokovýkonnostní distributivní analytické výpočty nad daty. Datová platforma je koncipována i pro běh multi-tenantní aplikace.
Navrhovaná architektura datové platformy je postavena na modelech IaaS (Infrastracture as a Service), PaaS (Platform as a Service) a SaaS (Software as a Service) na nativním cloudu od Microsoft Azure. Oranžový blok vymezuje komponenty, které běží v cloudu. Modré bloky znázorňují logické virtuální sítě a oddělení jednotlivých běžících servisů v architektuře mikroservisů. Šedé šipky vyjadřují často vzájemnou komunikaci mezi bloky nebo komponentami.
Cloud ArcGIS – geografické informace a řešení vektorových mapových dotazů bude využito nejnovější řešení od ESRI a to cloudové řešení ArcGIS. Cloudové řešení ArcGIS bude komunikovat s datovou platformou a sloužit jako hostované úložiště mapových vrstev a generování embedded map v rámci platformy. Komunikace bude implementována v ArcGIS for Javascript a rozhraních REST API.
Cost Management – v rámci využivání cloudových služeb bude možné monitorovat a předpovídat cenu služeb IaaS, PaaS a SaaS.
Container Registry, Docker – bude využito pro kontejnerizovaní mikroslužeb v cloudu, tak
aby celá platforma spňovala pricip přenositelnosti, tzv. portability.
Storage Explorer - je desktopový softwarový klient (průzkumník úložiště) pro uživatelskou správu cloudového úložiště (semi) strukturovaných a nestrukturovaných dokumentů.
Přístupné, intuitivní a bohaté grafické rozhraní (GUI) slouží k úplné správě prostředků cloudového úložiště.
Software Client - je myšlenkový libovolný softwarový klient, což může být jiná desktopová, webová, cloudová (cloud-to-cloud připojení), mobilní aplikace nebo nakonec např. government systém. Softwarový klient se připojuje na API gateway a může konzumovat služby nezávisle od grafického rozhraní.
End User - je koncový uživatel, který přistupuje na front-endovou část aplikace datové platformy (uživatel typu “laik” a “analytik”). Uživatel typu “vývojář” může přímo ovládat funkční prvky pomocí rozhraní REST API dokumentované standardem OpenAPI.
Web Application - blok webové aplikace ohraničuje monolitickou prezentační aplikaci pro koncového klienta.
Front End v Blazor WebAssembly - použití nové moderní technologie Blazor kompilující se do WebAssembly umožňuje efektivněji využívat full-stack vývoje na .NET a také efektivněji využívát koncová zařízení. Navíc uživatelské prostředí nabízí SPA technologii, kterou uživatelé ocení při práci s daty při dynamickém měnění uživatelského prostředí.
API Gateway - je množina API sekcí a API služeb jejichž záměrem je vysoká integrovatelnost datové platformy do jiných (sub)systémů. S API na šifrovaném novém protokolu HTTPS /2 s certifikátem se komunikuje pomocí JSON (Javascript Object Notation) zpráv. REST API komunikuje na základních dotazech HTTPS protokolu jako GET, POST, DELETE. Architektonickým cílem takového návrhu je nezávislost na operačním systému a programovacím jazyce klienta, který tuto REST API konzumuje. Logicky se API Gateway datové platformy bude dělit na externí a interní API skupiny a služby a bude řazena tématicky podle sekcí, např. v obrázku znázorněna API sekce pro množinu funkcí výhradně určených pro správu datového katalogu. Jednotlivé API služby nesou plnou odpovědnost za funkcionalitu v aplikaci a jsou využívány napříč celou datovou platformou všude, kde je zapotřebí komunikace s datovým katalogem a dotazovacím jazykem. To přináší také nespornou výhodu jednodušší testovatelnosti základních funkcí datové platformy.
Dokumentace OpenAPI - specifikace OpenAPI, původně známá jako Swagger Specification, je specifikací pro strojově čitelné soubory rozhraní pro popis, výrobu, spotřebu a vizualizaci webových služeb RESTful. Původně součást rámce Swagger se v roce 2016 stala samostatným projektem, na který dohlíží iniciativa OpenAPI Initiative, projekt spolupráce open-source nadace Linux Foundation. Swagger a některé další nástroje mohou generovat kód, dokumentaci a testovací případy dané souborem rozhraní. Detailněji se lze dočíst na: xxxxx://xxx.xxxxxxxx.xxx/ (přistupná dne 26. 4. 2022). Aktuálně OpenAPI tvoří průmyslový standard pro návrh a dokumentaci REST API aplikací. Zmíněný standard OpenAPI bude používán pro všechny externí a interní API na které datová aplikace komunikuje v rámci mikroservisní architektury.
External API - externí část API určená pro veřejný přístup nebo autentifikovaný bez speciálních autorizačních rolí.
Internal API - interní API je množina služeb, které jsou dedikovány pro účely autorizovaných přístupu. Zde se převážně jedná o přihlášené uživatele s vyšší autorizací v rolích admina a superadmina.
Web App Service UI - Azure App Service je služba založená na protokolu HTTP pro hostování webových aplikací, rozhraní REST API a mobilní back-endy. Můžete vyvíjet ve svém oblíbeném jazyce, ať už jde o .NET, .NET Core, Javu, Ruby, Node.js, PHP nebo Python. Aplikace se snadno spouštějí a mění v prostředích založených na systémech Windows i Linux. App Service nejen zvyšuje výkon aplikace Microsoft Azure, jako je zabezpečení, Vyrovnávání zatížení, automatické škálování a automatizovaná správa.
Můžete také využít své možnosti DevOps, jako je průběžné nasazování z Azure DevOps, GitHubu, Docker Hub a dalších zdrojů, Správa balíčků, přípravná prostředí, vlastní doména a certifikáty TLS/SSL. Se službou App Service platíte jenom za výpočetní prostředky Azure, které využijete. Výpočetní prostředky, které využijete, se určují podle plánu App Service , na kterém spouštíte aplikace.
Data Catalog Blob Storage - Azure Blob Storage pomáhá vytvářet datová jezera pro potřeby analýz a poskytuje úložiště umožňující vytvářet výkonné aplikace nativní pro cloud a mobilní aplikace. Optimalizuje náklady s využitím vrstveného úložiště pro dlouhodobá data a využívá možnost flexibilního vertikálního navyšování kapacity pro úlohy vysokovýkonného výpočetního prostředí a strojového učení. Úložiště objektů blob bloku se používá ke streamování a ukládání dokumentů, videí, obrázků, záloh a jiných nestrukturovaných textových nebo binárních dat. V případě datové platformy využíváme pro ukládání rozsáhlých struktur datového katalogu jako binární .csv a .json soubory metadat a schémat datových sad. Ukládání probíhá v momentě importování nové datové sady, a to buď přímo přes API nebo drag & drop uživatelském rozhraní. Technologie Blob Storage je ideální právě pro tyto struktury, a to jednak pro téměř neomezenou kapacitu (5 petabajtů dat) a nízkou cenu pro ukládání rozsáhlých dat.
Služba Azure Storage nabízí různé úrovně přístupu, což umožňuje ukládat data objektů BLOB nejefektivnějším způsobem. Dostupné úrovně přístupu zahrnují:
● Horká – optimalizovaná pro ukládání dat, ke kterým dochází často.
● Studená – optimalizovaná pro ukládání dat, která se nepoužívají zřídka a ukládají se aspoň na 30 dní.
● Archivační aplikace optimalizované pro ukládání dat, která se nepoužívají zřídka a jsou ukládána minimálně 180 dní a jsou v řádu hodin flexibilní požadavky na latenci.
V následující tabulce jsou popsány výchozí limity pro účty úložiště Azure pro obecné účely V1, v2, BLOB Storage a Block. Limit příchozího přenosu dat odkazuje na všechna data, která se odesílají do účtu úložiště. Limit odchozího přenosu dat odkazuje na všechna data přijatá z účtu úložiště.
Datasets Tables - Azure Table Storage je služba, která ukládá nerelační strukturovaná data (označovaná také jako strukturovaná data NoSQL) v cloudu a poskytuje úložiště klíčů a atributů s návrhem bez schématu. Vzhledem k tomu, že je Table Storage bez schématu, je snadné data přizpůsobovat měnícím se potřebám vaší aplikace. Přístup k datům Table Storage je pro mnoho typů aplikací rychlý a nákladově efektivní a pro podobné objemy dat obvykle znamená nižší náklady než tradiční SQL. Table Storage můžete používat k ukládání flexibilních datových sad, například uživatelských dat pro webové aplikace, adresářů, informací o zařízení nebo dalších typů metadat, které vaše služba vyžaduje. V tabulce můžete uložit libovolný počet entit a účet úložiště může obsahovat libovolný počet tabulek, až do limitu kapacity účtu úložiště.
Služba Azure Table Storage ukládá velké objemy strukturovaných dat. Služba je úložištěm dat typu NoSQL, které přijímá ověřená volání z cloudu Azure i z prostředí mimo něj. Tabulky Azure jsou ideální pro ukládání strukturovaných, nerelačních dat. Mezi běžná použití služby Table Storage patří:
● Ukládání terabajtů strukturovaných dat, která můžou obsluhovat škálované webové
aplikace
● Ukládání datových sad, které nevyžadují komplexní spojení, cizí klíče nebo uložené postupy a které můžete denormalizovat kvůli rychlému přístupu
● Rychle dotazování na data pomocí clusterovaného indexu
● Přístup k datům pomocí protokolu OData a dotazů LINQ s knihovnami .NET datové služby WCF
*TiB - terabajt
Služba Azure Table bude využívána v integraci nových datových sad v datové platformě. Při drag & drop importu datové sady se budou automaticky transformovat .csv soubory do tabulek v transakcích a podle schémat se vytvoří příslušné tabulky se sloupci odpovídajících datových typů (DateTime, Number, String).
App Service Plan - plán služby App Service definuje sadu výpočetních prostředků pro provozování webové aplikace. Tyto výpočetní prostředky jsou obdobné jako Serverová farma v části konvenční webové hostování. Jednu nebo více aplikací je možné nakonfigurovat tak, aby běžely na stejných výpočetních prostředcích (nebo ve stejném plánu App Service). Při vytváření plánu App Service v určité oblasti (například Západní Evropa) se pro tento plán v této oblasti vytvoří sada výpočetních prostředků. Všechny aplikace, které zadáte do tohoto
plánu App Service, běží na těchto výpočetních prostředcích, jak jsou definované vaším plánem App Service. Každý plán služby App Service definuje:
● Oblast (USA – západ, USA – východ atd.)
● Počet instancí virtuálních počítačů
● Velikost instancí virtuálních počítačů (malá, střední, velká)
● Cenová úroveň (Free, Shared, Basic, Standard, Premium, PremiumV2, PremiumV3,
izolovaný režim)
SQL Database - dedikovaná a automaticky spravovaná Microsoft SQL Database v SaaS modelu je použita. Úrovně služeb (service tiers) v modelu nákupu na základě DTU jsou rozlišené rozsahem výpočetních velikostí s pevným množstvím zahrnutého úložiště, pevným obdobím uchovávání záloh a pevnou cenou. Všechny úrovně služeb v modelu nákupu založeném na DTU poskytují flexibilitu při změně výpočetních velikostí s minimálními výpadky. v průběhu období ale dojde k přepnutí připojení do databáze po krátkou dobu, kterou je možné zmírnit pomocí logiky opakování. Samostatné databáze a elastické fondy se účtují po hodinách na základě úrovně služby a výpočetní velikosti. Využíváme nyní Basic databázi. Poskytovaná spolehlivost je garantovaná na 99,9% SLA (Service License Agreement). Pro porovnání Base, Standard a Premium databází v cloudu následující tabulka:
SQL databázi používáme pro datové sady, kde je potřeba SQL dotazů a také hlavně je v ní ukládán celý management uživatelských rolí jako jednotlivý uživatelé a jejich osobní údaje, seznam rolí a přidělené role.
SMTP Server SendGrid - cloudový e-mailový server umožňuje rozsáhlé funkce i s hromadnými distribučními listy jako zaslání newsletteru, e-mailové kampaně a uchovávání statistik a aktivit. V datové platformě budou využívané základní funkce pro potvrzovací e-maily pro registraci uživatele, zapomenutí hesla nebo změnu hesla.
SaaS model datové platformy
Narozdíl od legacy (zastaralých) systémů, kde se používají perpetuální licence. Využíváme subskripčních cenové politiky licencí, např. “pay-as-you-go”. V obrázku níže jsou popsány jednotlivé vrstvy a rozdělení do modelů IaaS, PaaS a SaaS. Kritérium pro výběr vhodného modelu je business case a orientace na váš business core.
Cenový forecast datové platformy a přidružených služeb
Odhad cenových nákladů na produkční prostředí je v příloze 1.
Základní funkce cloudu ArcGIS jsou do určitého počtu dotazů zdarma, dále se řídí podle aktuálního ceníku uváděného zde:
xxxxx://xxxxxxxxxx.xxxxxx.xxx/xxxxxxx/ (ke dni 26. 4. 2022)
B2 | Zpracování jednoduchých datových sad a ukázka možného čtení ve vlastním aplikačním modulu běžícího v cloudu | 25 % |
Implementovaný modul dostupný na URL: xxxxx://xxxxxxxxxxxxxxxxx.xxxxxxxxxxxxx.xxx/ podporuje zpracování heterogenních dat v souboru xlsx a .csv. Implementace je provedena 4-krokovým wizardem s přehlednými pokyny a validovaným formulářem. Wizard také ukládá v mezikrocích uživatelův postup či případně může být použito tlačítka “uložit draft” a pro pozdější účely znovu načíst tlačítkem “načíst draft”. Postupně uživatele provede následujícími kroky
1. Import tabulky
Rozpozná automaticky tabulky v souboru .xlsx a automaticky dokáže detekovat oddělovač v
.csv souboru. Součástí je vytvoření názvu datové sady, z níž je generováno UUID (unikátní klíč). V rámci analýzy souboru je přečteno prvních 100 řádku a jsou automaticky detekovány datové typy a poskytnut i automatický návrh popisu sloupců na základě strojového učení.
2. Popis datové sady
Popis datové sady je implementován podle standardu konsorcia W3C a to konkrétně Data Catalog Vocabulary (DCAT). Lze podle obrázku níže vyplnit popis sady, poskytovatele, periodicitu aktualizace, původ, geografické území, časové období a nejmenší geo-jednotku.
3. Autorizace
V autorizacích je uživatel vyzván ke zvolení oprávnění přístupu k datové sadě (veřejná, placená, individuální a soukromá), vyplnění URL odkazu na originální data a také vyplnění autorských, osobních a zvláštních práv vztahujících se k datové sadě.
4. Témata a klíčová slova
Zde v námi navrhovaném konceptu uživatel vybere témata a klíčová slova vztahující se
k integrované datové sadě.
K importu rozsáhlých datových .csv souborů je použita vlastní implementace streamování .csv souborů v segmentech. Stručně tak na straně uživatele dochází k segmentaci souboru .csv na malé části, které jsou dále komprimovány a streamovány s progressbarem ve wizardu. Na straně cloudu tak již první segmenty lze zapisovat do databáze. Takto dosahujeme až 10x větší rychlosti přenosu souboru oproti souborům bez komprese a segmentace. Níže obrázek použitého REST API pro streamování a očekávaného objektu segmentu, kde políčko dataBlock je vlastní komprimovaný segment.
Microsoft Azure Estimate
Your Estimate
Service type | Custom name | Region | Description | Estimated monthly cost | Estimated upfront cost |
Azure Cost Management | No charge for managed Azure spend. Additional premium | $0,00 | $0,00 | ||
and Billing | capabilities are available at no cost through December 2018 | ||||
when they will become paid features. 1% of managed spend | |||||
for AWS and Google Cloud Platform. | |||||
Azure Container Registry | West Europe | Basic Tier, 1 units x 30 days, 0 GB Bandwidth | $5,00 | $0,00 | |
API Management | West Europe | Basic tier, 1 unit(s), 730 Hours | $147,17 | $0,00 | |
Azure SQL Database | West Europe | Single Database, DTU Purchase Model, Standard Tier, S0: 10 | $14,72 | $0,00 | |
DTUs, 250 GB included storage per DB, 1 Database(s) x 730 | |||||
App Service | West Europe | Hours, 5 GB Retention Standard Tier; 1 S2 (2 Core(s), 3.5 GB RAM, 50 GB Storage) x | $146,00 | $0,00 | |
730 Hours; Windows OS | |||||
Storage Accounts | West Europe | Block Blob Storage, General Purpose V2, LRS Redundancy, | $20,73 | $0,00 | |
Hot Access Tier, 1,000 GB Capacity - Pay as you go, 10 x | |||||
10,000 Write operations, 10 x 10,000 List and Create | |||||
Container Operations, 10 x 10,000 Read operations, 100,000 | |||||
Archive High Priority Read, 1 x 10,000 Other operations. | |||||
1,000 GB Data Retrieval, 1,000 GB Archive High Priority | |||||
Retrieval, 1,000 GB Data Write | |||||
Azure Functions | West Europe | Consumption tier, 128 MB memory, 100 milliseconds | $0,00 | $0,00 | |
execution time, 0 executions/mo | |||||
Support | Support | $0,00 | $0,00 |
Licensing Program Microsoft Customer Agreement (MCA) Billing Account
Billing Profile
Total $333,61 $0,00
Disclaimer
All prices shown are in United States – Dollar ($) USD. This is a summary estimate, not a quote. For up to date pricing information please visit xxxxx://xxxxx.xxxxxxxxx.xxx/xxxxxxx/xxxxxxxxxx/ This estimate was created at 4/26/2022 10:02:32 AM UTC.
Subkritérium B3. Vytvoření jednoduchého ontologického modelu v notaci UFO/OntoUML Vytvoření jednoduchého ontologického modelu v notaci UFO/OntoUML pro zadanou datovou sadu s použitím vybraného nástroje. Pro model bude požadováno demonstrovat provedení automatizované syntaktické a sémantické verifikace a implementaci jednoduchého exportního formátu. Vizualizace sémantických grafů a jejich vazeb v aplikaci.
Účastník bude demonstrovat provedení automatizované syntaktické a sémantické verifikace a implementaci jednoduchého exportního formátu na praktické prezentaci SW řešení.
Pro zpracování příkladu jsme použili notaci UFO/OntoUML a nástroj OpenPonk. V příslušných adresářích je vždy model v OpenPonk (.opp), export diagramu (.png) a strojově čitelný export (.json).
V modelech je vidět koncepční navázání na datové sady (entity ...Data). Přesné navázání je poté vyjádřeno v pravidlech, které jsou vidět v JSON exportu. Tato pravidla jsou dále použita pro demonstraci subkritéria B4.
Soubor 'ukazka syntakticke verifikace.png' demonstruje požadovanou schopnost provedení syntaktické verifikace. Ukázka byla vytvořena též s pomocí nástroje OpenPonk. Syntaktická verifikace kontroluje soulad se specifikací UFO/OntoUML. U nalezených chyb je kromě indikace chyby k dispozici i odkaz na dokumentaci do portálu XxxxXXX.xxx.
Soubor 'ukazka semanticke verifikace.png' demonstruje požadovanou schopnost provedení sémantické verifikace, tedy kontroly významové čistoty modelu. K tomu jsme využili katalog nedoporučených vzorů (anti-patterns) UFO/OntoUML, který je též dostupný z nástroje OpenPonk. K nalezeným varováním je poté též k dispozici odkaz do dokumentace XxxxXXX.xxx.
Strojově čitelné exporty byly poté programově zpracovány a vygenerován sémantický graf (soubor 'semanticky graf.png'.
Obyvatelstvo
Úrazy - domácí
Vyjížďky do zaměstnání
Semantický graf
Ukázka syntaktické verifikace
Vysvětlení přístupu k propojování datových sad
Ontologické konceptuální modely datových sad a z nich vygenerovaný sémantický graf (viz subkritérium B3) dávají přehled o konceptech, o kterých přímo či nepřímo hovoří data. Mapovací pravidla (viz níže) poté poskytují provázání mezi ontologickými entitami a daty (sloupci). Díky tomu je možné formulovat dotazy v běžných pojmech i přes to, že sloupce mají technické názvy.
Dále je pomocí mapovacích pravidel dosažena normalizace dat a překlenutí syntaktické heterogenity – viz např. rozdílné kódování pohlaví v různých datových sadách.
Navíc je možné používat inferenci na základě pravidel obsažených v metamodelu UFO/OntoUML. Např. fakt, že Žena a Muž jsou podtypem Osoba nám dává možnost propojit datové sady, které hovoří o obyvatelstvu bez ohledu na pohlaví (Vyjížďky do zaměstnání) s datovými sadami, které pohlaví rozlišují (Obyvatelstvo).
Potenciální možnost propojení dat lze získat ze shlukové analýzy a analýzy souvislosti v sémantickém grafu. V případě těchto tří modelů je vidět silné propojení přes Geografické území – opět díky vztahu nadtyp-podtyp nás nezmate, že se v sadách hovoří někde o krajích vs okresech vs městech. Z ontologického modelu jsou zřejmé vztahy celek-část územního členění. V tomto jednoduchém příkladu nejsou k dispozici data o územních celcích, pokud by však byla doplněna, bylo by možné též přesně určovat, které město se nachází v kterém okrese a toto využít k dalším dotazům s využitím inference.
Ontologické modely díky své sémantice jsou schopny odchytit i logicky chybné dotazy. Pokud nás tedy bude zajímat např. “Úrazy v souvislosti s dojížďkou do zaměstnání”, na základě přítomnosti dat o úrazech a dat o dojíždění bychom se mohli pokusit tato data propojit. Data o úrazech jsou však výslovně uvedena jako domácí úrazy, tedy nemají s vyjížďkami do zaměstnání žádnou souvislost (např. v podobě automobilové nehody). V ontologického modelu je toto zřejmé -- úrazy v našem případě se týkají Xxxx s úrazem (jakožto UFO role Xxxxx) a nemají žádnou logickou souvislost s Vyjížďkou za prací.
Mapovací pravidla
Dále uvádíme přehled mapovacích pravidel z ontologických konceptuálních modelů. Skupiny pravidel obarveny dle logické příslušnosti, která vyplývá z ontologických modelů:
• modrá – údaje o věku
• žlutá – údaje o pohlaví
• zelená – geografické údaje
• oranžová – časové údaje
• bez barvy – specifické hodnoty datové sady
Je tedy zřejmé, že nyní na základě ontologických modelů a mapovacích pravidel jsme schopni posoudit možnosti propojení datových sad. V tomto případě je logicky možné hledat spojení přes věk, pohlaví, geografické či časové údaje. Samozřejmě záleží potom na konkrétních hodnotách, jestli má smysl pokračovat i k datovému spojení (např. časové údaje nejsou zcela rozdílné), ale to se již jedná pouze o operace s dotazy nad hodnotami, které pro jejich běžnost zde již nedemonstrujeme, pouze poukazujeme na to, že před jejich provedením je třeba provést dodatečné normalizace, např. datového formátu.
Obyvatelstvo
"vek_cis" -> "Věková kategorie"; "vek_txt" -> "Věková kategorie";
"vek_kod" = 400000600005000 -> "Věková kategorie {od: 0, do: 4}";
"vek_kod" = 400005610010000 -> "Věková kategorie {od: 5, do: 9}";
"vek_kod" = 410010610015000 -> "Věková kategorie {od: 10, do: 14}";
"vek_kod" = 410015610020000 -> "Věková kategorie {od: 15, do: 19}";
"vek_kod" = 410020610025000 -> "Věková kategorie {od: 20, do: 24}";
"vek_kod" = 410025610030000 -> "Věková kategorie {od: 24, do: 29}";
"vek_kod" = 410030610035000 -> "Věková kategorie {od: 30, do: 34}";
"vek_kod" = 410035610040000 -> "Věková kategorie {od: 35, do: 39}";
"vek_kod" = 410040610045000 -> "Věková kategorie {od: 40, do: 44}";
"vek_kod" = 410045610050000 -> "Věková kategorie {od: 45, do: 49}";
"vek_kod" = 410050610055000 -> "Věková kategorie {od: 50, do: 54}";
"vek_kod" = 410055610060000 -> "Věková kategorie {od: 55, do: 59}";
"vek_kod" = 410060610065000 -> "Věková kategorie {od: 60, do: 64}";
"vek_kod" = 410065610070000 -> "Věková kategorie {od: 65, do: 69}";
"vek_kod" = 410070610075000 -> "Věková kategorie {od: 70, do: 74}";
"vek_kod" = 410075610080000 -> "Věková kategorie {od: 75, do: 79}";
"vek_kod" = 410080610085000 -> "Věková kategorie {od: 80, do: 84}";
"vek_kod" = 410085610090000 -> "Věková kategorie {od: 85, do: 89}";
"vek_kod" = 410090610095000 -> "Věková kategorie {od: 90, do: 94}"; "vek_kod" = 410095799999000 -> "Věková kategorie {od: 95, do: undefined}"; "pohlavi_cis" -> "Žena" OR "Muž";
"pohlavi_kod" = 2 -> "Žena"; "pohlavi_kod" = 1 -> "Muž"; "pohlavi_kod" = "" -> Žena" OR "Muž"; "pohlavi_txt" = "muž" -> "Muž"; "pohlavi_txt" = "žena" -> "Žena";
( "vuzemi_cis" = 97 ) -> ( "hodnota" -> "Počet obyvatel České republiky" ); ( "vuzemi_cis" = 100 ) -> ( "hodnota" -> "Počet obyvatel kraje" );
( "vuzemi_cis" = 101 ) -> ( "hodnota" -> "Počet obyvatel města" ); "vuzemi_cis" = 97 -> "Česká republika";
"vuzemi_cis" = 100 -> "Kraj";
"vuzemi_cis" = 101 -> "Městský charakter";
( "vuzemi_cis" = 97 ) -> ( "vuzemi_kod" -> "Česká republika" ); ( "vuzemi_cis" = 100 ) -> ( "vuzemi_kod" -> "Kraj" );
( "vuzemi_cis" = 101 ) -> ( "vuzemi_kod" -> "Městský charakter" ); ( "vuzemi_cis" = 97 ) -> ( "vuzemi_txt" -> "Česká republika" );
( "vuzemi_cis" = 100 ) -> ( "vuzemi_txt" -> "Kraj" );
( "vuzemi_cis" = 101 ) -> ( "vuzemi_txt" -> "Městský charakter" ); "casref_do" -> "Referenční období";
"idhod" -> "Počet obyvatel České republiky" OR "Počet obyvatel kraje" OR "Počet obyvatel města"; "stapro_kod" -> "Počet obyvatel České republiky" OR "Počet obyvatel kraje" OR "Počet obyvatel města";
Úrazy
"typHodnoty" = 1 -> "Na 100 000 obyvatel";
"rok" -> "Referenční období";
"hodnota" -> "Počet úrazů";
"vekovaSkupina" | -> | "Věk"; | |||||||||||
"pohlavi" "pohlavi" "pohlavi" | = | = | = | 0 | 1 | -> | 2 | -> "Žena" | -> | OR | "Žena"; "Muž"; "Muž"; | ||
"orp" "okres" | -> | "Obec | s -> | rozšířenou | působností"; "Okres"; |
"kraj" -> "Kraj"; | ||||
Vyjížďky | ||||
"pohlavi_kod" | = | 1 | -> | "Muž"; |
"pohlavi_kod" | = | 2 | -> | "Žena"; |
"pohlavi_kod" "pohlavi_txt" "pohlavi_txt" | = | = = | "" | -> "muz" "zena" | "Muž" | -> -> | AND | "Žena"; "Muž"; "Žena"; |
"pohlavi_txt" | = | "" | -> | "Muž" | AND | "Žena"; | ||
"idhod" | -> | "Vyjížďka | za | prací"; |
"vuzemi_kod" | -> | "Obec"; | |||||
"vuzemi_txt" | -> | "Obec"; | |||||
"uzemi_cis" | = | 97 -> | "Česká | republika"; | |||
"uzemi_cis" | = | 100 | -> | "Kraj"; | |||
"uzemi_kod" | -> | "Kraj"; | |||||
"uzemi_txt" | = | "Česká | republika" | -> | "Česká | republika"; | |
"uzemido_cis" | = | "" | -> | "Zahraniční | stát"; | ||
"uzemiz_cis" | = | "" | -> | "Zahraniční | stát"; | ||
"uzemido_kod" | = | 101 | -> | "Okres" | ; | ||
"uzemiz_kod" | = | 101 | -> | "Okres" | ; | ||
"uzemido_cis" | -> | "Okres"; | |||||
"uzemiz_cis" | -> | "Okres"; | |||||
"uzemido_txt" | -> | "Okres"; | |||||
"uzemiz_txt" | -> | "Okres"; | |||||
"uzemido_cis" | = | 100 | -> | "Kraj | Praha"; | ||
"uzemido_kod" | = | 3018 | -> | "Kraj | Praha"; | ||
"uzemiz_cis" | = | 100 | -> | "Kraj | Praha"; | ||
"uzemiz_kod" | = | 3018 | -> | "Kraj | Praha"; | ||
"datum" | -> | "Referenční | období"; |
"rok" -> "Referenční období";
Xxxxxx v datové sadě
Dále pro ilustraci přikládáme náhledy datových sad, opět obarvených podle sémantických skupin: 'obyvatelstvo-zvyrazneni.png'
'urazy-zvyrazneni.png' 'vyjizdky-zvyrazneni.png'
Aplikace přirozeného jazyka
Výše naznačený postup dosahuje plného a jednoznačného propojení dat s jejich sémantikou. Jelikož UFO/OntoUML vychází mj. z lingvistiky, ontologické konceptuální modely představují “slovníček” přirozeného jazyka. Dotaz v přirozeném jazyce je tedy třeba pomocí některé existující NLP (natural language processing) knihovny rozparsovat na prvky větné stavby a klíčové druhy vyhledat v konceptuálních modelech, k čemuž slouží jejich strojově zpracovatelné exporty. Je vhodné použít partial matching techniky, aby dotazovací jazyk byl schopen pracovat i s překlepy či skloňovacími odchylkami.
Následně pomocí mapovacích pravidel zjistíme, zda-li pro dotazované pojmy existují data v datových sadách. V případě, že ano, můžeme uživateli nabídnout možná logická a následně i datová spojení, jak bylo vysvětleno výše.