Path: Home » Publications » Linee guida tecniche » Indice » Pubblicazione
vai al contenuto
 

WP4 - Gruppo di lavoro italiano "Interoperabilità e servizi"
Linee guida tecniche per i programmi di creazione di contenuti culturali digitali
Edizione italiana 2.0

PUBBLICAZIONE

Prevedibilmente, l’accesso alle risorse digitali da parte dell’utente finale avverrà anzitutto attraverso l’uso di reti locali e di protocolli Internet.
La preparazione per la pubblicazione richiede che il master digitale venga elaborato per generare oggetti digitali adatti a essere usati nel contesto di Internet, tipicamente attraverso meccanismi di scalabilità, come la riduzione della qualità e la generazione di file di dimensioni adeguate al trasferimento attraverso la rete, oppure attraverso metodi di trasmissione progressiva, che consentono una fruizione graduale e controllabile a seconda di parametri collegati con il profilo utente.
Inoltre, i file audio e le sequenze video possono essere resi disponibili sia per lo scaricamento (download) che per lo streaming. In quest’ultima modalità, anziché trasferire l’intero file prima che possa avviarsi la sua esecuzione, viene creato uno spazio di buffer (memoria tampone o di transito) sul computer dell’utente e i dati vengono trasmessi nel buffer. Non appena il buffer è pieno, il file streaming comincia a essere eseguito, mentre i dati continuano ad essere trasmessi.
Deve esser tenuto in considerazione che possono variare:

  • il tipo di hardware e il tipo di software impiegati dagli utenti
  • i livelli di larghezza di banda entro i limiti dei quali gli utenti operano.

Per raggiungere il più vasto pubblico possibile, i progetti dovrebbero rendere le risorse disponibili in più dimensioni, formati, risoluzioni o velocità di bit (bit-rate) alternativi, scegliendo, quando possibile, formati che offrano scalabilità di risoluzione e di qualità delle immagini.
I progetti dovrebbero rivedere periodicamente i criteri su cui si basano le decisioni in merito a formati e parametri di distribuzione.
Le seguenti raccomandazioni sui formati di distribuzione devono essere considerate contestualmente ai requisiti per i formati dei file (vedi § 6.1) per la memorizzazione delle risorse.

8.1  Procedure per la pubblicazione

8.1.1  Pubblicazione del testo

8.1.1.1  Codifica dei caratteri

La codifica dei caratteri adottata nei documenti di testo dovrebbe essere trasmessa nello header HTTP e anche registrata all’interno dei documenti come opportuno (vedi § 6.1.1.1).
Si noti che alcuni protocolli basati su XML possono imporre l’uso di una specifica codifica del carattere; ad esempio, il protocollo OAI per la raccolta automatica (harvesting) dei metadati (vedi § 9.1) richiede l’uso della codifica di carattere UTF-8.


standard

UTF-8
<http://www.utf-8.com/>

UNICODE
<http://unicode.org/>

esempi, raccomandazioni e linee guida

Jukka Korpela. A Tutorial on Character Code Issues
<http://www.cs.tut.fi/~jkorpela/chars.html>

8.1.1.2  Formati dei documenti

Il contenuto a base testuale dovrebbe essere distribuito come XHTML 1.0 oppure HTML 4 (o versioni successive), sebbene possa talora essere adeguato l’impiego di formati SGML o XML conformi ad altre DTD o schemi.
In alcuni casi, la distribuzione in formati proprietari come PDF (Portable Document Format), RTF (Rich Text Format) o Microsoft Word può essere opportuna, come formato aggiuntivo rispetto a XHTML/HTML, ma i progetti devono garantire che i problemi relativi all’accessibilità vengano affrontati (vedi § 8.4.1).


standard

HTML 4.01 HyperText Markup Language
<http://www.w3.org/TR/html401/>

XHTML 1.0 The Extensible HyperText Markup Language
<http://www.w3.org/TR/xhtml1/>

Portable Document Format (PDF)
<http://www.adobe.com/products/acrobat/adobepdf.html>

8.1.2  Pubblicazione di immagini fisse

8.1.2.1  Immagini a matrice di punti (raster)

