SPECIFICHE TECNICHE IST

Versione 2.1

Aggiornata al 24 Febbraio 2009

Via della Tecnica 18 – Tel. 0971 476311 – Fax 0971 476333 – 85100 POTENZAVia Castiglione,4 – Tel. 051 7459619 – Fax 051 7459619 – 40214 BOLOGNA

Via Lenin, 132/a – Tel. 050 89811 – 56017 San Giuliano Terme - PISAInternet http://www.publisys.it – E-mail:publisys@publisys.it

Codice Fiscale e N° Reg Imprese 00975860768 R.E.A. 73567 Iscr. Albo Nazionale N° 81 Gestione Accertamento e Riscossione dei Tributi

Specifiche tecniche di IST1 – ScopoScopo di questo documento è quello di definire le specifiche tecniche del SCI denominato IST, oggetto della variazione di contratto.

2 – Campo di applicazioneIl presente documento si applica al SCI denominato IST relativo al progetto BAS2005.

3 – Riferimenti

3.1 Documenti di Riferimento1. Manuale del Sistema Qualità: MAN2. Procedura “Il Processo Tecnico”: P-PRO_TEC3. Piano della progettazione e della qualità: BAS2005-GEST-PPRG4. Allegato tecnico dell’offerta: BAS2005-CONTR-OFF-ATEC5. Specifiche tecniche CMF: KSTAREVOL-TEC-SPEC-CMF6. Manuale Utente CMF: KSTAREVOL-TEC-MAN-CMF7. Specifiche Tecniche CMA: KSTAREVOL-TEC-SPEC-CMA8. "Quantificazione degli elementi costitutivi del sito e strumenti di qualificazione":

Documento dell'Ufficio S.I.R.S. della Regione Basilicata9. Minute delle riunioni del 12.06.2007 e del 24.07.2007.

3.2 BibliografiaN.A.

4 – Definizioni e acronimiSCI Software Configuration ItemCMA Content Management Application

5 – Specifiche TecnicheL'obiettivo del progetto è quello di realizzare su web l'area istituzionale ufficiale della Regione Basilicata. Si tratta a tutti gli effetti di implementare due siti, uno relativo al "Governo" regionale (che chiamiamo "Portale Regionale") e un altro al Consiglio. E' inoltre previsto il porting delle applicazioni delle Internet regionali, attualmente accessibili da Basilicatanet.it solo dai computer collegati alla rete interna. Il punto di partenza è dato dalle attuali implementazioni presenti sul portale Basilicatanet nella sezione "Area Istituzionale", in particolare le sottoaree:Per il Governo:

• Presidente• Giunta• Dipartimenti

1

Per la Giunta:• Consiglio Regionale

Area condivisa non accessibile dall'esterno:• Intranet Regione• Intranet Consiglio

Queste aree saranno accessibili tramite dei domini distinti (già in uso):• www.regione.basilicata.it : punto di accesso principale del progetto e indirizzo delle

funzioni del Governo • www.consiglio.basilicata.it : per l'accesso al portale del Consiglio • intranet.regione.basilicata.it : per la Intranet regionale.

E’ in corso di valutazione la possibilità di implementare la Intranet del Consiglio come una sezione del sito con accesso limitato (intranet.consiglio.basilicata.it ad esempio). A livello di sviluppo il progetto consiste nella realizzazione dei portali (d'ora in poi parliamo per comodità di "Portale Istituzionale" per indicare il punto d'accesso verso il Portale Regionale che quello del Consiglio) e nella migrazione delle applicazioni delle Intranet. Prioritario in quest'ultimo caso è migrare i sistemi basati sulla piattaforma Cold Fusion, oramai obsoleti e installati su hardware difficile da mantenere. La tecnologia su cui si baserà il progetto è Java Enterprise Edition (Java EE, ex J2EE). In particolare la soluzione per la realizzazione dei portali, inclusi i sistemi di gestione dei contenuti, è il Kaistar, il framework open source di Content Management & Delivery di Publisys.

5.1 Requisiti HW/SWDi seguito i requisiti SW di base del progetto.

• Java J2SE 1.4.x+• Server HTTP Apache HTTPD 1.3.x+• Servlet Container Jakarta Tomcat 4.1.24+• RDBMS MySQL 5.0+• Kaistar 2.4.3+• Motore di ricerca Apache Lucene 2.2

L'installazione del progetto condivide sia il SW ma soprattutto l'HW delle realizzazioni del bando in corso di realizzazione da parte di Publisys e non sono quindi necessarie delle forniture ad-hoc.

5.2 Architettura ad alto livelloA livello applicativo l'implementazione del portale istituzionale e delle intranet è caratterizzata da una classica architettura Java EE a tre livelli logici (three-tier), composti dal server web che gestisce le interazione con gli utenti, la business logic implementata mediante servlet e classi Java e i dati contenuti in un database relazionale. Questi strati logici possono fisicamente risiedere su server distinti, come nel caso del progetto in esame, o su un unico server. In dettaglio:

• Data Layer, che include il database relazionale che fa da repository per l'universo dei contenuti gestiti nel portale

• Application Layer, ovvero lo strato dove risiede la logica applicativa del sistema centrale, che nel caso in esame è completamente implementata con la tecnologia Java EE. Questo strato è composto da un insieme di applicazioni web, implementate a partire dal framework Kaistar che facilita lo sviluppo di sistemi web based in Java e offre

2

l'infrastruttura per realizzare dei portali per l'accesso a servizi e dati. Per la gestione di questo intero strato applicativo si fa uso del servlet container Java Apache Tomcat.

• Nel Front-End Layer invece risiede il server web Apache. Essendo il Front-End layer direttamente in "prima fila" verso Internet necessariamente qui saranno implementate delle efficaci politiche di security per proteggere il portale da attacchi e da intrusioni. L'architettura appena descritta può essere esemplificata nel grafico seguente.

•

A livello applicativo lo sviluppo si baserà sui più diffusi design pattern dell'architettura Java EE. Moduli software dedicati verranno sviluppati per gestire particolari aspetti realizzativi, ovvero:

• Java servlets: per gestire le interazioni tra gli utenti e il sistema• Pagine JSP: per la gestione gli aspetti di presentazione• Classi Java (POJOs/Java Beans), per modellare le entità logiche su cui operano i dati e

per implementare la logica di business, in particolare per quanto riguarda le applicazioni della Intranet.

Questo modello di sviluppo è conforme alla filosofia MVC (Model View Controller) che rappresenta lo standard nelle implementazioni Java server-side. In questo modello c'è una separazione netta tra la logica di "controllo", che gestisce l'interazione con le richieste degli utenti, la "vista", ovvero lo strato software che gestisce l'accesso ai dati e implementa le regole di business, e la "presentazione", il cui scopo è quello di gestire la visualizzazione, opportuna ed ergonomica, delle interfacce e dei dati per l'utente. Nel progetto questa scelta garantisce una buona "separazione delle responsabilità" fra i diversi tecnici che collaborano alla fase di sviluppo, favorendo il lavoro in parallelo e semplificando la successiva attività di manutenzione applicativa. A livello architetturale l'utilizzo del servlet container Apache Tomcat, di fatto lo standard per questo tipo di realizzazioni, permette di implementare un sistema estremamente scalabile che supporta meccanismi di ridondanza e fault-tolerance.

5.3 InterfacceA livello di navigazione il progetto in esame può essere acceduto da tre prospettive diverse. Ivisitatori navigheranno nel portale istituzionale a partire dalla URL www.regione.basilicata.it. Si tratta di implementare un'area nuova, attualmente non presente e che al contempo non rappresenti un duplicato di basilicatanet.it. Deve essere completamente rivolta alla comunicazione istituzionale "veloce" (news, eventi, articoli in primo piano, eventuali servizi di community) per poi rimandare alle due aree del Governo e del Consiglio, nonché ai principali

3

siti regionali (su tutti, ovviamente, basilicatanet.it). Si tratta quindi di un vero e proprio Punto d'ingresso ufficiale del Portale Istituzionale. Il Portale Regionale sarà accessibile come sotto-sezione del Portale Istituzionale (quindi sempre legato alla URL www.regione.basilicata.it). Qui saranno migrati gli spazi attualmente su Basilicatanet del Presidente, della Giunta e dei Dipartimenti. Il link all'area del Consiglio rimanderà invece alla URL specifica www.consiglio.basilicata.it. Fondamentale però è che l'insieme sia coerente dal punto di vista grafico. Queste tre aree del portale devono sembrare parte di una stessa struttura e non tre cose diverse e indipendenti tra loro. Naturalmente queste tre aree sono pubbliche, fanno perciò parte del cosiddetto Front-End del progetto. In parallelo ci sono invece i servizi di Back-End, accessibili solo tramite login/password e/o smartcard ai dipendenti regionali e ai redattori. In particolare nel back-end troviamo le due Intranet, della Regione e del Consiglio: la visibilità diquesta sezione deve essere garantita solo all'interno della Rete Regionale (eventualmente, comeora, facendo apparire ad-hoc il link specifico dalla home page del portale istituzionale o da Basilicatanet). Come ulteriore meccanismo di controllo si potrebbe permettere l'accesso alle Intranet solo agli utenti autenticati via smart-card (disponibile per tutti i dipendenti regionali). La terza funzionalità del back-end è relativa all'utilizzo del Sistema Editoriale per la gestione dei contenuti. Si tratta di una funzionalità implementata completamente tramite il Kaistar che rappresenta una base per tutte le applicazioni, sia per i portali che potenzialmente per la Intranet in cui potrebbe essere utile gestire la pubblicazione di contenuti specifici. Tutto quanto esposto finora può essere schematizzato nel grafico che segue.

