Příloha 2 - Technická specifikace Digitálního repositáře Strana 1
Hardwarová infrastruktura Návrh řešení musí obsahovat návrh hardwarové infrastruktury. Doporučujeme využít stávající infrastrukturu zadavatele. Softwarová infrastruktura a licence Popis řešení musí obsahovat návrh softwarové infrastruktury. Upřednostňujeme důraz na využití stávajících softwarových licencí vlastněných zadavatelem. Přehled licencí vlastněných zadavatelem souvisejících s provozem aplikace Digitální archiv: Klientské stanice Microsoft Windows XP SP2/MS Windows 7 64bit a vyšší Oracle DB EE + Spatial ext., popřípadě Microsoft SQL Server 2008 a vyšší Windows Server 2008 SE 64bit. SP2 Návrh musí obsahovat přesný výčet potřebných licencí včetně jejich orientačních cen po celou dobu projektu. Obecné požadavky na systém Architektura řešení Řešení by mělo být koncipováno jako trojvrstvé: klient aplikační server databáze. Obrázek 1- schéma požadované architektury řešení Aplikační server musí obsahovat veškerou aplikační logiku. Klientská část (tlustý klient) řešení musí obsahovat pouze logiku pro zadávání a zobrazování dat. Klientská část může být kdykoliv v budoucnu změněna bez nutnosti měnit aplikační logiku na aplikačním serveru. Součástí systému bude webový klient pro účely badatelské činnosti. Další součástí systému bude webová aplikace pro publikování označených dokumentů na Internetu. Databáze musí být relační. Preferujeme využití stávající technologie Oracle DB EE Spatial, pokud to bude technicky možné, případně Microsoft SQL Server 2008 nebo vyšší. Strana 2
Aplikační server bude přístupný pouze z intranetu. V případě integrace s internetovými řešeními bude dostupný pouze přes bránu dalšího aplikačního serveru. Aplikační server bude komunikovat s GIS serverem pro napojení digitálních kopií na geografické lokality. Pro určení geografické lokality bude využit stávající GIS server URM, komunikační rozhraní bude na úrovni www služeb (VMS nebo ESRI ArcGIS server Map Service) Předpokládá se součinnost URM. Servisně orientovaná architektura (SOA) Řešení musí splňovat podmínky servisní architektury založené na službách s možností použití komunikačního protokolu SOAP pro volání těchto služeb běžících na aplikačním serveru. Rozsah služeb je dán všemi funkčními požadavky budoucího řešení. Části systému z uživatelského pohledu - Digitalizační část zahrnuje ukládání dokumentů a metadat, editaci, GIS lokalizaci, vyhledávání, reporting, export pro archiv MHMP a potřeby dlouhodobých záloh - Badatelna webový klient, který umožní vyhledávání, tisk, ukládání na externí zařízení a zobrazování - Administrační část možnost definování práv, konfigurace reportů, číselníků, exportu, velikosti automaticky generovaných náhledů... Ergonomie Velký důraz bude kladen na ergonomii ovládání. Například vyhledávání bude obsahovat větší množství parametrů, které budou pohromadě v jedné záložce, další záložka bude obsahovat mapu s možností zakreslení polygonu pro upřesnění lokality. Návrhy ovládání a grafického ztvárnění budou předloženy ke schválení jako jeden z výsledků analýzy kompetentní osobě URM. GIS výběr území Součástí zadávání i vyhledávání dokumentů bude propojení s GIS serverem pro vyznačení území pomocí polygonu v mapě Prahy. Informace o dotčeném území bude součástí vyhledávání a upřesňování filtrů. Zabezpečení Jednotlivé požadavky musí být autorizované na straně aplikačního serveru a musí reflektovat nastavení jednotlivých uživatelských práv. Pro autentifikaci jednotlivých požadavků doporučujeme použít stávající DNS server. Všechny záznamy musí obsahovat čas vytvoření a změny záznamu a kdo záznam vytvořil / upravil. Nastavování práv Řešení musí umožňovat nastavení práv na jednotlivé operace minimálně na úrovni jednotlivých aplikačních rolí. Jednotlivá práva by měly být vázána na následující funkcionalitu: - Zakládání dokumentů - Oprava dokumentů Strana 3
- Náhled na dokument - Mazání dokumentů - Kontrola dokumentů (označení dokumentů Zkontrolováno ) - Vyskladnění / Uložení kontejnerů - Publikace dokumentů na web - Správa uživatelů Intranet - Správa uživatelů Internet Logování Všechny operace při práci s aplikací budou logovány a to jak na úrovni aplikačního serveru, tak na úrovni klienta a to tak, aby všechny operace byly v případě potřeby dohledatelné. Musí být možnost nastavit úroveň logování a to minimálně v tomto rozsahu: Všechny operace (trace) Chyby Aplikační informace informace vztažené k business logice celé aplikace Reporting Je preferováno propojení na MS Office, případně reporting services MS SQL serveru, otevřenost systému pro uživatelsky definované reporty. Funkční požadavky budoucího řešení Řešení by mělo plně podporovat procesy popsané v předmětu plnění veřejné zakázky. Primárním cílem je vytvoření softwarového řešení Digitální repositář (dále jen Aplikace) s možností plnění metadat k jednotlivým digitalizovaným dokumentům. Aplikace musí poskytovat níže uvedené funkcionality. Dokument Jednotlivé dokumenty jsou zakládané jako kolekce metadat s digitálními přílohami (soubory různého typu). Jednotlivé přílohy jsou ukládané v digitální podobě. Přílohy jako soubory můžou být tohoto typu: 1) Originální scan (tif formát) 2) Textový nebo vektorový dokument (pdf formát) 3) Obraz pro prezentaci (jpg formát) 4) Ostatní (txt, xml, csv) Klient musí umět zobrazit obsah vkládané přílohy a po potvrzení teprve umožnit uložení přílohy. Příloha typu originální scan, Obraz pro prezentaci a vektorový dokument pak umožní vložení těchto metadat k příloze: - Rozlišení (dpi) - Textový popis přílohy Příloha ostatního typu pak - Textový popis přílohy Metadata dokumentu Každý dokument musí obsahovat kolekci metadat tohoto výčtu v těchto logických skupinách: Hlavní identifikátory dokumentu - Název dokumentu - Název fondu (číselník) Strana 4
- Číslo URM nebo Původní přírustkové číslo nebo Signatura (musí být vyplněn minimálně jeden z těchto údajů) Číslo URM se generuje automaticky podle zařazení do fondu. - Příznak pro uzamčení dokumentu (dokument je uzamčen pro editaci jinými uživateli) Archivní metadata 1) Kód uložení 2) Číslo negativu 3) Umístění 4) Datum katalogizace 5) Uživatelské jméno uživatele, který provedl katalogizaci Fyzický popis 1) Médium (číselník) 2) Formát (číselník) 3) Formát pro uložení (číselník) 4) Počet kopií 5) Způsob dochování (číselník) 6) Stav dochování (číselník) 7) Technika vyobrazení (číselník) 8) Provedení vyobrazení (číselník) možno vložit několik možných variant Popisná metadata 1 1) Autor (číselník) s možností zadat k dokumentu více možných autorů. U každého přiřazeného autora musí být možnost vložení příznaku, že se jedná pouze o odhad 2) Země původu (číselník) 3) Místo vydání (číselník) 4) Měřítko (číselník) 5) Historické měřítko (textová hodnota) 6) Způsob zobrazení (číselník) s možností přiřadit více položek k danému dokumentu 7) Rok s možností vložení příznaku, že se jedná pouze o odhad 8) Období od 9) Období do 10) Jazyk (číselník) možnost vložit více záznamů k jednomu dokumentu 11) Poznámka Popisná metadata 2 1) Druh dokumentu (číselník) možnost vložit více záznamů k jednomu dokumentu 2) Počet stran možno zadat pouze k některým druhům dokumentů 3) Účel dokumentu (číselník) 4) Druh zobrazeného objektu s možností vložit více záznamů k jednomu dokumentu 5) Popisky / razítka textová hodnota s možností vložit více údajů tohoto typu k jednomu dokumentu 6) Výzdoba 7) Literatura (číselník) možnost vložit více záznamů k jednomu dokumentu Metadata lokalizace 1) Město (číselník) 2) Katastr (číselník) možnost vložit více údajů k jednomu dokumentu 3) Městská část (číselník) možnost vložit více údajů k jednomu dokumentu 4) Ulice (číselník) možnost vložit více údajů k jednomu dokumentu 5) Číslo popisné (možnost zadat víc ČP) 6) Číslo parcelní 7) Zobrazené veličiny mapy (číselník) - možnost vložit více údajů k jednomu dokumentu Strana 5
8) Zobrazené území mapy 9) Orientace mapy 10) Zadání lokalizace GIS (napojení na GIS server). Zobrazí se okno s mapovým podkladem s možností zadání polygonu. Po zadání se tyto údaje musí přenést jako metadata k editovanému dokumentu. Lokalizace bude zadána formou bodu, linie nebo plochy v souřadnicovém systému S-JTSK. Přílohy a skartace - příznak jestli existuje nebo neexistuje scan - pokud existuje scan, možnost vložit přílohy zdigitalizovaných dokumentů (musí být možnost tyto přílohy zadat i dodatečně k již uloženému dokumentu). - skartační znak (číselník) - skartační lhůta - datum pořízení - datum skartačního řízení Soubor dokumentů Soubor dokumentů bude obsahovat několik dílčích samostatných dokumentů, od kterých bude přebírat při založení některé vlastnosti přiřazených samostatných dokumentů. Všechny dokumenty lze zařadit do takzvaného Souboru dokumentů. Soubor dokumentů má stejné vlastnosti jako dokument s tím, že navíc obsahuje navázané dokumenty. Navázané dokumenty se vytváří automaticky při založení Souboru dokumentů. Navázané dokumenty mohou být kdykoliv přidávány nebo ubírány. Jejich počáteční počet se určí při založení Souboru dokumentů. Obsah metadat těchto nově vzniklých dokumentů se bude přebírat ze Souboru dokumentů, ke kterému jsou přiřazeny. Navázané dokumenty nemají část Hlavní identifikátor dokumentu, kterou již obsahuje Soubor dokumentů. Data metadat navázaných dokumentů mohou být rozdílná s daty v Souboru dokumentů. Vyhledávání Aplikace musí umožnit vyhledávání v metadatech dokumentů a Souborech dokumentů. Do vyhledávání musí být zahrnuty i Soubory dokumentů. Vyhledávání musí mít vazbu na GIS u zadávaného dokumentu bude k dispozici mapa Prahy, ve které půjde zakreslit polygon vymezující dotčenou oblast. Výsledná definice oblasti bude součástí metadat. Při vyhledávání bude opět k dispozici mapa Prahy s možností vytyčení prohledávané oblasti opět pomocí polygonu. Další vyhledávací parametry buď omezí vyhledané dokumenty ze zadané oblasti, nebo naopak, polygon omezí vyhledané dokumenty pouze na určitou oblast. Vyhledané dokumenty budou obsahovat náhled všech položek dokumentu ve zmenšené formě. Výsledná podoba vyhledávání musí obsahovat tyto sloupce (metadatada): - Příznak, zda-se jedná o Soubor dokumentů Strana 6
- Název dokumentu - Médium - Přírůstkové číslo URM - Signatura - Část fondu - Kód uložení Seznam vyhledaných dokumentů musí umožnit přímý přístup na dokument nebo Soubor dokumentů. Výčet minimálních parametrů pro vyhledávání: - Přírůstkové číslo URM - Příznak pro scan (do vyhledání zahrnout pouze dokumenty, které obsahují přílohy scany) - Původní přírůstkové číslo - Druh dokumentu (výběr z číselníku) - Část fondu (výběr z číselníku) - Médium (výběr z číselníku) - Kód uložení - Formát (výběr z číselníku) - Název (vyhledávat kdekoliv v obsahu) - Poznámka (vyhledávat kdekoliv v obsahu) - Účel dokumentu (výběr z číselníku) - Autor - Katastr (výběr z číselníku) - Ulice (výběr z číselníku) - Městská část (výběr z číselníku) - Číslo popisné - Číslo negativu (vyhledávat kdekoliv v obsahu) - Druh zobrazeného objektu (výběr z číselníku) - Rok - Období Od - Do - Způsob zobrazení (výběr z číselníku) Číselníky Aplikace musí umožnit přímou editaci číselníků. Z důvodu vyšší efektivity práce při vyplňování metadat dokumentů budou vytipované číselníky dynamicky doplňované přímo při editaci vlastností dokumentů. Aplikace musí umožnit správu číselníků v tomto rozsahu: - Části fondu základní rozdělení. Všechno dokumenty (Soubory dokumentů) jsou zařazeny ke konkrétní části fondu. - Autoři - DPI (rozlišení) - Druhy dokumentů (fotografie, obraz, kniha.) - Druh zobrazeného objektu (fotografie interiéru, fotografie plánu, psaný dokument, topologická mapa ) - Jazyk - Katastr - Literatura Strana 7
- Médium (Fólie, diapozitiv ) - Měřítko - Město - Městská část - Ulice - Místo vydání - Orientace mapy - Provedení vyobrazení (akvarel, inkoust, křída ) - Původce - Skartační znak - Technika vyobrazení (kresba, rukopis ) - Účel dokumentu (stavebně historický průzkum, regulační plán ) - Ulice - Země původu - Zobrazené veličiny mapy (vodstvo, správní objekty.) - Způsob dochování - Způsob zobrazení Vyskladnění kontejneru Každý dokument (Soubor dokumentů) může být vyskladněn (zápůjčka). Aplikace musí tento proces plně podporovat. Při vyskladnění kontejneru musí být proveden záznam komu a kdy byl kontejner předán. Musí obsahovat čísla dokumentů, které kontejner obsahuje a umístění kontejneru (doplní se automaticky). Uložení kontejneru Aplikace musí podporovat proces vrácení kontejneru, který byl vyskladněn. Aplikace musí zaznamenat identifikaci číslo kontejneru, kdo a kdy kontejner předal k uložení včetně následného umístění. Sestavy a tisky Aplikace musí obsahovat tyto základní sestavy. Zobrazení seznamu sestavy bude stejné jako u vyhledání. Sestavy musí umožnit přejít přímo na dokument (s vrácením na původní výsledek sestavy). Tisková sestava musí umožnit náhled před tiskem a případné uložení do formátu pdf / Excel. Výčet požadovaných sestav: - sestava Seznam nezkontrolovaných dokumentů s výběrem části fondu - sestava Seznam nekompletních dokumentů - sestava Seznam nelokalizovaných dokumentů - sestava Seznam vyhledaných dokumentů - tisková sestava Dokumenty v kontejneru s výběrem části fondu - tisková sestava Vyskladněné kontejnery - Tisk štítků (pro zvolené dokumenty (Soubory dokumentů) za zvolenou část fondu Export dokumentů Strana 8
Export dokumentů bude probíhat v definované formě pro následný import do systému Archivu MHMP a dlouhodobé zálohy. Exportovány musí být celé dokumenty, tedy datové soubory včetně metadat. Metadata pro export musí být možné definovat. Publikování na internet Součástí dodávaného řešení by měla být internetová aplikace umožňující publikovat vybrané dokumenty na internetu v upravené formě. Správa publikování jednotlivých dokumentů bude umožněna v klientské části Aplikace příznakem u jednotlivých dokumentů. Jednotlivé publikované dokumenty budou zpřístupněny formou odkazů na originální dokumenty s možností náhledu (pokud bude daný dokument obsahovat Obraz pro prezentaci). Internetová aplikace bude umožňovat vyhledávání (včetně GIS napojení) publikovaných dokumentů pro koncové uživatele. Internetová aplikace nesmí obsahovat kopie dokumentů ani jejich částí. Internetová aplikace nesmí umožnit přímý přístup externích uživatelů k databázi Aplikace nebo k rozhraní aplikačního serveru. Rozsah informací a konkrétní prezentace publikovaných dokumentů na internetu bude blíže specifikována na základě Analýzy funkčních potřeb repositáře. Nastavení práv Aplikace musí umožňovat minimálně tyto funkcionality: - Dynamicky měnit práva k jednotlivým aplikačním rolím - Přiřazovat / odebírat uživatele jednotlivým aplikačním rolím Aplikace může být napojena přímo na DNS a jednotlivé aplikační role můžou být mapovány na jednotlivé skupiny DNS. Aplikace musí umožňovat správu uživatelských účtů internetové aplikace minimálně na úroveň povolování / odebírání přístupu k internetové aplikaci. Internetové účty nebudou spravovány v DNS. Požadovaný obsah technické části nabídky používané metodiky vývoje software včetně testování používané metodiky projektového řízení předpokládaná struktura projektového týmu včetně CV všech osob, které se budou na projektu podílet návrh hardwarové infrastruktury návrh softwarové infrastruktury včetně licenční politiky dodávaného řešení (součást nabídky) samotný návrh softwarového řešení postup implementace řešení postup nasazení celého řešení návrh zálohování aplikace návrh údržby celého řešení včetně licencí po celé období trvání projektu Strana 9