Formato di pubblicazione di gruppi di documenti con meta-dati associati

Transcript

1 1 di 11 Regione Toscana Formato di pubblicazione di gruppi di documenti con Livelli di approvazione Funzione Nome Firma RTI Redazione P.L. Componente il Project Office I. Venuti Revisione P.L. Componente il Project Office R. Bonsignori Approvazione/Emissione Capo Progetto A.Rossi Livelli di approvazione Funzione Nome Firma Cliente Verifica Responsabile Tecnico di contratto G. Ugolini G. Landucci Approvazione Responsabile di Servizio Dirigente Resp. Approvazione Responsabile di contratto Dirigente Resp. LISTA DI DISTRIBUZIONE Componenti il Project Office per Regione Toscana ed R.T.I. (vedi Par. Organizzazione del Progetto del Piano di ualità)

2 2 di 11 AGGIORNAMENTI N. Paragrafi Versione Modificati Motivo della modifica /09/04 -- Prima stesura /10/ Riferimento allo scenario complessivo di uso di I.R /11/ Contesto applicativo Tool della Rete degli URP

3 3 di 11 SOMMARIO 1 INTRODUZIONE SCOPO E APPLICABILITÀ DOCUMENTI DI RIFERIMENTO SIGLE E ABBREVIAZIONI DOCUMENTI ALLEGATI FORMATO E LA MODALITÀ DI PUBBLICAZIONE PREMESSA FORMATO BUNDLE CONVENZIONI SUI VALORI DEI META-DATI QUALI META-DATI? DUBLIN CORE UN ESEMPIO APPLICATIVO COSTRUZIONE DI UN BUNDLE GESTIONE DEGLI AGGIORNAMENTI DATI DA FORNIRE A REGIONE TOSCANA UN CASO SPECIFICO: I TOOL DELLA RETE DEGLI URP...11

4 4 di 11 1 Introduzione 1.1 Scopo e applicabilità Il presente documento ha lo scopo di illustrare formato e la modalità di pubblicazione di gruppi di documenti della Rete degli URP, nell ambito della realizzazione del progetto di apri nome e nel rispetto di uanto previsto nel CAPITOLATO TECNICO ALLEGATO N. 1A al C.S.A (lotto1) per il Progetto Rete degli U.R.P., nell ambito del Piano di azione e.toscana. 1.2 Documenti di riferimento Capitolato Tecnico Progetto Rete degli URP emesso dalla Regione Toscana. Offerta tecnico-economica per il Progetto Rete degli URP prodotta dall RTI composto da: o Caribel Programmazione S.r.l., o Centrica S.r.l., o Codices S.r.l., o Pos S.r.l.. Documento Piano di Qualità del progetto Rete degli URP per la definizione dell organizzazione a la metodologia di conduzione e monitoraggio del progetto. 1.3 Sigle e abbreviazioni Back Office CART CSV E-R Front Office G.M. I.R. I.S. NAL SIL W.A. insieme delle funzioni dei Tools della Rete degli URP destinate ad essere usate dagli operatori dell URP per la predisposizione delle informazioni da pubblicare su web. Cooperazione Applicativa Regione Toscana. Comma Separated Values, formato di importazione ed esportazione dati basato su file di testo in cui le righe rappresentano i record e elencano i valori dei campi separati dal carattere virgola o altro carattere da definire. Entity Relationship, indica un diagramma che evidenzia le correlazioni tra entità di database. insieme delle funzioni dei Tools della Rete degli URP destinate ad essere usate da chi intende consultare le informazioni predisposte per il singolo URP mediante le funzioni di Back Office. Gestione Modulistica, applicativo per la definizione e la gestione della modulistica degli Enti. Information Retrieval, sistema di archiviazione e indicizzazione di documenti digitali. Invocazione metodi mediante protocollo SOAP. Nodo Applicativo Locale. Sistema Informativo Locale. Web Application. 1.4 Documenti allegati Nessuno