Dovrebbe essere presa in considerazione la possibilità di offrire la stessa immagine in diversi formati, dimensioni, qualità per consentirne una fruizione adeguata al contesto d’uso. Alle decisioni in merito a dimensioni e qualità dell’immagine possono concorrere le considerazioni riguardanti i diritti di proprietà intellettuale (vedi cap. 11).
Le tipologie dimensionali individuabili per una trasmissione via Web sono le seguenti:

  • immagini francobollo (icone, o thumbnail): dovrebbero essere fornite usando un massimo di 100-200 pixel per la dimensione maggiore, considerando 120 pixel come la taglia preferita per la dimensione maggiore
  • immagini cartolina,derivate da un originale riducendone le dimensioni: dovrebbero essere fornite usando un massimo di 600 pixel per la dimensione maggiore
  • immagini full-screen: dovrebbero essere fornite usando un massimo di 1024-1280 pixel per la dimensione maggiore.

Per le ultime due tipologie d’immagine il problema qualità/dimensioni è maggiormente avvertibile in relazione alla trasmissione; la scelta può dipendere, fra l’altro, anche dalla tipologia di utenza a cui è indirizzata (utenza registrata o no, utenza scientifica ecc.).
Le immagini derivate devono conservare la profondità di colore dell’originale.
Per consentire la visualizzazione fino alle dimensioni originali di file di grande formato, le immagini possono essere “mosaicate”, cioè ridotte a un insieme di tessere di dimensioni fisse (ad esempio: 1024 x 768 o 1024 x 1024). In tal modo è possibile ricondurre le varie tessere ai valori dimensionali previsti per le tipologie indicate in precedenza.
In alternativa o in combinazione con la mosaicatura, si possono impiegare tecniche di multirisoluzione, che consistono in una collezione aggiuntiva di immagini sottocampionate di quella originale, utilizzate per visualizzare rapidamente porzioni di essa a vari fattori di ingrandimento (zoom maggiori o minori del 100%), fino a giungere alla risoluzione nativa.
Esistono vari tipi di software proprietari che, a partire dai master, generano l’insieme di immagini multirisoluzione adatto alla trasmissione via Web (piramidalizzazione). Tale procedimento può essere utilizzato su immagini raster di qualsiasi dimensione e utilizzato per ridurre l’impegno della rete. Inoltre esso introduce una certa gestionalità delle immagini, consentendo di impedire la visualizzazione dell’intero file a piena risoluzione e scoraggiandone così usi illeciti.

8.1.2.1.1  Formato dei file

Le immagini raster derivanti dalla digitalizzazione di documenti o fotografie dovrebbero essere messe a disposizione sul Web in formato JPEG/SPIFF.
Le immagini grafiche non vettoriali dovrebbero essere distribuite sul Web usando il Graphical Interchange Format (GIF) o il formato Portable Network Graphics (PNG).
Tra i formati di compressione emergenti c’è anche il JPEG 2000, concepito per risolvere gran parte delle esigenze di un progetto di digitalizzazione e pubblicazione via Web. Al momento dell’edizione di questa guida non si registra una diffusione a livello mondiale di questo formato tale da imporne l’uso: rimane tuttavia un formato assai valido, che dovrebbe essere preso in considerazione proprio perché consente di gestire la base dati delle immagini e dei metadati in maniera integrata e di organizzare la fruizione remota via Web in maniera progressiva e collegabile alle varie tipologie di utenza. L’adozione o la migrazione verso un sistema di compressione e fruizione basato su JPEG 2000 dovrebbe essere presa in considerazione  dagli estensori di nuovi progetti.

8.1.2.1.2  Tempi di trasmissione

Si dovrebbe tenere in considerazione che la larghezza di banda a disposizione di un utente qualsiasi può essere tale (modem a 56 Kbps) da richiedere un tempo notevole per la visualizzazione completa di una immagine trasmessa via Web; anche in questo caso è opportuna una scelta oculata tra formati, dimensioni e qualità dell’immagine.
A titolo orientativo, i tempi di scaricamento per un file compresso delle dimensioni di circa 150 KByte sono quelli indicati in tabella (trasmissione seriale). Si tenga presente che la durata reale può variare sensibilmente in funzione di varie condizioni: stato della linea, utilizzo del server ecc.

Scaricamento (download) di un file di ~150 Kbyte

Alla velocità
di (bps)

Tempo impiegato (s.)

56 K

~ 28

128 K

~ 12

384 K

~ 4

512 K

~ 3

1 M

~ 1,4

Le immagini a matrice di punti tutelate dal diritto d’autore o di riproduzione dovrebbero essere trasmesse su Web utilizzando sistemi per la protezione dei diritti d’utilizzazione economica (vedi cap. 11).