Come dicevamo a livello di interfaccia utente sarà basilare garantire una forte identità e coerenza tra il punto di ingresso del Portale Istituzionale, le aree del Governo e del Consiglio. L'interfaccia utente delle Intranet può essere ottimizzata a partire dall'implementazione corrente, che è comunque già piuttosto gradevole dal punto di vista grafico. Il sistema di gestione dei contenuti si basa su un'applicazione web denominata CMA (Content Management Application),

4

le cui interfacce, generate automaticamente dal Kaistar, consentono qualche personalizzazione, benché limitata ad alcune caratteristiche di massima. Di seguito mostriamo tre schermate della CMA, nella customizzazione prevista per le scuole, del progetto attuale Publisys per la Regione.

5

A livello di interfacce applicative va ricordata la necessità di integrare le aree ad accesso controllato del portale al sistema di Identity Management federato basato su SAML 2.0, in corso di realizzazione. Da questo punto di vista quindi il portale (non la Intranet perciò, visto che è accessibile solo ai dipendenti regionali e non a chi è registrato su Basilicatanet) agirà da Service Provider, consentendo l'accesso agli eventuali servizi riservati agli utenti che sono stati riconosciuti dalla funzione Identity Provider di Basilicatanet. Resta da decidere in sede di implementazione se la gestione dei redattori della CMA conviene gestirla in autonomia (al limite legata agli accessi via smart-card dei dipendenti regionali) o se invece integrarla all'autenticazione di Basilicatanet.

5.4 FunzionalitàDescriviamo le funzionalità del progetto differenziandole per comodità di esposizione nelle due aree seguenti:

• Implementazioni per la Regioneo Portale Istituzionaleo Portale Regionale (area del Governo)o Intranet Regionale

• Implementazioni per il Consiglio Regionaleo o Portale del Consiglioo o Intranet del Consiglio.

La filosofia di fondo del progetto deve essere quella di realizzare un sito incentrato sui servizi per i cittadini e non sulla struttura burocratica. E' necessario ripensare ad un nuovo modello di navigazione del portale, prendendo anche spunto da altri portali regionali. Da questo punto di vista è necessario lavorare per dare due identità ben definite al Portale Istituzionale e a Basilicatanet. Una differenza potrebbe essere quella di lasciare in Basilicatanet i servizi

6

"orizzontali", tipici di un portale, come la Posta Elettronica, i servizi di community, etc.. Il Portale Istituzionale invece sarà il luogo deputato all'erogazione di servizi "ufficiali" verso cittadini, imprese e Pubbliche Amministrazioni, oltre che, ovviamente, lo spazio principale per gestire la comunicazione ufficiale. Per quanto riguarda la gestione dei contenuti l'obiettivo da raggiungere è assicurare l'autonomia degli uffici responsabili nell'aggiornamento delle varie aree del sito. Questa funzionalità deve avere una granularità molto fine, per permettere ad esempio a specifiche figure di gestire dei contenuti di sottosezioni (es. le aree dei dipartimenti). Dovranno essere definiti degli opportuni "workflow" da associare a singole tipologie di contenuto. Ad esempio per alcuni contenuti specifici i dipartimenti dovranno avere la possibilità di gestirli in autonomia, eventualmente definendo dei flussi di approvazione che coinvolgono solo il personale del dipartimento. Su altri contenuti invece dovrà essere possibile un processo di approvazione più complesso che coinvolge più uffici regionali. Il Kaistar supporta nativamente dei meccanismi di workflow molto sofisticati, disegnabili a piacere e che possono essere associati a singole tipologie di contenuto. Quindi questo requisito può essere soddisfatto senza problemi. Fondamentale nel progetto è poi l'attività di porting dei contenuti attualmente disponibili. Si tratta di un patrimonio informativo considerevole, memorizzato attualmente in modi diversi (file HTML, database, PDF, documenti Office), la cui attività di recupero è certamente delicata. Sarà necessario definire caso per caso delle tecniche ad-hoc, il più possibile automatizzate ma che facilitino un'eventuale fase di controllo/correzione manuale. Approfondiamo la funzionalità del progetto nei paragrafi che seguono.

5.5 Implementazioni per la Regione5.5.1 Portale IstituzionaleCome descritto nei paragrafi precedenti lo scopo di quest'area è quello di essere il punto di ingresso per eccellenza ai siti della Regione. Basilicatanet diventa quindi un portale "gemello", più orientato ai servizi per i cittadini: da qui quindi sparirebbero i link istituzionali presenti ora.Il Portale Istituzionale deve essenzialmente essere costituito da una pagina: non deve limitarsi però ad essere una semplice "splash page" ma deve presentare anche dei contenuti informativi diinteresse e costantemente aggiornati (al minimo news e calendario eventi). Da questo punto di vista un esempio assolutamente da non seguire è quello del portale della Regione Toscana cheall'indirizzo www.regione.toscana.it presenta solo un layout rigido che rimanda ai vari portali regionali. Il Portale Istituzionale va pensato quindi come uno spazio nuovo, che funga da aggregatore dei principali Portali regionali (ovviamente in primis quello del Consiglio, il portale Regionale "vero e proprio" e Basilicatanet). Per mantenerlo sempre "vivo" si può prevedere di pubblicare automaticamente in questa sua pagina i contenuti più recenti degli altri Portali Regionali. L'ottica è quella di fornire ai visitatori un'aggregazione automatica dei contenuti prodotti negli altri portali, dando molto spazio alle news e agli eventi. Lo scopo quindi è far sì che quest'area sia costantemente aggiornata senza sforzo, ricorrendo al massimo a tecniche di importazione automatica dei contenuti. I referenti regionali quindi, gestendo i contenuti dei portali di propria specifica competenza, garantiranno l'aggiornamento costante anche del Portale Istituzionale. E' importante sottolineare che lo scopo principale del Portale Istituzionale è quello di fornire un'introduzione al Portale Regionale e a quello del Consiglio: naturalmente i visitatori potranno accedere direttamente a questi due portali senza passare dal Portale Istituzionale. Quindi anche a livello grafico, fermo restando il principio di dare una coerenza e un look omogeneo al tutto, questi tre portali avranno anche una propria identità.

7

5.5.2 Portale RegionaleCome specificato nel documento di analisi dell'Ufficio SIRS [8] le aree funzionali principali checostituiscono il Portale Regionale possono essere così raggruppate:

• Sito principale • Siti dipartimentali

Fra le funzionalità individuate nel Sito Principale figurano:• Presidente: area di "Governo"• Giunta: area di "Governo"• Gli Assessori: area di "Governo". Nota bene: la URL indicata in [8] punta ad una pagina

non aggiornata. L'elenco più recente degli Assessori sembra essere quello di Basilicatanet, link "Giunta".

• Il Nucleo Regionale di Valutazione e Verifica degli Investimenti Pubblici: attualmente realizzato da un'applicazione Cold Fusion da migrare (accessibile dall'indirizzo http://www.regione.basilicata.it/nucleo/default.cfm ). Essenzialmente è un sottosito a tre livelli, le cui foglie sono documenti (es. in PDF).

• Bur-Bandi-Leggi: da implementare con un motore di ricerca. Le Leggi sono gestite su un portale esterno di Ancitel (attualmente il link sembra essere sbagliato), link esterni, Consiglio e testi coordinati in intranet.

• Sportello Europa: è un sottosito, strutturato essenzialmente a tre livelli, con molti contenuti gestiti in maniera abbastanza eterogenea tra loro. Sembrano poi esserci dei servizi (ricerche, aree ad accesso controllato,...)

• Novità: area per le news della Regione. Attualmente non gestita (la pagina www.regione.basilicata.it/novita/ è infatti vuota).

• Varie: mail, mappa, link, ...

L'area dei dipartimenti invece comprende le seguenti sottosezioni:• Presidenza della giunta• Salute, Sicurezza e Solidarietà sociale, Servizi alla persona e alla Comunità• Ambiente,Territorio, Politiche della Sostenibilità• Infrastrutture, Opere Pubbliche e Mobilità• Agricoltura, Sviluppo Rurale, Economia Montana• Attività Produttive, Politiche dell’Impresa, Innovazione Tecnologica• Formazione, Lavoro, Cultura e Sport