5 5 di 11 2 Formato e la modalità di pubblicazione 2.1 Premessa Per utilizzare le funzionalità di I.R. della Regione Toscana sono possibili tre modalità: 1. Pubblicare i dati in formato bundle in una pagina accessibile via Web; per la descrizione di uesta funzionalità si faccia riferimento al presente documento. 2. Utilizzare l interfaccia SOAP del modulo IR, come descritto nel documento Accesso ai servizi del modulo di Information Retrieval via SOAP. 3. Utilizzare la cooperazione applicativa facendo riferimento alle regole descritte nel documento Interfaccia Applicativa per l alimentazione della Rete degli U.R.P.. Questi tre scenari coprono tutti i casi di utilizzo; in particolare è possibile far indicizzare documenti senza conoscere le modalità di scambio di informazioni tra applicazioni (Web Services o altro) ma si limitano alla pubblicazione di dati in formato html (modalità 1). È anche possibile ricorrere all uso di invocazioni SOAP sincrone e far uso dell interfaccia SOAP (modalità 2) ma anche utilizzare servizi sia sincroni che asincroni e utilizzare l infrastruttura di cooperazione applicativa che di Regione Toscana (modalità 3). L ente è libero di scegliere la modalità che più soddisfa i propri bisogni e che ritiene più congeniale alla struttura delle sue applicazioni esistenti. In uesto documento viene descritto il formato e la modalità di pubblicazione di gruppi di documenti in modo tale che la piattaforma di Information Retrieval in funzione presso Regione Toscana, possa provvedere all autoalimentazione attraverso un opportuno meccanismo completamente automatico. Citeremo spesso il termine meta-dati (o, in maniera euivalente e intercambiabile, meta-informazioni). In genere, con uesti termini si descrivono informazioni che possono essere reperite dal documento/gruppo di documenti (attraverso un processo automatico di inferenza o deduzione) ma anche informazioni fornite esternamente al documento (perché il processo di inferenza o deduzione potrebbe essere costoso, ambiguo o addirittura impossibile). In uesto contesto faremo sempre riferimento a meta-dati esterni al documento ed espressi secondo un formalismo che ora andiamo a definire. I gruppi di documenti sono tali che: Possano essere raccolti in gruppi (ad esempio un atto e tutti i suoi allegati) Possano avere associati meta-dati a piacere sulle singole istanze (ad esempio meta-dati differenti per ogni allegato) Siano soggetti ad aggiornamenti periodici Il meccanismo di auto-alimentazione precedentemente citato consiste nell attivazione, da parte di Regione Toscana, di un opportuno agente software che periodicamente provvede, attraverso un azione denominata crawling, ad acuisire basi dati documentali prodotte da enti terzi distribuiti sul territorio. Lo scopo principale di tale modalità di alimentazione è uello di riuscire a disaccoppiare il più possibile l attività di produzione della documentazione da uella di acuisizione da parte di Regione Toscana in maniera da lasciare all ente una totale autonomia sia tecnica che organizzativa. Perché uesto meccanismo possa essere implementato occorre che l ente provveda a pubblicare tale documentazione in un formato prestabilito in uei casi in cui l informazione necessaria non sia contenuta totalmente nel documento ma anche in un insieme di meta-informazioni ricavate con alter modalità (ad esempio da un database).

6 6 di Formato Bundle È un insieme di documenti logicamente collegati tra loro nell ambito di un certo contesto come ad esempio un atto o un procedimento amministrativo. Nella figura precedente è mostrata la composizione di un Bundle, ovvero un gruppo di documenti che appartengono ad uno stesso gruppo. Un Bundle è composto da una collezione di package ciascuno composto da una coppia di documenti: Il documento originale in uno ualunue dei formati gestiti dalla piattaforma di Information Retrieval e/o suggeriti&imposti da Regione Toscana. Al momento sono possibili i formati HTML, TXT, DOC, RTF e PDF. Un documento di risorse in formato XML che fornisce un elenco di meta-dati e relativi valori che devono essere associati all istanza del precedente documento. La struttura del documento di risorse è la seguente: <?xml version="1.0"?> <metainfo> <meta type="documentwide" sliceid= slicename key="nome1">valore1</meta> <meta type="documentwide" sliceid= slicename key="nome2">valore2</meta>... </metainfo> type per il momento può essere solo documentwide e significa che il campo di applicazione è l intero documento. La possibilità di modificare tale dato riguarda espansioni future del sistema sliceid è il nome della sezione di indice in cui si vuole che il meta-data faccia parte. Il valore da assegnare dipende dal tipo di gestione che verrà fatto per sarà cura di Regione Toscana stabilire di volta in volta uesto dato. key è il nome del meta-dato (es. ) valorex è il valore del meta-dato (es. Procedimento amministrativo )