standard

JPEG 2000
<http://www.jpeg.org/jpeg2000/>

esempi, raccomandazioni e linee guida

ICCD. Normativa per l’acquisizione digitale delle immagini fotografiche. 1998
<http://www.iccd.beniculturali.it/standard/index.html>

ICCD. Normativa per la documentazione multimediale. 2004
<http://www.iccd.beniculturali.it/download/norme_300/multimediali_300.pdf>

ICCU. Linee guida per la digitalizzazione del materiale fotografico.
Roma: ICCU, 2005

ICCU. Linee di indirizzo per i progetti di digitalizzazione del materiale fotografico
<http://www.iccu.sbn.it/upload/documenti/Linee_guida_fotografie.pdf>

8.1.2.2  Immagini grafiche vettoriali

Le immagini grafiche vettoriali dovrebbero essere distribuite sul Web tramite l’uso di formati Scalable Vector Graphics (SVG).
In alternativa si può prendere in considerazione la possibilità di rasterizzare le immagini grafiche vettoriali, ossia di trasformarle in immagini bitmap, in modo da trasmetterle secondo le modalità già viste per le immagini raster o fotografiche. La scelta del software di rasterizzazione è importante in quanto è responsabile della qualità finale dell’immagine. Con questo metodo è possibile evitare l’invio su Web di file vettoriali originali coperti da copyright.

8.1.3  Pubblicazione di documenti video

Si dovrebbe tenere in considerazione il fatto che l’accesso degli utenti al video può essere limitato da restrizioni poste dall’ampiezza di banda: può pertanto essere opportuno fornire una serie di file o stream (“flussi”) di qualità differente.

8.1.3.1  Scaricamento (downloading)

I video dovrebbero essere distribuiti in rete per il download (scaricamento) attraverso il formato MPEG-1 o MPEG-4. In alternativa, posso essere adottati i formati proprietari Microsoft Audio Video Interleave (AVI), Windows Media Video (WMV) o Apple Quicktime.


standard

Moving Pictures Experts Group (MPEG)
<http://www.chiariglione.org/mpeg/>

8.1.3.2  Trasmissione a flusso continuo (streaming)

I video da trasmettere (streaming) dovrebbero essere distribuiti sul Web nei formati Microsoft Advanced Streaming Format (ASF), Windows Media Video (WMV) o Apple Quicktime.

8.1.4  Pubblicazione di documenti audio

Si dovrebbe tenere in considerazione il fatto che l’accesso degli utenti all’audio può subire limitazioni a causa dell’ampiezza di banda disponibile; può pertanto essere opportuno fornire una gamma di file o stream di diversa qualità.

8.1.4.1  Scaricamento (downloading)

I file audio dovrebbero essere distribuiti sul Web in forma compressa, usando il formato MPEG Layer 3 (MP3) o i formati proprietari Real Audio (RA) o Microsoft Windows Media Audio (WMA). Nei casi in cui sia necessaria una qualità del suono simile a quella del CD, dovrebbe essere usato un bit-rate di 256 Kb per secondo; un bit-rate di 160 Kbps assicura una buona qualità.
I file audio possono essere distribuiti in forma non compressa tramite i formati Microsoft WAV/AIFF o Sun AU.

8.1.4.2  Trasmissione a flusso continuo (streaming)

I file audio per lo streaming dovrebbero essere distribuiti in rete adottando il formato MPEG Layer 3 (MP3) o i formati proprietari Real Audio (RA) o Microsoft Media Audio (WMA).

8.2  3D e realtà virtuale