A tutti gli effetti l'area di un dipartimento va vista come un sito autonomo, che verrà gestito/aggiornato da specifici redattori. Ci sono varie figure, di diversi uffici, che andranno coinvolti nella riprogettazione del Portale Istituzionale, in primis i responsabili dell'URP dei vari dipartimenti. Piuttosto importante è poi l'attività di porting delle applicazioni esistenti. Si tratta di un insieme eterogeneo di web applications, realizzate nella maggior parte dei casi in Cold Fusion o come pagine ASP e che si appoggiano a database relazionali (in larga misura MS SQL Server e Oracle). L'elenco identificato in [8] comprende:

• Archivio• Rassegna stampa• Bur (internet): per questo va anche gestito il porting del servizio ad accesso controllato

(abbonamento)• Bandi• Leggi• Bur (intranet)• Consultazione decreti

8

• Consultazione delibere• Consultazione determine e disposizioni• Ricerca provvedimenti• Testi coordinati• Biblioteca della giunta• Biblioteca del consiglio• Consultazione orologio• Leggi della Regione• SIC• Protocollo informatico• Provvedimenti amministrativi• CHI E’• SRAP• SIL

Fra le nuove applicazioni sicuramente da sviluppare ci sarà anche una funzionalità per gestire l'invio delle richieste da parte dei cittadini. Una cosa simile è stata già sviluppata da Publisys per il sito del Patto con i Giovani (cfr. http://www.pattoconigiovani.basilicata.it/). Si veda a riguardo anche la descrizione delle funzionalità di e-democracy del portale del Consiglio.

L'albero di navigazione del nuovo Portale RegionaleSi propone di seguito un modello di razionalizzazione dei contenuti attuali del Portale Regionale./root

/Area Istituzionale/Il Presidente/La Giunta/Contatti

/I Dipartimenti/Presidenza della giunta/Salute, Sicurezza e Solidarietà sociale, Servizi alla persona e alla Comunità/Ambiente,Territorio, Politiche della Sostenibilità/Infrastrutture, Opere Pubbliche e Mobilità/Agricoltura, Sviluppo Rurale, Economia Montana/Attività Produttive, Politiche dell’Impresa, Innovazione Tecnologica/Formazione, Lavoro, Cultura e Sport

/I Servizi (Nota Bene: va trovato un nome più adatto)/Il Nucleo Regionale di Valutazione/Bur/Bandi/Leggi/Sportello Europa/Varie (mappa, link,....)

/News/Calendario Eventi

9

5.5.3 Intranet RegionaleLa Intranet è attualmente una raccolta di link a:

• Applicazioni interne, comprese quelle da migrare descritte sopra • Pagine/Documenti statici • Siti esterni.

E' stata sviluppata come pagine ASP. Ove possibile si può pensare di mantenere alcune delle applicazioni esistenti. Sicuramente ogni funzionalità basata su Cold Fusion dovrà però essere migrata. Sarà pertanto necessario analizzare con i referenti regionali quali applicazioni mantenere allo stato attuale, quali riscrivere o quali eventualmente eliminare.

5.6 Implementazioni per il Consiglio Regionale5.6.1 Portale del ConsiglioIl sito del Consiglio è attualmente molto ricco di contenuti e servizi ma appare strutturato in tanti livelli e sezioni che possono confondere un utente alla prima visita. E' consigliabile quindi pensare ad una nuova organizzazione delle informazioni pubblicate, al fine di rendere più immediata la navigazione. Come indicato nel paragrafo precedente proponiamo di considerare il portale del Consiglio totalmente "calato" nel resto del portale Istituzionale. Ci saranno degli elementi fortemente distintivi, ma il concetto fondamentale deve essere quello dell'omogeneità grafica del tutto. Le funzionalità che dovranno essere accessibili dal sito del Consiglio sono:

• Area URP e Guida agli Uffici• L'area dei Consiglieri (intesa come assemblea con commissioni, gruppi consiliari,

attività, , etc.)• L’Assemblea Regionale (Attività, Organismi, Commissioni, Resoconti, etc.)• L'archivio documentale (Iter dei provvedimenti)• Leggi• Organi Consultivi e di Partecipazione• Annuario• Sezione Cultura• Agenzia Informa• Le pubblicazioni (incluso il Consiglio Informa, etc.)• L'archivio multimediale e l'accesso alle dirette web• Strumenti di E-democracy

Un'ulteriore richiesta del Consiglio è quella di gestire i siti dei Gruppi Consiliari. Descriviamo nel seguito queste funzionalità. Importante sarà poi nel progetto razionalizzare le informazioni presenti sul sito del Consiglio. Il sito infatti contiene una grande quantità di informazioni nelle varie sezioni, spesso assai simili come natura. Alla fine del paragrafo proviamo quindi a proporre una possibile ipotesi di razionalizzazione, producendo un esempio di albero di navigazione.

Area URP e Guida degli UfficiSi tratta di strutturare le informazioni attuali per fornire indicazioni sui responsabili dei vari settori del Consiglio. Particolarmente delicata è l'area dell'URP, che include attualmente un insieme eterogeneo di servizi: informativi, contatti, materiale divulgativo da scaricare. (Pubblicazione Consulenze e Collaborazioni)

L'area dei Consiglieri RegionaliUna prima area di intervento riguarda le informazioni da pubblicare per ogni consigliere regionale. Una fonte di ispirazione in questo senso è data dall'organizzazione attuale della Camera dei Deputati. Per ogni Consigliere bisognerà pubblicare:

10

• Dati personali• Retribuzione dettagliata (divisa nell'elenco delle voci)• Incarichi in consiglio• Iniziative che lo vedono protagonista: proposte di legge, etc..• Contatto: es. sito web (se esiste), email, telefono, etc..• Statistiche sulle presenze: questo può essere organizzato in modo analitico (indicando

tante "entry" per ogni presenza/assenza) o sintetico, mantenendo aggiornato cioè solo il totale delle presenze e delle assenze.

La retribuzione deve essere modellata essa stessa come "contenuto" con i vari attributi dati dallesingole voci economiche che la compongono. Un "plus" del sistema sarebbe quello di gestire la storicizzazione dei consiglieri, associandoli alle varie legislature e/o al periodo in cui sono stati in carica. Questo deve essere fatto tenendo presente che:

• Un consigliere può essere eletto per più legislature• Viceversa un consigliere potrebbe non essere più rieletto• Le voci che compongono la retribuzione potrebbero cambiare nel tempo. Questo

potrebbe causare un problema per i consiglieri "storici" non più rieletti.Deve essere poi possibile gestire l'associazione tra il membro del consiglio e un suo eventualeruolo/incarico (es. Presidente, Vice Presidente, Consigliere Segretario, ...), dando anche la possibilità di storicizzare questa relazione. A livello di tempistiche questa deve essere la prima realizzazione da implementare, in quanto per obblighi di legge i dati dei consiglieri devono essere pubblicati entro fine anno. Considerando i tempi necessari per fare training sulla CMA, nonché quelli specifici per l'inserimento dei dati ne segue che questa funzionalità deve essere disponibile entro novembre.

Integrazione con archivio documentaleAttualmente il Consiglio usa un sistema per la gestione dei flussi documentali (atti, delibere, etc.) basato sul software Pegasus dell'azienda Euro Sistemi. I documenti sono scannerizzati e vengono conservati nel sistema sotto forma di file TIFF e PDF. Si vuole gestire la pubblicazione sul sito di questi documenti. A tale scopo sarà necessario implementare una procedura che consenta l'esportazione dei documenti e dei metadati che li accompagnano dal sistema Pegasus e la successiva re-importazione nella piattaforma di Content Management con cui verrà gestito il sito del Consiglio. Indispensabile per il raggiungimento di questo obiettivo è:

• definire un mapping corretto tra i metadati di Pegasus e quelli della piattaforma di content management del sito. Ad esempio deve essere possibile identificare i consiglieri coinvolti in un certo atto: quindi il modo di identificarli in Pegasus deve essere "comprensibile" dalla piattaforma di gestione del sito

• gestire in automatico la conversione dei documenti in formato TIFF in un formato più Internetfriendly (es. PDF).

Si deve dare poi la possibilità di fare ricerche sui metadati (i documenti sono nella maggior parte dei casi delle semplici immagini). In seguito ad un'analisi del software Pegasus si è visto che il sistema si basa su un database abbastanza semplice, formato da poche tabelle con una struttura molto intuitiva. I documenti sono gestiti come file sul server: per ogni documento c'è una "tripletta" di file con estensione .idx, .dat e .000. I file del primo tipo sembrano essere di tipo binario. Il .dat contiene dei dati di indice, in formato testuale, facilmente interpretabile. Il .000 è il file stesso e può essere un TIFF o un PDF. Normalmente solo questi due formati vengono usati sebbene il sistema possa teoricamente gestire file in qualsivoglia formato. A livello di "metadati" associati ai vari documenti prodotti c'è sempre l'identificazione del proponente e del destinatario. Come proponente è indicato il nome (o i nomi) dei politici coinvolti. Non c'è al momento una standardizzazione nel modo in cui sono indicati i nomi: di