7 7 di 11 La struttura completa del bundle è descritta da un opportuno file denominato index in formato HTML che contiene semplicemente una lista di riferimenti ipertestuali ciascuno dei uali punta al documento originale di ciascun package. 2.3 Convenzioni sui valori dei meta-dati Anche se non ci sono restrizioni sui valori dei meta-dati (purché siano valori validi per la sintassi XML), esistono delle regole per come scriverli al fine di rendere l informazione interrogabile correttamente dal modulo di IR. Supponiamo di avere il meta-dato description ; nel caso in cui il valore che è composto da un solo termine, come Test, esso si può specificare normalmente con: <?xml version="1.0"?> <metainfo> <meta type="documentwide" sliceid= 1 key="description">test</meta> </metainfo> Se invece il suo valore è composto da più termini, come Test di valore con tanti termini, allora è necessario assegnare tutti i termini come un unica meta-informazione, ma anche ciascuno dei termini ad altrettante metainformazioni: <?xml version="1.0"?> <metainfo> <meta type="documentwide" sliceid= 1 key="description">test di valore con tanti termini</meta> <meta type="documentwide" sliceid= 1 key="description">di</meta> <meta type="documentwide" sliceid= 1 key="description">valore</meta> <meta type="documentwide" sliceid= 1 key="description">con</meta> <meta type="documentwide" sliceid= 1 key="description">tanti</meta> <meta type="documentwide" sliceid= 1 key="description">termini</meta> </metainfo> Esiste un altra convenzione, nel caso di date. In uesto caso è necessario esprimere la data nei suoi componenti, ovvero giorno, mese e anno; ecco un esempio: <?xml version="1.0"?> <metainfo> <meta type="documentwide" sliceid= 1 key="date-giorno">24</meta> <meta type="documentwide" sliceid= 1 key="date-mese">04</meta> <meta type="documentwide" sliceid= 1 key="date-anno">2004</meta> </metainfo> 2.4 Quali meta-dati? La scelta di uali meta-dati rappresentare è legata al tipo di applicazione che ne fa uso. In linea teorica ualunue applicazione potrebbe decidere un proprio insieme di meta-dati. Questo ovviamente non è consigliabile per almeno due ragioni: 1) ogni volta è necessario capire uali meta-dati trattare ed è necessario definirli; uesto processo è, normalmente, costoso in termini di tempo e risorse impiegate 2) ogni applicazione troverà difficoltà ad utilizzare meta-dati per documenti provenienti da altre applicazioni, in uanto è poco probabile che coincidano