I progetti che fanno uso di fly through e di modelli di realtà virtuale tridimensionale devonoprendere in considerazione le esigenze degli utenti che accedono al loro sito usando comuni computer e connessioni modem a 56k.
I modelli di realtà virtuale vengono usati tipicamente per la ricostruzione di edifici e di altre strutture o nella simulazione di intere aree di un paesaggio. I modelli sono stati tradizionalmente costruiti e mostrati usando potenti workstation, e questo continua a essere il caso dei modelli più dettagliati.  Questi modelli non sono adatti ai progetti cui è richiesto di distribuire in Internet i propri risultati al più vasto pubblico possibile. Tuttavia, modelli meno complessi possono utilmente essere inseriti nei siti web a disposizione degli utenti.
Nel generare questi modelli, i progetti devono essere consapevoli che molti dei loro utenti nel prossimo futuro continueranno ad avere accesso a Internet usando un modem a 56k o una connessione condivisa, piuttosto che una tecnologia a banda larga. Le specifiche tecniche dei computer usati dai visitatori ordinari verosimilmente sono sensibilmente inferiori a quelle delle macchine su cui i progetti generano e testano tali modelli. I progetti devono pertanto esaminare l’usabilità dei loro modelli in tali condizioni e devono testarli usando connessioni modem comuni e sistemi di computer casalinghi, scolastici, di biblioteca con un’ampia selezione dei più diffusi sistemi operativi e browser.
In questo settore gli standard sono in continua evoluzione, ma i progetti dovrebbero produrre modelli VR compatibili con le specifiche X3D.
Apple Quick Time VR (QTVR) non è un autentico formato immagine 3D, ma offre alcune utili funzionalità. I progetti che non necessitano di tutte le funzionalità di X3D possono esaminare la possibilità di usare in suo luogo QTVR.


standard

Web3D Consortium
<http://www.web3d.org/>

X3D
<http://www.web3d.org/x3d/>

QuickTime VR
<http://www.apple.com/quicktime/qtvr/>

VRML Virtual Reality Modeling Language
<http://www.w3.org/MarkUp/VRML/>

esempi, raccomandazioni e linee guida

Archaeology Data Service. VR Guide to Good Practice
<http://ads.ahds.ac.uk/project/goodguides/g2gp.html>

8.3  Sistemi Informativi Geografici (GIS)

Molti beni e contenuti culturali, essendo fondati sul territorio, posseggono un indirizzo geografico. Questa loro caratteristica offre la possibilità di applicare ad essi specifici strumenti di conoscenza e di analisi.
Tali strumenti sono generalmente individuati con il nome di SIT (sistemi informativi territoriali), in inglese Geographic Information Systems (GIS). Essi si definiscono come l’insieme di strumenti, apparati, metodi e dati in grado di analizzare, progettare, controllare e gestire l’ambiente e il territorio e nel caso in ispecie i beni culturali.
Non è indispensabile che i progetti che intendono memorizzare l’informazione su base territoriale o includerne la localizzazione geografica sul proprio sito web installino e mantengano in efficienza una applicazione software appositamente progettata per memorizzare, gestire e ricercare informazioni basate sul territorio (GIS). Le informazioni territoriali possono essere memorizzate (anche se non necessariamente manipolate o riusate appieno) in una base di dati tradizionale, e semplici immagini di mappe per la localizzazione possono essere create attraverso vari strumenti.
Le informazioni territoriali possono essere memorizzate sia in modalità raster che vettoriale, e possedere diversi tipi di indirizzo geografico, da quello alfanumerico (come l’indirizzo stradale) a quello cartografico (quali le coordinate geografiche): ove si vogliano memorizzare tali informazioni, è necessario tenere conto di queste variabili e procedere a una loro corretta digitalizzazione e memorizzazione.
Le tecnologie delle reti, e in particolare il Web, permettono oggi di utilizzare funzionalità GIS che non risiedono su un singolo sistema e di usare dati che sono conservati e mantenuti su database remoti messi a disposizione da agenti diversi. Tutto questo è possibile se vi è interoperabilità, che può essere: tecnica, ovvero in questo caso la capacità per sistemi diversi di processare dati territoriali e di comunicare in tempo reale tramite interfacce condivise; semantica, riferita a standard legati al contenuto dei dati, ovvero ai nomi delle entità geografiche e agli schemi di metadati; e infine istituzionale, dovuta alla collaborazione tra utenti e produttori e legata al flusso del lavoro, alle partnership e alla necessità di oltrepassare le barriere istituzionali (nazionali, locali ecc.) per una più efficiente soddisfazione delle necessità degli utenti.
L’adozione dei GIS da parte del settore culturale è in rapida crescita. I progetti dovrebbero garantire che l’implementazione di un GIS e/o delle sue funzionalità offerte via Web possa avvenire in seguito, anche se non è stata pianificata nell’ambito del progetto stesso. A tal fine è necessario che in fase di progettazione del database del progetto si prevedano le possibili componenti territoriali dei dati.
In particolare, per la creazione di metadati di riferimento di contenuti e beni culturali che presentano una componente territoriale i progetti possono prendere in considerazione il Dublin Core Spatial Application Profile.
L’harvesting di metadati con il protocollo OAI-PMH, usando uno schema Dublin Core, può in tal caso consentire la presentazione dei dati tramite un sistema GIS esterno (vedi § 9.1).
Per quei progetti che comunque richiedono una piena interazione con informazioni su base territoriale, come quelle che un GIS può offrire, va tenuto a mente quanto segue.
I progetti che intendono fare uso delle funzionalità proprie di un GIS, anche erogate via Web (cosiddetti Web-services), ove utilizzino dati geografici realizzati da terze parti, devono preoccuparsi di ottenere le opportune autorizzazioni per l’uso dei dati cartografici e geografici, assicurandosi che le licenze si estendano ai servizi di distribuzione al pubblico da essi identificato attraverso i canali selezionati.
I progetti devono prestare particolare attenzione alla omogeneità di risoluzione e scalabilità dei data set, in modo tale che i servizi forniti rispettino scala e risoluzione. I prodotti GIS messi in essere nei progetti dovrebbero adeguarsi agli emergenti standard di Open GIS Consortium e ISO/TC211.
Quando registrano dati geografici e cartografici, i progetti devono adottare e dichiarare l’uso di un adeguato sistema di riferimento e di un modello dei dati coordinato e standard. I progetti devono usare e dichiarare l’uso di standard nazionali adeguati per la registrazione degli indirizzi viari.