11

norma vengono scritti con il cognome e l'iniziale del nome seguita da un punto, ma spesso vengono inseriti in modo diverso. Va quindi gestita con attenzione nella fase di importazione sul sistema di content management l'identificazione del/dei proponente/i, eventualmente azionando una procedura di scarto da gestire manualmente qualora non sia facile riconoscere la/le persona/e interessata/e. Nel campo destinatario è normalmente indicata la figura istituzionale (es. Presidente del Consiglio Regionale) e non un "nome proprio". Nel sistema sono stati finora registrati oltre 1.300 documenti (atti, delibere, etc.) da maggio 2005. Si stima quindi che il numero di documenti da gestire sia pari a circa 600 – 1.000 all'anno. Al momento l'inserimento dei documenti è sempre eseguito mentre non viene gestito sempre l'aggiornamento dell'iter associato In caso di modifica di un documento (ad. esempio se sono proposte nel corso dell'iter degli emendamenti) al momento si è deciso di lasciare sempre il file originale e di aggiungere(rinominandolo ad esempio con suffisso "bis") la sua versione aggiornata.

Leggi e ResocontiVa riorganizzata la sezione delle Leggi, integrandola con un motore di ricerca che consenta ilreperimento dell'atto secondo vari criteri (data di emissione, tipo, parole chiave, etc.). Utili all’indirizzo possono essere i metadati inseriti per norme in rete.

Organi Consultivi e di PartecipazioneLogicamente queste aree devono essere gestire come dei minisiti indipendenti, delegando completamente alle persone degli organi la gestione dei contenuti. Per ognuna di queste aree è possibile definire una struttura ad-hoc sebbene è consigliabile, anche in ottica di razionalizzazione, definire una certa standardizzazione. Da una prima analisi i contenuti che potrebbero essere qui pubblicati sono:

• Articolo: testo generico con possibilità di allegare foto e URL (cfr. Contenuti Informativi del paragrafo 5.7)

• URL: con titolo, descrizione e indirizzo • News: con testo, foto e URL• Attività

AnnuarioE' possibile pensare ad una reingegnerizzazione del servizio Annuario, in modo da costruire automaticamente e in tempo reale (o per motivi di efficienza con una frequenza giornaliera) i file PDF sia dell'annuario generale che delle varie singole tipologie, usando una veste graficapersonalizzabile.

Agenzia Informa Le funzionalità attuali di quest'area, in cui sono pubblicate notizie condivise con Basilicatanet, sono ritenute soddisfacenti. Si tratta solo di gestire la riorganizzazione grafica nell'ambito dellaristrutturazione complessiva del sito regionale.

Pubblicazioni (versione audio)Il consiglio ha una gran quantità di pubblicazioni, attualmente accessibili sotto varie sezioni (Pubblicazioni, Rivista BRN, Mondo Basilicata). Anche in questo caso si potrebbe pensare di raccoglierle in un'unica area, a sua volta suddivisa in varie sottoaree, una per ogni tipologia dipubblicazione. Essendo basate su file PDF si propone anche la loro indicizzazione con un motore di ricerca per consentire un più efficace reperimento delle informazioni.

Archivio multimediale e accesso a dirette web (Galleria Fotografica)

12

Il consiglio ha un archivio fotografico di grande valore. Si propone la definizione di uno spaziomultimediale nell'area del consiglio (o ad un livello superiore di navigazione, cioè nel PortaleIstituzionale) per pubblicare queste foto. Per quanto riguarda le dirette web è attualmente in fase di studio una possibilità di acquisire e storicizzare i video delle sedute del consiglio. Nel portale andrà integrata un'area per permetterne la visualizzazione: possibilmente si dovrà consentire anche la pubblicazione dei verbali dattiloscritti del consiglio (al solito con possibilità di ricerca full text).

Strumenti di e-democracyAndranno implementati degli strumenti di e-democracy nell'area del consiglio e più in generale nel portale regionale, prendendo come esempio delle iniziative di altri enti pubblici italiani, come il progetto Partecipa.net dell'Emilia Romagna. Al minimo dovranno essere implementanti:

• Strumenti di contatto: fornire dei canali (web, SMS, email) per informare i cittadini. Si può pensare a delle newsletter tematiche multicanale. Specularmente dovranno essere realizzati dei sistemi che facilitino la comunicazione tra l'utente e la Regione.

• Strumenti di partecipazione: a tale proposito saranno attivati forum tematici. Per garantire il successo dell'iniziativa fondamentale sarà individuare una figura di moderazione/incoraggiamento, che stimoli quindi la partecipazione dei cittadini al forum web.

• Strumenti di consultazione: oltre al forum verranno realizzati dei Poll, con un minimo di meccanismi antifrodo (minimo perché questi sistemi non sono esenti da falle a meno di non utilizzare delle forti restrizioni nel loro uso). Per quanto non perfetti dal punto di vista statistico forniranno comunque un utile indicatore degli umori e delle posizioni dei cittadini della Basilicata.

Siti degli editori lucaniIl Consiglio ha necessità di garantire uno spazio di visibilità agli editori lucani. Si propone diagganciare tramite appositi link i siti realizzati e/o in corso di realizzazione da parte dei vari editori lucani

L'albero di navigazione del nuovo sito del ConsiglioSi propone di seguito un modello di razionalizzazione dei contenuti attuali del sito del ConsiglioRegionale.

13

14

5.6.2 Intranet del ConsiglioVa anche reingegnerizzata l'area Intranet del Consiglio. Dovranno essere effettuati dei controlli rigidi per consentire l'accesso solo alle persone del Consiglio. Attualmente i servizi forniti sono molto semplici: a livello funzionale potrà essere organizzata, come nel caso della Intranet della Regione, come:

• Una suddivisione per aree tematiche• In ogni area sono raccolti dei link a siti/servizi o sarà possibile fare il download di

documenti.In entrambi i casi sarà predisposta una pagina testuale, gestita tramite il sistema editoriale, incui viene presentato il servizio e/o i documenti scaricabili. Per servizi specifici esistenti potrà essere realizzato, se necessario, un porting applicativo sulla nuova piattaforma.

5.7 Definizione dei datiI dati principali del progetto sono costituiti principalmente da contenuti. Nell'esposizione che segue li dividiamo in cinque tipologie principali: istituzionali, informativi, news, eventi ed immagini.

15

Contenuti IstituzionaliSono usati per fornire informazioni sulle attività della Regione. La struttura del contenuto (oltre la data del documento) è la seguente:

Titolo [property: CNT_TITLE] Sottotitolo [property: CNT_VALUE] Testo [property: CNT_SUMMARY] Allegati [componente: ATTACHMENT] Immagini [componente: IMAGE_DETAIL, IMAGE_PREVIEW] Link [componente: URI].

Contenuti InformativiHanno un taglio principalmente giornalistico. La struttura del contenuto è la seguente:

Titolo [property: CNT_TITLE] Sottotitolo [property: CNT_VALUE] Testo [property: CNT_SUMMARY] Allegati [componente: ATTACHMENT] Immagini [componente: IMAGE_DETAIL, IMAGE_PREVIEW] Link [componente: URI].

News La struttura del contenuto è la seguente: Data [CNT_ISSUEDATE] Titolo [CNT_TITLE] Sottotitolo [CNT_VALUE] Testo [CNT_SUMMARY] Immagini [componente: IMAGE_DETAIL, IMAGE_PREVIEW] Link [componente: URI].

Eventi La struttura del contenuto è la seguente: Data [CNT_ISSUEDATE] Titolo [CNT_TITLE] Sottotitolo [CNT_VALUE] Testo [CNT_SUMMARY] Immagini [componente: IMAGE_DETAIL, IMAGE_PREVIEW] Link [componente: URI].

ImmaginiServono per gestire l'archivio fotografico del Consiglio. La struttura del contenuto è la seguente:

Data [CNT_ISSUEDATE] Titolo [CNT_TITLE] Commento [CNT_SUMMARY] Immagine [componente: IMAGE_DETAIL, IMAGE_PREVIEW].

5.7.1 Contenuti specifici per il Portale del ConsiglioParticolare attenzione sarà rivolta nel Portale del Consiglio a definire i contenuti relativi ai Consiglieri. Questo perché è necessario definire per essi un insieme molto ricco di dati, alcuni testuali, altri più propriamente "scalari". Una prima ipotesi per definire i dati dei Consiglieri è la seguente:

16

• Cognome• Nome• Luogo di nascita• Data di nascita• Lista di Elezione (tassonomia: scelta da lista predefinita)• Gruppo Consiliare (Relazione)• Ruolo (Relazione)• Curriculum: testo libero• Attività legislativa• Mail• URL del proprio sito web (se esiste)• Telefono• Fax• Retribuzione (Relazione)• Stato: attivo, sospeso, dimissionario, deceduto...

Il Gruppo Consiliare, il Ruolo e la Retribuzione sono definite come "Relazioni" del Kaistar. Questo permette di gestire la "storicizzazione", ovvero tener traccia di eventuali cambiamenti che riguardano il Consigliere nel tempo. Definire la Retribuzione come Relazione è particolarmente comodo qualora i dati che la compongono siano gli stessi per più Consiglieri. Se invece ogni Consigliere ha alla fine dei dati diversi dai suoi colleghi si può scegliere una strategia per inserire in modo assai più semplice queste informazioni. Dalla pagina del Consigliere deve essere possibile visualizzare la lista delle leggi e delle iniziative da lui proposte. A tale scopo si può sfruttare l'integrazione con il sistema documentale del Consiglio. Come indicato però nel paragrafo 5.6.1 questo aggancio rischia di essere un po' debole, in quanto:

• Si deve usare per forza il cognome/nome del consigliere per gestire il collegamento. Non sempre questo dato è però scritto in modo corretto o in forma standard nel Sistema Documentale. C'è quindi il rischio che non sempre l'associazione sia possibile.

• La gestione dell'iter non è attualmente sempre tracciata nel Sistema Documentale e quindi non sempre si avranno informazioni dettagliate nel sito.

Infine è richiesta la pubblicazione delle Presenze del Consigliere. Non è ancora chiaro come questi dati possano essere inseriti (ad esempio se devono essere immessi a mano o se possono essere importati da un'applicazione esterna già esistente). In entrambi casi la piattaforma di Content Management può essere in grado di gestire tali informazioni e associarle ai Consiglieri tramite l’Ufficio che provvederà a registrare i dati.

5.7.2 Attori nella gestione dei contenuti del PortaleNel diagramma che segue mostriamo lo scenario di gestione dei contenuti nei nuovi portali.

17

Essenzialmente ci saranno tre tipologie di attori:• gli editori, che curano gli aspetti giornalistici dei siti. Lavorano indifferentemente nelle

aree della Regione e in quelle del Consiglio. • gli operatori della Regione, compresi coloro che avranno diritto a gestire solo una

specifica parte del Portale Regionale (ad esempio i referenti che aggiorneranno solo i siti dei vari Dipartimenti)

• gli operatori del Consiglio, anche in questo caso inclusi coloro che potranno gestire solo determinate parti del Portale del Consiglio (ad esempio i referenti dei vari Organi Consultivi).

Il sistema di gestione dei contenuti basato sul Kaistar consente di implementare delle logiche diworkflow e di gestione dei permessi molto sofisticate, al fine di definire con esattezza i diritti dei vari editori e la tipologia dei contenuti che potranno gestire. E' possibile inoltre prevedere delle logiche di approvazione esplicita, in cui (come mostrato nel diagramma di cui sopra), il lavoro di un redattore potrà andare in linea solo dopo l'OK esplicito di un supervisore.

5.8 Gestione dell'importazione dei contenutiI due portali della Regione e del Consiglio gestiscono attualmente una ricca mole di contenuti che deve essere necessariamente conservata nel nuovo sito. Ciò implica la necessità di effettuare un porting dei contenuti presenti ed un eventuale loro adattamento al fine di ottimizzare la presentazione grafica sul nuovo sito. Nei sistemi in linea ora i contenuti sono mantenuti in modo eterogeneo, ovvero:

• gestiti su file system • contenuti in Database relazionali (tipicamente su Microsoft SQL Server e Oracle)

18

A livello di tipologia, i contenuti sono costituiti da:• file HTML, che comprendono già la formattazione grafica• file "allegati", tipicamente file Word o PDF • immagini, loghi, etc.

Difforme è anche l'albero di navigazione delle varie sezioni del portale. Date tutte queste differenze non sarà possibile definire una strategia unica per importare i contenuti esistenti e bisognerà analizzare nel dettaglio caso per caso, cercando al contempo di minimizzare la necessità dell'intervento umano. Alcune delle strategie possibili saranno:

• esportazione dai database, ripulitura dei dati e caricamento nel sistema di gestione dei contenuti (CMA). Si tratta in questo caso di applicare una tecnica ETL - Extract, Transform, Load.

• copia di file system, pulitura automatica dei file e caricamento nella CMA • realizzazione di script per navigare parte dei siti esistenti, estrarne i contenuti e caricarli

nella CMA (Web Crawling) • per i file HTML verranno usati tool automatici (es. Tidy) per ripulire i tag che possono

compromettere una buona presentazione della pagina nella nuova grafica del sito.

5.9 Dettaglio economico

5.10 Requisiti di installazione e di accettazioneDa definire nel documento BAS2005-TEC-INST (documento interno Publisys conforme al Sistema di Qualità ISO9001:2000 aziendale).

5.11 Documentazione utenteDa definire nel documento BAS2005-TEC-MAN (documento interno Publisys conforme al Sistema di Qualità ISO9001:2000 aziendale).

19

6 – Allegato: la piattaforma KaistarVisto che un'area importante del progetto riguarda il Portale del Consiglio regionale si è deciso di allegare di seguito un inquadramento del Kaistar, principalmente enfatizzato sugli aspetti di gestione dei contenuti, in modo da presentare compiutamente ai responsabili del Consiglio le funzionalità che si andranno a realizzare. Publisys ha sviluppato nell’arco di circa otto anni una profonda competenza sulle problematiche della gestione e dell’erogazione dei contenuti e servizi attraverso il web. Le esperienze maturate in progetti industriali, molti dei quali realizzati per i più importanti gruppi editoriali italiani, nonché la partecipazione a progetti di ricerca, a livello europeo e nazionale, ha posto le basi per la creazione del Kstar (K*), un’architettura solida e matura per la gestione di siti web per l'erogazione di contenuti e servizi, che costituisce l’infrastruttura tecnologica e applicativa della soluzione proposta. Parallelamente alla realizzazione ed al deployment di soluzioni basate sul K*, anche sulla base delle spinte provenienti dalla maggior parte dei clienti nel settore della Pubblica Amministrazione, Publisys ha maturato una decisa scelta nella direzione del mondo open-source, riconoscendo epromuovendo il valore, la maturità e i vantaggi di soluzioni aperte. Si situa in questo senso la scelta, operata nel 2005, di rilasciare con licenza GPL versione 2, il nucleo di base del K*, sotto il nome di Kaistar (la prima parte del nome deriva da una parola giapponese che significa “aprire”, “aperto”, “schiuso”; la seconda ha un’evidente assonanza con l’originale K*), che arricchisce la già florida comunità open con una piattaforma innovativa per la creazione automatica di applicazioni a supporto della produzione, gestione, integrazione, distribuzione e pubblicazione multicanale di contenuti e servizi. Il sito web del progetto è www.kaistar.org. Kaistar fornisce un insieme di servizi per l’integrazione e la gestione dell’informazione, sia essafornita in formato strutturato o in formato documentale, e per la pubblicazione su Internet e Intranet. Su questo set di funzionalità vengono realizzate le specifiche applicazioni. La separazione architetturale tra i servizi di base e le applicazioni che le utilizzano consente la massima flessibilità del sistema informativo, abilitando l’integrazione dei sistemi esistenti e l’evoluzione verso nuove funzionalità.

Sull’infrastruttura di base di Kaistar vengono aggiunti moduli specifici, realizzati da Publisys o di terze parti, in base alle esigenze applicative dell’Amministrazione.

20

La caratteristica principale del Kaistar è la sua estrema flessibilità nel gestire le più svariate situazioni di produzione di contenuti. L’architettura si basa infatti sull’uso di metadati che permettono di descrivere le informazioni da pubblicare, gli utenti del sistema e i ruoli che essi possono assumere nonché i flussi di creazione e pubblicazione del contenuto (workflow). Basandosi solo sull’interpretazione di questi metadati il Kaistar fornisce automaticamente (ovvero senza la necessità di scrivere codice) una completa applicazione di “back-office” (CMA), che permette agli editor di gestire immediatamente tutte le informazioni del portale. Con altrettanta facilità il Kaistar si adatta alle evoluzioni dei bisogni del cliente: un nuovo contenuto, una modifica ad un tipo esistente, la definizione di nuovi utenti e nuovi ruoli vengono realizzati impostando opportunamente i metadati e sono immediatamente “recepiti” dal sistema. Vale la pena di sottolineare che nella programmazione dei sistemi di back-office viene di norma speso il 60%-70% del lavoro complessivo di un tipico progetto di Content Management. Questo fa capire quanto è significativo l’impatto del Kaistar nell’abbattere i costi e i tempi di delivery della soluzione. Tuttavia, le caratteristiche evolute del Kaistar non sono limitate al “back-office”: sul lato “front-office” viene fornito un sofisticato servizio di caching, che permette di limitare l’esecuzione di operazioni onerose - es. l’accesso ad un database - riducendo così drasticamente i tempi di risposta complessivi. Le tecnologie utilizzate, e specificatamene la piattaforma J2EE, sono state scelte per garantire un’elevata scalabilità e, nel contempo, consentire una facile integrazione con prodotti di mercato che possono risultare necessari per verticalizzazioni spinte. Tecnicamente Kaistar supporta tutte le piattaforme di Web Application Server che aderiscono allo standard Java Servlet. In particolare fra le diverse soluzioni disponibili sul mercato quella basata sull’integrazione del Web Server Apache con il servlet container Tomcat è da tempo alla base del funzionamento dei maggiori portali realizzati

21

da Publisys. Questa soluzione, nata e sviluppatasi nell’ambito di uno dei progetti Open Source di maggiore successo (http://www.apache.org), ha raggiunto ormai da tempo un'elevata maturità di prodotto sia in termini di performance che di stabilità. Tra le caratteristiche da menzionare, quelle di maggior rilievo sono l’estrema flessibilità d’uso e la sua dinamica evoluzione, che ne permette il continuo aggiornamento soprattutto in termini tecnologici. Grazie inoltre ad uno strato di “astrazione” verso le fonti dati (data layer) il Kaistar è completamentecompatibile con diversi database, fra cui, ad esempio Oracle e MySQL. Logicamente un sistema Kaistar è organizzato nelle seguenti componenti:

• Content Management Application (CMA): per l’inserimento e la manutenzione dei conteuti

• Content Repository: per lo storage ed il retrieval dei dati• Interfacce verso fonti date esterne ed applicazioni legacy• Content Delivery Application (CDA): per l’erogazione dei contenuti e applicazioni

Il nucleo del sistema è dato dal Repository che ospita i contenuti ed i relativi metadati secondo la struttura ed i formati richiesti dalle applicazioni. Il repository costituisce una “libreria di contenuti digitali” che funge da unico punto di raccolta di tutte le informazioni, e da unico punto di distribuzione ai diversi sistemi che fruiranno delle informazioni. I contenuti del repository sono gestiti tramite una Content Management Application (CMA) che consente di inserire, modificare e cancellare i contenuti, nonché annotarli con metadati che ne massimizzino le possibilità di ricerca e di navigazione ipertestuale. Al repository attingono una o più Content Delivery Application (CDA) che estraggono le informazioni e, dopo averle opportunamente trasformate nel formato desiderato (rendering), provvedono alla loro diffusione sui diversi canali di distribuzione (publishing).

La principale caratteristica di tale architettura è il disaccoppiamento tra la fase di raccolta, catalogazione e amministrazione delle informazioni e la fase di diffusione delle stesse (distribuzione o pubblicazione).

Il Kaistar è poi dotato di moduli accessori che implementano particolari funzionalità (es. il supporto all'e-commerce).

22

Content RepositoryIl modello dei contenutiKaistar si fonda su una base di dati relazionale caratterizzata da un modello dei contenuti estremamente flessibile. Tramite una semplice opera di configurazione, è possibile definire rapidamente uno o più repository di contenuti digitali eterogenei per conformarsi ai diversi requisiti applicativi di ogni specifico progetto. A seguito della configurazione del repository, Kaistar genera automaticamente un’applicazione di content management web-based che fornisce un immediato accesso alle funzionalità amministrative ed editoriali, consentendo di cominciare a popolare da subito il sistema. In alternativa i contenuti possono essere facilmente aggregati da basi di dati esistenti tramite un meccanismo di feed basato su XML.

Il Content Repository di Kaistar è caratterizzato da uno schema estremamente flessibile che tramite una semplice opera di configurazione consente di definire nuovi tipi di contenuto e, successivamente, di modificarne arbitrariamente la struttura. L’applicazione di Content Management è automaticamente generata. Tutto ciò si traduce in tempi ridotti di realizzazione dei progetti e in una forte riduzione dei costi di gestione.

Gli elementi di base del modello applicato da Kaistar sono gli oggetti, item informativi elementari o strutturati, di tipo diverso (testo, immagini, documenti) che, come le componenti di un Lego, concorrono nella definizione di strutture più complesse. I contenuti sono tipicamente entità strutturate caratterizzate da un insieme di metadati (ad es. la data di creazione/revisione/pubblicazione, l’autore, la lingua, le keywords, ecc…) e da una parte informativa tipicamente costituita da una gerarchia di oggetti (content items). Rispetto ad un semplice oggetto, un contenuto rappresenta un’entità “completa” (dal punto di vista dell’informazione che contiene) ed “autonoma”, ovvero dotata di un proprio ciclo di vita (creazione, approvazione, pubblicazione, archiviazione, ecc…). Un contenuto può concorrere alla creazione di diverse pubblicazioni ed essere oggetto di syndication (ovvero distribuito ad una terza parte). Il sistema consente di definire e gestire contenuti compositi ottenuti per aggregazione di contenuti più semplici, ognuno dotato dei propri metadati e di un ciclo di vita indipendente. In questo modo il sistema consente di realizzare strutture arbitrariamente complesse. Tecnicamente il meta-modello di Kaistar è costituito dalle seguenti entità:

• Alla base stanno le generiche “entità informative” denominate oggetti (objects).• Un oggetto è individuato da un tipo (object type) e da un identificatore unico (id).• Un object type è caratterizzato da un ben definito insieme di proprietà (properties)

ognuna delle quali è un attributo elementare (non dotato di struttura) riconducibile a un tipo di dato base (ad es. intero, decimale, stringa, data, file, etc.).

Ad esempio, è possibile definire il tipo “Articolo” caratterizzato dalle proprietà “Titolo”, “Autore”, “Data”, ecc…, ed il tipo “Paragrafo” con un’unica proprietà “Testo”.

• Un object type può intervenire nella definizione di relazioni di composizione con altri object type (object type components), dando così luogo a strutture gerarchiche. Per ciascuna componente è definita la molteplicità, ovvero il numero di istanze di oggetti associabili per mezzo di questa componente.

Ad esempio, per specificare che ogni paragrafo può avere un’immagine ed un insieme di linkdi approfondimento è sufficiente assegnare al tipo “Paragrafo” una componente singola“Immagine” ed una componente multipla “Link”. Analogamente è possibile associare una listadi “Paragrafi” ad un “Articolo”.

23

• Su un object type è possibile definire una o più tassonomie (object type taxonomies) che determinano le categorie con cui classificare gli oggetti.

In questo modo è possibile specificare che tutti gli oggetti di tipo “Articolo” possono essereclassificati rispetto alla tassonomia “Argomenti” (ad es. “normative”, “finanziamenti”,“ambiente”, ecc…) e rispetto alla tassonomia “Provincia” (ad es. “Cagliari”, “Nuoro”).

• Ad un object type è possibile associare degli specifici servizi (object type services) quali ad esempio il workflow, il locking (check-in/check-out) e l’auditing.

In questo modo è possibile definire diversi tipi di workflow di approvazione, in base al tipo dioggetto, e decidere quali oggetti sono sottoposti ad auditing e quali no. La libreria dei building-block.Kaistar è rilasciato con una libreria di object type general-purpose, da utilizzare come building block per la costruzione delle applicazioni.

• Content. È l’object type principale che racchiude tutti i dati caratteristici di un qualsiasi contenuto ed i meta-dati necessari per supportare i meccanismi di pubblicazione: il titolo, l’autore, una descrizione, l’abstract, la lingua, le keyword, le date di creazione, pubblicazione e la durata del periodo di validità, la priorità, ecc..

• Text. Un generico frammento di testo, eventualmente arricchito con tag di formattazione (es. HTML, XML, ecc…). Nel caso HTML la redazione dei testi avviene in una finestra WYSIWYG dotata di toolbar che permette ai redattori di passare senza difficoltà dall’utilizzo di strumenti come MSWord a Kaistar.

• Uri. Utilizzato per memorizzare un Uniform Resource Identifier (ad esempio una URL) è caratterizzato da un protocollo e da un indirizzo.

• Link. È possibile definire link logici, ad altri contenuti del repository, e link fisici (delle URI). È possibile decidere la modalità di apertura del link (nella pagina o in un popup).

• Upload. Consente di memorizzare sul repository uno stream di dati corrispondente al contenuto di un file. Fisicamente i dati vengono memorizzati sul repository in un campo BLOB e distribuiti, tramite un meccanismo di code, su tutti i file system dei server di front-end (deploy).

• Image. Oltre ad indicare il file che contiene l’immagine è possibile specificare ulteriori informazioni, ad es. il ridimensionamento orizzontale e verticale (rescaling), l’allineamento e quant’altro possa comportare la necessità di predisporre un rendering specifico dell’oggetto riferito (si noti come tali informazioni non si riferiscano a caratteristiche proprie dell’oggetto ma sono piuttosto relative alla modalità ed al contesto in cui esso deve essere presentato). È inoltre possibile associare allo stesso oggetto versioni alternative della stessa immagine (alta risoluzione, bassa risoluzione, thumbnail). La libreria di building-block è adeguata ai requisiti delle più comuni applicazioni di content management. Tuttavia il sistema è modulare e si presta all’implementazione di nuovi e object-type (solo in tal caso si renderà necessario l’intervento di un programmatore).

Integrazione di flussi e repository esterniL’integrazione di Kaistar con le informazioni presenti sui sistemi esterni avviene tramite un sistema di feed che consente di importare in modo automatico flussi di dati all’interno del sistema. In questo modo le informazioni diventano parte integrante del repository e saranno quindi classificabili e utilizzabili al pari di informazioni prodotte esplicitamente dalle redazioni interne. Il sistema è dotato di un’interfaccia in grado di recepire formati XML descritti da un DTD, per i quali è sufficiente specificare la corrispondenza con i tipi di contenuto definiti nel

24

repository di Kaistar. L’approccio è caratterizzato da un notevole grado di flessibilità in modo da rendere il più semplice possibile ciascuna integrazione, minimizzando anche il lavoro da svolgere sul sistema da integrare.

Portabilità dei contenutiI contenuti ospitati sul repository sono a tutti gli effetti una base di dati SQL, utilizzabile anche da applicazioni diverse da Kaistar e facilmente esportabile su altre tecnologie relazionali. In particolare il repository consente due livelli di accesso:

• accesso diretto (con opportuni diritti e permessi) alle strutture dati relazionali,• accesso tramite un API che espone un’interfaccia di più alto livello descrivendo tutte le

entità del sistema come tipi di dato astratto.È quindi possibile sviluppare estensioni proprietarie, anche in linguaggi diversi da Java (ad es. Microsoft ASP, PHP, Python, Perl, etc.), che accedono direttamente ai dati del repository. Inoltre è facile sviluppare applicazioni che, navigando la struttura del database, esportino i dati del repository in un qualsiasi formato, ad es. XML. I contenuti e i dati applicativi esportati potranno essere utilizzati per scopi molteplici, ad es. per l’importazione in un repository esterno o per dare luogo a dei feed tramite l’invio a sistemi di terze parti (syndication).

Il repository di Kaistar è un sistema aperto che consente sia la facile integrazione con applicazioni sviluppate da terze parti che l’esportazione dei contenuti e dati applicativi verso sistemi esterni.

Content Management Application (CMA)Al termine della configurazione del Repository Kaistar genera automaticamente una CMA web-based (ovvero caratterizzata da un’interfaccia HTML, fruibile con un comune Web browser) di cui si descrivono di seguito le principali funzionalità.

Gestione sitiKaistar consente la gestione contemporanea di diversi siti con redazioni autonome. I siti possono condividere i contenuti o essere completamente disgiunti. I redattori possono lavorare a uno o più siti.

25

La definizione dei siti viene fatta rapidamente configurando sul database i metadati che ne descrivono i contenuti. Terminata l’opera di configurazione, l’amministratore del sistema potrà creare gli account, assegnare i permessi agli utenti e definire la struttura del sito. Lo stesso modello può essere applicato a sezioni diverse di uno stesso sito; le sezioni, infatti, possono avere redazioni e contenuti indipendenti.

Gestione utenti e permessiQuesta componente consente la creazione, modifica, eliminazione degli utenti della redazione. Ilsistema dei permessi consente di gestire livelli di privilegio differenziati assegnando agli utenti diversi ruoli e gruppi (community). I ruoli servono a definire le autorizzazioni dell’utente, ovvero l’insieme delle diverse tipologie di contenuto alle quali può accedere e su ciascuna di esse l’insieme delle operazioni che possono essere fatte: creazione/lettura/modifica/cancellazione (CRUD). L’appartenenza ai gruppi determina invece l’insieme di visibilità dell’utente all’interno di una tipologia di contenuto. Queste funzionalità consentono di strutturare le redazioni in accordo all’organigramma interno e definire i permessi in base alle competenze professionali o a i ruoli. I ruoli assegnabili agli utenti sono definiti tramite meta-dati, per cui è possibile definire ruoli specifici per ogni applicazione (facendo riferimento alla figura sottostante la lista dei ruoli varia i relazione ai meta-dati definiti); in ogni caso esiste un ruolo di default del sistema che è il Supervisore. Tale ruolo crea e assegna i ruoli agli utenti che compongono la redazione stessa. Detiene il privilegio di supervisore su tutti i tipi di contenuto definiti sul sito, ossia è in grado di effettuare tutte le operazioni e le transizioni degli stati dei workflow su tutte le tipologie dei contenuti del sistema.

Kaistar supporta un team geograficamente distribuito di operatori che intervengono con diversi ruoli e a diversi livelli, nel processo di sviluppo e manutenzione dei contenuti.

Creazione contenuti e workflowIl sistema editoriale, formato dall’insieme degli strumenti per la gestione e classificazione delleinformazioni strutturate e dei documenti, è estremamente user-friendly in modo da fornire ancheall’utente meno esperto (quindi privo di particolari conoscenze tecniche quali HTML, programmazione server side, etc.) strumenti di immediato utilizzo, tramite interfaccia

26

WYSIWYG, per effettuare le tipiche operazioni di aggiornamento e manutenzione dei contenuti.

La creazione del contenuto avviene secondo il workflow o processo definito sulla particolare tipologia del contenuto. Il workflow definisce i passi necessari che portano ad avere un contenuto redatto in modo completo e approvato, stabilendo altresì la possibilità che ha un utente, a seconda del ruolo ricoperto, di intervenire su di esso per controllarne l’evoluzione.

27

Il workflow descrive l’insieme della fasi che definiscono il ciclo di vita dei contenti. Gli utenti,attraverso un’interfaccia Web-based intervengono esplicitamente per attivare i passi del workflow; il sistema gestisce e controlla la corretta applicazione di tali passi. In figura è mostrata la pagina di anteprima di un contenuto. Su tale pagina l’utente della redazione potrà, con un semplice click, decidere della sorte di questo contenuto, inclusa la sua pubblicazione immediata sul sito.

28

Più redattori possono contribuire alla redazione di un contenuto; il sistema registra le operazionieffettuate (auditing) da ciascun utente e, tramite un meccanismo di check-in/check-out, evita che più persone lavorino contemporaneamente sullo stesso oggetto (locking) rischiando di sovrascrivere l’uno il lavoro dell’altro.

Le funzioni di check-in e check-out assicurano che soltanto un redattore alla volta possa intervenire su un contenuto. L’auditing consente di tracciare gli eventi che ne caratterizzano il ciclo di vita.

Gestore OntologieQuesto componente permette la definizione e la condivisione delle ontologie tra le diverse applicazioni presenti, fornendo uno strumento flessibile e potente per la definizione di categorieorganizzate in strutture gerarchiche (tassonomie) e consentendo di utilizzare tali tassonomie per la classificazione ed il reperimento dei contenuti presenti nel sistema. Esso è quindi un potentestrumento per la gestione della conoscenza che permette ai redattori di organizzare i contenuti gestiti in maniera ottimale e agli utenti finali di reperire le informazioni cercate con la massima facilità ed efficienza, a prescindere dall’applicazione e dal tipo di contenuto utilizzati (notizie, pubblicazioni, documenti …).Contenuti, servizi e documenti possono essere classificati per più categorie facenti parte di tassonomie indipendenti. Le tassonomie/categorie definite possono essere utilizzate da diverseapplicazioni per molteplici scopi tra cui: specificare criteri di ricerca, accedere ai contenuti attraverso la navigazione delle strutture tassonomiche, associare ruoli e permessi di accesso a risorse basati su specifici criteri legati alle tassonomie stesse, monitorare gli accessi alle diverse categorie di contenuti da parte degli utenti finali, definire criteri per la presentazione di contenuti in determinate aree del sito, definire la struttura del sito. Il sistema di gestione delle ontologie fornisce quindi le seguenti funzionalità:

• Gestione di tassonomie: definizione e modifica (editing) di ontologie; import/export di ontologie preesistenti (attraverso il sistema per la gestione delle tassonomie);

29

• Gestione delle autorizzazioni degli utenti preposti a lavorare con le ontologie (demandato al sistema di gestione di contenuti ed utenti);

• Permettere la classificazione dei contenuti presenti basata sulle ontologie definite; • Permettere la definizione di criteri di ricerca di contenuti basata sulle ontologie definite; • Permettere l’accesso ai contenuti attraverso la navigazione delle tassonomie; • Permettere la gestione dinamica della mappa del sito (attraverso la definizione di

opportune sezioni).

Le sezioni successive specificano nel dettaglio le funzionalità elencate.

Gestione tassonomieIl sistema per la gestione delle tassonomie fornisce le funzionalità di definizione (editing) delle tassonomie, definizione e strutturazione delle categorie in tassonomie, l’import e l’export di tassonomie. Gli utenti hanno la possibilità di definire tassonomie attraverso un’interfaccia utente, oimportare tassonomie definite tramite XML. Tali funzionalità sono indirizzate ad utenti redattori sistemisti, che predispongono le strutture per la classificazione dei contenuti gestiti. Il processo di definizione di una tassonomia prevede i seguenti passi:

• Creazione della tassonomia;• Definizione delle categorie e strutturazione della tassonomia.

Una tassonomia in generale rappresenta un insieme di termini (categorie) strutturate in una gerarchia. La relazione gerarchica divide le informazioni in categorie e sottocategorie dai concetti più ampi a quelli più specifici. La creazione di una tassonomia coincide di fatto con la definizione di uno spazio concettuale (dominio) che possa essere utilizzato come riferimento per caratterizzare i contenuti presenti. Una volta individuato il dominio della tassonomia è necessario selezionare i termini che vi appartengono e strutturarli, ossia definire relazioni che permettano di passare dalla categoria generale alle sottocategorie che rappresentano ambiti particolari. Il sistema di gestione delle tassonomie fornisce un’interfaccia web per la loro definizione, e la strutturazione delle categorie all’interno di esse, attraverso una interfaccia utente assolutamente intuitiva (illustrata nella figura successiva).

30

Tale interfaccia è direttamente collegata all’applicazione per la gestione di contenuti (CMA), per permettere agli utenti redattori abilitati di gestire facilmente le tassonomie presenti. Con riferimento alla figura, nella parte a sinistra della maschera vengono presentate le tassonomie definite: nello specifico esistono una tassonomia geografica, denominata regioni, ed una tassonomia di contenuti, denominata argomenti. Nella parte centrale della maschera sono invece presentate le informazioni relative alla categoria selezionata, ed in basso un insieme di pulsanti permettono la definizione di nuove categorie, il posizionamento nella tassonomia e l’eventuale cancellazione.

Classificazione tramite tassonomieIl meccanismo di classificazione dell’informazione utilizza una struttura ad albero di categorie(tassonomia). I redattori possono assegnare e modificare le categorie di un contenuto senza limiti sul numero e sulla complessità delle strutture tassonomiche. I contenuti e i documenti, i servizi e i permessi possono essere classificati per più categorie facenti parte di tassonomie indipendenti, consentendo così un utilizzo e una ricerca efficienti dell’informazione o di un oggetto in generale. La classificazione degli oggetti attraverso le tassonomie ha un ruolo centrale in Kaistar e ha molteplici applicazioni tra le quali la definizione di permessi su risorse per area tematica, ricerche mirate per tassonomia e/o categoria e non ultima la possibilità di “navigare” un albero tassonomico accedendo ai contenuti associati a ciascuna categoria.

La classificazione tramite una tassonomia centralizzata abilita la distribuzione dell’informazione per più usi, l’aggregazione della stessa e l’integrazione tra sistemi eterogenei.

31

Definizione della struttura dei sitiOgni sito è tipicamente caratterizzato da una propria struttura di navigazione, ovvero da una specifica organizzazione in sotto-portali, sezioni e sottosezioni ad albero con un qualunque livello di profondità. Purtroppo è pratica comune cablare tale struttura direttamente nel codice HTML delle pagine. In questo modo ogni modifica diventa complessa e costosa in quanto richiede l’intervento di un programmatore. D’altra parte un sistema di publishing online è intrinsecamente un’entità dinamica, soggetta a continue evoluzioni per recepire e riflettere la dinamicità dell’azienda e dei processi che rappresenta.Kaistar offre una risposta a tale esigenza: una console di amministrazione presenta una visioneastratta del sito e consente di gestire in modo uniforme e automatizzata l’albero di navigazione,abilitare/disabilitare e addirittura creare nuove sezioni, definire la struttura delle sottoaree, assegnare i permessi ai redattori e ai supervisori su ciascuna area del sito. In questo modo Kaistar consegna all’amministratore del sistema il pieno controllo della situazione e la possibilità di vedere l’effetto delle proprie decisioni applicate in tempo reale.

32

Content Delivery Application (CDA)La pubblicazione dei contenuti avviene configurando per ogni sito o dominio la struttura gerarchica delle sezioni. Il contenuto di ciascuna sezione e delle relative pagine viene definito in base a regole flessibili basate sui tipi di contenuto disponibili e sulla loro classificazione. Il sistema di delivery consente la realizzazione di template per la visualizzazione dinamica delleinformazioni e dei documenti. La seguente figura illustra il modello di una tipica CDA.

Template per il rendering di pagine dinamicheI template, che possono essere realizzati velocemente tramite delle pagine JSP (Java Server Pages), usano delle specifiche API per l’accesso semplice e rapido ai dati. In questo modo le pagine non sono staticamente memorizzate sul file system del server Web ma vengono assemblate on-the-fly sulla base delle richieste dei visitatori e presentano quindi il contenuto sempre aggiornato.

CachingPer ottimizzare le prestazioni il sistema è dotato di meccanismi di cache. Una “cache dati” consente di ridurre il carico sul database memorizzando il risultato delle query più frequenti. Una “cache risultati” consente di memorizzare pagine intere o componenti di pagina riducendo il carico dovuto all’elaborazione. La permanenza delle informazioni nella cache può essere limitata nel tempo o illimitata. Nel secondo caso è cura del sistema editoriale di notificare automaticamente il gestore della cache in modo che, alla modifica di un contenuto, i risultati che da esso dipendono vengano invalidati e di conseguenza rigenerati.

La combinazione di template dinamici e di potenti meccanismi di caching fa sì che la pubblicazione di una nuova versione di un contenuto comporti la rigenerazione del solo frammento di pagina Web che ad esso corrisponde mentre il resto del sito resta invariato.

33

Rendering multi-formatoNel Kaistar la separazione delle fasi di content management e delivery, unitamente al meccanismo dei template, consentono di effettuare in modo naturale il rendering in più formati e, conseguentemente, di abilitare il delivery multicanale, ad esempio per WAP, UMTS, PocketPC, etc.. Inoltre, sebbene tradizionalmente il Kaistar sia stato concepito per produrre dinamicamente pagine HTML, è possibile sviluppare una specifica applicazione di delivery che interfacci direttamente il repository con un sistema per il rendering di documenti da stampare su carta, quale, ad esempio, XSL Formatting Objects (XSL-FO, http://www.w3.org/TR/xsl/slice6.html#fo-section), un linguaggio basato su XML e XSL che consente di definire, con il livello di dettaglio desiderato, le caratteristiche di impaginazione, layout e formattazione dei documenti. XSL-FO è supportato da una molteplicità di prodotti, sia commerciali (ad es. IBM XSL Formatting Objects Composer, RenderX-XEP, etc.) che open source (ad es. Apache FOP).

L’integrazione con XSL-FO consente di gestire l’impaginazione, il layout e lo stile dei contenuti e di effettuare il rendering in un formato adatto alla stampa quale PDF, Postscript, PCL, MIF, etc.

Le funzionalità del Kaistar permettono comunque un ulteriore livello di multicanalità. In particolare l’adozione del paradigma dei web services consente l’introduzione di meccanismi di distribuzione dell’informazione che si affiancano al canale web e al modello pull (in cui è l’utente a richiedere l’informazione nel momento in cui la individua nel Portale stesso). In maniera analoga il sistema permette la costruzione di servizi che colloquiano con l’utenza viaemail, sul canale mobile con i sistemi GPRS ed UMTS, con i messaggi multimediali MMS, ecc.Questo risultato è reso possibile grazie all’adozione per la componente di Content Management di un’interfaccia di presentazione dei contenuti basata su web services grazie ai quali è possibile instaurare in modo molto semplice ed immediato il colloquio applicativo con i sistemi per latrasmissione delle informazioni su canali diversi dal web. Vogliamo infine aggiungere che la presenza di un modulo di presentazione e delivery disgiunto dalla logica applicativa porta due ulteriori ed importanti vantaggi:

• consente al personale deputato alla gestione dell’interfaccia del Sistema di poterla modificare secondo le proprie esigenze senza dover intervenire nella parte applicativa e quindi senza dover possedere competenze specifiche nel settore dello sviluppo software ma esclusivamente nell’ambito del web design;

• consente l’introduzione di diversi modelli di interfaccia utente, tra cui delle versioni appositamente studiate per rispondere alle norme sull’accessibilità, sia quelle stabilite

34

dalla direttiva in materia del Ministro Stanca che quelle specificate dallo standard WAI del W3C.

35