Zbiva (http://zbiva.zrc-sazu.si/) je raziskovalna zbirka podatkov o arheologiji vzhodnih Alp in okoliških regij v zgodnjem srednjem veku, ki obstaja že od leta 1987. Združuje podatke o arheoloških najdiščih, grobovih in predmetih ter relevantno znanstveno literaturo. Že od začetka je zasnovana trojezično (sloveščina, angleščina, nemščina). Trenutno obstaja kot spletna aplikacija z GIS-om, ki se osredotoča na potrebe visoko investiranih raziskovalcev.

Največja vrednost zbirke je sistematično zbiranje in informatiziranje znanstvenih podatkov, ki neprekinjeno poteka že štiri desetletja. Pomen zbirke za znanstveno delo je trojen. Je temeljno orodje Inštituta za arheologijo ZRC SAZU, na katerem temeljijo vse njegove znanstvene objave, na ravni JV-alpske regije, ki jo zbirka s svojimi podatki pokriva, gre za najboljšo tovrstno zbirko, na mednarodni ravni pa predstavlja eno od treh zbirk, ki vključujejo arheološke podatke o grobovih na ravni objekta. Zbirka je naročniku omogočila sodelovanje na več mednarodnih raziskovalnih projektih na najvišji ravni (FP7, H2020).

Neizogibna posledica dolge zgodovine sta strukturna zastarelost ter razpršenost obstoječe zbirke, zato želi naročnik zbirko strukturno preobraziti. Iz komercialne in opuščene platforme MS Access jo želi prenesti na odprtokodne rešitve PostgreSQL in PostGIS.

Trenutno je baza podatkov sestavljena iz dveh ločenih delov, Zbive in Libere. Zbiva je namenjena zbiranju in hranjenju arheoloških podatkov o najdiščih, grobovih in predmetih, Libera pa publikacijam. Obe sta trenutno v MS Access, spletni pregled pa v prirejeni obliki odprtokodnega sistema Arches (v3). Sinhronizacija med obema sistemoma trenutno poteka ročno.

Natančnejši opis podatkov, diagram relacij med tabelami in statistiko je potencialnim ponudnikom pred oddajo ponudbe na voljo na vpogled pri naročniku, in sicer dne 21. 4. 2021 ob 11. uri, po predhodni najavi (kontakt: Mateja Belak, mateja.belak@zrc-sazu.si).

Namen povpraševanja je izbira izvajalca, ki bo izdelal strukturo podatkovne zbirke in novo aplikacijo za zbirko Zbiva, ustrezno pretvoril podatke iz stare v novo strukturo ter v novo aplikacijo iz komercialne in opuščene platforme MS Access prenesel obstoječe baze podatkov.

Predmet povpraševanja je:

izdelava strukture podatkovne zbirke,
izdelava aplikacije Nova ZBIVA v odprtokodnih rešitvahe rešitvah PostgreSQL in PostGIS),
prenos obstoječih podatkov zbirke ZBIVA z Libero oz. pretvorba iz stare strukture v novo.

Obveznosti se prevzemajo s pogodbo za čas trajanja poslovnega razmerja, ki ga ta določa.

Rok za izvedbo storitev je 30. november 2021.

Ponudnik bo za opravljeno delo pripravil poročilo s specifikacijo opravljenih del, ki ga bo potrdil skrbnik pogodbe, in na podlagi potrjenega poročila izdal e-računa, ki ju bo naročnik poravnal v roku 30 dni po prejemu in po opravljeni celotni storitvi.

B. Tehnične specifikacije

B.1 Osnovne zahteve

Aplikacija mora biti sestavljena iz treh strogo ločenih delov:

zaledni del, ki skrbi za hranjenje in obdelavo podatkov ter njihovo strukturo;
API dostopne točke, kamor se lahko priklapljajo druge aplikacije (Frontend) ter omogoča dostopne točke za izvoz podatkov v arhivske formate (xls, xlsx, csv ...);
administracijski vmesnik za napredno uporabo in dodajanje šifrantov. Administacijski vmesnik je glede na izvajalčevo željo lahko samostojen, ali pa je zaradi bolj napredne uporabo lahko pripojen zalednemu sistemu. Administracijski vmesnik Zbive in Libere je lahko ločen ali deljen (kar se zdi izvajalcu primerneje).