8.3.1  Un esempio italiano: il GIS del SIGEC

Nell’ambito del Sistema Informativo Generale del Catalogo (SIGEC) per la georeferenziazione sono richiesti il sistema di riferimento adottato per le coordinate e le seguenti informazioni necessarie per poter utilizzare correttamente i dati geografici:

  • il metodo di georeferenziazione (se cioè il punto, la linea o l’area sono stati acquisiti in modo esatto o approssimato)
  • la tecnica di georeferenziazione (rilievo tradizionale, rilievo con strumento, rilievo da cartografia con o senza sopralluogo; rilievo da foto aerea ecc.)
  • informazioni tecniche sulla base cartografica utilizzata per georeferenziare; nel SIGEC è disponibile una scheda elaborata con riferimento allo standard “CEN TC/287”, la scheda di Metainformazione cartografica, che contiene informazioni sulla denominazione, la collocazione, le caratteristiche grafiche e tecniche.

La valorizzazione dei campi delle normative ICCD relativi alle informazioni sul metodo e la tecnica di georeferenziazione e sul sistema di riferimento adottato è controllata da vocabolari chiusi, per agevolare la compilazione da parte del catalogatore e al tempo stesso normalizzare i contenuti, al fine di ottimizzare le operazioni di analisi e di ricerca.


normativa

Proposta di direttiva per la creazione della infrastruttura
europea dei dati territoriali
<http://inspire.jrc.it>

Codice dell’Amministrazione Digitale
<http://www.cmipa.gov.it>

standard

Dublin Core Spatial Application Profile
<ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/MMI-DC/cwa14858-00-2003-Nov.pdf> - <http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm#dublincore>

ISO/TC211 Geographic information, Geomatics
<http://www.isotc211.org/>

Open Geospatial Consortium
<http://www.opengis.org/> - <http://www.opengeospatial.org/standards/>

European Committee for Standardization. CEN/TC 287
<http://www.cen.eu/CENORM/BusinessDomains/TechnicalCommittees Workshops/CENTechnicalCommittees/CENTechnicalCommittees.asp? param=6268&title=CEN%2FTC+287>

Sistema pubblico di connettività
<http://www.cnipa.gov.it/site/it-it/In_primo_piano/ Sistema_Pubblico_di_Connettivit%C3%A0_(SPC)/>

esempi, raccomandazioni e linee guida

AHDS. GIS Guide to Good Practice
<http://ads.ahds.ac.uk/project/goodguides/gis/>

Zhong-Ren Peng – Ming-Hsiang Tsou. Internet GIS
<http://map.sdsu.edu/gisbook/ch6.htm>

8.4  Siti web

Le risorse dei progetti devono essere accessibili tramite un browser web. Questo si ottiene normalmente usando il linguaggio HTML o XHTML e il protocollo HTTP 1.1. Se vengono usati altri protocolli (ad esempio, Z39.50) devono essere disponibili dei gateway per consentire l’accesso tramite un browser web.
I progetti dovrebbero garantire la massima disponibilità del proprio sito web. Il programma di finanziamento dovrebbe richiedere una giustificazione di periodi significativi di indisponibilità del sito.