8 8 di 11 Per minimizzare l impatto del punto 1 e risolvere il punto 2 sono nati degli standard, che definiscono un insieme di meta-dati d uso generale. Quando uesti standard non coprono tutte le esigenze applicative (magari molto specifiche) allora si integrano i meta-dati dello standard con meta-dati specifici. In uesto progetto si è scelto di utilizzare un insieme di meta-dati chiamato Dublin Core. 2.5 Dublin Core Dublin Core versione 1.1 (sito di riferimento prevede l utilizzo di 15 elementi fondamentali; essi sono disponibili, con commento in italiano, alla pagina Alla pagina è disponibile il seguente XML Schema: <xs:schema xmlns:xs=" xmlns=" targetnamespace=" elementformdefault="ualified" attributeformdefault="unualified"> <xs:annotation> <xs:documentation xml:lang="en"> Simple DC XML Schema, by Pete Johnston (p.johnston@ukoln.ac.uk), Carl Lagoze (lagoze@cs.cornell.edu), Andy Powell (a.powell@ukoln.ac.uk), Herbert Van de Sompel (hvdsomp@yahoo.com). This schema defines terms for Simple Dublin Core, i.e. the 15 elements from the namespace, with no use of encoding schemes or element refinements. Default content type for all elements is xs:string with xml:lang attribute available. Supercedes version of Amended to remove namespace declaration for namespace, and to reference lang attribute via built-in xml: namespace prefix. xs:appinfo also removed. </xs:documentation> </xs:annotation> <xs:import namespace=" schemalocation=" </xs:import> <xs:element name="title" type="elementtype"/> <xs:element name="creator" type="elementtype"/> <xs:element name="subject" type="elementtype"/> <xs:element name="description" type="elementtype"/> <xs:element name="publisher" type="elementtype"/> <xs:element name="contributor" type="elementtype"/> <xs:element name="date" type="elementtype"/> <xs:element name="type" type="elementtype"/> <xs:element name="format" type="elementtype"/> <xs:element name="identifier" type="elementtype"/> <xs:element name="source" type="elementtype"/> <xs:element name="language" type="elementtype"/> <xs:element name="relation" type="elementtype"/> <xs:element name="coverage" type="elementtype"/> <xs:element name="rights" type="elementtype"/>

9 9 di 11 <xs:group name="elementsgroup"> <xs:seuence> <xs:choice minoccurs="0" maxoccurs="unbounded"> <xs:element ref="title"/> <xs:element ref="creator"/> <xs:element ref="subject"/> <xs:element ref="description"/> <xs:element ref="publisher"/> <xs:element ref="contributor"/> <xs:element ref="date"/> <xs:element ref="type"/> <xs:element ref="format"/> <xs:element ref="identifier"/> <xs:element ref="source"/> <xs:element ref="language"/> <xs:element ref="relation"/> <xs:element ref="coverage"/> <xs:element ref="rights"/> </xs:choice> </xs:seuence> </xs:group> <xs:complextype name="elementtype"> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute ref="xml:lang" use="optional"/> </xs:extension> </xs:simplecontent> </xs:complextype> </xs:schema> Altri riferimenti: per versione italiana schema Dublin Core [con Link agli standard consigliati per la definizione e la struttura dei diversi metadati, es. per metadato tipo: dublincore.org/documents/dcm-type-vocabulary 2.6 Un esempio applicativo In tabella un esempio applicativo tratto dai Tool della rete degli URP per uanto concerne i procedimenti amministrativi. Metadato Valore CERTIFICAZIONE DI IDONEITA ALLA GUIDA DI AUTOVEICOLI E PATENTE NAUTICA ALLEGATO TECNICO IN FORMATO WORD CERTIFICAZIONE DI IDONEITA ALLA GUIDA DI AUTOVEICOLI E PATENTE NAUTICA

10 10 di 11 ALLEGATO TECNICO IN FORMATO WORD Creator Ufficio tecnico Creator Ufficio Creator Tecnico Subject Sanità Servizi per le ASL Subjetc-classe Sanità Subjetc-materia Servizi per le ASL Subjetc-materia Servizi Subjetc-materia Per Subjetc-materia Le Subjetc-materia ASL Description RILASCIO DELLA CERTIFICAZIONE DI IDONEITA Description RILASCIO Description DELLA Description CERTIFICAZIONE Description DI Description IDONEITA 13132N settore_13 sottosettore_13 classe_2 sottoclasse_n sanita_105 comune_ Date-anno 2002 Date-mese 01 Date-giorno 01 Type Testo Format application/msword Identifier Source Language IT Coverage NO Applicativo Procedimenti Si noti come sono presenti sia meta-dati dell insieme dublin core che meta-dati applicativi (in particolare essi sono Subject-classe, Subject-materia e applicativo ). 2.7 Costruzione di un Bundle Questa operazione dipende dalla modalità con cui le informazioni vengono estratte dal SIL dell ente per cui si forniscono ui solamente dei macropassi comuni a tutti i casi: Copiare in una directory accessibile dal server HTTP tutti i documenti originali che andranno a costituire il boundle. Per ogni documento del boundle creare il corrispondente file di risorse nel formato descritto e avente lo stesso nome del file originale ma con estensione.sbm. Il file di risorse deve contenere tutti i meta-dati che si intendono associare al file originale che possono essere ottenuti ad esempio consultando una base dati. Per ogni documento originale creare un riferimento ipertestuale nel documento indice. Tutti i boundle possono essere creati nella stessa directory (o in directory diverse).

11 11 di 11 Ecco un esempio di bundle: il documento indice contiene: <html> <body> <a href="bundle1.doc"></a> <a href="bundle2.txt"></a> </body> </html> mentre la struttura dei file è: /percorso/index.htm /percorso/bundle1.doc /percorso/bundle1.doc.sbm /percorso/bundle2.txt /percorso/bundle2.txt.sbm 2.8 Gestione degli aggiornamenti Poiché l alimentazione del sistema avviene tramite un meccanismo di crawling periodico che è in grado di identificare i documenti già acuisiti in una passata precedente, i boundle vecchi possono essere lasciati nella directory insieme a uelli nuovi con la garanzia che non vengano duplicati dal processo di crawling. 2.9 Dati da fornire a Regione Toscana L attività di acuisizione (crawling) viene gestita autonomamente da Regione Toscana, l unica informazione che gli enti devono provvedere è la URL corrispondente alla directory nella uale vengono creati i bundle Un caso specifico: i Tool della Rete degli URP Il formato dei bundle è applicabile in ualunue contesto e ambito applicativo. Esso è stato applicato al progetto Tool della Rete degli URP. Al fine di rendere compatibili i documenti pubblicati in tale contesto è necessario specificare l insieme dei metadati descritti nel documento Metadati e dublin core negli atti, procedimenti e nelle schede informative della Rete degli URP. Oltre ai metadati di uso generale (dublin core) esistono dei metadati specifici e legati al contesto applicativo. Il formato di pubblicazione non varia, ma è importante distinguere uattro URL diverse. Questo perché i documenti hanno due proprietà importanti che guidano dove uncerto documento deve essere presente: sono la visibilità del documento e la proprietà che indica se del documento verrà memorizzata anche una copia permanente nello store centrale (cache) oppure se, una volta indicizzato, il documento originale è reperibile solo dall url di origine (nocache). Pertanto è necessario predisporre uattro tipi di URL: Prima URL: documento privati / senza cache Seconda URL: documento privati / con cache Terzaa URL: documento pubblici / senza cache Quarta URL: documento pubblici / con cache