Spletni vmesnik nove Zbive naj bo sestavljen iz dveh šibko ločenih sklopov: osnovne Zbive, ki je namenjena uporabi naročnika (Inštituta za arheologija ZRC SAZU) in Libere. Glede na trenutno stanje uporabe naj bosta spletna vmesnika strogo ločena, saj se s tem olajša uporaba Libere za tiste, ki jo uporabljajo neodvisno od Zbive.

B.2 Večjezičnost

Aplikacija je v osnovi dostopna v slovenščini, angleščini in nemščini ter omogoča podporo za pregled v izbranih jezikih. Slednje mora omogočati tudi nova oblika. Poleg spremnih besedil na spletnem vmesniku mora aplikacija omogočati tudi prevode kategoričnih vnosov v bazi, ki se jih ureja prek administracijskega vmesnika. Primeri takih kategorični vnosov so: ključne besede publikacij, imena lastnosti pripisanih posameznim najdbam, vrednosti pripisane lastnostim, tipi najdišč ...

B.3 Libera

Glavni namen Libere je zagotavljanje zanesljive baze literature za sklicevanje v Zbivi, vendar z razčlenjenim geslovnikom funkcionira tudi kot samostojna celota za iskanje literature.

Libera mora omogočati vodenje in urejanje publikacij, v preprostem spletnem uporabniškem vmesniku pa naj zunanjim uporabnikom omogoča iskanje po vneseni literaturi. Za naprednejše uporabnike mora Liberin spletni vmesnik omogočati tudi strukturirana iskanja in kombiniranje pogojev z uporabo Boolove-algebre (uporaba pogojev ALI, IN, NE pri posameznih iskalnih zahtevkih) in možnost shranjevanja preteklih iskanj lokalno v brskalniku.

B.3.1 Zaledje

Zaledni sistem Libere je direktno povezan s preostalo zbirko podatkov Zbiva in ne sme biti ločen od nje. Zaledni sistem mora za posamezno publikacijo voditi vse osnovne informacije in omogočati povezovanje zapisov Zbive s citati na enote Libere.

Zaledni sistem mora prek uredniškega vmesnika omogočati vnos in spreminjanje posameznih enot literature in dodajanje tako ključnih besed, kot spremembo šifranta ključnih besed. Administracijski vmesnik mora omogočati uvoz in izvoz podatkov iz Libere v izbranih formatih (Točna specikacija formata ali izbira več formatov je nepomembna; morda .ris in bibtex) in uvoz ter ročno združevanje uvoženih vnosov prek administracijskega vmesnika. Administracijski vmesnik Libere naj bo združen z administracijo Zbive. Administracijsko osebje bo praviloma enako, administracija Libere pa mnogo manjša, zato ni smiselno izdelovati posebnega vmesnika.

B.3.2 Spletni vmesnik

Spletni vmesnik Libere, ki je na voljo tudi zunanjim uporabnikom, mora vsebovati možnost iskanja po vseh poljih podatkov vnešenih publikacij. Poleg običajnega iskanja vmesnik ponuja tudi naprednejše iskanje z uporabo delnega ujemanja gesel in vsebine ter kombiniranja poljubnih iskalnih vzorcev z uporabo Boolove algebre. Omogočeno mora biti kombiniranje več različnih polj hkrati z enim samim pogojem. Ker je baza publikacij relativno majhna in se uporabniki zavedajo, da zahtevnejše poizvedbe lahko vzamejo nekaj časa, je sama optimizacija iskanja opcijska in ni nujni del storitve. Glede na zamišljeno končno strukturo uporabnikov naj bo kombiniranje iskalnih vzorcev narejeno grafično prek gnezdenja kombinacij pogojev, kot je recimo prikazano na sliki 1.

Slika 1: Primer gnezdenja različnih pogojev

Iskalnik naj podpira lokalno shranjevanje preteklih iskanj in izvoz ter uvoz iskalnega pogoja prek poljubnega formata iskalnika (json, poseben iskalni jezik, niz z zapisom poizvedbe ...). Sam format je nepomemben, ključna je zgolj možnost izvažanja in uvažanja. Shranjevanje preteklih iskanj za posameznega uporabnika v centralni bazi je že pretirana zahteva, ki bi po nepotrebnem zapletla in podražila razvoj, a ne bi prinesla večje uporabne vrednosti. Lokalno shranjevanje pa bi posameznemu uporabniku omogočilo delo z več različnimi poizvedbami in ne bi preveč obremenilo razvoja. Izvoz in uvoz v izbrani format omogoča lažje deljenje iskalnih zahtevkov in poveča možnost sodelovanja.

B.4 Zbiva