standard

Hypertext Transfer Protocol, HTTP/1.1
<http://www.w3.org/Protocols/HTTP/>

HTML 4.01 HyperText Markup Language
<http://www.w3.org/TR/html401/>

XHTML 1.0 The Extensible HyperText Markup Language (Second Edition)
<http://www.w3.org/TR/xhtml1/>

8.4.1  Accessibilità e qualità

Le informazioni sui progetti e le risorse da essi prodotte devono essere accessibili da browser diversi e da sistemi hardware, programmi automatici e utenti finali con caratteristiche diverse.
I siti web devono essere accessibili per un’ampia gamma di browser e dispositivi hardware (per esempio, Personal Digital Assistants [PDA] e PC). I siti web devono essere usabili per browser che supportano le raccomandazioni W3C, come HTML/XHTML, Cascading Style Sheets (CSS) e il Document Object Model (DOM).
I progetti che fanno uso di formati proprietari di file e di tecnologie browser plug-in devono garantire che il loro contenuto sia usabile anche per browser sprovvisti di plug-in. Di conseguenza, l’impiego di tecnologie come Javascript o Macromedia Flash nella navigazione del sito deve essere preso in attenta considerazione.
L’aspetto di un sito web dovrebbe essere controllato attraverso l’uso di fogli di stile in linea con l’architettura W3C e le raccomandazioni per l’accessibilità. Dovrebbe essere usata l’ultima versione di Cascading Style Sheets (CSS) raccomandata dal W3C (attualmente CSS 2) sebbene non tutte le caratteristiche definite dal CSS 2 siano usabili perché non ancora sufficientemente supportate da parte dei browser.
Per conseguire l’accessibilità dei contenuti di un sito web, i progetti devono costantemente fare riferimento alle linee guida definite nell’ambito dell’iniziativa WAI (Web Accessibility Initiative) del W3C. Il WAI tratta dell’accessibilità del Web in senso ampio, cioè non solo con riguardo ai contenuti ma anche agli strumenti con i quali le pagine web vengono realizzate, ai browser e più in generale alle tecnologie per l’accesso al Web. I progetti devono raggiungere la conformità al livello WAI A; dovrebbero mirare a raggiungere la conformità al livello WAI AA.
In relazione all’accessibilità dei contenuti, sono di particolare importanza le Web Content Accessibility Guidelines (WCAG) versione 1.0, pubblicate il 5 maggio 1999. Si tratta di 14 linee guida, in ciascuna delle quali sono presentati scenari tipici che possono creare difficoltà per utenti con disabilità.
In ogni linea guida è definito un certo numero di punti di controllo (checkpoint) che spiega in che modo la specifica linea guida è applicabile nello sviluppo dei contenuti. Le linee guida introducono il concetto di priorità e il conseguente concetto di conformità.
In linea con gli indirizzi formulati dalla WAI, in Italia è stata emanata la legge 9 gennaio 2004, Disposizioni per favorire l’accesso dei soggetti disabili agli strumenti informatici (cosiddetta Legge Stanca), rivolta in particolare alle pubbliche amministrazioni centrali e locali, agli enti pubblici economici, alle aziende private concessionarie di pubblici servizi, alle aziende municipalizzate regionali, agli enti di assistenza e di riabilitazione pubblici, alle aziende di trasporto e telecomunicazione a prevalente partecipazione di capitale pubblico e alle aziende appaltatrici di servizi informativi.
Il provvedimento introduce una serie di obblighi con prescrizioni dettagliate in merito ai requisiti di accessibilità che devono possedere i sistemi informativi in generale e i siti web in particolare.
Alla legge ha fatto seguito il Decreto del Ministro per l'innovazione e le tecnologie dell'8 luglio 2005, che stabilisce le linee guida recanti i requisiti tecnici e i diversi livelli per l'accessibilità e le metodologie tecniche per la verifica dell'accessibilità dei siti web, nonché i programmi di valutazione assistita utilizzabili a tale fine.
Il Ministero per i beni e le attività culturali ha in seguito emanato una direttiva rivolta ai propri istituti contenente il Piano di comunicazione coordinata dei siti web afferenti al Ministero per i beni e le attività culturali per la loro accessibilità e qualità, contenente sei linee guida, basate sul dettato della Legge Stanca e sui risultati raggiunti dal Progetto MINERVA.
Centro di riferimento e supporto alle iniziative per la qualità dei siti web afferenti al Ministero per i beni e le attività culturali è l’Osservatorio tecnologico per i beni e le attività culturali (OTEBAC), istituito presso la Direzione generale per l'innovazione tecnologica e la promozione.


