Allegato 2. a pag. 16:
“2. Si rimanda alle Linee guida sull’accessibilità e alle e alle Linee guida di design”.
Linee guida sull’accessibilità è necessario referenziarlo come “Linee guida sull’accessibilità degli strumenti informatici” e le linee guida di design attualmente non risultano essere pubblicate come tali.
Allegato “formati di file e riversamento”
Paragrafo 4.3 , punto 2
Non si comprende se in sintesi si chiede di conservare il file originario, la sua copia conforme e il suo riversamento.
Allegato “Certificazione di processo”
“Per l’acquisizione massiva dei documenti si ricorre a scanner professionali che a bordo devono essere dotati di sistemi di lettura ottica ovvero di algoritmi di elaborazione digitale delle immagini in grado di migliorare la qualità delle immagini medesime e correggere automaticamente i più comuni errori.”
Suggerisco di rimuovere la parola “a bordo” perché ambigua rispetto a sistemi di digitalizzazione massiva composti da stazione di acquisizione (hardware di scansione) e software di trattamento digitale delle immagini (su hardware di elaborazione) collegati al primo.
Salve, lascio il mio contributo per quanto riguarda l’allegato 5 sui metadati.
Trattandosi di annotazioni piuttosto articolate le ho scritte direttamente sul PDF.
Ho letto le indicazioni contenute nel documento sia dal punto di vista della pubblica amministrazione che deve applicare le norme (e/o chiedere ai fornitori di applicarle e/o controllare che i sistemi siano conformi) alla ricerca di possibili dubbi implementativi, sia da un punto di vista (poco) più esperto attento alla coerenza dello schema complessivo. Non sono entrato molto nel merito degli attributi del documento che si è scelto di descrivere/gestire con i metadati.
Do atto del grande lavoro fatto visto che, nelle vigenti regole tecniche, lo schema di metadati è davvero minimo e senz’altro inadeguato per un’efficiente gestione del documento digitale e il suo passaggio da un sistema documentale all’altro. E’ senza dubbio auspicabile che, nel tempo, lo schema proposto evolva e si arrichisca, sul modello di schemi adottati in altri paesi, di sezioni informative, esempi, vocabolari controllati ecc.
Ecco il link al mio pdf annotato: https://1drv.ms/b/s!AsgilBZZCl50gZduQCxMO4_Be3vtlw?e=NNeaT7
Buongiorno
Pagina 21 formato ODT ha estensione .odt e non odb (e’ un refuso)
Pagina 40 nel riquadro di mbox vi e’ citato MS-pst (refiso?) che non c’entra nulla
Allegato 6
Poiché manca nell’allegato la presentazione grafica dell’XML Schema della segnatura, mi permetto di linkare di seguito due rappresentazioni grafiche che sono riuscito a fare con l’unico tool gratuito che ho trovato (QXmlEdit).
Schema grafico (PDF): https://1drv.ms/b/s!AsgilBZZCl50gZgIKUJItZIfM15iEQ?e=MN2awc
Dettaglio degli elementi (PDF): https://1drv.ms/b/s!AsgilBZZCl50gZgAPGUt9_ZnFMYozw?e=CuY6HY
Schema con evidenziazione dei “Types” (PDF): https://1drv.ms/b/s!AsgilBZZCl50gZgKEP7JLgXv8YZwvA?e=QPGINT
Segnalo inoltre che non ho trovato traccia, e non mi pare che possano ricavarsi dall’XML Schema della segnatura, delle specifiche dei messaggi di conferma e annullamento.
Buona lettura!
EDIT: sostituiti i file linkati perché non si visualizzavano come sperato.
Allegato 6
Alcune osservazioni dal punto di vista di chi dovrebbe applicare il contenuto dell’allegato:
- nella parte iniziale, si potrebbe chiarire e distinguere meglio fra segnatura di protocollo secondo l’art. 55 TUDA e la segnatura, oggetto dell’allegato, utilizzata per l’interoperabilità di protocollo ai sensi dell’art. 20 del dpcm 3/12/2013 (regole tecniche sul protocollo informatico);
- la novità principale è senza dubbio l’apposizione di firma e sigillo in formato XaDES al file segnatura.xml. Infatti, difficoltà implementative a parte, questo consente finalmente di ottenere l’immodificabilità e l’integrità della segnatura e, tramite la messa in sicurezza delle impronte incluse nella segnatura, degli stessi file trasmessi . Tuttavia, non è chiarito in nessun modo chi deve firmare: il protocollista, l’eventuale firmatario del documento principale? E per le registrazioni automatizzate con invio automatizzato? È poi proprio necessaria la firma di una persona, non è sufficiente il sigillo?
- si nota una certa distanza fra i metadati individuati per la segnatura e i metadati del documento amministrativo informatico individuati dall’allegato 5;
- è stata eliminata la possibilità di gestire messaggi ibridi (con componenti analogiche non recapitabili elettronicamente);
- la mancanza della rappresentazione grafica dell’XML Schema ne limita la comprensione;
- sono apparentemente assenti le definizioni (XML Schema) dei messaggi di conferma, di anomalia, di annullamento;
- è stato espunto l’elemento PiuInfo che, opportunamente utilizzato, potrebbe essere utile complemento per la concreta interoperabilità.
Per osservazioni puntuali sul testo rimando al PDF annotato: https://1drv.ms/b/s!AsgilBZZCl50gZd1bNrvB7Yzlc0ioQ?e=6K6fWi
All 1 - Glossario dei termini e degli acronimi
Propongo le seguenti modifiche:
DEFINIZIONE DI AUTENTICITA’
MI lascia perplesso il primo capoverso della definizione di Autenticità. Faccio fatica a comprendere come un utente di livello medio-basso possa capire la seguente definizione:
“Il grado con cui una persona o un sistema considera un oggetto per quanto riguarda ciò che dichiara di essere.”
Forse una proposta di maggior semplicità per il primo capoverso potrebbe essere la seguente:
“Il grado con cui una persona o un sistema considera comprovata la paternità di un Oggetto digitale.
DEFINIZIONE DI CONSERVATORE
Consiglio di integrare la definizione di Conservatore per renderla conforme all’art. 44 comma 1-quater del CAD come segue:
“Soggetto pubblico o privato che svolge attività di conservazione dei documenti informatici ed offre idonee garanzie organizzative, tecnologiche e di protezione dei dati personali.”
DEFINIZIONE DI PRODUTTORE DEI PdV
Si consiglia di rivedere la definizione del “Produttore dei PdV” come segue:
Persona fisica o giuridica, di norma diversa dal soggetto che ha formato il documento e in caso di affidamento esterno diversa dal Conservatore, che produce il pacchetto di versamento ed è responsabile del trasferimento del suo contenuto nel sistema di conservazione.
Nelle pubbliche amministrazioni, tale figura è una persona fisica e si identifica con il responsabile della gestione documentale.
DEFINIZIONE DI RAPPORTO DI VERSAMENTO
Rivedere la parte finale della definizione del Rapporto di Versamento
Documento informatico che attesta l’avvenuta presa in carico da parte del sistema di conservazione dei pacchetti di versamento inviati dal Produttore dei PdV.
DEFINIZIONE DI RESPONSABILE DEL SERVIZIO DI CONSERVAZIONE
Rivedere la definizione del Responsabile del servizio di conservazione, in quanto nell’ambito privato è possibile affidare in esterno le attività di conservazione anche ad un Conservatore non accreditato e al suo Responsabile del Servizio di conservazione.
Si propone la seguente definizione:
“Soggetto che coordina il processo di conservazione all’interno del Conservatore.
Nel caso di Conservatore accreditato, il Responsabile del servizio di conservazione deve essere in possesso dei requisiti professionali individuati da AGID.”
DEFINIZIONE DEL TITOLARE DELL’OGGETTO DI CONSERVAZIONE
Consiglio di rivedere la definizione di Titolare dell’oggetto di conservazione seguente “Soggetto produttore degli oggetti di conservazione.”
Sostituendola con quanto segue in coerenza con l’art. 1 comma 1 lett. cc) del CAD
“È il titolare del contenuto degli oggetti di conservazione. È il soggetto che ha originariamente formato per uso proprio o commissionato ad altro soggetto gli oggetti di conservazione, o che ne ha la disponibilità in quanto li detiene”.
DEFINIZIONE DI VERSAMENTO
Rivedere il primo capoverso della definizione di “Versamento” seguente “ Passaggio di custodia, di proprietà e/o di responsabilità dei documenti.”
Nel caso di Versamento di PdV al sistema di conservazione io non individuo affatto un passaggio di proprietà e/o di responsabilità dei documenti ma solo un passaggio di responsabilità della conservazione degli Oggetti digitali in caso di esito positivo della presa in carico tramite rapporto di versamento.
Quindi la definizione che sicuramente è stata concepita per avere un senso più legato alla custodia e all’ambito archivistico va a mio avviso revisionata.
ACRONIMI
Consiglio di esplicitare anche l’acronimo in inglese per maggior chiarezza su AiP, DiP e SiP.
Aggiungerei inoltre l’acronimo del Rapporto di Versamento.
Quindi propongo:
PdA (AiP) = Pacchetto di Archiviazione (Archival information Package).
PdD (DiP) = Pacchetto di Distribuzione (Distribution information Package).
PdV (SiP) = Pacchetto di Versamento (Submission information Package).
RdV = Rapporto di Versamento
Concordo al 100%: sia perdendo l’occasione per normare i tracciati di formazione (bozza), registrazione e conservazione in modo appropriato, incluse le relative conversioni e predisposizioni alle azioni di pubblicazione, accesso (omississ) e conservazione.
Già riscontriamo confusione nella gestione del versioning che alcuni Enti/Clienti chiedono univoca, sia in fase di predisposizione delle bozze, che per la “manipolazione” dei dati già registrati in gestione corrente
Allegato 5 - Metadati
Pur apprezzando il grande lavoro fatto e che si nota nella profondità dei dettagli forniti, come nel caso dell’allegato sui metadati, si rileva l’indicazione di una lista onnicomprensiva di qualsiasi informazione importante riguardante i dati (evidenze documentali e di procedimento) gestiti.
La scelta di riportare informazione ed attributi in stile XML/UML rende certamente ordinata ed agevole la lettura, ma si perde il caso d’uso e lo scopo di ogni informazione gestita, fondamento per ogni lecito e logico trattamento.
Ad esempio non è chiaro il punto di registrazione di ogni informazione e il limite d’uso ovvero se è un’informazione dedicata alla pubblicazione/accessibilità del procedimento in itinere o se sia un informazione/metadato di conservazione.
Per la conservazione si raccomanda la scelta di metadati chiari “chiave/valore” o di indicare la lista di informazioni minime obbligatorie per le 4 fattispecie indicate [documenti, documenti sottoscritti, atti, aggregazioni], a meno che non si voglia vincolare e obbligare all’uso di strutture object UML DMS in qualsiasi fase (formazione, gestione e conservazione) di vita dei documenti PA, dove a quel punto si potranno generare e sottoscrivere copie (stampe) di atti o documenti formati in modo totalmente logico e trattabili (es. oscuramento/omississ, anonimizzazione/oblio, ecc) fino nel dettaglio del singolo documento.
Allegato 2 Formati di file e riversamento.
L’allegato tratta in maniera organica l’utilizzo dei vari formati nel contesto delle Linee Guida ed è sicuramente un passo notevole in avanti rispetto alle precedenti che ci avvicina a modelli internazionali.
Molto apprezzabile il paragrafo 4.3 sul riversamento.
Alcune osservazioni:
- Nel par. 4.3, la frase “Le considerazioni in questo e nei successivi paragrafi si applicano informatici rappresentati in file” non è chiara.
- Nell’articolazione delle informazioni su ogni singolo formato, si potevano inserire anche i codici identificativi in uso presso registri come Pronom (vedi le modalità dei metadati PREMIS di identificare i formati ad esempio).
- Un formato che non è stato indicato ma è di interesse è WARC (Web ARChive) . La descrizione è disponibile nel sistema della Library of Congress Statunitense in merito alla sostenibilità dei formati all’indirizzo: http://www.loc.gov/preservation/digital/formats/fdd/fdd000236.shtml.
- in merito al paragrafo 4.2 comma 3 l’indicatore di interoperabilità (che forse va inteso come sostenibilità) viene descritto come uno degli elementi qualitativi da valutare. Forse questo aspetto andrebbe maggiormente evidenziato.
- Par. 4.3 comma 5 viene riportato " un processo certificato di conformità della copia riversata (cfr. Allegato 5 delle presenti linee guida)". Si intende l’allegato 3?
- Par. 4.3 comma 5 punto 3. L’attestazione del riversamento deve essere necessariamente strutturata e conservata in un nuovo pacchetto di archiviazione creato a partire dal file riversato?
- Par. 4.3 comma 5 punto 4. Il processo di verifica degli obblighi dovrebbe essere indipendente da trigger come questi e caratterizzarsi come autonomo?
- Par. 4.3 comma 3, vedi osservazione 5.
- Considerazione generale: è importante che il riversamento non intacchi in nessun modo il contenuto del documento informatico e la sua rappresentazione. E’ importante sviluppare e condividere analisi indirizzate a questo specifico aspetto. Focalizzarsi su aspetti prettamente informatici dei formati è importante per strutturare un modello documentabile, replicabile e anche automatizzabile ma altrettanto importante la verifica che il processo di “copia conforme” non modifichi la rappresentazione del documento informatico.
Allegato 3.
Nell’ambito del paragrafo 1.2 sui principi generali, sia fa riferimento al solo art. 22 comma 1-bis del CAD, tralasciando il riferimento all’art. 23-ter comma 1-bis del CAD, come se questo fosse superfluo. Si tratta di un comportamento voluto?
Segnalo che all’art. 22 comma 1-bis si fa riferimento alla “certificazione di processo nei casi in cui siano adottate tecniche in grado di garantire la corrispondenza della forma e del contenuto dell’originale e della copia”, mentre all’art. 23, comma 1-bis si fa riferimento alla sola “corrispondenza del contenuto dell’originale e della copia”.
Personalmente trovo la formulazione un po’ fuorviante, dato che dal CAD la certificazione di processo sembrerebbe richiedere, a seconda delle previsioni, l’adozione di tecniche in grado di garantire la corrispondenza della forma e del contenuto dell’originale e della copia, piuttosto che il solo contenuto dell’originale e della copia; mentre dalle Linee guida, tale differenziazione non sembra emergere.
Allegato 3 - Paragrafo 1.2
Nell’allegato si asserisce che nel modello di certificazione di processo devono concorrere due elementi fondamentali, ovvero:
• la presenza di una procedura tecnologica in grado di garantire la corrispondenza della forma e del contenuto dell’originale e della copia;
• la documentazione e verifica della corretta esecuzione di questo processo, al fine conferire ai documenti risultanti dal processo l’efficacia probatoria prevista.
A leggendo tale indicazione fuori dal contesto complessivo dell’allegato 3 sembrerebbe che con la locuzione “processo”, introdotta nell’enunciazione del secondo elemento, ci si riferisca all’esecuzione della “procedura tecnologia” delineata nel primo elemento.
Malgrado ciò, tale interpretazione cozza apertamente con quanto riportato nel successivo paragrago 2.1, dove si specifica che poiché il modello della certificazione di processo vuole perseguire lo stesso risultato che tradizionalmente è conseguibile attraverso l’implementazione del metodo del raffronto tra originale e copia, tale modello dovrà essere caratterizzato sia dal punto di vista oggettivo, che da quello di vista soggettivo. Dunque, “ nella certificazione di processo non ci si potrà limitare a descrivere il processo con il quale è stata creata la copia digitale, ma occorrerà anche, necessariamente, certificare la copia risultato ” .
Mi aspetterei, pertanto, che la consequenza logica di tale impostazione consista, da un lato, nella necessità di certificare il ciclo di dematerializzazione da parte di un organismo terzo e secondo determinati standard internazionali (ambito oggettivo), mentre dall’altro, nella necessità di concludere in ogni caso il processo di dematerializzazione mediante il metodo di raffronto dei documenti (ambito soggettivo).
L’interpretazione fornita alla fine è corretta?
In ogni caso sarebbe possibile esplicitare meglio i termini con cui si manifesta il legame tra i due elementi?
allegato 2
pag. 100
“segnatura di protocollo”
si fa riferimento all’abroganda circolare 60/2013
il link al “foglio di stile per visualizzare la segnatura” (esiste davvero??) punta a un foglio di stile per HL7/CDA2
Considerazione generale: il concetto e la regolamentazione del riversamento è un’apprezzabile novità. Altra grande novità è che il riversamento (o migrazione di formato) venga “sdoganato” anche in fase di gestione, non solo di conservazione. Ho provato a leggere l’allegato per cercare di capire come gestire, per esempio, una conversione da .doc a .pdf in fase di “capture” di un documento nel protocollo informatico di una pubblica amministrazione ma non sono riuscito a capire cosa dovrei fare esattamente per implementare una simile soluzione. Per esempio: devo documentare con riferimento opponibile a terzi il tempo di inizio e fine riversamento? devo o non devo conservare il documento nel suo formato originale? come mi comporto per file imbustati in formati di per sé adatti a tutto (es.: p7m), ma che hanno al loro interno formati da evitare (es.: .xls)? e un file .zip, posso catturarlo tout-court dopo averlo decompresso?
Non sarebbe male qualche indicazione a uso dei poveri responsabili della gestione documentali degli 8000 comni italiani o delle 9000 scuole pubbliche su cosa fare in caso di ricezione di un file in un formato poco raccomandato.
Altra questione generale, sulla quale ammetto che il poco tempo a disposizioni per comprendere bene non gioca a favore: per una pubblica amministrazione che intenda digitalizzare le se procedure, i formati decritti nell’allegato sono da ritenere come nucleo minimo di formati da accettare per le comunicazioni in arrivo?
Allegato 5 - I Metadati
Unità documentaria
“Unità minima elementare di riferimento di cui è composto un archivio (standard ISO 23081-2:2009)”
Si propone di affiancare questo termine al ‘documento informatico’ per indicare la somma di documento principale e allegati che compongono un documento “archivistico”.
Chiarisce meglio la distinzione tra documento informatico (sinonimo di unità documentaria) e file
Valutare se unificare Documenti informatico e Documento amministrativo informatico indicando solo le differenze nei campi e nelle obbligatorietà; renderebbe più chiara la differenza; ad esempio i documenti della PA non protocollati o repertoriati sono ‘documenti informatici’.
IdAgg - Documento amministrativo informatico
Si propone di rendere facoltativo nel documento il riferimento alla ‘aggregazione documentale informatica’ visto che esistono obbligatoriamente i riferimenti dei documenti nella ‘aggregazione documentale informatica’. Questo eviterebbe poi di rettificarlo se viene ulteriormente fascicolato…
Documento informatico e Documento amministrativo informatico
Impronta: è l’hash del documento principale o della somma di file presenti nella unità documentaria ?
Si propone di mettere per ogni allegato i seguenti campi:
- impronta/algoritmo
- riservatezza
- formato/versione
- firma/sigillo/marcatura/attestazione di conformità
Se tipo agente = PG meglio indicare il codice fiscale, sempre presente, mentre la partita iva potrebbe non essere presente se la persona giuridica non svolge attività economiche (es. condomini)
Rendere il tempo di conservazione facoltativo perché nel caso di piano di conservazione gestito sui fascicoli il tempo dipende da questi e non è necessario metterlo sui documenti, soprattutto se ‘multifascicolati’
Aggregazione documentale informatica
La classificazione (numero di fascicolo) e il catalogo processi sarebbe meglio renderli ‘facoltativi’.
IdAggPrincipale: nel caso di sottofascicoli di terzo livello (inserti) meglio indicare il livello superiore e non il fascicolo principale.
Valutare se indicare anche la ‘serie archivistica di fascicoli’ come elenco di fascicoli e un ridotto numero di metadati a corredo.
Allegato 2 - formati di file e riversamento
Si propone di predisporre una tabella di interoperabilità “base” sulle informazioni dei formati presenti nell’allegato.
PRECISAZIONI
Allegato 2 - Formato dei File e Riversamento Pagina 18 - 107, Punto 4
Il formato PDF è stato sviluppato da John Warnock, fondatore, presidente e chief technical officer di Adobe, nel corso degli anni ottanta, e annunciato all’inizio degli anni novanta prima come Progetto Camelot e poi come PDF. Aldus, poi acquisita da Adobe, non è mai stata convolta nello sviluppo del PDF, anche se PageMaker è stato il primo programma a salvare in quel formato (all’annuncio del PDF). Maggiori informazioni su https://en.wikipedia.org/wiki/PDF e https://en.wikipedia.org/wiki/John_Warnock.
Allegato 2 - Formato dei File e Riversamento Pagina 33 - 107, Punto 6 (Tabella)
Sia nell’intestazione della Tabella che nel testo del Punto 6 il formato viene chiamato ODP e non ODB, creando confusione con il formato Open Document Presentation (ODP) proprio di LibreOffice Impress e di altri software per la creazione di presentazioni. Inoltre, il formato ODB non è mai stato deprecato, ma siccome non è ottimizzato per la gestione professionale di database non viene mai consigliato per l’implementazione in ambienti di produzione.
Allegato 2 - Formato dei File e Riversamento Pagina 38 - 107, Punto 17
Nell’allegato sono descritte cinque (e non tre) specializzazioni di Open Document Format: ODT per i documenti, ODS per i fogli di calcolo, ODP per le presentazioni, ODB per i database, e ODG per i file grafici.
ANNOTAZIONI DI TIPO TECNICO
Allegato 2 - Formato dei File e Riversamento Pagina 20 - 107, Tabella
(1) La versione più recente del formato OOXML è la 12.0 del 24 settembre 2019, che è una major version con modifiche significative al contenuto tecnico. Piuttosto, la definizione del versionamento per i file OOXML (in tutte le loro accezioni: DOCX, XLSX e PPTX) è poco chiara all’interno della documentazione del formato stesso, dove si fa spesso confusione tra versionamento inteso come versione dello standard e versionamento come versione di un singolo documento (nel caso in cui più utenti intervengano in modifica sul documento stesso). Il problema era stato sollevato durante il Ballot Resolution Meeting di Ginevra, precedente alla standardizzazione, ma non ha mai avuto una risposta precisa.
(2) La versione standard del formato OOXML in tutte le sue declinazioni (DOCX, XLSX e PPTX) è quella Strict, che non è la versione utilizzata per difetto né da Microsoft Office né da nessun altro software per la produttività individuale. Questo significa che la versione corrente non è standard in quanto può contenere elementi proprietari ed elementi binari che creano problemi di interoperabilità, e non è riconoscibile se non accedendo al file XML dove viene chiarito che si tratta di file Strict. Il formato OOXML Strict doveva originariamente diventare il formato standard per difetto di tutte le versioni di Microsoft Office a partire dalla 2010, così come era stato assicurato da Microsoft sia durante il Ballot Resolution Meeting di Ginevra sia nella fase di consolidamento dello standard OOXML, ma questo non si è mai verificato. Quel che è peggio, ci sono presentazioni ufficiali di Microsoft che affermano che il formato di Office 365 è OOXML Strict, mentre una verifica dimostra che si tratta di OOXML Transitional (in quanto la rappresentazione dei numeri nei file XLSX è ancora quella progressiva a partire dal 1° gennaio 1900).
(3) Il formato standard OOXML, in entrambe le versioni Strict e Transitional, è stato approvato nonostante la presenza di numerosi problemi tecnici incontrati durante la standardizzazione e mai risolti, che rendono più difficile l’interoperabilità (tanto che nella maggior parte dei casi si procede ancora con il reverse engineering del formato e non seguendo la descrizione del formato stesso come invece dovrebbe essere nel caso di un formato standard ISO). In modo molto sintetico, i problemi sono: (3.1) l’utilizzo di formati proprietari Microsoft in luogo di formati standard esistenti, come invece dovrebbe avvenire nel caso dello sviluppo di formati standard (per esempio, l’uso di DrawingML in luogo di SVG, standard W3C, e di OMML in luogo di MathML, anch’esso standard W3C); (3.2) l’utilizzo di codici linguistici numerici non standard, in contrapposizione allo standard ISO 639, che definisce i codici linguistici con il sistema ampiamente utilizzato lingua_VARIANTE, dove it_IT è Italiano Italia e it_CH è Italiano Svizzera; (3.3) l’utilizzo di alcuni codici colore esadecimali non standard in luogo di quelli ampiamente utilizzati da tutti i software grafici.