B.4.1 Zaledje

Glavni namen zalednega dela aplikacije je povezava z bazo in zagotavljanje API-dostopa za ospredje. Vsa povezava med ospredjem in zaledjem naj poteka prek API-ja. Ključni razlog za to je večja modularnost pri morebitnih nadgradnjah in enostavnost implementacije izvoza. Na ta način je vsak odgovor na API-klic takoj izvozljiv v izbrano obliko. Stroga ločitev zalednega dela in ospredja omogoča tudi neodvisnost tehnologij in lažje posodobitve. Zaledni del je odgovoren tudi za povezavo z administracijskim vmesnikom, za katerega pa ta ločitev ni nujna in je odvisna od vrste implementacije.

Sama implementacija in zasnova zalednega vmesnika je neodvisna od izbire baze in ospredja, saj vsa komunikacija poteka prek API-zahtevkov. Čim večji del poizvedb glede GIS sistemov naj se izvaja v sami podatkovni bazi (PostGIS ali primerljivo) in ne v aplikaciji.

B.4.2 Administracijski vmesnik

Glavna naloga administracijskega vmesnika je urejanje posameznih šifrantov, dodajanje novih lastnosti in njihovih vrednosti ter upravljanje s prevodi. Administracijski vmesnik mora biti dostopen le primerno akreditiranim uporabnikom. Akreditirani uporabniki lahko ostalim registriranim uporabnikom sistema določajo pravice za pregled in urejanje podatkov prek osprednjega sistema.

Administracijski vmesnik naj omogoča tudi pregled osnovnik statistik podatkovne baze (število vnosov, osnovna filtriranja in poizvedbe). Administracijski vmesnik naj ima možnost izvedbe poljubne poizvedbe nad bazo, ki je namenjena naprednim uporabnikom za natančnejše analize. (S tem ima uporabnik popoln dostop do baze, kar pomeni da lahko tudi dodaja in briše.)

Administracijski vmesnik mora omogočati izvoz celotne baze podatkov, izbrane tabele ali izbranega pogleda v predpisano obliko (cs, xls ...).

B.4.3 Ospredje

Naloga osprednega sistema je omogočanje vnosa in pregleda podatkov prek uporabniškega vmesnika. Ospredni sistem naj ponuja spletni uporabniški vmesnik, ki naj bo dostopen na javnem spletnem naslovu. Glede na zahteve naj bodo neregistriranim uporabnikom na voljo zgolj nekatere funkcionalnosti (osnovni pregledi in iskanja).

B.4.3.1 Urejanje in dodajanje

Ospredni sistem mora v intuitivni obliki omogočati urejanje in dodajanje posameznih vnosov v bazo (najdišče, grob, predmet) in glede na strukturo baze vse povezane podatke. Za posamezne vnose mora omogočati dodajanje pripojenih lastnosti že iz samega pogleda glavnega vnosa (npr. dodajanje teles v grobove, risb, izbira položaja telesa z določanjem prikazane risbe ...) in omogočati enostaven pregled vseh pripojenih lastnosti. Točna izvedba in prikaz sta odvisna od končne implementacije. Pomembno je, da se morajo forme na osprednem sistemu dinamično generirati iz lastnosti predmetov v zaledju (primer: ob dodajanju šifranta za novo obliko ogrlice jo mora ob naslednjem odprtju forma sama pokazati zraven že obstoječih).

Pregled mora minimalno omogočati dodajanje vseh elementov iz form v že obstoječi Zbivi.

B.4.3.2 Iskanje in poljubni pogledi

Osnovni iskalnik mora omogočati iskanje in filtriranje poljubnih objektov glede na njihove lastnosti in poljubne kombinacije pogojev na enak način kot v Liberi, to je z uporabo logičnih izrazov in njihovih kombinacij. Poleg filtriranj po lastnostih mora iskalnik tudi omogočati geografsko bazirano iskanje prek risanja poljubne oblike na zemljevidu in določanja časovnega intervala. Zaradi delne nestrukturiranosti mora baza aplikaciji omogočati polno iskanje po vseh poljih.

Ospredje naj vsebuje tudi pregled zemljevida, kjer so kot točke (ali skupki več točk) na zemljevidu prikazani objekti, ki ustrezajo iskalnim pogojem. Pri spreminjanju povečave se mora zemljevid in prikaz objektov ustrezno prilagajati (opcija: in omogočati izbiro različnih dodatnih, torej uvoženih načrtov). Ospredje naj omogoča natančnejši pregled posameznega najdišča in njegove vsebine pri veliki povečavi na zemljevidu. Kliki na posamezne točke na zemljevidu naj prikažejo ustrezne podatke o objektih in vsebujejo povezave do pregledov in urejanj teh objektov.