normativa

Legge 9 gennaio 2004, n. 4
Disposizioni per favorire l'accesso dei soggetti disabili agli strumenti informatici
<http://www.pubbliaccesso.it/normative/legge_20040109_n4.htm>

Decreto del Ministro per l'innovazione e le tecnologie, 8 luglio 2005
Requisiti tecnici e i diversi livelli per l'accessibilità agli strumenti informatici
<http://www.pubbliaccesso.it/normative/DM080705.htm>

Direttiva del viceministro per i beni e le attività culturali del 9 novembre 2005
recante linee guida per il Piano di comunicazione coordinata dei siti web afferenti al Ministero per i beni e le attività culturali per la loro accessibilità e qualità
<http://www.otebac.it/siti/realizzare/direttive/direttiva091105.html>

standard

Cascading Style Sheets (CSS), Level 2
<http://www.w3.org/TR/REC-CSS2/>

Document Object Model
<http://www.w3.org/TR/REC-DOM-Level-1/>

XHTML 1.0 The Extensible HyperText Markup Language (Second Edition)
<http://www.w3.org/TR/xhtml1/>

HyperText Markup Language (HTML) Home Page
<http://www.w3.org/MarkUp/>

esempi, raccomandazioni e linee guida

Web Accessibility Initiative (WAI)
<http://www.w3.org/WAI/>

Web Content Accessibility Guidelines (WCAG) 1.0
<http://www.w3.org/WAI/intro/wcag.php> - <http://www.w3.org/TR/WAI-WEBCONTENT/> - <http://www.w3.org/TR/WCAG10/>

RNIB: Accessible Web Design
<http://www.rnib.org.uk/digital/hints.htm>

Watchfire Bobby Online Service
<http://webxact.watchfire.com/>

useit.com: Jakob Nielsen’s Website
<http://www.useit.com/>

MINERVA, Manuale per la qualità dei siti web pubblici culturali
<http://www.minervaeurope.org/publications/qualitycriteria-i.htm>
 
MINERVA, Principi per la qualità di un sito web culturale
<http://www.minervaeurope.org/structure/workinggroups/ userneeds/documents/cwqp-i.htm>

MINERVA Quality Principles for cultural Web sites: a handbook
<http://www.minervaeurope.org/publications/qualitycommentary/ qualitycommentary050314final.pdf>

Museo & Web. Un kit di progettazione di un sito web di qualità per un museo di piccole e medie dimensioni
<http://www.minervaeurope.org/structure/workinggroups/ userneeds/prototipo/index.html>

Ministero per i Beni e e le Attività Culturali. Museo & Web: CMS Open Source
<http://www.minervaeurope.org/structure/workinggroups/userneeds/prototipo/cms.html>

Osservatorio tecnologico per i beni e le attività culturali (OTEBAC)
<http://www.otebac.it>

8.4.2  Sicurezza

Le macchine adoperate per la diffusione dei progetti e dei loro risultati devono esser fatte funzionare nella maniera più sicura possibile. Devono essere seguite le istruzioni relative alla sicurezza fornite dai manuali sui sistemi operativi. Devonoessere applicate tutte le patch per la sicurezza rilasciate.
Le macchine dovrebbero essere configurate per gestire il numero minimo possibile di servizi di rete. Le macchine dovrebbero inoltre essere protette da un firewall con accesso a Internet solo sulle porte necessarie alla distribuzione dei risultati del progetto.
I progetti dovrebbero dimostrare di conoscere i codici di prassi per la sicurezza informatica forniti da ISO/IEC 17799:2000 e ISO/IEC 17799:2005.
La gestione e l’uso dei dati personali deve avvenire in conformità alla legislazione nazionale pertinente.
Quando informazioni sensibili sono trasferite da un client a un server attraverso la rete, i progetti devono usare il protocollo Secure Sockets Layer (SSL) per criptare i dati (trasferimento di username e password, dati relativi alle carte di credito e altre informazioni personali). L’uso di SSL aumenta la fiducia dell’utente finale nell’autenticità del servizio.


standard

Secure Sockets Layer (SSL), 3.0
<http://wp.netscape.com/eng/ssl3/>

