|
|
|
|
|
|
|
|
|
| |
|
| |
|
WP4 - Gruppo di lavoro italiano "Interoperabilità e servizi"
|
|||||||||||||||
Scaricamento (download) di un file di ~150 Kbyte |
|
Alla velocità |
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>
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.
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.
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/>
I video da trasmettere (streaming) dovrebbero essere distribuiti sul Web nei formati Microsoft Advanced Streaming Format (ASF), Windows Media Video (WMV) o Apple Quicktime.
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à.
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.
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).
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>
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.
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:
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>
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/>
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.net/publications/qualitycriteria-i.htm>
MINERVA, Principi per la qualità di un sito web culturale
<http://www.minervaeurope.net/structure/workinggroups/ userneeds/documents/cwqp-i.htm>
MINERVA Quality Principles for cultural Web sites: a handbook
<http://www.minervaeurope.net/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.net/structure/workinggroups/ userneeds/prototipo/index.html>
Ministero per i Beni e e le Attività Culturali. Museo & Web: CMS Open Source
<http://www.minervaeurope.net/structure/workinggroups/userneeds/prototipo/cms.html>
Osservatorio tecnologico per i beni e le attività culturali (OTEBAC)
<http://www.otebac.it>
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>
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>
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/>
È 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>
|
|
|
|
Copyright Minerva Project 2007-03,
last revision 2007-03-26, edited by Minerva
Editorial Board. | |