B.4.3.3 API dokumentacija

Izvajalec mora naročniku zagotoviti natančno API dokumentacijo za dostop do zalednega sistema in prenos podatkov s strani tretjih strank.

Izvajalec mora ob koncu projekta oddati kompletno dokumentacijo, ki naročniku omogoča samostojno uporabo rešitve.

B.5 Zasnova tehnologij

B.5.1 Baza podatkov

Podatki v novi Zbivi so relativno strogo strukturirani. Z izjemo splošnih komentarjev ob posameznih vnosih in stratigrafiji, ki se bodo vodili izven sistema. Zato predlagamo shranjevanje v relacijski bazi (SQL) z dodatnimi možnostmi za komentarje in iskanje (Full text search) po nestrukturiranem delu podatkov.

Želimo uporabo sistema PostgreSQL skupaj z razširitvijo PostGIS.

B.5.2 Zaledni sistem

Zaledni sistem mora biti zgrajen z uporabo že uveljavljenega ogrodja, ki avtomatsko podpira tako PostgreSQL kot PostGIS. Izmed obstoječih ogrodji na trgu je najbolj primeren odprtokodni Django (spisan v jeziku Python, prav tako Django uporablja tudi Arches), ali primerno alternativo na osnovi NodeJS (spisana v jeziku JavaScript).

B.5.3 Ospredje

Ospredje mora biti zgrajeno z uporabo knjižnice na osnovi Node.js ogrodja, na primer ReactJS ali katere podobne rešitve, ki omogoča modularno spreminjanje, enostavno dodajanje komponent in je odprtokoden ter dobro podprt.

B.6 Dodatna obveznosti izvajalca

priprava časovnice,
namestitev aplikacije na infrastrukturo (strežnik) naročnika,
konfiguracija obvestila o uporabi piškotkov,
končna predaja del naročniku po uspešnem testnem delovanju,
predaja dokumentacije, ki je potrebna za uporabo aplikacije, ki je predmet te pogodbe (programska in uporabniška dokumentacija, programske specifikacije, opis programa, uporabniška navodila).

C. Pogoji, ki jih mora izpolnjevati ponudnik

C1: Ponudnik mora navesti eno referenco, ki dokazuje, da je v zadnjih treh (3) letih pred rokom za oddajo ponudb uspešno zaključil primerljiv projekt v vrednosti vsaj 20.000 EUR brez DDV. Kot primerljiv projekt šteje izdelava spletne aplikacije na odprtokodni rešitvi, ki zbira, ureja ter obdeluje podatke iz različnih virov.

Dokazilo: Referenca (OBR-4), pri čemer ni treba, da je ta potrjena s strani naročnika posla. ZRC SAZU lahko v primeru dvoma referenco preveri pri navedenih kontaktnih osebah.

D. Merila za izbiro najugodnejše ponudbe

Merilo za izbiro najugodnejšega ponudnika je najnižja končna cena.

V primeru enakovrednih ponudb bo izbrana ponudba, ki je prej prispela na e-naslov naročnika.

ZRC SAZU si pridržuje pravico, da ne izbere nobenega ponudnika.

E. Način in rok za predložitev ponudbe

Svojo ponudbo z dokazili o izpolnjevanju pogojev iz poglavja pošljite na elektronski naslov iza@zrc-sazu.si.

Kot pravočasne bodo štele ponudbe, ki bodo prispele na elektronski naslov naročnika najkasneje do 23. 4. 2021 do 10. ure.

F. Pogoji za pravilnost ponudbe

Dokumentacija, ki jo morajo predložiti ponudniki:

- Podatki o ponudniku (OBR-1);

- Predračun (OBR-2);

- Vzorec pogodbe (OBR-3);

- Referenca (OBR-4);

- Predlog časovnice.

Vsi navedeni obrazci z izjemo Vzorca pogodbe (OBR-3) naj bodo podpisani in žigosani. Vzorec pogodbe je treba le parafirati.

G. Pojasnila ponudnikom

Ponudnik lahko pridobi dodatna pojasnila o povabilu k oddaji ponudbe najpozneje do 22. 4. 2021, do 14. ure pri dr. Benjamin Štular (e-naslov: benjamin.stular@zrc-sazu.si).