ISO/IEC 17799:2000  Information technology -- Security techniques - Code of practice for information security management
<http://www.iso.org/iso/en/prods-services/popstds/informationsecurity.html>

esempi, raccomandazioni e linee guida

Introduction to Secure Socket Layer (SSL)
<http://www.cisco.com/en/US/netsol/ns340/ns394/ns50/ns140/ networking_solutions_white_paper09186a0080136858.shtml>

8.4.3  Autenticità

I nomi a dominio specifici del progetto dovrebbero essere registrati nel Domain Name System (DNS). Il nome del dominio è parte integrante del branding (marchio) del progetto e aiuterà gli utenti finali a identificare l’autenticità del contenuto distribuito attraverso il suo sito web. I nomi a dominio dovrebbero pertanto essere contraddistinti chiaramente dal nome del progetto o da quello dell’organizzazione che lo gestisce e ne distribuisce le risorse.
In alcune situazioni può essere opportuno proteggere la connessione in rete fra il client e il server usando Secure Sockets Layer (SSL) per aumentare la fiducia dell’utente finale nello scambio di informazioni con il sito web del progetto.

esempi, raccomandazioni e linee guida

Domain Names System (DNS). Resources Directory
<http://www.dns.net/dnsrd/>

Consiglio nazionale delle ricerche. Network Information Center per l'Italia. Registro del ccTLD 'it'
<http://www.nic.it>

8.4.4  Autenticazione dell’utente

Alcuni progetti possono voler limitare l’accesso a parte delle proprie risorse (per esempio a immagini ad altissima risoluzione ecc.) solo a utenti autorizzati. L’autenticazione dell’utente è uno strumento utile a garantire che solo utenti legittimi abbiano accesso alle risorse on-line del progetto.
Quando i progetti scelgono di implementare l’autenticazione dell’utente per materiali selezionati, essa dovrebbe essere basata su una combinazione di username e password. Nel caso di progetti basati sul Web (Web-based), per trasmettere la combinazione username/password dal browser al server deve essere usata la HTTP Basic Authentication.
In alcuni casi l’autenticazione basata sull’IP (IP-based, che confronta l’indirizzo IP dell’utente con una lista di indirizzi IP conosciuti) può essere un’alternativa adeguata all’impiego di username e password. Tuttavia, l’impiego di questo metodo per l’autenticazione è fortemente scoraggiato, in quanto il crescente impiego di indirizzi IP dinamici da parte di molti Internet Service Provider rende molto difficile la gestione di una lista di indirizzi IP autorizzati. Inoltre, l’autenticazione dell’indirizzo IP è difficile da gestire anche in relazione a utenti di cellulari e utenti protetti da firewall.
Se opportuno, i progetti possono scegliere di far uso di servizi di autenticazione forniti da terzi cui far gestire per proprio conto username e password.

standard

Hypertext Transfer Protocol, HTTP/1.1
<http://www.w3.org/Protocols/HTTP/>

8.4.5  Indicatori di prestazione (Performance Indicators)

È buona norma che i responsabili dei progetti di digitalizzazione promuovano indagini sull’utenza e sugli usi dei servizi, per fornire indicazioni in merito all’impatto del progetto di digitalizzazione e ottenere indicazioni per il miglioramento del servizio.
Si possono inoltre adottare indicatori di prestazione per misurare oggettivamente l’uso che viene fatto di un servizio web.
 Un popolare indicatore di prestazione si serve dei log files del server web. L’analisi dei log files sul server può fornire informazioni valide sull’incremento di un servizio e sui modelli di impiego, sebbene i rapporti debbano essere interpretati con prudenza.
I progetti devono tenere aggiornate le statistiche sull’uso dei siti web e dovrebbero adoperarle opportunamente per analizzare l’uso che viene fatto delle risorse digitali.
Ulteriori linee guida in quest’ambito sono in corso di sviluppo. Si segnala in particolare il toolkit per la valutazione qualitativa degli utenti delle risorse digitali messo a punto dal progetto EValued.

esempi, raccomandazioni e linee guida

Evalued. An evaluation toolkit for e-library developments
<http://www.evalued.uce.ac.uk/>

E-Metrics. Measures for Electronic Resources
<http://www.arl.org/stats/newmeas/emetrics/>

COUNTER Code of Practice 
<http://www.projectcounter.org/code_practice.html>


 

About

Structure

Interoperability

Quality, accessibility, usability

Best Practices