Note

2019-10-20T16:44:55Z

Lorenzo.amorosa: note init

== Note ==

Vedere altre note su fogli di carta e promemoria del telefono. Ce ne sono molte.

* Per personaggi molto piccoli (meno di 1m x 1m x 1m) possibilità di essere in (x,y,z) tra 0 e 1.000.000 (ordine del micrometro, 1*10^-6 == 0,000001) e avere (lenX, lenY, lenZ). In questo modo sono definite dimensioni inferiori ad 1 m^3.
* Parametri interi per mossa (direzione, consumabili) con lower e upper bound
* Segnalazione (comando per fare nota)
* Modalità battaglia con interazione stile battaglia navale (non si vede mossa dell'avversario)
* Looney toons
* X fa una mossa contro Y: Z potrebbe reagire (Es. ricevendo il colpo al posto di Y). Può essere realizzato sia come se "Y chiede soccorso Z" o come reazione di alleati adiacenti "Z soccorre Y"

[[Category: La Lotta]]

Mossa

2019-10-20T16:29:00Z

Lorenzo.amorosa: Creata pagina con "== Mossa == Scrivi qui la seconda sezione del tuo articolo. Category: La Lotta"

== Mossa ==

Scrivi qui la seconda sezione del tuo articolo.

[[Category: La Lotta]]

Stato

2019-10-20T16:28:17Z

Lorenzo.amorosa: Creata pagina con "== Stato == Scrivi qui la seconda sezione del tuo articolo. Category: La Lotta"

== Stato ==

Scrivi qui la seconda sezione del tuo articolo.

[[Category: La Lotta]]

Statistica

2019-10-20T16:27:26Z

Lorenzo.amorosa: Creata pagina con "== Statistica == Scrivi qui la seconda sezione del tuo articolo. tuo articolo. Category: La Lotta"

== Statistica ==

Scrivi qui la seconda sezione del tuo articolo.
tuo articolo.

[[Category: La Lotta]]

Ente (Personaggio/Oggetto)

2019-10-20T16:26:18Z

Lorenzo.amorosa: Creata pagina con "== Ente == Scrivi qui la prima sezione del tuo articolo. == Personaggio == Scrivi qui la seconda sezione del tuo articolo. == Oggetto == Scrivi qui la seconda sezione del..."

== Ente ==

Scrivi qui la prima sezione del tuo articolo.

== Personaggio ==

Scrivi qui la seconda sezione del tuo articolo.

== Oggetto ==

Scrivi qui la seconda sezione del tuo articolo.

[[Category: La Lotta]]

Classi Dominio

2019-10-20T16:19:25Z

Lorenzo.amorosa: classi versione 0

== Ente ==
https://lalotta.fandom.com/it/wiki/Ente_(Personaggio/Oggetto)

'''link corretto'''

== Personaggio ==
https://lalotta.fandom.com/it/wiki/Ente_(Personaggio/Oggetto)

'''link corretto'''

== Oggetto ==
https://lalotta.fandom.com/it/wiki/Ente_(Personaggio/Oggetto)

'''link corretto'''

== Statistica ==
https://lalotta.fandom.com/it/wiki/Statistica

'''link corretto'''

== Stato ==
https://lalotta.fandom.com/it/wiki/Stato

'''link corretto'''

== Mossa ==
https://lalotta.fandom.com/it/wiki/Mossa

'''link corretto'''

[[Category: La Lotta]]

Categoria:La Lotta

2019-10-20T16:11:16Z

Lorenzo.amorosa: categoria "La Lotta" init

Questa categoria indica una pagina del wiki appartenente al progetto (gioco) "La Lotta"

La Lotta

2019-10-20T16:08:31Z

Lorenzo.amorosa: la lotta - main page

== Benvenuto nel wiki del gioco La Lotta ==
Ciao! Questo è un progetto personale che mira a simulare un gioco di lotta in una qualunque modalità pensabile e tra combattenti di una qualunque tipologia immaginabile.

Su questo wiki sarà presente la parte progettuale, a questo link: https://github.com/Lostefra/LaLotta sarà presente il codice sorgente dell'applicazione (attualmente il progetto è privato, per visionarlo contattami).

Il gioco sarà testuale e molto basilare in apparenza, ma avrà una logica interna tutt'altro che banale! Buon divertimento!

== Indice ==
Qui puoi trovare un indice che riassume le sezioni del wiki: ''' link Indice_classi_dominio'''

Attualmente è presente l'indice delle classi di dominio, quando ci saranno altre sezioni sarà fornito un indice generale.

Qui puoi trovare le note, ossia spunti di riflessione che sto portando avanti nella progettazione del gioco: '''link note'''

== Elenco lavori in corso ==
Attualmente è in lavorazione l'analisi del dominio del gioco. Sono reperibili qui sul wiki informazioni sulla struttura delle classi che saranno utilizzate. Il progetto complessivamente è in fase embrionale.

== Note ==
''' da spostare'''
Vedere altre note su fogli di carta, ora le note e promemoria del telefono non dovrebbero contenere altri appunti.
* Per personaggi molto piccoli (meno di 1m x 1m x 1m) possibilità di essere in (x,y,z) tra 0 e 1.000.000 (ordine del micrometro, 1*10^-6 == 0,000001) e avere (lenX, lenY, lenZ). In questo modo sono definite dimensioni inferiori ad 1 m^3.
* Parametri interi per mossa (direzione, consumabili) con lower e upper bound
* Segnalazione (comando per fare nota)
* Modalità battaglia con interazione stile battaglia navale (non si vede mossa dell'avversario)
* Looney toons
* X fa una mossa contro Y: Z potrebbe reagire (Es. ricevendo il colpo al posto di Y). Può essere realizzato sia come se "Y chiede soccorso Z" o come reazione di alleati adiacenti "Z soccorre Y"

[[Category: La Lotta]]

Servizio web per il trattamento dei dati personali contenuti in documenti OOXML complessi

2019-09-30T06:07:05Z

Lorenzo.amorosa: /* Ottimizzazioni del processo di minimizzazione */

==Introduzione==

Il recente Regolamento Generale europeo sulla Protezione dei Dati (UE) 2016/679 ([0034], [0035]) o ''GDPR'' (''General Data Protection Regulation'', come nel seguito sarà chiamato) ha modernizzato significativamente la normativa in materia di protezione dei dati personali, rendendola omogenea fra tutti gli stati membri. È bene notare che, fin dal titolo, il ''GDPR'' non riduce gli spazi per i trattamenti di dati personali, ma anzi ne protegge la "libera circolazione", dettando, però, regole definite e certe. Rinunciando ad una presentazione più completa del ''GDPR'', saranno riportati nei successivi capitoli i concetti necessari alla discussione dell'argomento.<div></div>
Enti ed organizzazioni, aventi a che fare con documenti contenenti dati sensibili, devono operare in maniera conforme al ''GDPR''; potrebbero, di conseguenza, trarre beneficio da servizi specifici in grado di supportarli in queste esigenze.<div></div>
L'oggetto principale della tesi sarà dunque, come riportato dal titolo, la progettazione e la realizzazione di un servizio per la gestione di dati personali.
<div></div>(QUI IMG [0F05])<div></div>

La larga maggioranza dei documenti testuali viene generata con strumenti cosiddetti di "produttività individuale", cioè da ''word-processors''. L'osservazione, ovvia nella sua evidenza, consente di introdurre una riflessione: quando un documento è generato da un'elaborazione automatica, magari per composizione di ''template'' con dati estratti da un database, l'individuazione dei "dati personali" nel documento prodotto può avvenire in modo rigoroso e senza incertezze, sulla base degli elementi di composizione del documento; ad es.: i campi del documento estratti da una anagrafica di soggetti sono certamente dati personali e come tali possono essere opportunamente trattati nel processo di elaborazione automatica (ad es. cancellati).

Ma, in quella larga maggioranza di documenti testuali generata con ''word-processors'' l'individuazione ed il trattamento dei dati personali vanno affrontati con altri approcci, discussi in questa tesi.

==Scenario di lavoro==

===Minimizzazione dei dati personali===

Un concetto espresso in modo pervasivo dal ''GDPR'' è quello della "''minimizzazione''" dei dati personali trattati ed a maggior ragione dei dati personali pubblicati. In particolare l'Art. 5 ed il Considerando 39 prescrivono che i dati personali trattati siano "''adeguati, pertinenti e limitati a quanto necessario rispetto alle finalità per le quali sono trattati («minimizzazione dei dati»)''" ([0035]).<div></div>
Con questo fine, il GDPR delinea due possibilità organizzative e tecniche di "''minimizzazione''": l'anonimizzazione e la psedonimizzazione.

====Anonimizzazione====

Sono anonimizzati i dati personali non (più) riferibili alle persone a cui sono appartenuti; si tratta di serie di dati, spesso ingenti, che sono stati definitivamente ed irreversibilmente separati da ogni riferimento alle persone che caratterizzavano. Sono le serie di dati utilizzate per fini statistici, scientifici, etc. E' importante notare che, come fissato dal Considerando 26 del ''GDPR'', il Regolamento non si applica al "''trattamento di tali informazioni anonime''" ([0035]). Per questo, sottoporre database e documenti ad un procedimento, cioè un trattamento, di anonimizzazione consente di non doversi più preoccupare del ''GDPR''.

====Pseudonimizzazione====

Fra le definizioni dell'Art. 4 del ''GDPR'', la "pseudonimizzazione" viene indicata come "''il trattamento tale che i dati personali non possano più essere attribuiti a un interessato specifico senza l’utilizzo di informazioni aggiuntive, a condizione che tali informazioni aggiuntive siano conservate separatamente''" ([0035]).<div></div>
Traducendo in termini "operativi", si tratta del procedimento che, dal "record" dei dati di un interessato, separa i campi che caratterizzano l'interessato stesso da quelli che lo identificano, trasferendo questi ultimi in una nuova distinta tabella; nelle due tabelle vengono aggiunti i riferimenti che permettono la ricostruzione del record originario; il procedimento è completo quando la nuova tabella con gli identificativi viene archiviata separatamente ed eventualmente cifrata. In margine si annota che in molti casi, come molti studi dimostrano, è possibile identificare, quindi "riconoscere", gli interessati utilizzando la sola tabella con i dati pseudonimizzati.

====Altri trattamenti di "minimizzazione" ====

Un problema pratico che si incontra di frequente è quello di dover pubblicare documenti più o meno ampi che contengono dati personali. Spesso la pubblicazione è obbligatoria per legge: si pensi alle graduatorie relative a concorsi pubblici, alle sentenze dei tribunali, etc.<div></div>
In questi frequenti casi, analizzando meglio le finalità per le quali sono pubblicati quei dati personali, si osserva che sono possibili e legittimi almeno due approcci per "minimizzare" il dato nel "trattamento di pubblicazione" e, dunque, per minimizzarne la propagazione, ad esempio attraverso motori di ricerca, ben oltre ogni ragionevole finalità. I contesti ed i corrispondenti approcci sono:
# Situazioni in cui è necessario che l'interessato possa riconoscersi nel documento ed essere riconosciuto dagli altri soggetti menzionati nel contesto, ma non è plausibile la necessità di identificazione dell'interessato al di fuori di quel contesto specifico. A questo caso si riconducono le graduatorie di concorsi, gli elenchi per la formazione di classi, gli elenchi per convocazioni, etc. In tutti questi casi, nel processo di redazione del documento è più pratico trattare internamente i dati personali in forma completa; ma praticamente mai è necessario pubblicarli per intero, esponendo al pubblico accesso codici fiscali, indirizzi, recapiti telefonici etc. Per di più, nella maggior parte delle volte, è sufficiente pubblicare il solo cognome perché l'interessato conosca la sua posizione in graduatoria; ciò è spesso sufficiente anche a trasmettere l'informazione necessaria ai colleghi dell'interessato nella medesima graduatoria, o nella medesima classe, etc. Notare che, pubblicando il solo cognome, viene di fatto oscurato anche il sesso. Dunque, in questi casi è auspicabile cancellare una larga parte dei dati personali presenti nel documento.
# Situazioni in cui il documento deve essere pubblicato affinché siano rese note le motivazioni che lo hanno originato, senza che sia necessaria la precisa identificazione dei soggetti che vi compaiono. Questo è il caso della pubblicazione di sentenze giudiziarie di ogni grado. Le sentenze vengono notificate direttamente agli "aventi causa"; ma anche, come la legge prescrive, pubblicate al fine di costituire giurisprudenza. In questo secondo caso, risulta del tutto eccedente la pubblicazione dei reali nominativi degli interessati, che troverebbero verosimilmente la propria vicenda inutilmente indicizzata dai motori di ricerca negli anni a venire. Nella pubblicazione delle sentenze appare un approccio ottimale quello di sostituire con pseudonimi o con iniziali alterate i veri nominativi degli interessati presenti: il senso e le argomentazioni della sentenza restano pienamente comprensibili, come è necessario; il dato personale, del tutto superfluo ai fini della giurisprudenza, viene protetto.
In questi casi appare opportuno sostituire i dati identificativi dell'interessato, ed in particolare il nome e cognome, con pseudonimi o, ancora, con iniziali alterate, cioè non coincidenti con le iniziali reali. <div></div>
Proprio questi tipi di trattamenti di "minimizzazione" sono l'oggetto di questa tesi.

===Punti di partenza per la progettazione del servizio===

La tesi è stata svolta in collaborazione con l'azienda AFA Systems (www.afasystems.it/gdpr) con la quale si sono discusse le problematiche di progettazione e realizzazione di un servizio generalizzato di minimizzazione dei dati personali presenti in un documento.
Con l'intenzione di fornire il servizio ad un bacino d'utenza il più vasto e variegato possibile, si è pensato ad un'applicazione ''web-based'', indipendente così dai singoli devices sui quali poi sarà utilizzata.
L'attenzione è stata concentrata sul trattamento dei nomi e dei cognomi (che da qui chiameremo nominativi), poiché sono quelli sempre presenti nei documenti (ad es. gli indirizzi sono presenti solo a volte), rappresentano gli elementi tramite i quali è immediato il riconoscimento della persone, non hanno formato predefinito (come ad es. i codici fiscali); altri dati personali (indirizzi, codici fiscali, etc.), potranno essere considerati in successive evoluzioni del progetto.
È utile notare che la parte iniziale della collaborazione con l'azienda è stata dedicata alla discussione delle specifiche, la cui più precisa definizione è parte rilevante di questa tesi.<div></div>
Tra i requisiti che necessitano di un opportuno studio troviamo ad esempio:
* L'individuazione di metodi efficaci per il riconoscimento dei nominativi nei documenti
* L'identificazione delle migliori procedure di interazione con l'utente
* La scelta dei formati da trattare
* I vincoli non funzionali legati al rispetto del ''GDPR''.

==Definizione delle specifiche==

===Riconoscimento dei nominativi===

====Scelta della strategia di riconoscimento====

Le difficoltà principali con cui ci si imbatte nel processo di riconoscimento dei nominativi riguardano la complessità strutturale dei documenti di testo, ma soprattutto l'intrinseca ambiguità del linguaggio naturale. <div></div>
Le variabili ed impredicibili strutture e formattazioni dei documenti introducono alcuni problemi significativi. Rendendo fortemente eterogeneo il contenuto dei documenti, infatti, esse non consentono di ricondurre il problema del riconoscimento dei nominativi ad uno o a pochi singoli casi, ma comportano lo studio di tutte le strutture e formattazioni possibili, rendendo quindi l'analisi molto generale. L'altra rilevante difficoltà presente sta nella complessità di effettuare il riconoscimento di una stringa testuale immersa in un insieme di elementi non tutti testuali. Ogni elemento di formattazione, che sia una tabella o una barra orizzontale, introduce infatti un proprio significato logico e semantico nel documento di cui bisogna tenere conto.<div></div>
Il linguaggio naturale introduce anch'esso complessità: si pensi alle molteplici tipologie di proposizioni con cui possono essere articolati i periodi; ma i problemi principali derivano dalle sue ambiguità. Esse vengono classificate in diverse tipologie ([0025]); le principali sono le ambiguità sintattiche e lessicali.<div></div>
Si ha ambiguità sintattica quando la sintassi di una frase può essere interpretata in diversi modi e, di conseguenza, la frase stessa assume significati diversi. Essa è presente, ad esempio, nelle seguenti frasi:<div></div>
* "''Rapina in banca con rivoltella da centomila euro''"
* "''Luigi ha visto un uomo nel parco con il binocolo''"
<div></div>
L'esasperazione massima della problematica delle ambiguità sintattiche si presenta con l'<i>antinomia</i>, ossia un particolare tipo di paradosso che indica la compresenza di due affermazioni contraddittorie che possono essere entrambe dimostrate o giustificate.
L'antinomia di Epimenide o ''Paradosso del mentitore'', nota fin dal VI secolo, è probabilmente uno dei più noti esempi: "''il cretese Epimenide afferma che tutti i cretesi mentono''". Se la proposizione è vera (i cretesi mentono) allora il suo significato implica che sia falsa (Epimenide mente e quindi i cretesi dicono la verità), ma se è falsa (i cretesi dicono la verità) ciò significa che è vera (Epimenide dice la verità e quindi i cretesi mentono). La proposizione appare contemporaneamente vera e falsa. A partire dagli anni venti del '900, sono state elaborate varie teorie per la risoluzione delle contraddizioni provocate dalle antinomie, soprattutto attraverso l'elaborazione di linguaggi multilivello o attraverso l'elaborazione di logiche polivalenti (quindi non-booleane).<div></div>
Si ha ambiguità lessicale, invece, quando una parola possiede più di un significato nella lingua a cui appartiene ([0026]), in tal caso la parola è definita ''polisemica''. In italiano, alcuni termini soggetti a questo tipo di ambiguità sono, ad esempio "''acuto''" o "''venti''". È questo genere di ambiguità che risulta critico per il riconoscimento dei nominativi. La difficoltà determinata dalle ambiguità sintattiche, infatti, riguarda l'individuazione corretta di soggetti, predicati e complementi di un periodo, mentre le ambiguità lessicali ostacolano la comprensione del significato del singolo lessema. Nel processo di riconoscimento è irrilevante determinare la funzione logica che il nominativo svolge nella frase, mentre è necessario essere certi che i termini che compongono il nominativo siano effettivamente dei nomi propri di persona o dei cognomi, non altri vocaboli del lessico comune. <div></div>
In linguistica, l'intervento con cui si toglie ambiguità a una parola o a una frase prende il nome di "disambiguazione" ([0027]). Il problema della disambiguazione automatica (in inglese ''Word Sense Disambiguation'' o, abbreviato, ''WSD'') riveste particolare importanza nelle ricerche sull'intelligenza artificiale e, in particolare, nell'elaborazione del linguaggio naturale. Si prevedono benefici della disambiguazione, ad esempio, in programmi di traduzione automatica, recupero dell'informazione o estrazione automatica di informazioni. Nell'analisi delle soluzioni esistenti in letteratura per la risoluzione delle ambiguità, ci si sofferma specialmente sulle ricerche incentrate sul trattamento dell'ambiguità lessicale, essendo essa la più rilevante per i nostri interessi.<div></div>
La ''WSD'' richiede due input necessariamente: un dizionario per specificare i sensi che devono essere disambiguati e un corpus di dati linguistici da disambiguare. Nello scenario più realistico, si trattano testi le cui parole non sono note a priori e risulta molto onerosa la produzione del corpus, essendo infatti necessaria la valutazione di un operatore umano per verificare la correttezza delle disambiguazioni effettuate dagli algoritmi (''supervised learning'').<div></div>
Uno tra i principali dizionari semantici-lessicali utilizzati della lingua inglese è ''WordNet'' ([0029]), mentre alcuni dei database equivalenti che trattano l'italiano sono ''BabelNet'' ([0030]), ''ItalWordNet'' ([0031]) e ''MultiWordNet'' ([0032]).
Un elemento importante da considerare è che le prestazioni di disambiguazione per la lingua inglese, impiegando ''WordNet'', risultano corrette tra l'80% e il 90% delle volte ([0028]), percentuali discrete ma non sufficienti per avere la totale garanzia.<div></div>
I fattori che ostacolano la realizzazione di algoritmi di intelligenza artificiale per la disambiguazione sono molteplici:
# Differenze tra dizionari impiegati: i database prima citati si basano su varie fonti che raggruppano semanticamente in maniera diversa i vocaboli, quindi programmi sviluppati con dizionari diversi generalmente hanno performance differenti.
# Complessità della codifica di parte del discorso: per poter disambiguare correttamente un termine è importante riuscire a comprendere correttamente il contesto in cui è inserito, operazione non banale.
# Varianza tra giudici: i supervisori dell'apprendimento degli algoritmi possono avere opinioni diverse, o semplicemente sbagliare, nella valutazione delle disambiguazioni, ciò porta ad algoritmi che hanno comportamenti diversi.
# Impossibilità di applicare la disciplina della ''pragmatica'', ossia la logica del ''buon senso'': per identificare correttamente il senso di alcune parole, ad esempio nella comprensioni di anafore e catafore, è necessario applicare il buon senso.
# Dipendenza del senso delle parole dai contesti: ogni scenario richiede la propria divisione del significato delle parole in sensi rilevanti. In un contesto informatico, ad esempio, il termine "''mouse''" deve essere ricondotto al dispositivo di puntamento, non al cognome del celebre personaggio Disney ''Mickey Mouse''; viceversa dovrà invece avvenire in un contesto di letteratura a fumetti.<div></div>
Laddove la ''WSD'' è una tecnica molto generale e che mira a risolvere un'ambiguità riguardante una qualunque parola, per le finalità del servizio oggetto di questa tesi è sufficiente risolvere le ambiguità dei nomi e dei cognomi.
Uno dei difetti che il servizio presenterebbe adottando un approccio ''WDS'' è legato alla impredicibile formattazione dei documenti, che aggiunge informazione semantica al testo ma introduce complessità nella individuazione automatica delle parti che formano il contesto; un altro difetto dipende dalla vastità del lessico da elaborare, essendo i documenti da trattare forniti dai più disparati utenti, su qualunque genere di argomento e relativi ai più vari ambiti.<div></div>

La strategia che sarà adottata per risolvere la problematica del riconoscimento dei nominativi sarà impostata attraverso un modello ''pattern-based'', impiegando le ''regular expressions'' (''regex''). Esse risultano comunemente usate per effettuare operazioni di ricerca o sostituzione in un testo, di conseguenza se si riesce ad individuare un pattern associato ad un nominativo dato, allora sarà possibile processare il documento ricercando le occorrenze del nominativo e "minimizzarlo" opportunamente.<div></div>

Le ''regular expressions'' risultano particolarmente efficaci poiché, se opportunamente progettate, possono identificare un nominativo indipendentemente dal significato linguistico del contesto in cui è calato, basandosi piuttosto sui singoli caratteri che compongono i lessemi analizzati; permettono, di conseguenza, di effettuare una valutazione estremamente minuziosa, riducendo al minimo le possibilità di errori.<div></div>
Un algoritmo di risoluzione ''pattern-based'' risulta, inoltre, più efficiente nell'esecuzione, in generale, di un algoritmo di intelligenza artificiale; per fornire la risposta il più velocemente possibile ad un utente, fruitore del servizio via web, l'approccio di riconoscimento tramite pattern è il più indicato.<div></div>

====Definizione dei pattern====
Nella progettazione del servizio si adotta, come detto, un approccio ''pattern-based'' per il riconoscimento dei nominativi. In linea di massima è opportuno che vengano riconosciuti più nominativi possibili e allo stesso tempo che la correttezza dell'identificazione di un nominativo sia garantita, quindi bisogna individuare dei pattern non troppo stringenti ma neppure troppo laschi. Per analizzare come i pattern devono essere strutturati si prende come caso di studio un generico nominativo, ad esempio ''Lorenzo Mario Amorosa''. Nel documento esso può comparire esattamente come appena indicato, ma anche in altre plausibili varianti, in cui l'ordine dei termini viene alterato, si pensi ad esempio ad "Amorosa Lorenzo Mario" o "Mario Lorenzo Amorosa", o in altre varianti ancora in cui alcuni nomi non compaiono, come in "Lorenzo Amorosa". Bisogna tuttavia supporre un limite alla variabilità: si osserva infatti che il cognome deve sempre comparire (il solo nome ''Lorenzo'' non è riconducibile a ''Lorenzo Mario Amorosa'') e che esso inoltre deve essere necessariamente anteposto o posposto, ma non interposto, ai nomi (è poco ragionevole ricondurre "Lorenzo Amorosa Mario" a "Lorenzo Mario Amorosa'').<div></div>
Questa prima specifica permette di ricondursi a una soluzione generale, sufficiente nella maggior parte dei casi, ma che non risolve alcune criticità. Un nominativo può, in alcuni documenti, comparire manifestandosi unicamente attraverso il cognome (riferendoci all'esempio precedente, ''Lorenzo Mario Amorosa'' apparirebbe nella forma ''Amorosa''). Sorge qui il problema che molti dei cognomi italiani hanno un significato proprio nel linguaggio comune; ad es., nella frase ''una relazione amorosa è bella'' è errato considerare la parola ''amorosa'' come cognome di un nominativo. Per risolvere questo genere di ambiguità si potrebbe pensare che per stabilire che il termine ''Amorosa'' sia un cognome sia sufficiente verificare che esso inizi con una lettera maiuscola, ma ciò può verificarsi anche perché la parola si trova ad inizio di frase. Inoltre, vari cognomi italiani possono iniziare con una lettera minuscola (''de Angelis'', ''d'Onofrio'', etc.), quindi basare l'identificazione di un cognome sul fatto che la sua prima lettera sia in maiuscolo non è in generale un metodo valido. Volendo in maniera prioritaria garantire il corretto funzionamento del servizio, e quindi attuare le procedure di anonimizzazione solo sui nominativi senza applicarle erroneamente ad altri termini, risulta necessario evitare il trattamento dei nominativi che si manifestano con i soli cognomi. Per via del contesto e dei significati che i cognomi possono assumere, infatti, risulta spesso impossibile distinguerli da parole del linguaggio comune.

Ci si concentra, quindi, nello studio di nominativi composti da un cognome seguito o preceduto da uno o più nomi.<div></div>
Si rappresenta dunque in formato di ''regular expression'' il pattern attualmente ideato. Per semplicità espositiva, si definisce il tag <span style="font-family: monospace;"><nomi></span> come l'insieme delle permutazioni di tutti i nomi del nominativo più l'insieme delle permutazioni di tutti i possibili sottoinsiemi di nomi del nominativo. Considerando il nominativo preso precedentemente come caso di studio, ad esempio, si avrebbe:
<div></div>
<span style="font-family: monospace;"> <nomi> = Lorenzo Mario|Mario Lorenzo|Lorenzo|Mario</span>
<div></div>
Posto inoltre il tag <span style="font-family: monospace;"><cognome></span> ad indicare il cognome contenuto nel nominativo e il tag <span style="font-family: monospace;"><regex></span> ad indicare la ''regular expression'' associata al nominativo, si ottiene:
<div></div>
<span style="font-family: monospace;"> <regex> := <cognome> (<nomi>)|(<nomi>) <cognome></span>
<div></div>
Una osservazione sottile ma di fondamentale importanza per la corretta progettazione delle ''regular expressions'' sta nella piena comprensione della semantica dell'operatore di scelta, espresso con il carattere ''pipe'' ("|"). Un qualunque ''engine'' di elaborazione delle ''regex'', infatti, interrompe la valutazione di una stringa non appena può stabilire se tale stringa fa match o meno con il pattern dato, senza quindi necessariamente valutarlo nella sua interezza, come parimenti avviene nelle valutazioni ''a corto circuito'' delle espressioni logiche nei linguaggi di programmazione. Ogni nominativo avrà a sè associato un pattern che lo rappresenta in più possibili sequenze di caratteri; per effettuare una corretta "minimizzazione" dei dati è necessario che le sequenze contenenti tutti i nomi sia poste per prime, mentre quelle contenenti un singolo nome per ultime.<div></div>
In questa prima formulazione della ''regex'', inoltre, si è posto come separatore unicamente lo spazio bianco, ma alcuni documenti potrebbero contenere dei nominativi i cui termini sono separati da altri caratteri, come ad esempio una virgola nel caso di "Amorosa, Lorenzo Mario". Per poter quindi identificare un nominativo anche in questi casi, si potrebbe considerare un qualunque carattere di interpunzione come possibile separatore dei termini del nominativo.
Adottando questa soluzione si ha però come effetto collaterale che risultano critici i casi in cui nel testo sono presenti dei nominativi soggetti ad omonimia. Si consideri una generica frase contenente una sequenza di nominativi, ad esempio ''Amorosa Lorenzo, Mario Giacomo e Fabio Rossi'', e si supponga che i nominativi da trattare siano ''Amorosa Lorenzo Mario'', ''Mario Giacomo'' (in cui la parola ''Mario'' è il cognome) e ''Fabio Rossi''. Gli ultimi due nominativi compaiono nella frase nella loro forma estesa, mentre il primo compare con il solo nome ''Lorenzo'' (eventualità possibile considerando la definizione del pattern precedentemente data). Considerando la virgola come carattere separatore dei termini del nominativo, la sequenza di parole ''Amorosa Lorenzo, Mario'' sarebbe ricondotta, venendo elaborata per prima, ad ''Amorosa Lorenzo Mario'', mentre rimarrebbe non trattata la parola ''Giacomo'', in quanto il cognome ''Mario'' che gli era associato è stato già identificato come un nome del nominativo ''Amorosa Lorenzo Mario'' ed il termine ''Giacomo'' preso singolarmente non rappresenta un nominativo.<div></div>
Prima di valutare ulteriormente le problematiche relative alle omonimie, si possono scegliere due approcci per risolvere questo specifico caso:
# Si riconduce una sequenza di parole ad un nominativo se e solo se tutti i suoi nomi sono contenuti nella sequenza
# Si considerano come separatori dei termini contenuti nei nominativi solo spazi bianchi, tabulazioni e a capo, non gli altri segni di punteggiatura.
<div></div>
Entrambe le strategie sono valide, in quanto risolvono il problema garantendo la corretta identificazione dei nominativi, ma allo stesso tempo entrambe presentano lo svantaggio di ridurre le sequenze di parole riconducibili a dei nominativi, aumentando le possibilità che alcuni di essi non vengano trattati.
Si consideri nuovamente il nominativo preso come caso di studio ''Amorosa Lorenzo Mario'': applicando la prima strategia, non sarebbe possibile ricondurgli la sequenza ''Amorosa Lorenzo'', mentre applicando il secondo metodo non sarebbe riconducibile la sequenza ''Amorosa, Lorenzo Mario''.
Si decide di attuare la seconda strategia, in quanto è opportuno non imporre vincoli troppo stringenti sui nomi e poiché nella gran parte dei casi i termini dei nominativi nei documenti sono separati tra loro da caratteri quali spazi bianchi, tabulazioni ed a capo.<div></div>
Un altro elemento su cui porre l'attenzione è la possibilità che i documenti da trattare contengano dei nominativi scritti interamente in maiuscolo o minuscolo, di conseguenza è conveniente che le ''regular expressions'' siano progettate ''case-insensitive''.<div></div>
Un ulteriore punto su cui bisogna soffermarsi è la posizione all'interno di un periodo in cui un nominativo può comparire, in particolare si vogliono evitare quei casi critici in cui uno dei termini del nominativo è una sotto-stringa di un'altra parola del testo (si pensi ad ''amorosa'' in ''clamorosa''). Come regola generale si può stabilire che è sempre necessario che un nominativo sia preceduto e seguito da un ''carattere non alfabetico''. Un caso particolare si presenta quando il nominativo è posto ad inizio o a fine documento, situazione in cui quindi esso non è preceduto o non è seguito da alcun carattere: entrambe le posizioni sono da considerare corrette.<div></div>
È opportuno ora definire il concetto di ''carattere non alfabetico'', e ciò si può fare più facilmente ragionando sul problema in logica positiva; infatti risulta più semplice individuare quei caratteri che rappresentano lettere piuttosto che quelli che rappresentano segni di interpunzione ed individuare ogni altro carattere che non può mai comporre una parola.

Inquadrando lo scenario di applicazione del servizio, molto probabilmente l'utente vorrà trattare un documento scritto nella lingua di uno dei paesi dell'Unione Europea, poiché il ''GDPR'' vige nei soli paesi membri dell'Unione.
Si può, quindi, ipotizzare che i documenti trattati possono sì contenere parole e nominativi stranieri, ma che i caratteri contenuti siano appartenenti all'alfabeto latino (''Latin script''), usato in molti stati nel mondo e da tutti i principali stati europei (fatta eccezione per la Grecia ed alcuni stati che scrivono in caratteri cirillici).
Inoltre, testi scritti in altri alfabeti, come esempio il cinese, l'arabo o il cirillico, vengono generalmente traslitterati. Considerare, quindi, ''caratteri non alfabetici'' tutti i caratteri diversi dalle lettere contenute nell'alfabeto latino sarebbe di conseguenza estremamente riduttivo ed inoltre in questo modo non si terrebbe conto delle lettere accentate, molto utilizzate anche nella lingua italiana.
<div></div>(XXXX QUI IMG [0F00])<div></div>
Per risolvere il problema facciamo riferimento alla codifica standard Unicode dell'alfabeto latino ([0022]); in essa è possibile individuare, oltre ai caratteri rappresentanti le lettere nella codifica ''ASCII'' classica, i caratteri rappresentanti le lettere nella codifica standard ''ISO/IEC 8859-1'' ([0023]), encoding orientato principalmente alla rappresentazione delle lingue dell'Europa occidentale.

<div></div>
<center><i>Caratteri latini nei primi due blocchi dello standard Unicode</i></center>
{| class="nounderlines" border="1" cellpadding="2" cellspacing="0" style="border-collapse:collapse"
|----- align="center"
!style="background:#ccf; text-align:center; font-weight: bold;"|U+
!style="text-align:center; font-weight: bold;"|0||style="text-align: center; font-weight: bold;"|1||style="text-align: center; font-weight: bold;"|2||style="text-align: center; font-weight: bold;"|3||style="text-align: center; font-weight: bold;"|4||style="text-align: center; font-weight: bold;"|5||style="text-align: center; font-weight: bold;"|6||style="text-align: center; font-weight: bold;"|7||style="text-align: center; font-weight: bold;"|8||style="text-align: center; font-weight: bold;"|9||style="text-align: center; font-weight: bold;"|A||style="text-align: center; font-weight: bold;"|B||style="text-align: center; font-weight: bold;"|C||style="text-align: center; font-weight: bold;"|D||style="text-align: center; font-weight: bold;"|E||style="text-align: center; font-weight: bold;"|F||style="text-align: center; font-weight: bold;"|Block||style="text-align: center; font-weight: bold;"|#
|-
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0040
|style="background:#fff"|@||A||B||C||D||E||F||G||H||I||J||K||L||M||N||O
|rowspan="4" style="background:#fff" align:"center"|C0 Controls and Basic Latin<br>0000–007F<br>(identical to ASCII)
|rowspan="4" style="background:#fff"|52
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0050
|P||Q||R||S||T||U||V||W||X||Y||Z||style="background:#fff"|[||style="background:#fff"|\||style="background:#fff"|]||style="background:#fff"|^||style="background:#fff"|_
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0060
|style="background:#fff"|`||a||b||c||d||e||f||g||h||i||j||k||l||m||n||o
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0070
|p||q||r||s||t||u||v||w||x||y||z||style="background:#fff"|{||style="background:#fff"||||style="background:#fff"|}||style="background:#fff"|~||style="background:#fff; font-size:75%"|DEL
|-
!colspan="19"|
|----- align="center" style="background:#fff"
!style="background:#fff; text-align:center; font-weight: bold;"|00A0
| ||¡||¢||£||¤||¥||¦||§||¨||©||ª||«||¬||||®||¯
|rowspan="6" style="background:#fff" align="center"|C1 Controls and Latin-1 Supplement<br>0080–00FF<br>(identical to ISO/IEC 8859-1)
|rowspan="6" style="background:#fff"|62
|----- align="center" style="background:#fff"
!style="background:#fff; text-align:center; font-weight: bold;"|00B0
|°||±||²||³||´||µ||¶||·||¸||¹||º||»||¼||½||¾||¿
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00C0
|À||Á||Â||Ã||Ä||Å||Æ||Ç||È||É||Ê||Ë||Ì||Í||Î||Ï
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00D0
|Ð||Ñ||Ò||Ó||Ô||Õ||Ö||style="background:#fff"|×||Ø||Ù||Ú||Û||Ü||Ý||Þ||ß
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00E0
|à||á||â||ã||ä||å||æ||ç||è||é||ê||ë||ì||í||î||ï
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00F0
|ð||ñ||ò||ó||ô||õ||ö||style="background:#fff"|÷||ø||ù||ú||û||ü||ý||þ||ÿ
|---- align="center" style="background:#f66"
|}
<div></div>

I caratteri indicati in rosso nella tabella sono tutti i possibili ''caratteri alfabetici'' che compaiono nei documenti scritti in 29 lingue diverse ([0023]), tra le quali sono presenti l'italiano, l'inglese, lo spagnolo, il tedesco e il portoghese.
Aggiungendo pochi altri caratteri all'insieme dei ''caratteri alfabetici'' appena mostrati, si riesce a rappresentare ogni parola di altre 12 lingue ([0023]), tra cui il francese, l'olandese, il ceco e il turco.<div></div>
I caratteri mostrati in tabella corrispondono ad una parte dei primi due blocchi dello standard Unicode che codificano l'alfabeto latino e, come già accennato in precedenza, essi sono presenti negli standard ''ASCII'' e ''ISO/IEC 8859-1''. I rimanenti ''caratteri alfabetici'', invece, sono presenti in estensioni dello standard Unicode per il ''Latin script''. Queste estensioni sono state realizzate per fornire il massimo supporto a tutte le lingue e contenenti molti simboli ad uso speciale, come ad esempio per la rappresentazione dei fonemi. Si osserva, inoltre, che i ''caratteri alfabetici'' definiti nelle estensioni dello standard Unicode sono presenti anche nella codifica ''ISO/IEC 8859-2'' o nelle versioni successive ([0023]).<div></div>
Definiti i ''caratteri non alfabetici'' come elementi di separazione tra un nominativo ed il testo in cui esso è inserito, occorre definire opportunamente la ''regex'' che al nominativo è associata.

Utili strumenti messi a disposizione dalle ''regular expressions'' sono i gruppi speciali ''lookahead'' e ''lookbehind''. Un pattern di un nominativo deve essere preceduto o seguito da una prestabilita sequenza di caratteri, la quale però non è parte del nominativo. Utilizzando i due costrutti citati, è possibile far sì che nell'elaborazione di una stringa facciano match solamente le parole effettivamente appartenenti al nominativo, non i caratteri che lo delimitano dal resto del testo, e allo stesso tempo che un nominativo faccia match se e solo se preceduto o seguito da una certa sequenza di caratteri. <div></div>
Per esprimere nella sintassi delle ''regex'' un carattere letterale in un qualunque alfabeto si può utilizzare il costrutto ''\p{L}'', che però risulta molto generale e troppo lasco per i requisiti considerati. Si può piuttosto valutare l'impiego del costrutto ''\p{Latin}'', il quale identifica un qualunque carattere alfabetico presente nell'alfabeto latino. Tra i caratteri corrispondenti al costrutto, però, ve ne sono alcuni che per le specifiche del servizio devono essere considerati ''caratteri non alfabetici'', come ad esempio i caratteri dei fonemi, i segni diacritici e gli indicatori ordinali; di conseguenza è necessario individuare una strategia ad hoc per risolvere questa problematica.<div></div>
Per chiarezza espositiva, si definisce il tag <span style="font-family: monospace;"><start></span>, per indicare un qualunque carattere non alfabetico o l'inizio stringa, il tag <span style="font-family: monospace;"><end></span>, per indicare un qualunque carattere non alfabetico o il fine stringa, ed il tag <extra>, per indicare i ''caratteri alfabetici'' non presenti negli standard ''ASCII'' o ''ISO/IEC 8859-1'':<div></div>
<span style="font-family: monospace;">
<extra> := ĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ
<br/>
<start> := (?<=[^A-Za-zÀ-ÖØ-öø-ÿ<extra>]|^)
<br/>
<end> := (?=[^A-Za-zÀ-ÖØ-öø-ÿ<extra>]|$)
</span>
<div></div>
Si osserva che si sono utilizzati i gruppi speciali prima descritti e che si sono inseriti i caratteri dello standard Unicode presentati in precedenza. Si definisce nuovamente la ''regular expression'' associata ad un generico nominativo. Applicando i tag appena definiti, il costrutto ''(?i)'' che rende il pattern ''case-insensitive'' ed il costrutto ''\s'' che rappresenta un carattere qualunque tra i separatori non visibili, ossia ''\r \n \t \f \v'' e lo spazio bianco, si ottiene:<div></div>
<span style="font-family: monospace;">
<regex> := (?i)(<start><cognome>\s+(<nomi>)|(<nomi>)\s+<cognome><end>)
</span>
<div></div>
Si osserva, inoltre, che in questa nuova formulazione della ''regular expression'' i nomi sono da intendersi separati tra loro da ''\s+''.<div></div>
A questo punto si è quasi giunti alla formulazione finale del pattern da associare ad un nominativo, rimangono solo da trattare alcuni casi critici non ancora risolti.<div></div>
Si è già presentato in precedenza il problema legato al fatto che alcuni cognomi possono avere un significato proprio nel lessico comune e che ciò costringeva, quindi, ad abbandonare l'idea di trattare nominativi formati dal solo cognome. Questa problematica di ambiguità si presenta anche con alcuni nomi (si pensi, ad esempio, al nome ''Gioia''). Ciò non rappresenta generalmente un problema, in quanto la coppia nome-cognome che forma il nominativo, presa complessivamente, non è soggetta ad ambiguità. Esistono, però, dei casi in cui questo non è vero. Si prenda in analisi il nominativo ''Gioia Grande'': risulta evidentemente soggetto a rischio di ambiguità. Una soluzione che si può adottare, per risolvere questo caso critico, si basa sull'associazione di un pattern più stringente ai nominativi. In particolare, si osserva che i nomi propri di persona compaiono sempre ed obbligatoriamente, in un documento grammaticalmente corretto, con la prima lettera maiuscola ([0024]). I cognomi, invece, non sono soggetti ad una regola così stringente: un cognome iniziante con una lettera minuscola (come ''de Rosa'') in alcuni casi, ad esempio se posto dopo un punto fermo, può comparire scritto con la prima lettera sia maiuscola che minuscola; naturalmente, in nessuna occorrenza un cognome che inizi con una lettera maiuscola potrà comparire con una minuscola. <div></div>
Occorre quindi ridefinire, alla luce di queste osservazioni, la ''regex'' associata ad un nominativo, poiché precedentemente era stata posta interamente ''case-insensitive''. Nel pattern, in particolare, i nomi dovranno sempre iniziare con una maiuscola, mentre i cognomi avranno questo vincolo solo se nel nominativo compaiono con la prima lettera maiuscola. Si mostra quindi quali sono i tag <span style="font-family: monospace;"><nomi></span> e <span style="font-family: monospace;"><cognome></span> associati a due nominativi, ad esempio ''Gioia Grande'' e ''Antonio de Rosa''. <div></div>
Per ''Gioia Grande'' si ha:<div></div>
<span style="font-family: monospace;"><nomi> = G((?i)ioia)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = G((?i)rande)</span>
<div></div>
Per ''Antonio de Rosa'' si ha:<div></div>
<span style="font-family: monospace;"><nomi> = A((?i)ntonio)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = (?i)de Rosa</span>
<div></div>
Si presenta dunque la definizione finale del tag <span style="font-family: monospace;"><regex></span>. Nella definizione il tag <span style="font-family: monospace;"><nomi></span> è definito il base al numero di nomi del nominativo ed il tag <span style="font-family: monospace;"><cognome></span> è definito in base al carattere iniziale del cognome.<div></div>
<span style="font-family: monospace;">
<regex> := <start><cognome>\s+(<nomi>)|(<nomi>)\s+<cognome><end>
</span>
<div></div>
Vengono inoltre mostrati i valori dei due tag <span style="font-family: monospace;"><nomi></span> e <span style="font-family: monospace;"><cognome></span> per il nominativo preso come caso di studio in fase iniziale, ossia ''Amorosa Lorenzo Mario''. Si ottiene:<div></div>
<span style="font-family: monospace;"><nomi> = L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = A((?i)morosa)</span>
<div></div>
Infine, per completezza, viene mostrata la ''regular expression'', associata a quest'ultimo nominativo, risolvendo tutti i tag che la compongono:
<div></div>
<span style="font-family: monospace;">
<regex> = (?<=[^A-Za-zÀ-ÖØ-öø-ÿĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ]|^)(A((?i)morosa)\s+(L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario))|(L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario))\s+A((?i)morosa))(?=[^A-Za-zÀ-ÖØ-öø-ÿĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ]|$)
</span>
<div></div>

====Gestione delle omonimie====

Nei ragionamenti che hanno portato alla formulazione della ''regular expression'' associata ai nominativi, si è tenuto conto di possibili ambiguità con termini appartenenti al linguaggio comune, risolte con l'introduzione nel pattern di stringhe ''case-sensitive'', e di possibili nominativi posti in sequenza parzialmente omonimi (ossia aventi un nome o il cognome in comune tra loro), gestite con l'imposizione dei soli caratteri separatori non visibili come delimitatori delle parole componenti un nominativo. Per rendere l'analisi completa occorre valutare come ci si debba comportare in altri possibili casi di omonimia. Si osserva, per inciso, che nel pattern individuato nella sezione precedente il tag <span style="font-family: monospace;"><nomi></span> è stato l'unico non definito formalmente. La definizione di tale tag infatti dipende, oltre che dai nomi del nominativo, anche dall'insieme complessivo dei nominativi da trattare presenti nel documento.<div></div>
Il caso più semplice di omonimia, che si verifica quando un solo nome o il solo cognome di un nominativo coincide con un nome o il cognome di un altro (come nel caso di ''Lorenzo Mario Amorosa'' e ''Stefano Amorosa''), risulta già ben gestito dall'attuale formulazione del pattern. Infatti, un riconoscimento è determinato quando almeno un nome e il cognome del nominativo appaiono in sequenza.<div></div>
Il problema si complica quando un nominativo ha due o più componenti in comune con un altro. Si osserva che se l'omonimia riguarda solo i nomi dei nominativi, ciò non risulta problematico, in quanto il cognome, supposto sempre presente nel pattern, funge da elemento di disambiguazione. Si considera da ora, quindi, che i nominativi abbiano il medesimo cognome e si analizzano i casi in cui anche uno o più nomi risultano in comune, attraverso degli esempi:
* Nomi_A = {"Lorenzo", "Mario", "Luca"}; Nomi_B = {"Stefano", "Mario"}
<div></div>(QUI IMG [0F01])<div></div>
In questo caso sono elementi di disambiguazione i nomi ''Lorenzo'' e ''Luca'' per il primo nominativo e ''Stefano'' per il secondo, bisognerà quindi far sì che almeno uno tra tali nomi compaia sempre nelle ''regex'' associate ai nominativi in questione. L'occorrenza ''Mario <cognome>'' rimane ambigua e non può essere trattata.
* Nomi_A = {"Lorenzo", "Mario", "Luca"}; Nomi_B = {"Mario", "Luca"}
<div></div>(QUI IMG [0F02])<div></div>
L'insieme Nomi_B risulta un sottoinsieme di Nomi_A, di conseguenza solo il primo nominativo presenta degli elementi utili per risolvere l'ambiguità. Nel pattern relativo al primo nominativo dovrà essere presente almeno un tra i nomi non in comune, mentre il pattern del secondo nominativo rappresenterà inevitabilmente espressioni ambigue poiché riconducibili all'altro. Le soluzioni possibili sono due: rifiutarsi di effettuare il trattamento del secondo nominativo oppure decretare che esso è riconosciuto se e solo se appare nella sua forma estesa, presentando quindi tutti i nomi. Quest'ultima soluzione è ragionevole e la si sceglie, poiché così si aumentano, per quanto possibile, le sequenze "minimizzabili", e viene inoltre messo in conto di informare l'utente opportunamente sulla gestione di questo genere di omonimia per rendere le operazioni trasparenti.
* Nomi_A = Nomi_B = {"Lorenzo", "Mario", "Luca"}
<div></div>(QUI IMG [0F03])<div></div>
Qualora l'insieme dei nomi dei due nominativi sia identico risulta impossibile distinguerli e non possono in alcun modo essere trattati, poiché l'ordine con cui compaiono i nomi di un nominativo non rappresenta un elemento di disambiguità. I dati appartenenti a persone completamente omonime contenuti in uno stesso documento, quindi, non sono "minimizzabili" distintamente.<div></div>
Si osserva che è di fondamentale importanza che i documenti che gli utenti forniscono siano grammaticalmente corretti, in quanto un errato uso dei segni di interpunzione può rendere impossibile l'applicazione delle ''regular expression''. Si prenda ad esempio una sequenza anomala di caratteri in cui non è corretto l'uso delle virgole, come "''Amorosa Mario Rossi Giacomo''": supponendo che nel documento si vogliano trattare i nominativi ''Amorosa Mario'', ''Rossi Mario'' e ''Rossi Giacomo'', risulta impossibile identificare quali tra questi siano rappresentatati nella sequenza.<div></div>
In conclusione, risultano quindi individuate le strategie che permettono di formulare ''regular expressions'' anche per i nominativi soggetti ad omonimia.

====Formattazione dei documenti====

I documenti prodotti in enti ed organizzazioni presentano generalmente formattazioni e non sono puramente testuali. Si vuole qui considerare quale debbano essere le interpretazioni più adatte da dare agli elementi grafici per rendere sempre efficace il riconoscimento dei nominativi. In particolare, quindi, non si tratteranno gli elementi di punteggiatura, come parentesi o virgolette, poiché già compresi nelle ''regex'', bensì tutti gli elementi che in un pattern composto da caratteri non sono espressi. Si inizia dunque la rassegna:
* Elementi di formattazione del testo
I font, la dimensione dei caratteri, il grassetto, il corsivo, l'evidenziazione e tutti i possibili elementi di modifica della apparizione grafica del testo non alterano il significato dei lessemi coinvolti. Se il cognome di un nominativo è posto in grassetto ed il nome no, ad esempio, la coppia nome-cognome rappresenta sempre il nominativo iniziale; lo stesso vale per gli altri elementi citati.
* Aree di comparizione del testo
In genere ogni documento è formato da più sezioni, ha un corpo principale ed eventuali titoli, note a piè pagina, intestazioni ed altre possibili aree. Il trattamento di "minimizzazione", secondo il ''GDPR'', deve essere effettuato al documento in ogni sua parte, ma ogni sezione deve essere elaborata in maniera indipendente dalle altre sezioni in quanto rappresenta un blocco logico a sé. Ciò significa che, ad esempio, bisogna individuare eventuali nominativi presenti nel titolo, ma non bisogna considerare nominativo una sequenza di parole che è posta in parte nel titolo e in parte nel primo paragrafo del testo.
* Elementi blocco
Gli elementi blocco, come ad esempio le immagini, possono causare un'interruzione netta in un paragrafo, suddividendolo quindi in più blocchi logici, che devono essere analizzati separatamente; tuttavia nel caso in cui questi elementi siano posti ''fluttuanti'', ossia ancorati ai bordi della pagina, il testo scorre in un unico flusso e forma quindi un unico blocco logico.
* Divisione in sillabe
Un problema rilevante nella formattazione del documento è che spesso, per esigenze estetiche, contiene delle parole divise in sillabe poste su righe diverse e separate da un trattino. Ovviamente se un nome va a capo a fine linea non perde il suo significato semantico, bisognerà quindi continuare a riconoscerlo.
* Tabelle
Molti documenti, specialmente quelli contenenti ingenti quantità di nominativi, possono essere strutturati in forma tabellare. Trascurando una trattazione per esteso delle modalità con cui i nominativi potrebbero comparire nelle tabelle, si considera esclusivamente il caso di gran lunga più ricorrente. In genere, infatti, in una tabella contenente dei nominativi, essi sono presenti nella stessa colonna o in colonne contigue: l'una contenente i nomi, l'altra il cognome, o viceversa. Senza basarsi sull'intestazione delle colonne, si può valutare se il contenuto di due celle adiacenti poste su di una stessa riga faccia match con il pattern di un nominativo, ed in caso ciò accada si può affermare la coppia di celle individuata rappresenta un nominativo.<div></div>
Si osserva che si sono fornite solamente le interpretazioni più plausibili e comuni a questi elementi grafici e non si è ideato alcun particolare algoritmo per la loro elaborazione. L'espressione di tali strutture, infatti, è fortemente determinata dal formato in cui il documento è redatto. Si rimanda, quindi, ai capitoli successivi per specificazioni ulteriori della soluzione. Occorre notare, infine, che gli elementi di formattazione non sono descritti da stringhe nel formato delle ''regular expressions'': bisognerà quindi integrare gli elementi presentati in questa sezione con l'approccio ''pattern-based'' adottato.

===Analisi dell'usabilità===

====Elenco dei nominativi da trattare esplicitamente espressi come dati in input====

In questo caso, per usufruire del servizio, l'utente deve fornire un documento contenente una serie di nominativi da trattare. Una garanzia della corretta elaborazione del documento si ha richiedendo all'utente stesso quali siano i nominativi da trattare: in questo modo potranno essere "minimizzati" i dati (cioè i nominativi) di tutte e sole le persone espressamente richieste. In molti plausibili scenari, infatti, è necessario anonimizzare solo alcuni dei nominativi presenti nel documento; ad esempio in un atto giudiziario serve anonimizzare le parti in causa ma non i magistrati.

Questa configurazione del servizio permette quindi all'utente di avere il massimo controllo possibile del risultato. Tuttavia questo approccio è poco pratico nel caso in cui i documenti da trattare contengano grandi quantità di nominativi diversi e, magari, l'utente che ne richiede il trattamento non li conosce; si pensi ad esempio a lunghe graduatorie di concorsi o altro. Si osserva inoltre che anche per pochi nominativi l'usabilità può degradare, se l'inserimento viene fatto con estemporanea digitazione, esposta anche al rischio di possibili errori di battitura, con conseguenti noiose ripetizioni delle operazioni.

Si osserva, infine, che il sistema progettato è sufficientemente robusto nel trattare i nominativi in input espressi da un utente che ha digitato caratteri maiuscoli o minuscoli violando le convenzioni grammaticali. Supposto che il documento trattato debba essere grammaticalmente corretto, infatti, si ha la garanzia che i nomi ivi presenti comincino con una maiuscola; è sufficiente, quindi, forzare una conversione ''to-upper-case'' dei nomi inseriti dall'utente e le ''regex'' progettate funzionano correttamente. Un discorso a parte va fatto per i cognomi inseriti dall'utente, in quanto essi possono comparire con la prima lettera sia maiuscola che minuscola. L'inserimento di un cognome iniziante con una minuscola non crea grossi problemi, in quanto in tal caso la ''regex'' risultante sarebbe totalmente ''case-insensitive'' per il cognome, mentre l'aggiunta di un cognome cominciante con una maiuscola determina una ''regex'' ''case-insensitive'' per la prima lettera del cognome; qualora quindi un utente inserisse un nominativo tutto in maiuscolo, le occorrenze del cognome, presenti nel documento, inizianti con una lettera minuscola non verrebbero riconosciute.
Per le altre lettere dopo la prima, sia per i nomi che per i cognomi, il pattern è stato progettato ''case-insensitive'', quindi non emergono problemi. <div></div>
In sintesi, il rischio che vengano introdotte delle ambiguità lessicali, incaricando l'utente dell'inserimento dei nominativi, è piuttosto basso ed il controllo che si ha sui nominativi è il massimo desiderabile, mentre i requisiti di usabilità risultano penalizzati.

====Elenco dei nominativi da trattare dedotti automaticamente da un dizionario====

Se si desidera privilegiare la tematica dell'usabilità nella progettazione del servizio, risulta necessario individuare delle strategie che semplifichino il più possibile i compiti che devono essere svolti dall'utente. L'unica operazione che inevitabilmente resta a suo carico è l'upload del documento da trattare; non è infatti necessario richiedergli l'elencazione dei nominativi dei nominativi da trattare, in quanto questi possono essere dedotti automaticamente impiegando dei dizionari, dei quali va quindi valutato il contenuto e le modalità di utilizzo. <div></div>

Si scarta subito l'ipotesi di dedurre automaticamente i nominativi basandosi unicamente sul fatto che le iniziali di nomi e cognomi siano maiuscole; come già argomentato infatti l'uso delle lettere maiuscole non è limitato solo a questi usi e, inoltre, non si può avere la certezza che un cognome inizi con una maiuscola.

Sono disponibili fortunatamente alcuni dizionari di nomi ed altri di cognomi, in diverse lingue; si fa qui riferimento a quelli di "Data World" (un'azienda focalizzata sulla raccolta, produzione e pubblicazione di dataset: https://data.world) ([0037]).

Si inizia l'analisi inquadrando le dimensioni che un dizionario contenente nomi o cognomi avrebbe. Risalta subito all'occhio la differenza tra il numero di termini contenuti nei due casi: facendo riferimento ai soli nomi e cognomi italiani, risultano esistenti circa 350.000 cognomi ([0036]) e circa 9.000 nomi, dei quale circa 5.000 maschili e circa 4.000 femminili ([0037]); il numero dei cognomi è quindi quasi 40 volte più grande del numero dei nomi.<div></div>
Si ipotizza, per chiarire le idee, di applicare questi dizionari in uno scenario reale, in cui, ad esempio, si vuole trattare un documento di 10 pagine contenente 5.000 parole. Si trascurano inoltre i meccanismi che permettono di ricondurre un nome od un cognome ad un nominativo per concentrarsi unicamente sul numero di confronti necessari da effettuare nell'elaborazione. Nel peggiore dei casi possibili, ossia quando nessuna parola del documento compare tra i termini del dizionari, e dove occorre quindi confrontare ogni singola parola del documento con tutti i termini del dizionario, per semplice moltiplicazione si ottiene che l'impiego di un dizionario di nomi darebbe luogo a 45.000.000 confronti, mentre un dizionario di cognomi ben a 1.750.000.000 confronti. Se invece le parole nel documento fossero 50.000 si avrebbero 450.000.000 di confronti nel primo caso e 10.750.000.000 nel secondo. In sintesi, sebbene il rapporto tra il numero di confronti nei due casi rimanga sempre costante (circa 1:40) indipendentemente dalla lunghezza del documento, la differenza tra il numero di confronti cresce proporzionalmente al numero di parole che vengono sottoposte all'elaborazione. Per quantificare, infine, attraverso un unità di tempo, la differenza esistente tra l'impiego delle due diverse tipologie di dizionario, si realizza un semplice programma java, di cui si riporta qui sotto il contenuto del metodo principale, che realizza i confronti necessari attraverso l'uso di ''regular expression'':
<div></div>
<div style="font-family: monospace;">
final String regex = "\bLorenzo\b";<br/>
final String string = ... //testo di prova<br/>
<br/>
final Pattern pattern = Pattern.compile(regex, Pattern.MULTILINE);<br/>
final Matcher matcher = pattern.matcher(string);<br/>
int start, total;
<br/>
start = System.currentTimeMillis();
while (matcher.find()) {
System.out.println("Full match: " + matcher.group(0));
for (int i = 1; i <= matcher.groupCount(); i++) {
System.out.println("Group " + i + ": " + matcher.group(i));
}
} <br/>
total = System.currentTimeMillis() - start;
System.out.println("Total: " + total + " ms");
</div>
<div></div>
Eseguendo il test più volte, inserendo fino a 10 occorrenze della parola "Lorenzo" nel testo, si ha un tempo di elaborazione medio di circa 3 ms, con prestazioni di picco di 2 ms, ottenibili con poche occorrenze del nome presenti, e tempo di attesa massimo di 6 ms, dovuto alla presenza invece a una presenza più frequente del nome nel testo.
Questo fenomeno si comprende meglio ricordando che, come spiegato nel capitolo precedente, le ''regular expressions'' ottimizzano la ricerca, considerano le stringhe del testo trattato solo finché necessario, ossia fino a quando non vi è certezza che esse corrispondano o non corrispondano ad un match. Ogni volta che nel testo si presenta una parola che inizia con una lettera diversa dalla 'L' di "Lorenzo", la ricerca procede direttamente con la valutazione della parola successiva, ignorando i rimanenti caratteri della parola.

Risulta, invece, più onerosa la verifica della corrispondenza tra una stringa ed il pattern desiderato, poiché in questo caso vanno elaborati tutti i caratteri della parola. Come caso limite, si è posta come stringa da elaborare la sequenza di caratteri "Lorenzo " ripetuta 500 volte: il tempo di esecuzione medio del programma risultante, a parità di piattaforma, è stato di circa 25 ms.

Un'altra diretta conseguenza di questo meccanismo di confronto è che all'aumentare del numero di parole nel documento non corrisponde un eccessivo aumento del tempo di esecuzione: considerando un documento di 5000 parole, con 0 occorrenze del nome "Lorenzo" il tempo di esecuzione medio risulta di 9 ms, con 10 occorrenze di 10 ms, con 100 occorrenze di 15 ms.

Occorre precisare, prima di formulare ulteriori ragionamenti, che in documento di 5.000 parole potranno essere presenti al più 2500 coppie nome-cognome; in un dizionario con più di 2.500 termini almeno uno di questi non contribuirà nell'individuazione di un nominativo. Se poi sono presenti altre parole oltre ai nominativi nel documento, la percentuale di nomi che presenterà 0 occorrenze crescerà di conseguenza. Ad ogni modo, si sceglie di sviluppare i ragionamenti considerando necessario il tempo medio di 10 ms per individuare le occorrenze di un termine di un dizionario in un documento di 5.000 parole; questo tempo è sicuramente maggiore rispetto al caso reale, ma valutando per eccesso questo valore è possibile trascurare il tempo impiegato nelle altre operazioni di routine a supporto dell'algoritmo di ricerca.

Ritornando all'esempio di partenza, considerando quindi necessari 10 ms per individuare le occorrenze di un termine di un dizionario in un documento di 5.000 parole, risulta che l'identificazione di tutti i cognomi contenuti nel testo richieda circa 3.500 secondi, (quasi un'ora!), mentre l'individuazione dei nomi "solo" 90 secondi.
I tempi di attesa che l'utente dovrebbe aspettare sono estremamente elevati e irragionevoli, specialmente se calati nel contesto nelle ''web application''. Come primo espediente per ovviare al problema si decide di abbandonare completamente l'idea di impiegare un dizionario di cognomi, in quanto, seppur si individuassero delle soluzioni in grado di effettuare il riconoscimento di tutte le occorrenze di un termine in un documento indipendentemente dalla lunghezza in solo 1 ms (irreale), sarebbero comunque necessari 3 minuti e 50 secondi per l'elaborazione. Non verranno quindi neppure trattate possibili soluzioni che prevedono l'applicazione di entrambi i dizionari.

I 90 secondi richiesti dal dizionario di nomi, invece, risultano anch'essi eccessivi, ma attraverso opportune valutazioni si possono individuare delle strategie che consentono la minimizzazione del tempo necessario all'elaborazione dei documenti. Tali metodi di ottimizzazione saranno trattati in un successivo capitolo, mentre ora ci si continua a concentrare sulle modalità di impiego del dizionario.

Per inciso, si osserva che i problemi di efficienza sono strettamente legati al riconoscimento automatico dei nominativi, in quanto in questo caso devono essere applicate quasi una decina di migliaia di ''regex'' diverse; nel caso in cui i nominativi da elaborare e le ''regex'' a loro associate siano noti, si ha a che fare con un numero esiguo di pattern da trattare e l'esecuzione del programma risulta infinitamente più rapida.<div></div>

Per migliorare l'efficacia del servizio sarebbe opportuno introdurre nel dizionario anche nomi stranieri, sempre più diffusi in una società sempre più globalizzata. Il tempo di esecuzione medio del riconoscimento, già critico, crescerebbe ulteriormente: si decide allora di introdurre nel dizionario i soli nomi inglesi, in totale quasi 5500 ([0037]). Considerando sempre un tempo medio di esecuzione di 10 ms per nome, con un dizionario di circa 14.500 termini si avrebbe un tempo di esecuzione medio complessivo di 145 secondi, ossia pari a 2 minuti e 25 secondi, e risulta ancora possibile effettuare alcune ottimizzazioni che lo riducono ad un livello accettabile.

Una volta individuati i nomi contenuti nel documento occorre stabilire se essi fanno parte di un nominativo, progettando un'opportuna ''regular expression''. È importante notare che per conseguire questo scopo bisogna individuare la soluzione più efficiente possibile.

Un nominativo, come già ripetuto più volte, è composto da uno o più nomi e da un cognome. Individuato un nome, la priorità che si ha è verificare se accanto ad esso sia presente un cognome. Finora i cognomi sono stati supposti non regolamentati da alcun pattern specifico, ma è necessario formularne almeno uno per consentirne il riconoscimento automatico. È ragionevole supporre che un cognome sia formato da massimo due parole, separate da spazio o apostrofo, sempre inizianti entrambe con una maiuscola, fatta eccezione per la prima parola laddove essa sia una preposizione semplice o articolata oppure un articolo, tenendo conto dei possibili troncamenti, come <i>d'</i> e <i>dell'</i>. Inoltre per verificare se un termine adiacente al nome trovato rappresenti un nome si evita di impiegare nuovamente il dizionario per non gravare ulteriormente sul tempo di esecuzione. Inoltre, si nota che avendo supposto un cognome composto da massimo due parole inizianti con una lettera maiuscola, un altro nome, oltre quello trovato dal dizionario, viene già automaticamente riconosciuto qualora il cognome sia composto da una sola parola. Rinunciando ad individuare nominativi composti da tre nomi o più, si formula una ''regular expression'' per il riconoscimento automatico in seguito al identificazione di un nome, qui indicato con il tag <span style="font-family: monospace;"><nome></span>, supponendo il cognome come precedentemente indicato e ipotizzando la presenza di un ulteriore nominativo.
<div></div>
<div style="font-family: monospace;">
<prep> := d((a|e)(l(l[aeo]?)?|i|gli?)?|i)?|(ne|a|su)(l(l[aeo]?)?|i|gli)?|l[aeo]?|co[iln]?|i[ln]?|gli|per

<cognome> := (([A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]*|<prep>)('|\s))?[A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]+

<second_name> := [A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]+

<regex> := (<second_name>\s)?(<nome>)\s<cognome>|<cognome>\s(<nome>)(\s<second_name>)?
</div>
<div></div>
Nella scrittura della ''regex'' si è prestata particolare attenzione all'utilizzo della simbologia per rendere l'espressione il più performante possibile, attraverso il massimo sfruttamento dei cortocircuiti logici e l'opportuno ordinamento dei caratteri (sono stati anteposti i caratteri comuni a più preposizioni od articoli). Inoltre, per alleggerire la ''regex'' si è rinunciato all'utilizzo dei caratteri dell'alfabeto latino non appartenenti ai primi due blocchi Unicode.
<div></div>
È mostrata in figura la corretta elaborazione di 57 possibili casi di cognomi diversi
<div></div>(QUI IMG [0F04])<div></div>
Si osserva tuttavia che in alcune circostanze, come nella frase "''di Amorosa Lorenzo non si hanno notizie''", accade che un parola ("''di''" in questo caso), non sia parte del cognome ma il programma non è in grado di riconoscerlo. Questa ambiguità è fortemente dipendente dal contesto e non è possibile trattarla senza significativi degradi delle performance; quindi è necessario rinunciare a trattarla, accettando riconoscimenti erronei. In altre situazioni, invece, dove magari si sta elaborando la stringa contenente il nominativo ''Mario Lorenzo'', risulta impossibile determinare quale tra i due termini sia il nome e quale il cognome; cioè significa che l'unico trattamento di "minimizzazione" automatico che risulta ragionevole applicare è la sostituzione del nominativo con uno pseudonimo, non il troncamento o l'alterazione dei nomi.
In conclusione, con il riconoscimento automatico dei nominativi si migliora complessivamente l'usabilità del servizio, in quanto l'utente non deve digitare i nominativi, ma la latenza introdotta è notevole, si è soggetti a rischi di ambiguità e non è in alcun modo esprimibile la preferenza su quali nominativi si desidera "minimizzare" o meno. La soluzione così ideata non risulta quindi adeguata.

====Soluzione ibrida adottata====
Entrambe le tipologie di riconoscimento prima individuate hanno significativi problemi, si cerca quindi di sintetizzare una soluzione in grado di trarre i vantaggi dell'una e dell'altra. Risulta efficace, in particolare, che il documento venga inizialmente trattato tramite dizionari, evitando all'utente l'onere di specificare i nominativi, e che in seguito venga lasciata all'utente la possibilità di intervenire.
Infatti, esso potrebbe voler esprimere delle preferenze su quali nominativi debbano essere trattati tra quelli individuati e gestire gli eventuali errori di riconoscimento dovuti a richieste di trattamento di nominativi aventi un nome non presente nel dizionario o anche dovuti a casi di ambiguità lessicale già presentati.

Una volta inserito il documento e terminata l'elaborazione tramite il dizionario, l'utente può sia richiedere l'immediato download del file ed effettuare le operazioni prima definite, attraverso un'opportuna interfaccia. Per fornire il supporto alle esigenze più disparate, si prevede la possibilità di:
# eseguire download del file trattato unicamente con il dizionario
# ripetere la "minimizzazione" del documento, specificando:
## nuovi nominativi
## quali nominativi tra quelli precedentemente individuati ''non'' si vogliono trattare
## quale parola/e dei nominativi individuati rappresenta il cognome (in tal caso, si possono utilizzare altri metodi, oltre alla sostituzione con pseudonimo, per il trattamento)
## quale parola/e dei nominativi individuati non compone il nominativo (situazione che si verifica quando ci si imbatte in una ambiguità).

Senza soffermarsi in questo momento sull'intera sequenza concreta di interazioni tra utente e servizio, si osserva che l'unico vincolo non funzionale da valutare resta il tempo medio di attesa dell'utente. L'usabilità complessiva è molto buona ed i vincoli funzionali sono soddisfatti.

===Scelta dei formati da trattare===

Una considerazione intuitiva, ed una buona prassi, è che un documento contenente dati personali sia pseudonimizzato o anonimizzato quanto prima possibile e cioè quando è ancora solo nelle mani del suo autore: questo approccio scongiura che informazioni sensibili e dati personali in chiaro ''sfuggano'' in rete.
Si può per questo ragionevolmente ipotizzare che i naturali destinatari del servizio siano gli stessi autori (creatori) che redigono il documento. Nello scenario tipico di utilizzo, infatti, il fruitore del servizio procederà al trattamento dei dati non appena avrà finito di scrivere il documento del quale, essendone autore, potrà scegliere il formato. Si osserva che potrebbe accadere che il documento sia redatto da terzi: in tal caso l'utente che richiede il trattamento può scegliere il formato in maniera indiretta concordandolo con il redattore. Avendo quindi l'utente la possibilità di stabilire il formato del proprio documento, risulta ragionevole progettare un servizio che lavori su un solo formato.
A questo punto occorre individuare quale sia il formato che maggiormente si presta alle finalità del servizio.<div></div>
Una possibilità è quella di richiedere all'utente di inserire come documento da trattare un semplice file di testo in formato ''txt'': in questo modo ci sarebbe il grande vantaggio di trattare file molto semplici, riducendo così al minimo la complessità realizzativa, e inoltre si avrebbe l'indipendenza dagli editor di testo utilizzati, in quanto tutti supportano i file in formato ''txt''.
Risulta tuttavia sconveniente utilizzare questo formato, poiché non ha alcuna capacità espressiva per gestire elementi complessi come tabelle, modifiche allo stile del testo e così via.
Bisogna quindi optare per un formato in grado di gestire questi elementi, al costo di aumentare la complessità della progettazione, ricordando sempre che è necessario allo stesso tempo che tale formato sia supportato da tutti i principali editor di testo.<div></div>
Con facilità è possibile individuare quali sono i formati di testo più comuni oltre al ''txt'': ''doc'', ''docx'', ''odt'', ''pdf'', ''pages'', ''rtf'', ''tex''. Si passa ora dunque a valutare quale tra questi formati potrebbe meglio soddisfare i requisiti prima enunciati.
Facendo una cernita iniziale sulla base delle finalità per le quali un formato è utilizzato, si può immediatamente escludere ''tex'', che trova impiego principalmente in ambito scientifico e matematico. In questo settore, infatti, non è richiesta generalmente l'applicazione delle procedura di trattamento dei dati. <div></div>
Si può inoltre abbandonare l'idea di trattare documenti con estensione ''pages'', formato proprietario di Apple, poiché utilizzati esclusivamente dall'omonimo editor di testo anch'esso proprietario, e i documenti con estensione ''rtf'', acronimo di ''Rich Text Format'', formato proprietario di Microsoft che supporta una formattazione avanzata, poiché, pur gestito da vari editor, è un formato decisamente datato (ultima versione 1.9.1 risalente a marzo 2008 ([0009])). <div></div>
Si esclude inoltre il formato ''pdf'' per motivi di usabilità: molti editor, infatti, consentono di esportare un documento in questo formato ma non permettono di importarlo. Un utente dopo aver effettuato l'anonimizzazione di un documento non può quindi proseguire modificandolo ulteriormente. Il ''Portable Document Format'', infatti, è ideato per realizzare dei documenti destinati alla sola lettura.
L'ultima esclusione, piuttosto immediata da effettuare, riguarda il formato ''doc'', binario e proprietario di Microsoft. Esso infatti risulta, a partire dal 2006, soppiantato dal formato ''docx'', sempre proprietario di Microsoft.

Si giunge infine a valutare quale tra gli ultimi due possibili formati rimanenti, ossia ''docx'' e ''odt'', si presta meglio alle finalità del servizio. In via preliminare si osserva che entrambi i formati possiedono ottime capacità espressive, hanno una struttura interna di simile complessità e sono entrambi supportati dai principali editor di testo. È necessario quindi effettuare delle analisi più approfondite per poter sceglierne uno tra i due.
La struttura del formato ''docx'', sviluppato da Microsoft e formalmente denominato ''Office Open XML Document (OOXML Document)'', è costituita da un file compresso .zip contenente un insieme di file ''XML''. Il formato ''OOXML'' permette la rappresentazione, oltre che di documenti testuali, anche di fogli elettronici (formato ''OOXML 'Workbook'', noto anche come ''xslx'') e di presentazioni (formato ''OOXML Presentation'', noto anche come ''pptx'') ([0008], [0013]).
Il formato inoltre è stato inizialmente standardizzato nel 2006 dall'<i>ECMA</i> (come ''ECMA-376'') e successivamente nel 2008 dall'<i>ISO</i> e dall'<i>IEC</i> (come ''ISO/IEC 29500'') in una versione ''transitional'', retrocompatibile con alcune versioni precedenti del formato contenenti elementi deprecati, e in una versione ''strict'', dove tali elementi non sono ammessi. I due standard sono stati poi successivamente aggiornati e sono tutt'ora oggetto di revisioni ([0002]).

Anche la struttura del formato open source ''odt'', sviluppato dall'<i>OASIS</i> e formalmente denominato ''OpenDocument Text'', è basata su uno zip contenente un insieme di file ''XML''. Inoltre, il formato ''OpenDocument Format (ODF)'' permette di trattare fogli elettronici (formato ''OpenDocument Spreadsheet'', noto anche come ''ods'') e presentazioni (formato ''OpenDocument Presentation'', noto anche come ''odp'') ([0007]). Anche ''OpenDocument Text'' è stato standardizzato, in particolare dall'<i>OASIS</i> stesso nel 2005 e dall'<i>ISO/IEC</i> nel 2006, ed è soggetto a revisioni e aggiornamenti ([0003]).

In sintesi, basandosi sulla struttura dei documenti e sulla standardizzazione dei formati, non è ancora possibile individuare quale sia il formato migliore. L'unico elemento che potrebbe portare punti a favore del formato ''odt'' è che esso, a differenza del formato ''docx'', è aperto, tuttavia, essendo le specifiche di entrambi i formati pubbliche, ciò non rappresenta un fattore determinante nell'elezione del formato.
Entrambi i formati, inoltre, sono largamente supportati dai word processors.

Le seguenti tabelle riepilogano il supporto all'uno ed all'altro formato dei ''word-processors'' più usati, ossia ''Microsoft Office Word'', ''LibreOffice Writer'', ''OpenOffice Writer'' e ''Pages''.
Le tabelle sono tratte da wikipedia ([0000], [0001], [0006]). <div></div>

<center><i>Supporto fornito dagli editor di testo al formato docx</i></center>
{| class="wikitable"
|-
! !! Microsoft Office Word !! LibreOffice Writer !! OpenOffice Writer !! Pages
|-
! Version
|| 2013, 2011 for Mac || All versions || 3.0 || '08
|-
! Operating systems
|| Windows, Mac OS X || Windows, OS X, Linux, Unix, Android || Windows, Linux, Unix, Mac OS X || Mac OS X
|-
! Office suite
|| Microsoft Office || || OpenOffice.org || iWork
|-
! Developer
|| Microsoft || The Document Foundation || Apache OpenOffice || Apple Inc.
|-
! License
|| proprietary || MPL || LGPL || proprietary
|-
! ECMA-376
|| yes || yes || yes || yes
|-
! ISO/IEC 29500:2008
|| yes || yes || ||
|-
! Notes
|| || || Import only ||
|}

<div></div>
<center><i>Supporto fornito dagli editor di testo al formato odt</i></center>
{| class="wikitable"
|-
! !! Microsoft Office Word !! LibreOffice Writer !! OpenOffice Writer
|-
! Version
|| 2007 SP2 || 4.0.3 || 3.0.0
|-
! Operating systems
|| Windows || Unix-based systems, Mac OS X, Solaris || Windows, Linux, Unix-based systems, Mac OS X, Solaris
|-
! Office suite
|| Microsoft Office || || OpenOffice.org
|-
! Developer
|| Microsoft || The Document Foundation || Apache OpenOffice
|-
! License
|| Proprietary || MPL || LGPL
|-
! ISO/IEC 26300:2006
|| yes || yes || yes
|-
! Notes
|| some limitations || Multiple ODF versions supported (ISO/ODF 1.0/1.1/1.2/1.2 Extended) || adjustable ODF version (ISO/ODF 1.2)
|}
<div></div>

Si possono effettuare le seguenti osservazioni:
* ''Microsoft Office Word'' è, in ambiente Microsoft, il word processor maggiormente usato; è molto usato anche in ambiente Apple Mac. Esso offre il pieno supporto al formato ''OOXML Document''; solo parzialmente invece gestisce il formato ''OpenDocument Text'': il processamento di file con estensione ''odt'' con questo editor comporta la perdita di alcune informazioni secondarie.
* ''LibreOffice Writer'', l'editor open source maggiormente utilizzato, supporta pienamente entrambi formati. Nato con lo scopo di gestire i file con formato ''OpenDocument Text'', attualmente supporta completamente anche il formato ''OOXML Document''.
* ''OpenOffice Writer'', un altro degli editor di testo tra i più utilizzati, supporta pienamente ''odt'', mentre è solo in grado di importare i file con estensione ''docx''.
* ''Pages'', il word process installato a default sui Mac della Apple e, di conseguenza anche maggiormente usato su questi dispositivi, non offre supporto al formato ''odt'', ma elabora correttamente i documenti con estensione ''docx'' ([0005],[0004]). <div></div>
Queste osservazioni evidenziano che quindi è impossibile adottare un formato supportato da tutti gli editor; la scelta va allora indirizzata verso quello maggiormente supportato dai word processor più popolari.
Per avere un'indicazione di ''popolarità'', e quindi per poter comprendere meglio quali tra gli editor prima citati siano i più usati, si può fare un'analisi, tramite motori di ricerca, di quanti file con una certa estensione siano presenti in rete.
È possibile, ad esempio, ricercare su Google i file che contengono nel proprio nome una determinata sequenza di caratteri o aventi una certa estensione (''filetype''). Sono qui presentati i risultati delle interrogazioni riguardo ai file aventi formato ''docx'', ''doc'' e ''odt'' ed il cui nome contiene uno dei caratteri, fra i più frequenti, "1" o "a" o "e". L'investigazione è stata effettuata inserendo nella barra di ricerca di Google le stringhe ''1 filetype:docx'', ''a filetype:docx'' e così via.

{| class="wikitable"
|-
! Formato cercato !! Documenti con "1" nel nome !! Documenti con "a" nel nome !! Documenti con "e" nel nome
|-
| docx || 16.900.000 || 12.800.000 || 8.730.000
|-
| odt || 736.000 || 667.000 || 507.000
|-
| doc || 32.300.000 || 26.300.000 || 21.500.000
|}

Effettivamente il formato più diffuso è il ''doc''; tuttavia esso è supportato per retro-compatibilità anche dagli editor che supportano formati ''OOXML'', con i quali non si ha difficoltà nel convertire i documenti dal formato ''doc'' al ''docx''. In conclusione, quale che sia l'editor più diffuso, è ragionevole adottare il formato ''OOXML Document'' per le finalità del servizio, in quanto molto diffuso, ben supportato dagli editor e avente ottime capacità espressive. Di conseguenza i documenti che saranno elaborati dovranno essere forniti dall'utente in tale formato. In successive sezioni verrà approfondita la struttura dei documenti ''OOXML''.

===Privacy by design===

L'Art. 25 del ''GDPR'', con i Considerando 75 e 78, ha per titolo e per oggetto la "protezione dei dati fin dalla progettazione e protezione per impostazione predefinita" ([0035]), perfettamente in linea con i concetti di "minimizzazione", già richiamati.<div></div>
Il senso dell'Art. 25 viene spesso sintetizzato con l'espressione "''PbD - privacy by design, privacy by default''" ([0035]). Il principio fissato nell'Art. 25 dovrà sempre più essere tenuto ben presente nell'ambito dell'ingegneria del software, in quanto impone di adottare nuove cautele nella realizzazione delle applicazioni software.<div></div>
Del principio ''PbD'' si è ben tenuto conto nella progettazione descritta in questa tesi. In particolare, relativamente alla ''privacy by design'', si è fatto in modo che nessun dato personale permanga registrato sul sistema di esecuzione, o altrove, al termine dell'applicazione. Anche laddove l'applicazione termini in modo anomale non vi sono strutture dati superstiti, che restano memorizzate sul sistema.<div></div>
Marginale in questa tesi è la nozione di ''privacy by default'', giacché l'applicazione non offre all'utente alcuna opzione che possa indurlo in errore ed acconsentire a trattamenti dei dati personali, oltre quello realizzato dall'applicazione.<div></div>
È utile osservare quanto sia importante esprimere queste impostazioni di progettazione fra le condizioni d'uso presentate all'utente: esse costituiscono uno dei presupposti affinché l'utente abbia piena fiducia (''trust'') nel servizio, lo utilizzi, lo divulghi, lo renda un servizio di successo.

==Architettura del servizio==

===I componenti software nell'architettura LAMP===

Il servizio è realizzato in forma di ''web-based application'' poiché, come già illustrato nell'introduzione, si intende renderlo disponibile per il massimo numero di utenti possibili. Nella progettazione e realizzazione dell'architettura web si adotta la piattaforma ''LAMP'', il cui nome deriva dall'acronimo dei componenti open source che la realizzano (il sistema operativo Linux, il server HTTP Apache, il sistema per la gestione di database relazionali MySQL ed il linguaggio di programmazione PHP). Poichè il modello è composto da quattro livelli, spesso si parla anche di ''stack LAMP''. Uno degli elementi di forza del modello ''LAMP'' è che i componenti dei vari ''layer'' sono sostituibili, a seconda delle esigenze, con dei componenti più adatti, tipicamente open source ([0015], [0018], [0019]). Basando la piattaforma su un sistema operativo della famiglia di Microsoft Windows, ad esempio, si ottiene uno ''stack WAMP'', mentre se si usa un sistema operativo Mac OS si realizza uno ''stack MAMP''. Un'architettura web basata sul modello ''LAMP'' può, inoltre, essere integrata con software open source che offre utili funzionalità, come, ad esempio, il monitoraggio (''Nagios''), il load balancing (''Linux Virtual Server''), la rilevazione di accessi illeciti (''Snort'') e il security testing (''netsniff-ng''). <div></div>
Si valutano ora brevemente la diffusione dei componenti tradizionali dello ''stack LAMP'' e le alternative maggiormente usate per i vari ''layer''.
Le distribuzioni Linux risultano essere la scelta più comune per l'ultimo ''layer'' dello ''stack''. Secondo W3Techs, infatti, nell'ottobre del 2013, il 58.5% dei web server a livello globale avevano come sistema operativo la distribuzione Debian o Ubuntu, mentre il 37.3% una tra RHEL, Fedora e CentOS([0016]). <div></div>
Tra i web server, Apache risulta essere maggiormente usato. Secondo le stime fatte da Netcraft, a giugno del 2014 circa il 51.9% del milione di siti web più trafficati al mondo usavano un web server Apache, il 19.2% nginx ed il 12.4% Microsoft ([0017]). <div></div>
I principali ''DBMS'' relazionali, oltre a MySQL, che possono essere presenti nello ''stack LAMP'' sono MariaDB e PostgreSQL, mentre tra i ''DBMS NoSQL'' MongoDB risulta essere il più comune. <div></div>
Nello stack, infine, il ruolo di linguaggio di programmazione, solitamente svolto dal linguaggio PHP, spesso è ricoperto dai linguaggi Perl o Python. <div></div>
Si osserva, ad ogni modo, che le informazioni sulla diffusione delle tecnologie non rappresentano un fattore vincolante nella scelta delle stesse, in quanto la piattaforma ''LAMP'' è anche aperta verso molti altri componenti oltre quelli citati; di conseguenza la scelta delle tecnologie da impiegare può essere effettuata basandosi principalmente sui requisiti e sulle specifiche del servizio. <div></div>

===Principi di progettazione per l'architettura===

====Single Responsibility Principle====

Per rendere il servizio maggiormente manutenibile ed estensibile, si presta particolare attenzione al rispetto del ''Single Responsibility Principle'' (''SRP'') ([0020]). Si cerca, quindi, di fattorizzare il software in più moduli, suddividendo tra questi le elaborazioni da svolgere. Un altro importante beneficio che si ottiene dalla fattorizzazione del codice è la riusabilità dei componenti. Ogni singolo modulo, infatti, svolge il proprio compito in maniera indipendente dal resto della applicazione ed è, quindi, riutilizzabile in altri scenari simili senza dover essere re-implementato. Inquadrando meglio questa metodologia di progettazione con i requisiti del servizio e la piattaforma web ''LAMP'', si individuano i due principali compiti a carico dell'applicazione:
* La gestione dell'interazione web con l'utente per la trasmissione del documento e dei nominativi da trattare
* Il processamento del documento per effettuare la "minimizzazione" dei dati.
Questi due differenti ''task'' saranno, quindi, portate a termine da componenti diversi.<div></div>
Progettando la struttura dell'applicazione in questo modo, si disaccoppia completamente la logica di business del servizio dalle interfacce web di comunicazione con l'utente. In un futuro sviluppo sarà possibile, quindi, realizzare nuove interfacce utilizzando altre tecnologie senza dover modificare la logica applicativa.

====Dependency Inversion Principle====

Un altro principio di design architetturale che risulta importante nella progettazione è il ''Dependency Inversion Principle'' (''DIP'') ([0038]). Esso si traduce nella realizzazione di componenti che non dipendono dalle specifiche implementazioni degli altri moduli del sistema, bensì dalle loro ''astrazioni''.
In relazione all'estensibilità e manutenibilità del prodotto software, infatti, l'impiego di moduli dipendenti direttamente dalla definizione dei metodi presenti in altri componenti risulta problematica: il modulo dipendente deve essere re-implementato ad ogni variazione del modulo da cui dipende.
Nella programmazione orientata agli oggetti, per rispettare questo principio, si su può fare uso di classi astratte o interfacce, costrutti che definiscono i moduli senza implementarli completamente o senza implementarli affatto.

===Stile architetturale REST===

Il modello architetturale del servizio che si sta definendo presenta una serie di caratteristiche, come ad esempio l'indipendenza dei moduli, che permettono di realizzarlo secondo il paradigma delle ''RESTful API''. L'espressione "Representational State Transfer" e il suo acronimo "REST" furono introdotti nel 2000 nella tesi di dottorato di Roy Fielding ([0021]), uno dei principali autori delle specifiche dell'Hypertext Transfer Protocol (HTTP). Roy Fielding descrive il ''Representational State Transfer'' come uno stile architetturale ("''architectural style''"), ovvero un'astrazione degli elementi di un'architettura all'interno di un sistema hypermedia distribuito. ''REST'' non specifica i dettagli dell'implementazione dei componenti e della sintassi del protocollo, ma definisce i ruoli dei componenti, i vincoli sulla loro modalità di interazione e la loro interpretazione.
Riassumiamo quindi i principi che deve rispettare una architettura ''REST'':
# Architettura Client-Server <br/>In una architettura ''REST'' viene data particolare importanza ai principi ''SRP'' e ''DIP'' prima citati, più generale si può affermare che l'architettura sposi il paradigma noto con il termine di "''Separation of Concerns''". Una ''Restful API'' applica questi principi in un architettura Client-Server, capace di supportare l'evoluzione indipendente della logica lato client e della logica lato server.
# Stateless <br/>La comunicazione tra utente e fornitore del servizio deve essere senza stato, quindi ogni richiesta del client deve contenere tutte le informazioni di cui il fornitore necessita per l'erogazione del servizio offerto. Questa ipotesi viene fatta per rendere una ''Restful API'' facilmente scalabile orizzontalmente.
# Uso della cache <br/>In un Architettura ''REST'' i messaggi di risposta inviati dal server devono esplicitamente indicare se possono essere memorizzati nella cache del client o di componenti middleware per il riutilizzo nelle richieste successive.
# Interfaccia uniforme <br/>I componenti devono essere in grado di comunicare attraverso un'interfaccia uniforme e le risorse devono essere trasferite in un formato standard. Inoltre l'utente deve poter effettuare la navigazione tra le risorse di suo interesse tramite collegamenti ipertestuali. Per inciso, si osserva che il protocollo HTTP usato correttamente rispetta i requisiti di un architettura ''REST'' e che nelle implementazioni delle ''RESTful API'' il formato più usato per la modellazione dei dati è JSON.
# Layered System <br/>In un sistema a livelli, componenti intermedi (come i proxy) possono essere collocati tra client e server per intercettare il traffico per scopi specifici; ad esempio il caching o la sicurezza. Una soluzione basata su ''REST'' può essere composta da più livelli architettonici, indipendenti l'uno dall'altro.
# Code on Demand <br/>Questo vincolo facoltativo è inteso principalmente a consentire aggiornamenti alla logica all'interno dei client (come i browser Web) indipendentemente dalla logica lato server. Una ''single page application'', ad esempio, rispetta in pieno questo punto.

Un'applicazione progettata sul modello dell'architettura ''REST'' ha quindi gli indiscutibili vantaggi di:
* consentire l'evoluzione indipendente delle diverse componenti
* avere un'interfaccia utente portabile con altri tipi di piattaforme
* permettere agevolmente la replicazione delle macchine server
* non vincolare moduli server e client a linguaggi e tecnologie specifiche.

L'architettura del servizio oggetto di questa tesi si trova già perfettamente in linea con alcuni dei vincoli discussi, ma sono necessarie alcune considerazioni. Il punto 1 ("architettura Client-Server") è chiaramente soddisfatto.
Il punto 2 ("Stateless"), direttamente collegato con i punti 3 e 5 ("Uso della cache", "Layered System"), può essere rispettato con facilità; a ogni richiesta di "minimizzazione" del client corrisponde la restituzione del documento trattato dal server, non c'è quindi necessita di avere uno stato nell'interazione.

Analizzando le caratteristiche di una applicazione stateless in relazione al principio ''privacy by design'' illustrato in precedenza, si osserva che l'assenza di stato determina la semplificazione delle problematiche critiche relative al principio. Non vengono conservate, infatti, informazioni contenenti dati sensibili, poiché dopo aver effettuato l'invio della risposta, sarà subito eliminato sul server il file elaborato.

Nei capitoli precedenti tuttavia si è detto che l'utente può ripetere più volte il trattamento di uno stesso documento nella stessa sessione di interazione; essendo il vincolo dell'efficienza già difficile da rispettare per via dell'elaborazione onerosa del documento, si può progettare una modalità alternativa del funzionamento con stato del servizio, applicabile in assenza di replicazione delle macchine server e sfruttando le ripetute richieste di trattamento per uno stesso documento.
Si può infatti memorizzare lato server il documento inviato dal client inizialmente e, alle successive richieste di trattamento del medesimo documento, evitarne la ritrasmissione da client a server. Per rispettare il ''PbD'', al termine della sessione di interazione il documento verrà rimosso dal server. Si nota, inoltre, che per predisporre il servizio alla gestione delle due diverse modalità di funzionamento si può utilizzare un parametro di configurazione a livello applicativo.
I punti 4 e 6 infine ("Interfaccia uniforme", "Code on Demand") si possono rispettare utilizzando il formato JSON per la trasmissione dei documenti e dei nominativi, e usando localmente sul client Javascript per offrire tutte le funzionalità del servizio in un'unica pagina html.

===Moduli software del servizio===

====Scelta dei componenti software====

Si opera ora la scelta delle tecnologie da utilizzare per i componenti dei 4 layer dello ''stack LAMP''. Per i due layer inferiori risulta piuttosto immediato decidere di usare le tecnologie presenti per default. Un sistema operativo Linux ed un web server Apache sono adatti all'architettura del servizio.
Inoltre anche il linguaggio di programmazione PHP può essere usato senza significativi problemi, anche se verranno fatte in seguito, in una sezione di questo capitolo, alcune considerazioni sulle problematiche di esecuzioni concorrenti di script PHP. Il linguaggio sarà impiegato in particolare per la realizzazione della logica necessaria a gestire l'interazione web con il cliente, mentre l'elaborazione del documento OOXML lato server sarà effettuata da un programma Java.

I due ''task'' principali del servizio sono delegati, quindi, a due programmi distinti realizzati con tecnologie diverse. Si concretizza in questo modo il principio ''SRP'' e, sfruttando l'<i>openness</i> della piattaforma LAMP, le funzionalità necessarie vengono realizzate attraverso i linguaggi più adatti.
La scelta del linguaggio Java per l'implementazione del ''main core'' della logica di business è dovuta alla libreria open source in ambiente java Docx4j ([40],[41]). Questa libreria è realizzata per il processamento delle tre tipologie di formati OOXML (''docx'', ''xslx'', ''pptx'') e permette tutte le possibili operazioni di creazione, lettura e modifica su questo tipo di documenti. Anche questa libreria sarà approfondita in sezioni successive. Si osserva, per inciso, che esistono altre librerie equivalenti in ambiente .NET.

Nella scelta del linguaggio di programmazione usato per elaborare i documenti ed effettuare i confronti tramite ''regular expressions'', un dato non di poco conto da considerare è l'encoding delle stringhe. In Java, in particolare, una stringa è rappresentata internamente come un array di char, ognuno codificato da 2 byte in formato UTF-16 ([0042]); la codifica esprime in 16 bit tutti i caratteri definiti dallo standard Unicode, quindi è possibile scegliere Java.

Per il ''layer'' della persistenza, infine, l'impiego di un database MySql risulta una buona scelta. Si osserva che questo livello non verrà utilizzato nella tradizionale maniera prevista dallo ''stack LAMP''. Infatti, generalmente, la base di dati viene interrogata direttamente dal componente che si occupa dell'interazione con l'utente (PHP) per il reperimento delle informazioni utili da restituire al client; nel servizio, invece, la base di dati sarà a supporto unicamente del programma Java, poiché gli unici dati persistenti da gestire sono i nomi del dizionario (si ricordi sempre il ''PbD'') e solo i moduli dell'eseguibile Java devono utilizzarli. Se il dizionario contenessero unicamente i nomi (senza informazioni accessorie correlate) e fossero usati in sola lettura, un semplice file di testo poteva essere sufficiente per la rappresentazione. Tuttavia, poiché saranno individuate tecniche di ottimizzazione nell'impiego dei dizionari che richiedono operazioni di scrittura e ordinamento dei dati, risulta opportuno usare un database relazionale.

====Logica di business e dinamiche di interazione====

Vengono presentati in questa sezione gli aspetti principali dei funzionamenti dei moduli del servizio. Per mettere bene a fuoco quali siano le meccaniche di interazione e i flussi di esecuzione dei programmi, si propone il diagramma di sequenza del tipico scenario di utilizzo. In questo schema UML si descrive il caso d'uso dove un utente, dopo aver inserito un documento ed averlo ricevuto "minimizzato", esprime delle preferenze e richiede poi un secondo trattamento.<div></div>
<div></div>(QUI IMG [0F00])<div></div>
Si descrivono quindi ora le principali operazioni che vengono eseguite.
All'avvio dell'interazione viene presentata una pagina PHP di benvenuto contenente le informazioni su come i dati personali vengano elaborati ed un ''file-picker'' per consentire l'upload di un documento ''OOXML''; nel momento in cui l'utente confermerà il caricamento del documento, esso verrà trasferito sul server.
Bisogna prestare particolare attenzione al comportamento del sistema nel caso in cui più utenti richiedano contemporaneamente l'esecuzione del servizio, e cioè alle problematiche di esecuzioni concorrenti di script PHP; è necessario, in particolare, evitare situazioni in cui i nomi dei file inviati dagli utenti siano in conflitto. Analizzando più in dettaglio il problema, ogniqualvolta un web server Apache riceve una richiesta HTTP per una pagina PHP, si ha la generazione di un nuovo processo che esegue il codice presentato nella pagina PHP richiesta. Supponendo quindi che N utenti eseguano l'invio del file contemporaneamente, si avrebbe che sul server N processi diversi dovrebbero procedere con la scrittura di un file. Ovviamente se due o più file condividono il nome almeno uno di essi sarà sovrascritto. Per risolvere questo problema, supponendo di voler salvare tutti i documenti in una cartella temporanea, occorre modificare il filename dei documenti inviati dagli utenti per esser certi di non incorrere in sovrascritture o altri tipi di errori correlati.
Una valida possibilità è l'inserimento di un ''prefisso'' univoco nel filename. Per la generazione di una stringa univoca da anteporre al filename, che permetta di distinguere file caricati da utenti diversi, si può direttamente usare il ''session id'' dell'utente. In PHP esso è determinato casualmente combinando ([0043]): l'IP del cliente, orario di attribuzione dell'id, un numero pseudo-casuale (con il ''PHP Linear Congruence Generator'') e, se presente un "''random source''" sul sistema operativo del Client (spesso chiamato impropriamente "''seme''"), un ulteriore numero pseudo-casuale.
Per introdurre ulteriore alea, necessaria se, ad esempio, un utente tenti l'upload di file omonimi (con contenuto interno diverso) e mantenga il medesimo ''session id'', si utilizza un ulteriore generatore pseudo-casuale per produrre un altro numero con cui comporre il prefisso.
Concatenando i due numeri generati si ha praticamente certezza di aver individuato un numero univoco nel sistema per il tempo in cui il servizio sarà erogato al cliente.

Una volta memorizzato il file, lo script PHP dovrà ricorrere all'invocazione del modulo Java, delegato al vero e proprio processamento del documento. Occorre quindi individuare un set di opzioni che consenta al modulo che gestisce l'interazione con il cliente di sfruttare al meglio il componente delegato all'elaborazione del documento, in qualunque circostanza; la totale indipendenza dei moduli, la loro sostituibilità e la replicazione possibile di macchine server sono solo alcuni dei fattori che rendono mutevole la configurazione del sistema. Va definito un protocollo di comunicazione, quindi, che astragga completamente dall'implementazione dei moduli o dalla locazione dei file.

Valutando i possibili flussi logici, anche con l'ausilio del diagramma di sequenza, si ha che i tipi di esecuzione sono due:
* "minimizzazione" con dizionario
* "minimizzazione" di specifici nominativi
Il protocollo di comunicazione tra i due moduli è costituito in entrambi i casi di una singola richiesta a cui segue una singola risposta. Più in particolare, lo script PHP invoca il comando Java esprimendo obbligatoriamente il path del file da trattare e opzionalmente l'elenco dei nominativi. A suo volta, il modulo Java restituisce i nominativi trovati, qualora non espressamente richiesti dallo script, e segnala la corretta terminazione dell'elaborazione.
Si definiscono come canali di comunicazione standard del protocollo gli argomenti presi in input dal modulo di processamento del documento e lo standard output del processo che esegue tale programma. Inoltre è importante definire un formato standard per la comunicazione dei nominativi tra moduli; è necessario quindi scegliere un pattern che permetta di determinare univocamente la composizione dei nominativi. Un possibile formato, espresso tramite ''regex'', è il seguente:
<div></div>
<span style="font-family: monospace;"> <nominativo> = ^(<nome>:)*<nome>;<cognome>$</span>
<div></div>
<span style="font-family: monospace;"> <nominativi> = ^(<nominativo>\s+)+$</span>
<div></div>
Dove nome e cognome sono una sequenza di caratteri Unicode come già discusso. Ulteriori opzioni importanti da definire nel protocollo per l'invocazione del programma che si occupa delle funzionalità di elaborazione sono le seguenti:
* path file da elaborare (opzione "-i <file_path>", obbligatoria)
* path con cui salvare il file elaborato (opzione "-o <file_path>", opzionale: per default viene creato un nuovo file automaticamente)
* abilitazione stampe verbose, da usare solo in fase di debug (opzione "-d", opzionale)
<div></div>
Una volta terminato il processamento, il modulo di gestione dell'interazione con l'utente dovrà accertarsi che l'<i>exit status</i> sia 0 e leggere dallo standard output del processo appena terminato, qualora si sia stata eseguita la "minimizzazione" con dizionario, l'elenco dei nominativi trovati. Se invece la "minimimizzazione" ha avuto luogo con i nominativi già specificati non sarà scritto nulla sullo standard output.
A margine si osserva che l'impiego dell'opzione "-d" deve sempre consentire una semplice individuazione dei nominativi trovati; in particolare, se tale opzione è specificata, nello standard output i nominativi compariranno con un ''header'' riconoscibile ("''NOMINATIVO=''").
Ritornando alla descrizione del flusso di esecuzione tipo, una volta che il modulo Java ha completato il trattamento del documento, lo script PHP ne effettuerà l'upload sul client e presenterà all'utente le opzioni già descritte nel capitolo sull'usabilità.
A questo punto l'interazione con client potrebbe concludersi, qualora si eseguisse il download e si chiudesse il browser, o continuare elaborando i ''suggerimenti'' dell'utente espressi dopo il primo trattamento. Le modalità di comunicazione dei moduli varierebbero leggermente come appena illustrato, mentre, a seconda della configurazione stateful o stateless del servizio, verrebbe eseguito o meno un nuovo upload del file dal client al server.<div></div>

Si osserva infine che, per predisporre a successivi studi di ottimizzazione il servizio e per agevolare tutti i possibili sviluppi futuri, si applica largamente nella progettazione del modulo di elaborazione Java il ''Dependency Inversion Principle'', in quanto si desidera realizzare classi estendibili ed intercambiabili.
In particolare, si introducono delle classi astratte per rappresentare in maniera generica il concetto di "''persona''" e "''minimizzatore''". È possibile infatti realizzare successivi studi per trattare ulteriori dati personali oltre che ai nomi e cognomi; inoltre, in base ai tipi di documenti trattati o eventuali altri fattori utili, è possibile studiare differenti tecniche di "minimizzazione" realizzate da differenti algoritmi "''minimizzatori''".
In particolare una "''persona''" dovrà sempre esporre un metodo "''minimizza''" che prende in input una stringa, la "minimizza" e la restituisce; il pattern con il quale si effettua la "minimizzazione" sarà fornito in implementazione a seconda dei dati sensibili di interesse.
Un "''minimizzatore''" esporrà sempre un metodo "''work''" che, presa in input una lista di persone ed un documento ''OXML'', con l'ausilio della libreria Docx4j, fornirà in output un documento del tutto "minimizzato"; la definizione delle modalità con cui si estrapolano le informazioni dal documento e con cui si invoca il metodo "''minimizza''" della classe persona sono confinate nell'implementazione.
Definendo delle classi astratte risulta, quindi, più veloce la realizzazione dei futuri componenti e si svincola il processo di "minimizzazione" dal tipo di dati che si "minimizzano" e viceversa.

====Le classi principali del progetto====
Le classi principali del progetto vengono quindi presentate in appendice. Esse sono:
* App.java, contenente il main
* Elaborator.java, che presenta il metodo "''work''"
* Persona.java, che presenta il metodo "''minimizza''"
* Testing.java, contenente alcune funzioni usate in fase di debug.

Gli script in PHP sono stati forniti dall'azienda come implementazione minimale e provvisoria, da perfezionare a seguito della eventuale definizione sulle modalità di presentazione del servizio su Internet.

Una considerazione di implementazione comune a tutte le classi deriva del principio ''Privacy by Design'', indifferentemente dalla modalità di configurazione stateful o stateless del servizio: è di fondamentale importanza che nel sistema non siano memorizzati permanentemente in alcun caso i documenti inviati dagli utenti del servizio.
Per realizzare un sistema robusto, per fronteggiare crash improvvisi del client o congestioni della rete, è opportuno impostare dei timeout lato server che procedano automaticamente alla eliminazione dei documenti degli utenti dopo un periodo di inattività troppo prolungato. Qualora invece si dovesse verificare un interruzione critica del servizio a causa di un errore logico del server o semplicemente per via di un'interruzione dell'alimentazione della macchina server, bisogna considerare altri metodi; essendo il servizio realizzato con un sistema operativo Linux, si può configurare il demone ''crond'' per eseguire a ogni reboot e, per sicurezza, una volta al giorno l'eliminazione dei file usati dall'applicazione tutti contenuti all'interno della cartella temporanea.

==Approfondimenti tecnologici==

===Analisi della struttura del formato OOXML===

Come argomentato, il formato dei documenti elaborati dal servizio progettato dovrà essere ''Office Open XML'', o ''OOXML''; si tratta di un formato ''XML-based'' per documenti di testo, fogli elettronici e presentazioni, in grado di rappresentare grafici, diagrammi, immagini e altro materiale grafico. La specifica fu sviluppata da Microsoft e adottata dall'<i>ECMA International</i> come standard ''ECMA-376'' nel 2006. Una seconda versione fu rilasciata nel 2008, una terza nel 2011, una quarta nel 2012 ed una quinta tra il 2015 ed il 2016 ([0010]). La specifica è stata adottata, inoltre dall'<i>ISO</i> e dall'<i>IEC</i> come standard ''ISO/IEC 29500'' a partire dal 2008 ([0011], [0012]).

====Linguaggi di markup====

Lo standard ''ECMA-376'' ([0010]) include tre differenti specifiche di linguaggio per ognuna delle tre principali categorie di documenti:
* ''WordprocessingML'' per i documenti testuali
* ''SpreadsheetML'' per i fogli elettronici
* ''PresentationML'' per le presentazioni elettroniche
* ''DrawingML'' ed altri linguaggi di markup di supporto per la rappresentazione di disegni, forme e diagrammi.
<div></div>
La specifica include sia gli schemi ''XML'' sia i vincoli espressi per iscritto. Ogni documento conforme al formato dovrà, quindi, rispettare gli schemi ''XML'' e dovrà essere codificato in ''UTF-8'' o ''UTF-16''. La specifica, inoltre, permette l'aggiunta di ''custom tag XML'' a supporto dei linguaggi di markup dati, per default nel formato ''OOXML'', consentendo quindi la libera personalizzazione dei documenti.

====File packaging====

Oltre alla specifiche relative ai linguaggi di markup, la seconda parte dell'<i>ECMA-376</i> ([0010]) definisce la struttura gerarchica dei file del formato adottando le ''Open Packaging Conventions'' (''OPC''). ''OPC'', una tecnologia ''file-container'' basata sul comune formato compresso ''zip'', che stabilisce che tutti i file che riguardano una stessa entità devono essere raggruppati in un unico package ([0014]). Un documento ''OOXML'' è, infatti, un archivio ''zip'' contenente alcuni files ''XML'' (detti anche ''parti'') organizzati in un singolo package. Questa frammentazione dei dati in più files rende più semplice e veloce l'accesso ai dati stessi e riduce le possibilità di una loro corruzione. Le ''parti'' possono contenere qualsiasi tipo di dato; per tenere traccia della relazione tra una ''parte'' e la sua tipologia di contenuto, senza basarsi sull'estensione del file, è presente nel package, nella cartella radice della gerarchia, il file denominato ''[Content_Types].xml'', il quale mappa appunto queste associazioni. È mostrata qui ad esempio l'associazione tra la ''parte'' rappresentante il documento principale e il suo ''ContentType''.
<div style="font-family: monospace;">
<Override PartName="/word/document.xml" ContentType="application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml"/>
</div>
Le informazioni relative alle relazioni che ogni ''parte'' ha con le altre ''parti'', con risorse esterne e con il package in sé sono mantenute separatamente dal contenuto della ''parte'' stessa. Tali informazioni sono presenti, infatti, all'interno delle cartelle denominate ''_rels'': ne esiste una per il package nel suo complesso e una per ogni sotto-cartella del package contenente delle ''parti'' coinvolte in delle relazioni. In questo modo i riferimenti che una ''parte'' ha verso altre ''parti'' o risorse sono salvati una sola volta e possono essere aggiornati con semplicità se necessario, senza dover modificare il contenuto stesso delle ''parti'' coinvolte. È mostrato qui un esempio di relazione contenuta in ''_rels/.rels'' relativa al documento principale e al suo schema.
<div style="font-family: monospace;">
<Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument" Target="word/document.xml"/>
</div>
Il documento principale, ossia il file ''word/document.xml'', ha inoltre numerose relazioni con altre ''parti'', come ad esempio ''word/styles.xml'' e ''word/footer.xml'', e risorse esterne collegate con degli URI. Per descrivere queste relazioni si usa la cartella ''word/_rels''.

====Parti di un Documento OOXML====

Vengono qui presentate le ''parti'' che sono caratteristiche esclusive di un ''WordprocessingML package'', non presenti quindi negli altri due formati ''OOXML''. È importante osservare che alcune di esse sono facoltative e sono presenti nel package solo se necessario.

Le ''parti'' relative al vero e proprio contenuto testuale sono:
* ''Main Document'', contiene le informazioni principali ed è salvata come ''word/document.xml''
* ''Header'', contiene i dati relativi alle intestazioni ed è salvata in ''word/header.xml''. Ogni sezione del documento può avere intestazioni diverse per la prima pagina, per le pagine pari e per le dispari, quindi possono esserci molteplici ''parti header''
* ''Footer'', contiene le informazione relative al piè pagina ed è salvata in ''word/footer.xml''. Può essere presente più volte, per motivi analoghi alla ''parte header''
* ''Footnotes'', contiene le eventuali note a piè pagina del documento ed è salvata come ''word/footnotes.xml''
* ''Endnotes'', contiene le note di chiusura del documento ed è salvata in ''word/endnotes.xml''.

Sono presenti poi delle ''parti'' relative allo stile e alle impostazioni del documento:
* ''Style Definitions'', contiene la definizione di un insieme di stili usati dal documento, salvata in ''word/styles.xml''
* ''Font Table'', contiene informazioni riguardo i font usati, salvata in ''word/fontTable.xml''
* ''Numbering Definitions'', contiene le definizioni sulla struttura delle liste contenute nel documento, salvata in ''word/numbering.xml''
* ''Document Settings'', specifica come il word processor debba trattare il documento (spell checking, gestione delle revisioni, etc.), contenuta in ''word/settings.xml''
* ''Web Settings'', contiene informazioni su come il documento debba essere convertito in ''HTML'' se richiesto, contenuta in ''word/webSettings.xml''.

Sono presenti anche delle ''parti'' che rappresentano testo secondario:
* ''Comments'', contiene i commenti sul documento inseriti attraverso un word processor
* ''Glossary'', contiene dati testuali aggiuntivi secondari, ne è permessa una sola. Tutte le ''parti'' prima elencate, tranne il ''Main Document'', possono comparire una seconda volta in relazione alla ''parte glossary''.

====Analisi del Main Document====

Il file ''document.xml'', elemento principale di un documento ''WordprocessingML'', è costituito da due tipi di informazioni:
* ''properties'', che definiscono lo stile e la formattazione del testo
* ''stories'', che rappresentano il contenuto testuale delle varie parti del documento.

Le ''properties'' verranno trattate in misura minore. Queste informazioni sono espresse attraverso una struttura XML gerarchica che ha come elemento radice il nodo ''document''. Esso ha due nodi figli:
* ''background'', che contiene alcune ''properties'' che descrivono lo sfondo del documento
* ''body'', che contiene tutti i rimanenti contenuti ed è potenzialmente molto complesso.

Si osserva che per le finalità del trattamento dei dati risultano di primario interesse le ''stories'' e che è opportuno effettuare un'analisi ''bottom-up'' del problema: anziché considerare la gerarchia a partire dal ''body'' (nodo padre) partiremo dalla rappresentazione più semplice del testo contenuta nel documento (nodi figli).

Facendo direttamente riferimento allo standard ''ECMA-376'' ([0010]), si evince che l'unico nodo che contiene puro testo ha il nome ''t'' (''Text''). Questo elemento contiene una stringa rappresentante gli esatti caratteri che vengono poi mostrati negli editor a video. Il nodo ''Text'' non presenta figli e l'unico nodo padre che può avere è ''r'' (''Run''). Quest'altro nodo definisce una regione di testo con comuni proprietà (ad esempio l'uso del grassetto). Attraverso l'uso di tag ''t'' ed ''r'' quindi si rappresenta una regione di testo formattata con differenti elementi stilistici.
Occorre però evidenziare che un nodo ''r'' può presentare molti altri figli oltre a ''t'', come ad esempio immagini, in quanto rappresenta un'area generica del documento.
Si supponga quindi di avere due nodi ''Text'' fratelli, ossia figli dello stesso nodo ''r'': essi rappresenteranno semanticamente un unico blocco logico se e solo se compariranno a video come una sequenza di parole continua. Questo fenomeno è facilmente identificabile anche nel file ''XML'' descrittivo: due sequenze di parole mostrate a video adiacenti compaiono infatti nel file ''XML'' in due righe consecutive; se invece due parti di testo dovessero essere intervallate ad es. da un'immagine nel documento ''XML'' ci sarebbe un tag ''drawing'' a dividere i due tag ''t''. Dalla consecutività dei nodi ''Text'' nel file ''document.xml'' si può determinare quali siano i blocchi logici da trattare.
Un insieme di ''Run'' infine può essere figlio di diversi nodi, ma ciò non è di rilevante importanza, in quanto ogni area di testo individuata dal nodo ''Run'' rappresenta già un blocco logico a sé e, di conseguenza, contiene sufficienti informazioni per la "minimizzazione".
L'unico caso di rilievo nel quale bisogna valutare quale sia la gerarchia a monte di un nodo ''Run'' è nell'elaborazione di una tabella. In tal caso, in realtà, occorre verificare opportunamente la strutturazione della gerarchia processata. Per chiarezza espositiva viene mostrata la rappresentazione in formato ''OOXML'' di una tabella con una riga e due colonne (senza l'uso di ''properties'' per la formattazione stilistica).
<br/>
<div style="font-family: monospace;">
<w:tbl>
<w:tr>
<w:tc>
<w:p>
<w:r>
<w:t>Cella A</w:t>
</w:r>
</w:p>
</w:tc>
<w:tc>
<w:p>
<w:r>
<w:t>Cella B</w:t>
</w:r>
</w:p>
</w:tc>
</w:tr>
</w:tbl>
</div>

Come si osserva in figura, in una tabella il nodo ''r'' sarà figlio del nodo ''p'' (''Paragraph''), il quale a sua volta sarà contenuto in un noto ''tc'' (''Table Cell''). Celle di una tabella appartenenti ad una stessa riga saranno presenti all'interno dello stesso ''tr'' (''Table Row'') ed infine tutte le righe della tabella saranno inserite del tag ''tbl'' (''Table'').

Per determinare quindi se due nodi ''Text'' sono scritti in due colonne adiacenti di una stessa riga (e quindi costituiscono un unico blocco logico) è necessario verificare che per i due nodi ''Text'':
# il nodo "padre" '''non sia''' in comune
# il nodo "padre di 2° livello" sia ''Paragraph'' e '''non sia''' in comune
# il nodo "padre di 3° livello" sia ''Table Cell'' e '''non sia''' in comune
# il nodo "padre di 4° livello" sia ''Table Row'' e '''sia''' in comune
# i nodi "padre di 3° livello" '''siano''' consecutivi.
Se tutte queste ipotesi sono soddisfatte, le due celle vanno "minimizzate" come unico blocco logico.

Si valutano infine gli ultimi vincoli emersi nell'analisi sull'interpretazione della formattazione di un documento.
In particolare, descrivendo le parti che compongo un documento ''OOXML'', era già emerso che alcune sezioni di testo, ossia note a piè pagina ed intestazioni, compaiono in altri file ''XML'' e non in ''document.xml''. Questi file (''header.xml'', ''footer.xml'', ''endnotes.xml'', etc.) sono tutti raccolti in un package ("''word''") e la grammatica ''XML'' è la stessa usata per il Main Document.
Si conclude osservando che il problema della divisione in sillabe delle parole non si pone, in quanto la divisione sillabica mostrata a video dai word-processors è calcolata dinamicamente; in particolare, su una porzione di testo viene applicata la sillabazione (ove necessario) se è presente tra le ''properties'' di quella regione di documento il tag ''hyphenationZone''.

====La libreria in ambiente java open source Docx4j====

La libreria Docx4j offre completo supporto alla manipolazione di documenti ''docx'' (compressione e decompressione archivio zip, generazione file ''XML'' necessari, etc.). Offre inoltre un'utile mappatura in specifici oggetti Java della gerarchia ''XML'' presente nei vari file del formato.
Uno tra gli elementi più interessanti è la tecnica con cui vengono recuperati i nodi dai file ''XML'', in quanto si fa impiego del linguaggio standard W3C ''XPath'' ([0044], [0045]). Con ''XPath'' è possibile esprimere con una stringa un sottoinsieme di nodi presenti in una gerarchia ''XML'' non solo in base al loro nome o valore, ma anche in relazione alla posizione reciproca rispetto agli altri nodi. Riferendoci alle problematiche del servizio risulta, ad esempio, significativamente agevolato il trattamento di dati personali in forma tabellare.
Si osserva infine che la libreria attribuisce un id univoco ad ogni nodo del documento, di conseguenza se ne può trarre vantaggio nei confronti tra i nodi.

===Ottimizzazioni del processo di minimizzazione===

Durante l'analisi dei requisiti è emerso che l'efficienza costituisce un aspetto problematico del servizio. Si ricorda di aver stimato la durata di una prestazione media di circa 145 secondi, considerando dati:
* un documento di medie dimensioni (10 pagine ~ 5000 parole)
* tempo medio di 10 ms per individuare le occorrenze di un nome
* un dizionario di circa 14.500 parole

In linea di massima si individuano due generi di strategie che consentirebbero la riduzione del tempo medio di esecuzione: uno mirato a ridurre il più possibile il testo da sottoporre a "minimizzazione" automatica, l'altro a ottimizzare l'impiego del dizionario e dell'algoritmo di ricerca.

====Riduzione del testo da trattare====

Come già spiegato, l'approccio di ricerca ''pattern-based'' è poco sensibile all'aumentare della lunghezza del documento, ma da questo valore ha una dipendenza non trascurabile.

Nel documento è altamente probabile che ci siano interi periodi, se non pagine, dove non sia presente alcun nominativo. Anche all'interno di una frase che necessita di ''minimizzazione'' è plausibile che siano sono poche le coppie (al più le terne) di parole riconducibili ad una sequenza nome-cognome. È inessenziale che sezioni di testo che non necessitano di "minimizzazione" vengano processate. Si osserva per inciso che, ovviamente, questo ragionamento è corretto per via dell'indipendenza dal contesto di un approccio ''pattern-based''.

Il pattern definito per la ricerca di un nominativo è molto restrittivo, in quanto accetta solo sequenze di parole costituenti un nominativo contenente un nome specifico; d'altronde la progettazione del pattern è stata effettuata mirando ad identificare il più accuratamente possibile le sequenze da anonimizzare.

Analizzando attentamente il problema, si può fare il seguente ragionamento: per ridurre il più possibile il numero di parole da processare a ogni iterazione di ricerca del pattern di un nome, è possibile individuare preliminarmente tutte le sequenze di parole del documento che ''potrebbero essere'' dei nominativi e ''potrebbero'' fare match.

L'operazione di pre-filtraggio si applica processando il documento con un ''pattern'' che presenta un'espressione più generale e permissiva delle ''regex'' definite per i nomi del dizionario. Si osserva che una qualunque successione di caratteri ''alfabetici'' iniziante con un carattere maiuscolo ''potrebbe'' rappresentare un nome. Per realizzare un espressione adatta si parte dalla definizione della ''regular expression'' già data ai nomi del dizionario:

<div style="font-family: monospace;">
<regex> := (<second_name>\s)?(<nome>)\s<cognome>|<cognome>\s(<nome>)(\s<second_name>)?
</div>

Nell'uso fatto finora di questa espressione, al tag <span style="font-family: monospace;"><nome></span> viene attributo, ciclo dopo ciclo, una parola del dizionario diversa. È possibile definire una variante più generale dell'espressione appena presentata:

<div style="font-family: monospace;">
<nome_pre> := [A-Z][a-zA-ZÀ-ÖØ-öø-ÿ<extra>]+

<regex_pre> := (<second_name>\s)?(<nome_pre>)\s<cognome>|<cognome>\s(<nome_pre>)(\s<second_name>)?
</div>

Con questa ''regex'' si identifica una qualunque sequenza che rappresenta un nominativo, ma allo stesso tempo anche, ad esempio, tutte le parole consecutive inizianti con una maiuscola. È importante sottolineare che questo pattern presenta tutte le caratteristiche già ampiamente discusse sul formato delle ''regex'' per riconoscimenti automatici (gestione dei delimitatori, posizione relativa tra i nomi ed il cognome, etc.).
Il processamento di una ''regex'' generale inoltre sarà inevitabilmente più lento di quello di ''regex'' aventi i nomi specificati, in quanto molte più sequenze faranno match essendo l'espressione più permissiva. La mancanza di accuratezza va rapportata all'impiego della ''regular expression'': fornendo essa un semplice pre-filtraggio del documento non risulta necessario nè che individui esclusivamente nominativi nè che sia in grado di distinguerli gli uni dagli altri. Il leggero ritardo introdotto viene valutato sperimentalmente, applicando lo stesso l'algoritmo già usato in precedenza ed elaborando gli stessi documenti, sempre a parità di piattaforma.

Partendo dall'elaborazione di un documento contenente 10 nominativi ed in totale 5.000 parole, si misura che tempo il processamento medio della ''regex'' di pre-filtraggio è di circa 36 ms; si ricorda che per lo stesso documento il tempo di esecuzione medio per il processamento di un nominativo non presente è di circa 9 ms, se le occorrenze salgono a 10, il tempo è in media di circa 10 ms.
Sebbene l'elaborazione di questa ''regex'' sia circa 4 volte più lenta dell'elaborazione di ''regex'' più specifiche, un ritardo introdotto dell'ordine dei millisecondi è trascurabile rispetto al tempo di processamento complessivo (stimato di circa 145 second).
Si osserva, per inciso, che nell'elaborazione di questo particolare documento sono stati individuati altre 21 sequenze che rispettavano il pattern che non costituivano dei nominativi.

Terminata l'esecuzione dell'operazione di pre-filtraggio, occorre sfruttare opportunamente le informazioni ottenute: in particolare, si possono elaborare con le ''regex'' dei nomi le sole sotto-stringhe che hanno fatto match con la ''regular expression'' nell'operazione preliminare. In altri termini, con questo metodo si effettua una sola elaborazione del testo completo e molteplici processamenti delle sotto-stringhe che ''potrebbero'' contenere nominativi.
Si osserva inoltre che, conoscendo con certezza gli indici di inizio e fine delle sotto-stringhe che ''potenzialmente'' contengono nominativi, è possibile "alleggerire" la ''regex'' associata ai nomi del dizionario: si possono rimuovere i costrutti ''lookahead'' e ''lookbehind'' in quanto la sotto-stringa è stata già rimossa dal contesto e quindi rappresenta esclusivamente i caratteri individuati dalla ''regular expression'' di pre-filtraggio.

A questo punto occorre valutare sperimentalmente l'ottimizzazione ottenuta. Si misura che sono sufficienti 2 ms di elaborazione in media per nome, mentre, nel caso raro in cui tutti i 10 nominativi presenti si riconducano ad un unico nome, il tempo medio di esecuzione tende verso i 3 ms. Si osserva che questo è possibile perché le parole nelle sotto-stringhe sono poco meno di 50, ossia si è ridotta di oltre il 99% la dimensione complessiva di dati da processare!
Valutando l'ottimizzazione complessiva in termini di tempo si ha che, processando un dizionario di circa 14.500 termini, sono necessari in media 29 secondi.

Ovviamente questo dato è fortemente dipendente dal contenuto del documento. Vanno effettuate opportune misurazioni nel caso in cui la percentuale di nominativi presenti rispetto alle parole complessive nel documento sia maggiore. Si considera un documento di 5.000 parole contenente 200 sequenze riconosciute dall'algoritmo di pre-filtraggio delle quali 100 costituiscono dei nominativi.
Si misura che il tempo di esecuzione medio è di 6 ms nel caso generale del processamento di un nome con poche occorrenze e tenderà verso i 10 ms nel caso sporadico in cui le occorrenze del nome saranno proprio 100 o poco meno. Il tempo di esecuzione del pre-filtraggio è di circa 48 ms.
Per inciso, si osserva che la ragione per cui il tempo necessario al pre-filtraggio non aumenta esageratamente è dovuta al pattern della ''regex''. La ''regular expression'' impiegata infatti, facendo principalmente uso di caratteri espressi in un range unitamente al quantificatore "+", risulta particolarmente efficiente da elaborare.
Nel caso di documenti più "ricchi" di nomi si stima l'elaborazione media complessiva di circa 1 minuto e 27 secondi.

Facendo il punto della situazione, si è ridotto di circa 5 volte il tempo di esecuzione complessivo nel caso di documenti "scarsamente popolati" da nominativi e quasi dimezzato il tempo necessario nell'elaborazione di documenti contenenti molte coppie nome-cognome. Occorre proseguire nello studio per migliorare l'ottimizzazione, considerando dove l'algoritmo di ricerca e l'impiego del dizionario possono essere migliorati.

====Ordinamento del dizionario====

Viene posta una semplice domanda sulle modalità di ricerca dei nominativi nell'insieme delle sotto-stringhe del documento: è computazionalmente equivalente prendere una ad una le sotto-stringhe e confrontarle con le ''regex'' dei nomi rispetto che prendere una ad una le ''regex'' dei nomi e confrontarle con le sotto-stringhe?

Si fornisce una spiegazione formale alla domanda.

Si definiscono due insiemi:
* A = {a_1, a_2, ... a_n}
* B = {b_1, b_2, ... b_m}

Gli elementi dell'insieme A rappresentano le sotto-stringhe (cardinalità N), mentre gli elementi dell'insieme di B indicano le ''regex'' dei nomi (cardinalità M). È importante considerare che per il secondo insieme è definita una relazione di unicità che lega il valore degli elementi: per ogni ''b_i'' appartenente a B non esiste un indice ''j'', ''j'' compreso tra 1 ed M, tale che il testo del nodo ''i'' sia uguale al testo del nodo ''j'' (tranne se ''i'' = ''j''); in altre parole gli elementi rappresentanti le ''regex'' (''b_i'') per definizione sono posti univoci in B.

Si presti attenzione al fatto che l'insieme delle sotto-stringhe presenta N elementi distinti tra loro in identità ("id nodo"), ma il cui contenuto testuale può essere equivalente a quello di altre sotto-stringhe. L'equivalenza tra due sotto-stringhe sussiste, in questo particolare contesto, qualora i contenuti testuali di entrambe facciano match con una stessa ''regex'' presente nell'insieme B. L'insieme delle ''regex'', invece, presentano elementi i cui valori testuali sono sempre univoci, in quanto ottenuti da nomi sempre diversi.

Definiti gli insiemi si procede alla formulazione della risposta alla domanda precedente. Per chiarezza espositiva indicheremo con "A->B" la procedura con cui si opera il confronto prendendo una ad una le sotto-stringhe per poi confrontarle con le ''regex'', mentre indicheremo con "B->A" la procedura con cui si opera il confronto prendendo una ad una le ''regex'' dei nomi per poi confrontarle con le sotto-stringhe.

Nel caso in cui l'insieme delle sotto-stringhe non contenga alcun nominativo, si ha una complessità computazionale equivalente per "A->B" e per "B->A". Viene mostrato nei calcoli in figura che il numero di confronti necessari ''C_1'' è dato dal prodotto delle cardinalità degli insiemi, ossia ''C_1 = N · M''.

(QUI FIG[0F07])

Si suppone ora che il testo della sotto-stringa di posizione ''r'' faccia match con la ''regex'' in posizione ''k''; si applica "A->B". Come si mostra attraverso i calcoli in figura, il numero totale di confronti ''C_2'' sarà inferiore a ''C_1'' poiché, quando la sotto-stringa in posizione ''r'' risulta equivalente alla ''regex'' in posizione ''k'' si può direttamente passare alla valutazione della stringa in posizione ''r + 1'' e non svolgere i rimanenti ''m - k" confronti per la stringa in posizione ''r''. Si calcola che ''C_2 = k + m · (n -1)''.

(QUI FIG[0F08])

Supponendo sempre che il testo della sotto-stringa di posizione ''r'' faccia match con la ''regex'' in posizione ''k'', si applica "B->A". Similmente al caso precedente, quando la sotto-stringa in posizione ''r'' risulta equivalente alla ''regex'' in posizione ''k'' si può direttamente passare alla valutazione della ''regex'' in posizione ''k + 1'' e non svolgere i rimanenti ''n - r" confronti per la ''regex'' in posizione ''k''. Si osserva inoltre che è inutile confrontare le rimanenti ''m - k'' ''regex'' con la sotto-stringa di posizione ''r'': essa è risultata già equivalente ad una ''regex'' e, essendo le ''regex'' poste per definizione diverse tra loro, è di conseguenza impossibile che soddisfi un'altra uguaglianza.
Per inciso si osserva che nel calcolo di ''C_2'' un ragionamento di questo genere non è applicabile: ogni sotto-stringa può potenzialmente fare match con una qualsiasi ''regex''.
Il numero totale di confronti ''C_3'' viene calcolato come mostrato, si ottiene ''C_3 = k + m · (n -1) - n + r''.

(QUI FIG[0F09])

Si osserva che ''C_3 = C_2 - n + r'' e, essendo ''r'' la posizione della sotto-stringa coinvolta nel match, si ha che ''C_3'' è sempre minore di ''C_2'' qualunque sia la posizione della sotto-stringa. L'unico caso in cui ''C_3 = C_2'' si verifica quando la ''r = n'', ossia se la sotto-stringa è l'ultima dell'insieme.

Per estendere il ragionamento, si prende la ''regex'' di posizione ''k'' e si indica con ''T'' il numero di sotto-stringhe che sono già risultate equivalenti ad una ''regex'' nelle elaborazioni precedenti. Risulta che, per il ragionamento spiegato nel calcolo di ''C_3'', potranno essere risparmiati almeno ''N - T'' confronti per la ''regex'' ''k'' e per ogni ''regex'' in posizioni successive. In generale, maggiore è il numero di nominativi nel documento, maggiore sarebbe l'ottimizzazione della procedura.

Le conclusioni che si traggono sono due:
* indipendentemente dal numero o dalla posizione dei nominativi nelle sotto-stringhe, nell'algoritmo di minimizzazione è più efficiente prendere una ad una le ''regex'' dei nomi e con ognuna trattare l'insieme delle sotto-stringhe
* un efficace ordine di elaborazione delle ''regex'' può introdurre ottimizzazioni

Va eseguita ora una valutazione sperimentale dei tempi di esecuzione del processo di "minimizzazione" tenendo conto di questi elementi. Le ''regex'' che fanno match con i nominativi presenti nel testo, quindi, vengono trattate tra le prime. Risulta di interesse principalmente valutare i miglioramenti ottenibili nel caso di documenti ''molto popolati'' da nominativi, poiché è questo il caso in cui l'ottimizzazione entra in gioco.
Si esegue il test sullo stesso documento trattato precedentemente con la sola tecnica di pre-filtraggio. Esso è composto da 5.000 parole, dal pre-filtraggio sono individuate 200 sotto-stringhe delle quali 100 costituiscono dei nominativi.
Nel test si è fatto riferimento a dati Istat ([0046]) per stabilire, quanto più realisticamente possibile, il miglior ordine di elaborazione delle ''regex'' associate ai nomi; risulta che circa il 25% dei nominativi è individuato entro i primi 15 cicli di esecuzione; circa il 35% entro i primi 50 ed il 100% entro circa i primi 3000. Per inciso, si osserva che un altro documento può dare origine a tempi significativamente peggiori qualora presenti molti nominativi con nomi desueti e presenti in fondo al dizionario.
Si misura che, dopo il "transitorio iniziale" (ossia dalla 51° ''regex'' in poi), il tempo medio è di 5 ms per l'elaborazione di una ''regex''. Si osserva che, una volta che sono state elaborate circa le prime 3000 ''regex'', il tempo medio di elaborazione di una ''regex'' scende a 4 ms. Per completezza, si riporta anche il tempo medio per la fase di "transitorio iniziale", che si misura di circa 8 ms; il tempo di pre-filtraggio, già precedentemente calcolato, risulta di 48 ms.
Calcolando complessivamente la durata del processamento si ottiene che l'elaborazione media complessiva è di circa 61 secondi, si ottiene quindi una riduzione significativa rispetto al tempo di 1 minuto e 27 prima individuato.

Si considerano, in relazione alle conclusioni della discussione teorica prima formalizzata, le implicazioni realizzative: in primis che l'imposizione del verso con cui eseguire la "minimizzazione" non determina particolari problemi implementativi, in secundis che l'ordinamento efficiente dei nomi del dizionario può essere trattato attraverso una tecnica di ''machine learning''.

La tecnica di apprendimento che si realizza si basa sull'estrapolazione di informazioni utili nei documenti inviati dagli utenti. Si tiene traccia, infatti, della ''frequenza'' con cui un nome appare in diversi processamenti. Alla fine di ogni "minimizzazione", dopo aver concluso il salvataggio del nuovo file ''OOXML'', il programma Java eseguirà l'update sul database MySql delle frequenze dei nomi trovate, incrementandole.
Nell'interrogazione al database per l'ottenimento dell'insieme dei nomi, di conseguenza, si richiederà l'ordinamento per frequenza delle tuple restituite. In questo modo, più volte un nome compare nei documenti, più incrementi riceverà il suo campo frequenza, più avrà la probabilità di comparire in cima al dizionario.
Si progetta inoltre l'inserimento di un campo "ultimo utilizzo", associato ai nomi sul database, che permette di avere un secondo criterio di ordinamento utile. Tale campo viene impiegato anche per evitare una crescita esagerata del valore della frequenza; periodicamente, con ''crond'' ad esempio, si decrementano i valori del campo "frequenza" dei nomi il cui "ultimo utilizzo" è troppo vecchio. Si osserva che i valori di configurazione per la gestione di queste elementi dipendono dal carico medio del sistema, noto solo dopo la progettazione, andranno valutati con precisione in fasi future. Ovviamente l'aggiornamento del campo "ultimo utilizzo" sarà contestuale all'aggiornamento della ''frequenza''.
Si osserva, per inciso, che l'impiego di un dizionario di cognomi sarebbe stato problematico per l'aggiornamento delle frequenze. Per via del principio ''Privacy by Design'', infatti, aggiornando la frequenza per la entry del cognome di una persona, indirettamente si sarebbe tenuto traccia di un dato sensibile, specialmente nel caso in cui il cognome risulti "raro".
Una valutazione rilevante da fare è sulle implicazioni relative agli accessi concorrenti al dizionario, dovute all'introduzione dell'algoritmo appena spiegato, che esegue scrittura di "frequenza" e ''ultimo utilizzo'' sul database. Si osserva che non sono problematiche le "letture sporche", poiché, se si verificano, al più risulta alterato l'ordine di qualche nome; inoltre nemmeno un "lost update" risulta eccessivamente problematico, poiché l'ultimo utilizzo risulta sempre aggiornato e la perdita di un incremento delle frequenza di un nome non rappresenta in linea di massima un problema. Questi scenari presentati vanno valutati complessivamente, però, una volta che si realizza il reale carico del sistema: perdere molti update risulta critico per l'ottimizzazione del processamento. Conviene in linea precauzionale prevedere una semantica transazionale per l'interazione tra modulo Java e database. Per inciso, eseguire l'update finale con una transazione non influenza il tempo di attesa dell'utente, poiché il documento è stato già elaborato per intero.

Si fa infine un'ultima osservazione che consente di abbattere i tempi di attesa enormemente, a costo di perdere dell'accuratezza nel processamento automatico: ridurre il numero di nomi del dizionario processato, elaborando solo quelli in cima.
Si osserva che questa soluzione è ancor più efficace se i nomi contenuti nel documento sono pochi. In questo caso, infatti, il processamento dei nomi durante la fase di "transitorio iniziale" richiede lo stesso tempo del processamento di nomi "a regime", ossia dopo l'avvenuta riduzione del numero di sotto-stringhe da elaborare. Nei documenti "ricchi" di nominativi, come già spiegato, ciò non avviene.
Per concludere, si usano i risultati dei test sperimentali precedentemente misurati per stimare il tempo di processamento complessivo, supponendo di:
* applicare la tecnica di pre-filtraggio
* usare i primi 1.500 nomi di un dizionario ordinato per frequenza

Caso A:
* documento contenente 10 nominativi ed un totale di 5.000 parole
* processamento medio della ''regex'' di pre-filtraggio di circa 36 ms
* individuazione di 31 sotto-stringhe totali
* durata elaborazione in media per nome di circa 2 ms

Durata esecuzione senza troncamento: 29 secondi circa

Durata esecuzione con troncamento: 3 secondi circa

Caso B:
* documento contenente 100 nominativi ed un totale di 5.000 parole
* processamento medio della ''regex'' di pre-filtraggio di circa 48 ms
* individuazione di 200 sotto-stringhe totali
* durata elaborazione in media per nome di circa 8 ms per prime 50 iterazioni
* durata elaborazione in media per nome di circa 5 ms per successive

Durata esecuzione con solo pre-filtraggio: 1 minuto e 27 secondi

Durata esecuzione senza troncamento: 61 secondi circa

Durata esecuzione con troncamento: 7.7 secondi circa

I tempi a cui si giunge risultano soddisfacenti in entrambi i casi. Si prevede di lasciare all'utente la possibilità di scegliere di ricevere un servizio o più veloce o più accurato, in base alle sue esigenze.

===Tecnologie complementari===

La redazione di questa tesi è avvenuta su Mediawiki, la più importante fra le piattaforme wiki essendo il motore di Wikipedia.

Le piattaforme wiki sono riconosciute come elemento caratterizzante dell’evoluzione Internet al Web 2.0, cioè al web nel quale gli utenti-navigatori, fino ad allora "''consumatori"'' ("''consumers"'') di contenuti si sono trasformati essi stessi in "''produttori"'' ("''producers"''), e cioè in "''prosumers"''.

Un ''wiki'' è fondamentalmente un sito web che contiene informazioni e che consente agli utenti di editare facilmente il suo contenuto.

Nel redigere una pagina wiki si utilizza ciò che è chiamato ''wikitext" per definire capitoli, paragrafi, hyperlinks, elementi di formattazione della pagina, etc.; sebbene il ''wikitext" risulti non difficile da apprendere, quasi ogni piattaforma wiki è corredata da editor di tipo visuale, che non richiede alcuna conoscenza della sintassi del ''wikitext"; tuttavia è esperienza comune che utilizzare direttamente il ''wikitext" induce a concentrarsi maggiormente sui contenuti e non sulla formattazione. Il linguaggio ''wikitext'' è strettamente correlato con il linguaggio HTML, infatti nella scrittura è possibile utilizzare tag come h1, span, div e così via, oltre che la sintassi esclusiva di ''wikitext''; simmetricamente una pagina prodotta da media wiki è costituita da HTML ben formato e direttamente importabile in ogni word processor.

I wiki presentano una funzionalità di grande utilità nella redazione di documenti articolati: la tracciatura delle successive revisioni ("''Cronologia"''). La possibilità di ripercorrere l’evoluzione del testo è davvero d’aiuto quando si fissano idee originali in uno scritto, cercando di definirle, precisarle, chiarirle, come è avvenuto in effetti, anche nella redazione di questa tesi. Per curiosità, si segnala che, pur avendo redatto la maggior parte del testo off-line, la pagina wiki di questa tesi conta oltre 50 revisioni.

Per inciso, si osserva che è stata molto utile la funzionalità di "ricerca nel codice" offerta dalla piattaforma di revisione online GitHub nella corretta comprensione della libreria Docx4j, il cui codice sorgente è ivi rilasciato.

Si conclude infine dicendo che per ottimizzare le procedure di debug del codice sono stati realizzati utili tool a riga di comando per Linux per la rapida estrazione-modifica-ricompattazione di documenti ''OOXML''. Si propone in appendice un comando bash per questi scopi.

==Sviluppi futuri==

In questa sezione si fa cenno, senza poterle approfondire, ad alcune interessanti questioni emerse nello svolgimento della tesi.

===Accesso al servizio web===

In fase iniziale, il servizio web potrà essere reso accessibile in forma completamente aperta, senza richiedere cioè la registrazione dell’utente o l’autenticazione dell’utente già registrato. In questo modo, in effetti, si premia la facilità d’uso, ma si incorre nella nota problematica di un uso malevolo, costituito da accessi a raffica, finalizzati a saturare il server e generare una condizione di ''DoS – Denial of Service''. Diverse sono le tecniche che possono essere adottate per contrastare questo tipo di accessi malevoli, come richiedere di superare "''captcha''" e/o introdurre ritardi crescenti ed eventualmente blocchi in risposta ad accessi prevenienti con alta frequenza dallo stesso indirizzo IP.
È possibile anche pensare ad un accesso previa registrazione ed autenticazione dell’utente, penalizzando l’immediatezza di utilizzo del servizio, ma eventualmente ottenendo l’indirizzo email degli utenti che acconsentono a lasciarlo per successive finalità marketing.
È possibile, infine, un utilizzo misto, contando in un cookie il numero di accessi eseguiti e richiedendo all’utente di registrarsi per continuare ad utilizzare il servizio, dopo qualche accesso.

===Ampliamento dinamico del dizionario===

Nel restituire il documento elaborato all'utente, gli si da la possibilità di richiedere una nuova elaborazione, dopo aver indicato i nominativi che fossero sfuggiti; pare inesauribile, infatti, la "fantasia" dei genitori nel dare nome ai propri figlioli!
I nominativi indicati dall'utente sono sfuggiti al servizio perché non presenti nel dizionario: facilmente viene in mente l’idea di arricchire il dizionario con i nominativi indicati dall’utente. Va però considerato il caso che l’utente in malafede indichi nominativi fasulli al fine di inquinare il dizionario.
Il caso malevolo può essere affrontato attraverso una strategia che preveda non direttamente l'inserimento del nuovo nominativo nel dizionario, ma invece l'utilizzo di un concetto di "candidatura": il nuovo nominativo viene registrato, ma si attende di avere un certo numero di utenti che lo propongono prima di approvarne l'inserimento nel dizionario.
Può anche essere utilizzato un concetto di "attendibilità" della candidatura di un nuovo nominativo, verificando ad esempio l'utente che lo propone scarichi effettivamente il file rielaborato.
Nel caso l'accesso avvenga con autenticazione, e cioè identificando gli utenti, si apre la possibilità di individuare e bannare gli utenti malevoli.

===Natura del documento e ricorrenza del nominativo===

Si coglie facilmente la differenza di formato fra un documento in forma di elenco (es. una graduatoria) da un documento in forma di relazione (es. una sentenza giudiziaria). Differenze di questo tipo potrebbero essere utilizzate per escludere o ammettere la ripetizione dei nominativi.
Per meglio dire: in un elenco la ripetizione di un nominativo è di fatto da escludersi o va trattata come omonimia. In una relazione, l’individuazione di un nominativo può essere utilizzata per ricercarlo direttamente in altri punti del documento stesso.

===Altri dati personali===

Altri dati personali sono trattabili con le stesse tecniche analizzate in questa tesi: date e luoghi di nascita, codici fiscali, indirizzi, email, numeri di telefono, sesso etc. In qualche caso, come per i codici fiscali, l’individuazione del pattern da trattare è persino più semplice.
Diversi studi ([0039]) hanno dimostrato che, utilizzando set di dati personali parziali, è possibile la re-identificazione dei soggetti, pur in documenti pseudonimizzati. È questo un altro motivo per estendere i trattamenti descritti anche agli altri dati personali richiamati.

===Altri alfabeti===

È possibile estendere il sotto-insieme di caratteri Unicode utilizzati nelle ''regex'' per elaborare documenti scritti in altri alfabeti non latini.

==Conclusioni==

Questa tesi è partita da un problema basilare, quasi scolastico, dell'informatica: la ricerca di un testo in un documento, al fine della sua cancellazione o modifica.

Il problema si è subito discostato dalla sua formulazione basilare, principalmente perché, nei casi d'uso, il documento da ricercare non è un semplice testo ("''plain text''") ma invece è il prodotto di un ''word-processor'': quindi è costituito da una struttura XML più o meno complessa, rappresentante formattazioni, riferimenti interni o esterni, note, etc. La ricerca deve avvenire nei soli nodi di puro testo, individuando ed escludendo dall'analisi lessicale gli elementi testuali di mark-up che non costituiscono contenuto informativo. Nell'approfondire le strutture ed i concetti XML ho potuto notare quanto essi siano ricorrenti in molti ambiti dell'informatica.

Nell'analisi delle specifiche, un'altra complicazione si è presto aggiunta: l'usabilità del servizio cresce drasticamente se si evita di chiedere all'utente, come si era pensato in un primo tempo di fare, quali siano le stringhe (i nominativi) da ricercare e trattare; è nata allora l'idea di reperire queste stringhe in un dizionario di nomi ed in un dizionario di cognomi, considerando anche le permutazioni dei lemmi reperiti. Ho così dovuto approfondire alcuni problemi tipici dei dizionari, come il loro ampliamento automatico con tecniche oggi comprese nel ''machine-learning''. Non ho potuto "resistere" alla tentazione di ''formalizzare la matematica'' in base alla quale ho costruito le strategie di ricerca.

Spunto per la tesi è stata la recente legislazione in materia di dati personali, il GDPR. Esaminandone gli articoli pertinenti, ho maturato una riflessione generale: sempre più il software dovrà essere progettato e realizzato anche alla luce di altre discipline, non solo di quelle informatiche, come le discipline giuridiche ed il diritto.

Durante la fase iniziale della collaborazione con l'azienda mi sono dedicato alla messa a punto delle specifiche; ciò mi ha permesso di comprendere quanto questa fase sia importante e come completezza e precisione delle specifiche siano alla base di un progetto efficace.

Molto importanti sono state la analisi relative al tipo e formato dei documenti da assumere come input ed alla presentazione ottimale del servizio rispetto all'usabilità.

Centrale nel lavoro ed avvincente è stata la definizione della strategia per il riconoscimento dei lessemi attraverso la costruzione dinamica di ''regex'' idonee. In questo fase del lavoro, anche per passione personale, ho approfondito le questioni del riconoscimento "di testi nei testi" che legano, fin dalle origini, l'informatica e la linguistica.

La fase di definizione dell'architettura del servizio mi ha permesso di ripercorrere molte le materie studiate nei tre anni del Corso di Ingegneria Informatica, affrontando argomenti come il Single Responsibility Principle, il Dependency Inversion Principle, lo "stile" architetturale REST. Molto istruttiva è stata anche la riflessione sulla scomposizione del servizio in moduli software.

Come sempre accade nell'affrontare un progetto nuovo, sono nate molte nuove idee; ho così immaginato numerosi sviluppi futuri, sia a perfezionamento funzionale dell'accesso web al servizio, sia ad estensione delle specifiche per coprire casi applicativi contigui (es. quando il dato che si vuole trattare è un codice fiscale). Dovendo necessariamente tener presente che questo lavoro è una tesi, verificherò con il supporto del mio relatore come poterne proseguire lo sviluppo.

==Bibliografia==

<div></div>[0000]https://en.wikipedia.org/wiki/Comparison_of_Office_Open_XML_software
<div></div>[0001]https://en.wikipedia.org/wiki/Comparison_of_OpenDocument_software
<div></div>[0002]https://en.wikipedia.org/wiki/Standardization_of_Office_Open_XML
<div></div>[0003]https://en.wikipedia.org/wiki/OpenDocument_standardization
<div></div>[0004]https://support.apple.com/en-us/HT202227
<div></div>[0005]https://en.wikipedia.org/wiki/Pages_(word_processor)
<div></div>[0006]https://en.wikipedia.org/wiki/Comparison_of_word_processors
<div></div>[0007]https://en.wikipedia.org/wiki/OpenDocument
<div></div>[0008]https://en.wikipedia.org/wiki/Office_Open_XML_file_formats
<div></div>[0009]https://en.wikipedia.org/wiki/Rich_Text_Format
<div></div>[0010]https://www.ecma-international.org/publications/standards/Ecma-376.htm
<div></div>[0011]https://www.iso.org/standard/51463.html
<div></div>[0012]https://www.iso.org/standard/71691.html
<div></div>[0013]https://en.wikipedia.org/wiki/Office_Open_XML
<div></div>[0014]https://en.wikipedia.org/wiki/Open_Packaging_Conventions
<div></div>[0015]https://en.wikipedia.org/wiki/LAMP_(software_bundle)
<div></div>[0016]https://w3techs.com/blog/entry/debian_ubuntu_extend_the_dominance_in_the_linux_web_server_market_at_the_expense_of_red_hat_centos
<div></div>[0017]https://news.netcraft.com/archives/2014/06/06/june-2014-web-server-survey.html
<div></div>[0018]https://whatis.techtarget.com/definition/LAMP-Linux-Apache-MySQL-PHP
<div></div>[0019]https://www.ibm.com/cloud/learn/lamp-stack-explained
<div></div>[0020]https://en.wikipedia.org/wiki/Single_responsibility_principle
<div></div>[0021]https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
<div></div>[0022]https://en.wikipedia.org/wiki/Latin_script_in_Unicode
<div></div>[0023]https://it.wikipedia.org/wiki/ISO/IEC_8859-1
<div></div>[0024]http://www.treccani.it/enciclopedia/uso-delle-maiuscole_%28La-grammatica-italiana%29/
<div></div>[0025]https://en.wikipedia.org/wiki/Ambiguity#Linguistic_forms
<div></div>[0026]Steven L. Small; Garrison W Cottrell; Michael K Tanenhaus (22 October 2013). Lexical Ambiguity Resolution: Perspective from Psycholinguistics, Neuropsychology and Artificial Intelligence. Elsevier Science. ISBN 978-0-08-051013-2.
<div></div>[0027]http://www.treccani.it/vocabolario/disambiguazione/
<div></div>[0028]R. Navigli, K. Litkowski, O. Hargraves. 2007. SemEval-2007 Task 07: Coarse-Grained English All-Words Task. Proc. of Semeval-2007 Workshop (SemEval), in the 45th Annual Meeting of the Association for Computational Linguistics (ACL 2007), Prague, Czech Republic, pp. 30–35 http://www.aclweb.org/anthology/S/S07/S07-1006.pdf
<div></div>[0029]https://wordnet.princeton.edu/
<div></div>[0030]R. Navigli, S. P. Ponzetto. BabelNet: Building a Very Large Multilingual Semantic Network. Proc. of the 48th Annual Meeting of the Association for Computational Linguistics (ACL 2010), Uppsala, Sweden, July 11-16, 2010, pp. 216-225. http://aclweb.org/anthology/P/P10/P10-1023.pdf
<div></div>[0031]Roventini A., Alonge A., Calzolari N., Magnini B., Bertagna F. (2000), "ItalWordNet: a Large Semantic Database for Italian", Proc. of the 2nd International Conference on Language Resources and Evaluation (LREC 2000), Athens, Greece, 2000, pp. 783-790.
<div></div>[0032]E. Pianta, L. Bentivogli, C. Girardi. MultiWordNet: developing an aligned multilingual database, Proc. of the First International Conference on Global WordNet, Mysore, India, January 21-25, 2002. http://multiwordnet.fbk.eu/paper/MWN-India-published.pdf
<div></div>[0033]https://www.iso.org/standard/28245.html
<div></div>[0034]https://www.gpdp.it/web/guest/regolamentoue
<div></div>[0035]https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=uriserv:OJ.L_.2016.119.01.0001.01.ITA&toc=OJ:L:2016:119:TOC
<div></div>[0036]https://www.corriere.it/Primo_Piano/Cronache/2006/09_Settembre/15/cognomi.shtml
<div></div>[0037]https://data.world/axtscz/italian-first-names
<div></div>[0038]https://en.wikipedia.org/wiki/Dependency_inversion_principle
<div></div>[0039]https://imperialcollegelondon.app.box.com/s/lqqcugie51pllz26uixjvx0uio8qxgo5/file/493461282808
<div></div>[0040https://www.docx4java.org/trac/docx4j]
<div></div>[0041]https://github.com/plutext/docx4j
<div></div>[0042]https://docs.oracle.com/javase/9/docs/api/java/lang/String.html
<div></div>[0043]https://github.com/php/php-src/blob/master/ext/session/session.c
<div></div>[0044]https://github.com/plutext/docx4j/search?q=getJAXBNodesViaXPath+in%3Afile&type=Code
<div></div>[0045]https://www.w3.org/TR/xpath-30/
<div></div>[0046]https://www.istat.it/it/dati-analisi-e-prodotti/contenuti-interattivi/contanomi
<div></div>[0047]
<div></div>[0048]

==Indice delle figure==

[0F00]https://en.wikipedia.org/wiki/Latin_script


[0F01]Diagramma di Venn 1

[0F02]Diagramma di Venn 2

[0F03]Diagramma di Venn 3

[0F04]Esito unit test regex (cartella immagini)

[0F05]Inforgrafica GDPR

[0F06]Diagramma di sequenza UML

[0F07]Primo calcolo valutazione algoritmo

[0F08]Secondo calcolo valutazione algoritmo

[0F09]Terzo calcolo valutazione algoritmo

Servizio web per il trattamento dei dati personali contenuti in documenti OOXML complessi

2019-09-30T04:00:52Z

Lorenzo.amorosa: /* Ottimizzazioni del processo di minimizzazione */ - nomi sotto pragraf.

==Introduzione==

Il recente Regolamento Generale europeo sulla Protezione dei Dati (UE) 2016/679 ([0034], [0035]) o ''GDPR'' (''General Data Protection Regulation'', come nel seguito sarà chiamato) ha modernizzato significativamente la normativa in materia di protezione dei dati personali, rendendola omogenea fra tutti gli stati membri. È bene notare che, fin dal titolo, il ''GDPR'' non riduce gli spazi per i trattamenti di dati personali, ma anzi ne protegge la "libera circolazione", dettando, però, regole definite e certe. Rinunciando ad una presentazione più completa del ''GDPR'', saranno riportati nei successivi capitoli i concetti necessari alla discussione dell'argomento.<div></div>
Enti ed organizzazioni, aventi a che fare con documenti contenenti dati sensibili, devono operare in maniera conforme al ''GDPR''; potrebbero, di conseguenza, trarre beneficio da servizi specifici in grado di supportarli in queste esigenze.<div></div>
L'oggetto principale della tesi sarà dunque, come riportato dal titolo, la progettazione e la realizzazione di un servizio per la gestione di dati personali.
<div></div>(QUI IMG [0F05])<div></div>

La larga maggioranza dei documenti testuali viene generata con strumenti cosiddetti di "produttività individuale", cioè da ''word-processors''. L'osservazione, ovvia nella sua evidenza, consente di introdurre una riflessione: quando un documento è generato da un'elaborazione automatica, magari per composizione di ''template'' con dati estratti da un database, l'individuazione dei "dati personali" nel documento prodotto può avvenire in modo rigoroso e senza incertezze, sulla base degli elementi di composizione del documento; ad es.: i campi del documento estratti da una anagrafica di soggetti sono certamente dati personali e come tali possono essere opportunamente trattati nel processo di elaborazione automatica (ad es. cancellati).

Ma, in quella larga maggioranza di documenti testuali generata con ''word-processors'' l'individuazione ed il trattamento dei dati personali vanno affrontati con altri approcci, discussi in questa tesi.

==Scenario di lavoro==

===Minimizzazione dei dati personali===

Un concetto espresso in modo pervasivo dal ''GDPR'' è quello della "''minimizzazione''" dei dati personali trattati ed a maggior ragione dei dati personali pubblicati. In particolare l'Art. 5 ed il Considerando 39 prescrivono che i dati personali trattati siano "''adeguati, pertinenti e limitati a quanto necessario rispetto alle finalità per le quali sono trattati («minimizzazione dei dati»)''" ([0035]).<div></div>
Con questo fine, il GDPR delinea due possibilità organizzative e tecniche di "''minimizzazione''": l'anonimizzazione e la psedonimizzazione.

====Anonimizzazione====

Sono anonimizzati i dati personali non (più) riferibili alle persone a cui sono appartenuti; si tratta di serie di dati, spesso ingenti, che sono stati definitivamente ed irreversibilmente separati da ogni riferimento alle persone che caratterizzavano. Sono le serie di dati utilizzate per fini statistici, scientifici, etc. E' importante notare che, come fissato dal Considerando 26 del ''GDPR'', il Regolamento non si applica al "''trattamento di tali informazioni anonime''" ([0035]). Per questo, sottoporre database e documenti ad un procedimento, cioè un trattamento, di anonimizzazione consente di non doversi più preoccupare del ''GDPR''.

====Pseudonimizzazione====

Fra le definizioni dell'Art. 4 del ''GDPR'', la "pseudonimizzazione" viene indicata come "''il trattamento tale che i dati personali non possano più essere attribuiti a un interessato specifico senza l’utilizzo di informazioni aggiuntive, a condizione che tali informazioni aggiuntive siano conservate separatamente''" ([0035]).<div></div>
Traducendo in termini "operativi", si tratta del procedimento che, dal "record" dei dati di un interessato, separa i campi che caratterizzano l'interessato stesso da quelli che lo identificano, trasferendo questi ultimi in una nuova distinta tabella; nelle due tabelle vengono aggiunti i riferimenti che permettono la ricostruzione del record originario; il procedimento è completo quando la nuova tabella con gli identificativi viene archiviata separatamente ed eventualmente cifrata. In margine si annota che in molti casi, come molti studi dimostrano, è possibile identificare, quindi "riconoscere", gli interessati utilizzando la sola tabella con i dati pseudonimizzati.

====Altri trattamenti di "minimizzazione" ====

Un problema pratico che si incontra di frequente è quello di dover pubblicare documenti più o meno ampi che contengono dati personali. Spesso la pubblicazione è obbligatoria per legge: si pensi alle graduatorie relative a concorsi pubblici, alle sentenze dei tribunali, etc.<div></div>
In questi frequenti casi, analizzando meglio le finalità per le quali sono pubblicati quei dati personali, si osserva che sono possibili e legittimi almeno due approcci per "minimizzare" il dato nel "trattamento di pubblicazione" e, dunque, per minimizzarne la propagazione, ad esempio attraverso motori di ricerca, ben oltre ogni ragionevole finalità. I contesti ed i corrispondenti approcci sono:
# Situazioni in cui è necessario che l'interessato possa riconoscersi nel documento ed essere riconosciuto dagli altri soggetti menzionati nel contesto, ma non è plausibile la necessità di identificazione dell'interessato al di fuori di quel contesto specifico. A questo caso si riconducono le graduatorie di concorsi, gli elenchi per la formazione di classi, gli elenchi per convocazioni, etc. In tutti questi casi, nel processo di redazione del documento è più pratico trattare internamente i dati personali in forma completa; ma praticamente mai è necessario pubblicarli per intero, esponendo al pubblico accesso codici fiscali, indirizzi, recapiti telefonici etc. Per di più, nella maggior parte delle volte, è sufficiente pubblicare il solo cognome perché l'interessato conosca la sua posizione in graduatoria; ciò è spesso sufficiente anche a trasmettere l'informazione necessaria ai colleghi dell'interessato nella medesima graduatoria, o nella medesima classe, etc. Notare che, pubblicando il solo cognome, viene di fatto oscurato anche il sesso. Dunque, in questi casi è auspicabile cancellare una larga parte dei dati personali presenti nel documento.
# Situazioni in cui il documento deve essere pubblicato affinché siano rese note le motivazioni che lo hanno originato, senza che sia necessaria la precisa identificazione dei soggetti che vi compaiono. Questo è il caso della pubblicazione di sentenze giudiziarie di ogni grado. Le sentenze vengono notificate direttamente agli "aventi causa"; ma anche, come la legge prescrive, pubblicate al fine di costituire giurisprudenza. In questo secondo caso, risulta del tutto eccedente la pubblicazione dei reali nominativi degli interessati, che troverebbero verosimilmente la propria vicenda inutilmente indicizzata dai motori di ricerca negli anni a venire. Nella pubblicazione delle sentenze appare un approccio ottimale quello di sostituire con pseudonimi o con iniziali alterate i veri nominativi degli interessati presenti: il senso e le argomentazioni della sentenza restano pienamente comprensibili, come è necessario; il dato personale, del tutto superfluo ai fini della giurisprudenza, viene protetto.
In questi casi appare opportuno sostituire i dati identificativi dell'interessato, ed in particolare il nome e cognome, con pseudonimi o, ancora, con iniziali alterate, cioè non coincidenti con le iniziali reali. <div></div>
Proprio questi tipi di trattamenti di "minimizzazione" sono l'oggetto di questa tesi.

===Punti di partenza per la progettazione del servizio===

La tesi è stata svolta in collaborazione con l'azienda AFA Systems (www.afasystems.it/gdpr) con la quale si sono discusse le problematiche di progettazione e realizzazione di un servizio generalizzato di minimizzazione dei dati personali presenti in un documento.
Con l'intenzione di fornire il servizio ad un bacino d'utenza il più vasto e variegato possibile, si è pensato ad un'applicazione ''web-based'', indipendente così dai singoli devices sui quali poi sarà utilizzata.
L'attenzione è stata concentrata sul trattamento dei nomi e dei cognomi (che da qui chiameremo nominativi), poiché sono quelli sempre presenti nei documenti (ad es. gli indirizzi sono presenti solo a volte), rappresentano gli elementi tramite i quali è immediato il riconoscimento della persone, non hanno formato predefinito (come ad es. i codici fiscali); altri dati personali (indirizzi, codici fiscali, etc.), potranno essere considerati in successive evoluzioni del progetto.
È utile notare che la parte iniziale della collaborazione con l'azienda è stata dedicata alla discussione delle specifiche, la cui più precisa definizione è parte rilevante di questa tesi.<div></div>
Tra i requisiti che necessitano di un opportuno studio troviamo ad esempio:
* L'individuazione di metodi efficaci per il riconoscimento dei nominativi nei documenti
* L'identificazione delle migliori procedure di interazione con l'utente
* La scelta dei formati da trattare
* I vincoli non funzionali legati al rispetto del ''GDPR''.

==Definizione delle specifiche==

===Riconoscimento dei nominativi===

====Scelta della strategia di riconoscimento====

Le difficoltà principali con cui ci si imbatte nel processo di riconoscimento dei nominativi riguardano la complessità strutturale dei documenti di testo, ma soprattutto l'intrinseca ambiguità del linguaggio naturale. <div></div>
Le variabili ed impredicibili strutture e formattazioni dei documenti introducono alcuni problemi significativi. Rendendo fortemente eterogeneo il contenuto dei documenti, infatti, esse non consentono di ricondurre il problema del riconoscimento dei nominativi ad uno o a pochi singoli casi, ma comportano lo studio di tutte le strutture e formattazioni possibili, rendendo quindi l'analisi molto generale. L'altra rilevante difficoltà presente sta nella complessità di effettuare il riconoscimento di una stringa testuale immersa in un insieme di elementi non tutti testuali. Ogni elemento di formattazione, che sia una tabella o una barra orizzontale, introduce infatti un proprio significato logico e semantico nel documento di cui bisogna tenere conto.<div></div>
Il linguaggio naturale introduce anch'esso complessità: si pensi alle molteplici tipologie di proposizioni con cui possono essere articolati i periodi; ma i problemi principali derivano dalle sue ambiguità. Esse vengono classificate in diverse tipologie ([0025]); le principali sono le ambiguità sintattiche e lessicali.<div></div>
Si ha ambiguità sintattica quando la sintassi di una frase può essere interpretata in diversi modi e, di conseguenza, la frase stessa assume significati diversi. Essa è presente, ad esempio, nelle seguenti frasi:<div></div>
* "''Rapina in banca con rivoltella da centomila euro''"
* "''Luigi ha visto un uomo nel parco con il binocolo''"
<div></div>
L'esasperazione massima della problematica delle ambiguità sintattiche si presenta con l'<i>antinomia</i>, ossia un particolare tipo di paradosso che indica la compresenza di due affermazioni contraddittorie che possono essere entrambe dimostrate o giustificate.
L'antinomia di Epimenide o ''Paradosso del mentitore'', nota fin dal VI secolo, è probabilmente uno dei più noti esempi: "''il cretese Epimenide afferma che tutti i cretesi mentono''". Se la proposizione è vera (i cretesi mentono) allora il suo significato implica che sia falsa (Epimenide mente e quindi i cretesi dicono la verità), ma se è falsa (i cretesi dicono la verità) ciò significa che è vera (Epimenide dice la verità e quindi i cretesi mentono). La proposizione appare contemporaneamente vera e falsa. A partire dagli anni venti del '900, sono state elaborate varie teorie per la risoluzione delle contraddizioni provocate dalle antinomie, soprattutto attraverso l'elaborazione di linguaggi multilivello o attraverso l'elaborazione di logiche polivalenti (quindi non-booleane).<div></div>
Si ha ambiguità lessicale, invece, quando una parola possiede più di un significato nella lingua a cui appartiene ([0026]), in tal caso la parola è definita ''polisemica''. In italiano, alcuni termini soggetti a questo tipo di ambiguità sono, ad esempio "''acuto''" o "''venti''". È questo genere di ambiguità che risulta critico per il riconoscimento dei nominativi. La difficoltà determinata dalle ambiguità sintattiche, infatti, riguarda l'individuazione corretta di soggetti, predicati e complementi di un periodo, mentre le ambiguità lessicali ostacolano la comprensione del significato del singolo lessema. Nel processo di riconoscimento è irrilevante determinare la funzione logica che il nominativo svolge nella frase, mentre è necessario essere certi che i termini che compongono il nominativo siano effettivamente dei nomi propri di persona o dei cognomi, non altri vocaboli del lessico comune. <div></div>
In linguistica, l'intervento con cui si toglie ambiguità a una parola o a una frase prende il nome di "disambiguazione" ([0027]). Il problema della disambiguazione automatica (in inglese ''Word Sense Disambiguation'' o, abbreviato, ''WSD'') riveste particolare importanza nelle ricerche sull'intelligenza artificiale e, in particolare, nell'elaborazione del linguaggio naturale. Si prevedono benefici della disambiguazione, ad esempio, in programmi di traduzione automatica, recupero dell'informazione o estrazione automatica di informazioni. Nell'analisi delle soluzioni esistenti in letteratura per la risoluzione delle ambiguità, ci si sofferma specialmente sulle ricerche incentrate sul trattamento dell'ambiguità lessicale, essendo essa la più rilevante per i nostri interessi.<div></div>
La ''WSD'' richiede due input necessariamente: un dizionario per specificare i sensi che devono essere disambiguati e un corpus di dati linguistici da disambiguare. Nello scenario più realistico, si trattano testi le cui parole non sono note a priori e risulta molto onerosa la produzione del corpus, essendo infatti necessaria la valutazione di un operatore umano per verificare la correttezza delle disambiguazioni effettuate dagli algoritmi (''supervised learning'').<div></div>
Uno tra i principali dizionari semantici-lessicali utilizzati della lingua inglese è ''WordNet'' ([0029]), mentre alcuni dei database equivalenti che trattano l'italiano sono ''BabelNet'' ([0030]), ''ItalWordNet'' ([0031]) e ''MultiWordNet'' ([0032]).
Un elemento importante da considerare è che le prestazioni di disambiguazione per la lingua inglese, impiegando ''WordNet'', risultano corrette tra l'80% e il 90% delle volte ([0028]), percentuali discrete ma non sufficienti per avere la totale garanzia.<div></div>
I fattori che ostacolano la realizzazione di algoritmi di intelligenza artificiale per la disambiguazione sono molteplici:
# Differenze tra dizionari impiegati: i database prima citati si basano su varie fonti che raggruppano semanticamente in maniera diversa i vocaboli, quindi programmi sviluppati con dizionari diversi generalmente hanno performance differenti.
# Complessità della codifica di parte del discorso: per poter disambiguare correttamente un termine è importante riuscire a comprendere correttamente il contesto in cui è inserito, operazione non banale.
# Varianza tra giudici: i supervisori dell'apprendimento degli algoritmi possono avere opinioni diverse, o semplicemente sbagliare, nella valutazione delle disambiguazioni, ciò porta ad algoritmi che hanno comportamenti diversi.
# Impossibilità di applicare la disciplina della ''pragmatica'', ossia la logica del ''buon senso'': per identificare correttamente il senso di alcune parole, ad esempio nella comprensioni di anafore e catafore, è necessario applicare il buon senso.
# Dipendenza del senso delle parole dai contesti: ogni scenario richiede la propria divisione del significato delle parole in sensi rilevanti. In un contesto informatico, ad esempio, il termine "''mouse''" deve essere ricondotto al dispositivo di puntamento, non al cognome del celebre personaggio Disney ''Mickey Mouse''; viceversa dovrà invece avvenire in un contesto di letteratura a fumetti.<div></div>
Laddove la ''WSD'' è una tecnica molto generale e che mira a risolvere un'ambiguità riguardante una qualunque parola, per le finalità del servizio oggetto di questa tesi è sufficiente risolvere le ambiguità dei nomi e dei cognomi.
Uno dei difetti che il servizio presenterebbe adottando un approccio ''WDS'' è legato alla impredicibile formattazione dei documenti, che aggiunge informazione semantica al testo ma introduce complessità nella individuazione automatica delle parti che formano il contesto; un altro difetto dipende dalla vastità del lessico da elaborare, essendo i documenti da trattare forniti dai più disparati utenti, su qualunque genere di argomento e relativi ai più vari ambiti.<div></div>

La strategia che sarà adottata per risolvere la problematica del riconoscimento dei nominativi sarà impostata attraverso un modello ''pattern-based'', impiegando le ''regular expressions'' (''regex''). Esse risultano comunemente usate per effettuare operazioni di ricerca o sostituzione in un testo, di conseguenza se si riesce ad individuare un pattern associato ad un nominativo dato, allora sarà possibile processare il documento ricercando le occorrenze del nominativo e "minimizzarlo" opportunamente.<div></div>

Le ''regular expressions'' risultano particolarmente efficaci poiché, se opportunamente progettate, possono identificare un nominativo indipendentemente dal significato linguistico del contesto in cui è calato, basandosi piuttosto sui singoli caratteri che compongono i lessemi analizzati; permettono, di conseguenza, di effettuare una valutazione estremamente minuziosa, riducendo al minimo le possibilità di errori.<div></div>
Un algoritmo di risoluzione ''pattern-based'' risulta, inoltre, più efficiente nell'esecuzione, in generale, di un algoritmo di intelligenza artificiale; per fornire la risposta il più velocemente possibile ad un utente, fruitore del servizio via web, l'approccio di riconoscimento tramite pattern è il più indicato.<div></div>

====Definizione dei pattern====
Nella progettazione del servizio si adotta, come detto, un approccio ''pattern-based'' per il riconoscimento dei nominativi. In linea di massima è opportuno che vengano riconosciuti più nominativi possibili e allo stesso tempo che la correttezza dell'identificazione di un nominativo sia garantita, quindi bisogna individuare dei pattern non troppo stringenti ma neppure troppo laschi. Per analizzare come i pattern devono essere strutturati si prende come caso di studio un generico nominativo, ad esempio ''Lorenzo Mario Amorosa''. Nel documento esso può comparire esattamente come appena indicato, ma anche in altre plausibili varianti, in cui l'ordine dei termini viene alterato, si pensi ad esempio ad "Amorosa Lorenzo Mario" o "Mario Lorenzo Amorosa", o in altre varianti ancora in cui alcuni nomi non compaiono, come in "Lorenzo Amorosa". Bisogna tuttavia supporre un limite alla variabilità: si osserva infatti che il cognome deve sempre comparire (il solo nome ''Lorenzo'' non è riconducibile a ''Lorenzo Mario Amorosa'') e che esso inoltre deve essere necessariamente anteposto o posposto, ma non interposto, ai nomi (è poco ragionevole ricondurre "Lorenzo Amorosa Mario" a "Lorenzo Mario Amorosa'').<div></div>
Questa prima specifica permette di ricondursi a una soluzione generale, sufficiente nella maggior parte dei casi, ma che non risolve alcune criticità. Un nominativo può, in alcuni documenti, comparire manifestandosi unicamente attraverso il cognome (riferendoci all'esempio precedente, ''Lorenzo Mario Amorosa'' apparirebbe nella forma ''Amorosa''). Sorge qui il problema che molti dei cognomi italiani hanno un significato proprio nel linguaggio comune; ad es., nella frase ''una relazione amorosa è bella'' è errato considerare la parola ''amorosa'' come cognome di un nominativo. Per risolvere questo genere di ambiguità si potrebbe pensare che per stabilire che il termine ''Amorosa'' sia un cognome sia sufficiente verificare che esso inizi con una lettera maiuscola, ma ciò può verificarsi anche perché la parola si trova ad inizio di frase. Inoltre, vari cognomi italiani possono iniziare con una lettera minuscola (''de Angelis'', ''d'Onofrio'', etc.), quindi basare l'identificazione di un cognome sul fatto che la sua prima lettera sia in maiuscolo non è in generale un metodo valido. Volendo in maniera prioritaria garantire il corretto funzionamento del servizio, e quindi attuare le procedure di anonimizzazione solo sui nominativi senza applicarle erroneamente ad altri termini, risulta necessario evitare il trattamento dei nominativi che si manifestano con i soli cognomi. Per via del contesto e dei significati che i cognomi possono assumere, infatti, risulta spesso impossibile distinguerli da parole del linguaggio comune.

Ci si concentra, quindi, nello studio di nominativi composti da un cognome seguito o preceduto da uno o più nomi.<div></div>
Si rappresenta dunque in formato di ''regular expression'' il pattern attualmente ideato. Per semplicità espositiva, si definisce il tag <span style="font-family: monospace;"><nomi></span> come l'insieme delle permutazioni di tutti i nomi del nominativo più l'insieme delle permutazioni di tutti i possibili sottoinsiemi di nomi del nominativo. Considerando il nominativo preso precedentemente come caso di studio, ad esempio, si avrebbe:
<div></div>
<span style="font-family: monospace;"> <nomi> = Lorenzo Mario|Mario Lorenzo|Lorenzo|Mario</span>
<div></div>
Posto inoltre il tag <span style="font-family: monospace;"><cognome></span> ad indicare il cognome contenuto nel nominativo e il tag <span style="font-family: monospace;"><regex></span> ad indicare la ''regular expression'' associata al nominativo, si ottiene:
<div></div>
<span style="font-family: monospace;"> <regex> := <cognome> (<nomi>)|(<nomi>) <cognome></span>
<div></div>
Una osservazione sottile ma di fondamentale importanza per la corretta progettazione delle ''regular expressions'' sta nella piena comprensione della semantica dell'operatore di scelta, espresso con il carattere ''pipe'' ("|"). Un qualunque ''engine'' di elaborazione delle ''regex'', infatti, interrompe la valutazione di una stringa non appena può stabilire se tale stringa fa match o meno con il pattern dato, senza quindi necessariamente valutarlo nella sua interezza, come parimenti avviene nelle valutazioni ''a corto circuito'' delle espressioni logiche nei linguaggi di programmazione. Ogni nominativo avrà a sè associato un pattern che lo rappresenta in più possibili sequenze di caratteri; per effettuare una corretta "minimizzazione" dei dati è necessario che le sequenze contenenti tutti i nomi sia poste per prime, mentre quelle contenenti un singolo nome per ultime.<div></div>
In questa prima formulazione della ''regex'', inoltre, si è posto come separatore unicamente lo spazio bianco, ma alcuni documenti potrebbero contenere dei nominativi i cui termini sono separati da altri caratteri, come ad esempio una virgola nel caso di "Amorosa, Lorenzo Mario". Per poter quindi identificare un nominativo anche in questi casi, si potrebbe considerare un qualunque carattere di interpunzione come possibile separatore dei termini del nominativo.
Adottando questa soluzione si ha però come effetto collaterale che risultano critici i casi in cui nel testo sono presenti dei nominativi soggetti ad omonimia. Si consideri una generica frase contenente una sequenza di nominativi, ad esempio ''Amorosa Lorenzo, Mario Giacomo e Fabio Rossi'', e si supponga che i nominativi da trattare siano ''Amorosa Lorenzo Mario'', ''Mario Giacomo'' (in cui la parola ''Mario'' è il cognome) e ''Fabio Rossi''. Gli ultimi due nominativi compaiono nella frase nella loro forma estesa, mentre il primo compare con il solo nome ''Lorenzo'' (eventualità possibile considerando la definizione del pattern precedentemente data). Considerando la virgola come carattere separatore dei termini del nominativo, la sequenza di parole ''Amorosa Lorenzo, Mario'' sarebbe ricondotta, venendo elaborata per prima, ad ''Amorosa Lorenzo Mario'', mentre rimarrebbe non trattata la parola ''Giacomo'', in quanto il cognome ''Mario'' che gli era associato è stato già identificato come un nome del nominativo ''Amorosa Lorenzo Mario'' ed il termine ''Giacomo'' preso singolarmente non rappresenta un nominativo.<div></div>
Prima di valutare ulteriormente le problematiche relative alle omonimie, si possono scegliere due approcci per risolvere questo specifico caso:
# Si riconduce una sequenza di parole ad un nominativo se e solo se tutti i suoi nomi sono contenuti nella sequenza
# Si considerano come separatori dei termini contenuti nei nominativi solo spazi bianchi, tabulazioni e a capo, non gli altri segni di punteggiatura.
<div></div>
Entrambe le strategie sono valide, in quanto risolvono il problema garantendo la corretta identificazione dei nominativi, ma allo stesso tempo entrambe presentano lo svantaggio di ridurre le sequenze di parole riconducibili a dei nominativi, aumentando le possibilità che alcuni di essi non vengano trattati.
Si consideri nuovamente il nominativo preso come caso di studio ''Amorosa Lorenzo Mario'': applicando la prima strategia, non sarebbe possibile ricondurgli la sequenza ''Amorosa Lorenzo'', mentre applicando il secondo metodo non sarebbe riconducibile la sequenza ''Amorosa, Lorenzo Mario''.
Si decide di attuare la seconda strategia, in quanto è opportuno non imporre vincoli troppo stringenti sui nomi e poiché nella gran parte dei casi i termini dei nominativi nei documenti sono separati tra loro da caratteri quali spazi bianchi, tabulazioni ed a capo.<div></div>
Un altro elemento su cui porre l'attenzione è la possibilità che i documenti da trattare contengano dei nominativi scritti interamente in maiuscolo o minuscolo, di conseguenza è conveniente che le ''regular expressions'' siano progettate ''case-insensitive''.<div></div>
Un ulteriore punto su cui bisogna soffermarsi è la posizione all'interno di un periodo in cui un nominativo può comparire, in particolare si vogliono evitare quei casi critici in cui uno dei termini del nominativo è una sotto-stringa di un'altra parola del testo (si pensi ad ''amorosa'' in ''clamorosa''). Come regola generale si può stabilire che è sempre necessario che un nominativo sia preceduto e seguito da un ''carattere non alfabetico''. Un caso particolare si presenta quando il nominativo è posto ad inizio o a fine documento, situazione in cui quindi esso non è preceduto o non è seguito da alcun carattere: entrambe le posizioni sono da considerare corrette.<div></div>
È opportuno ora definire il concetto di ''carattere non alfabetico'', e ciò si può fare più facilmente ragionando sul problema in logica positiva; infatti risulta più semplice individuare quei caratteri che rappresentano lettere piuttosto che quelli che rappresentano segni di interpunzione ed individuare ogni altro carattere che non può mai comporre una parola.

Inquadrando lo scenario di applicazione del servizio, molto probabilmente l'utente vorrà trattare un documento scritto nella lingua di uno dei paesi dell'Unione Europea, poiché il ''GDPR'' vige nei soli paesi membri dell'Unione.
Si può, quindi, ipotizzare che i documenti trattati possono sì contenere parole e nominativi stranieri, ma che i caratteri contenuti siano appartenenti all'alfabeto latino (''Latin script''), usato in molti stati nel mondo e da tutti i principali stati europei (fatta eccezione per la Grecia ed alcuni stati che scrivono in caratteri cirillici).
Inoltre, testi scritti in altri alfabeti, come esempio il cinese, l'arabo o il cirillico, vengono generalmente traslitterati. Considerare, quindi, ''caratteri non alfabetici'' tutti i caratteri diversi dalle lettere contenute nell'alfabeto latino sarebbe di conseguenza estremamente riduttivo ed inoltre in questo modo non si terrebbe conto delle lettere accentate, molto utilizzate anche nella lingua italiana.
<div></div>(XXXX QUI IMG [0F00])<div></div>
Per risolvere il problema facciamo riferimento alla codifica standard Unicode dell'alfabeto latino ([0022]); in essa è possibile individuare, oltre ai caratteri rappresentanti le lettere nella codifica ''ASCII'' classica, i caratteri rappresentanti le lettere nella codifica standard ''ISO/IEC 8859-1'' ([0023]), encoding orientato principalmente alla rappresentazione delle lingue dell'Europa occidentale.

<div></div>
<center><i>Caratteri latini nei primi due blocchi dello standard Unicode</i></center>
{| class="nounderlines" border="1" cellpadding="2" cellspacing="0" style="border-collapse:collapse"
|----- align="center"
!style="background:#ccf; text-align:center; font-weight: bold;"|U+
!style="text-align:center; font-weight: bold;"|0||style="text-align: center; font-weight: bold;"|1||style="text-align: center; font-weight: bold;"|2||style="text-align: center; font-weight: bold;"|3||style="text-align: center; font-weight: bold;"|4||style="text-align: center; font-weight: bold;"|5||style="text-align: center; font-weight: bold;"|6||style="text-align: center; font-weight: bold;"|7||style="text-align: center; font-weight: bold;"|8||style="text-align: center; font-weight: bold;"|9||style="text-align: center; font-weight: bold;"|A||style="text-align: center; font-weight: bold;"|B||style="text-align: center; font-weight: bold;"|C||style="text-align: center; font-weight: bold;"|D||style="text-align: center; font-weight: bold;"|E||style="text-align: center; font-weight: bold;"|F||style="text-align: center; font-weight: bold;"|Block||style="text-align: center; font-weight: bold;"|#
|-
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0040
|style="background:#fff"|@||A||B||C||D||E||F||G||H||I||J||K||L||M||N||O
|rowspan="4" style="background:#fff" align:"center"|C0 Controls and Basic Latin<br>0000–007F<br>(identical to ASCII)
|rowspan="4" style="background:#fff"|52
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0050
|P||Q||R||S||T||U||V||W||X||Y||Z||style="background:#fff"|[||style="background:#fff"|\||style="background:#fff"|]||style="background:#fff"|^||style="background:#fff"|_
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0060
|style="background:#fff"|`||a||b||c||d||e||f||g||h||i||j||k||l||m||n||o
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0070
|p||q||r||s||t||u||v||w||x||y||z||style="background:#fff"|{||style="background:#fff"||||style="background:#fff"|}||style="background:#fff"|~||style="background:#fff; font-size:75%"|DEL
|-
!colspan="19"|
|----- align="center" style="background:#fff"
!style="background:#fff; text-align:center; font-weight: bold;"|00A0
| ||¡||¢||£||¤||¥||¦||§||¨||©||ª||«||¬||||®||¯
|rowspan="6" style="background:#fff" align="center"|C1 Controls and Latin-1 Supplement<br>0080–00FF<br>(identical to ISO/IEC 8859-1)
|rowspan="6" style="background:#fff"|62
|----- align="center" style="background:#fff"
!style="background:#fff; text-align:center; font-weight: bold;"|00B0
|°||±||²||³||´||µ||¶||·||¸||¹||º||»||¼||½||¾||¿
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00C0
|À||Á||Â||Ã||Ä||Å||Æ||Ç||È||É||Ê||Ë||Ì||Í||Î||Ï
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00D0
|Ð||Ñ||Ò||Ó||Ô||Õ||Ö||style="background:#fff"|×||Ø||Ù||Ú||Û||Ü||Ý||Þ||ß
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00E0
|à||á||â||ã||ä||å||æ||ç||è||é||ê||ë||ì||í||î||ï
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00F0
|ð||ñ||ò||ó||ô||õ||ö||style="background:#fff"|÷||ø||ù||ú||û||ü||ý||þ||ÿ
|---- align="center" style="background:#f66"
|}
<div></div>

I caratteri indicati in rosso nella tabella sono tutti i possibili ''caratteri alfabetici'' che compaiono nei documenti scritti in 29 lingue diverse ([0023]), tra le quali sono presenti l'italiano, l'inglese, lo spagnolo, il tedesco e il portoghese.
Aggiungendo pochi altri caratteri all'insieme dei ''caratteri alfabetici'' appena mostrati, si riesce a rappresentare ogni parola di altre 12 lingue ([0023]), tra cui il francese, l'olandese, il ceco e il turco.<div></div>
I caratteri mostrati in tabella corrispondono ad una parte dei primi due blocchi dello standard Unicode che codificano l'alfabeto latino e, come già accennato in precedenza, essi sono presenti negli standard ''ASCII'' e ''ISO/IEC 8859-1''. I rimanenti ''caratteri alfabetici'', invece, sono presenti in estensioni dello standard Unicode per il ''Latin script''. Queste estensioni sono state realizzate per fornire il massimo supporto a tutte le lingue e contenenti molti simboli ad uso speciale, come ad esempio per la rappresentazione dei fonemi. Si osserva, inoltre, che i ''caratteri alfabetici'' definiti nelle estensioni dello standard Unicode sono presenti anche nella codifica ''ISO/IEC 8859-2'' o nelle versioni successive ([0023]).<div></div>
Definiti i ''caratteri non alfabetici'' come elementi di separazione tra un nominativo ed il testo in cui esso è inserito, occorre definire opportunamente la ''regex'' che al nominativo è associata.

Utili strumenti messi a disposizione dalle ''regular expressions'' sono i gruppi speciali ''lookahead'' e ''lookbehind''. Un pattern di un nominativo deve essere preceduto o seguito da una prestabilita sequenza di caratteri, la quale però non è parte del nominativo. Utilizzando i due costrutti citati, è possibile far sì che nell'elaborazione di una stringa facciano match solamente le parole effettivamente appartenenti al nominativo, non i caratteri che lo delimitano dal resto del testo, e allo stesso tempo che un nominativo faccia match se e solo se preceduto o seguito da una certa sequenza di caratteri. <div></div>
Per esprimere nella sintassi delle ''regex'' un carattere letterale in un qualunque alfabeto si può utilizzare il costrutto ''\p{L}'', che però risulta molto generale e troppo lasco per i requisiti considerati. Si può piuttosto valutare l'impiego del costrutto ''\p{Latin}'', il quale identifica un qualunque carattere alfabetico presente nell'alfabeto latino. Tra i caratteri corrispondenti al costrutto, però, ve ne sono alcuni che per le specifiche del servizio devono essere considerati ''caratteri non alfabetici'', come ad esempio i caratteri dei fonemi, i segni diacritici e gli indicatori ordinali; di conseguenza è necessario individuare una strategia ad hoc per risolvere questa problematica.<div></div>
Per chiarezza espositiva, si definisce il tag <span style="font-family: monospace;"><start></span>, per indicare un qualunque carattere non alfabetico o l'inizio stringa, il tag <span style="font-family: monospace;"><end></span>, per indicare un qualunque carattere non alfabetico o il fine stringa, ed il tag <extra>, per indicare i ''caratteri alfabetici'' non presenti negli standard ''ASCII'' o ''ISO/IEC 8859-1'':<div></div>
<span style="font-family: monospace;">
<extra> := ĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ
<br/>
<start> := (?<=[^A-Za-zÀ-ÖØ-öø-ÿ<extra>]|^)
<br/>
<end> := (?=[^A-Za-zÀ-ÖØ-öø-ÿ<extra>]|$)
</span>
<div></div>
Si osserva che si sono utilizzati i gruppi speciali prima descritti e che si sono inseriti i caratteri dello standard Unicode presentati in precedenza. Si definisce nuovamente la ''regular expression'' associata ad un generico nominativo. Applicando i tag appena definiti, il costrutto ''(?i)'' che rende il pattern ''case-insensitive'' ed il costrutto ''\s'' che rappresenta un carattere qualunque tra i separatori non visibili, ossia ''\r \n \t \f \v'' e lo spazio bianco, si ottiene:<div></div>
<span style="font-family: monospace;">
<regex> := (?i)(<start><cognome>\s+(<nomi>)|(<nomi>)\s+<cognome><end>)
</span>
<div></div>
Si osserva, inoltre, che in questa nuova formulazione della ''regular expression'' i nomi sono da intendersi separati tra loro da ''\s+''.<div></div>
A questo punto si è quasi giunti alla formulazione finale del pattern da associare ad un nominativo, rimangono solo da trattare alcuni casi critici non ancora risolti.<div></div>
Si è già presentato in precedenza il problema legato al fatto che alcuni cognomi possono avere un significato proprio nel lessico comune e che ciò costringeva, quindi, ad abbandonare l'idea di trattare nominativi formati dal solo cognome. Questa problematica di ambiguità si presenta anche con alcuni nomi (si pensi, ad esempio, al nome ''Gioia''). Ciò non rappresenta generalmente un problema, in quanto la coppia nome-cognome che forma il nominativo, presa complessivamente, non è soggetta ad ambiguità. Esistono, però, dei casi in cui questo non è vero. Si prenda in analisi il nominativo ''Gioia Grande'': risulta evidentemente soggetto a rischio di ambiguità. Una soluzione che si può adottare, per risolvere questo caso critico, si basa sull'associazione di un pattern più stringente ai nominativi. In particolare, si osserva che i nomi propri di persona compaiono sempre ed obbligatoriamente, in un documento grammaticalmente corretto, con la prima lettera maiuscola ([0024]). I cognomi, invece, non sono soggetti ad una regola così stringente: un cognome iniziante con una lettera minuscola (come ''de Rosa'') in alcuni casi, ad esempio se posto dopo un punto fermo, può comparire scritto con la prima lettera sia maiuscola che minuscola; naturalmente, in nessuna occorrenza un cognome che inizi con una lettera maiuscola potrà comparire con una minuscola. <div></div>
Occorre quindi ridefinire, alla luce di queste osservazioni, la ''regex'' associata ad un nominativo, poiché precedentemente era stata posta interamente ''case-insensitive''. Nel pattern, in particolare, i nomi dovranno sempre iniziare con una maiuscola, mentre i cognomi avranno questo vincolo solo se nel nominativo compaiono con la prima lettera maiuscola. Si mostra quindi quali sono i tag <span style="font-family: monospace;"><nomi></span> e <span style="font-family: monospace;"><cognome></span> associati a due nominativi, ad esempio ''Gioia Grande'' e ''Antonio de Rosa''. <div></div>
Per ''Gioia Grande'' si ha:<div></div>
<span style="font-family: monospace;"><nomi> = G((?i)ioia)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = G((?i)rande)</span>
<div></div>
Per ''Antonio de Rosa'' si ha:<div></div>
<span style="font-family: monospace;"><nomi> = A((?i)ntonio)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = (?i)de Rosa</span>
<div></div>
Si presenta dunque la definizione finale del tag <span style="font-family: monospace;"><regex></span>. Nella definizione il tag <span style="font-family: monospace;"><nomi></span> è definito il base al numero di nomi del nominativo ed il tag <span style="font-family: monospace;"><cognome></span> è definito in base al carattere iniziale del cognome.<div></div>
<span style="font-family: monospace;">
<regex> := <start><cognome>\s+(<nomi>)|(<nomi>)\s+<cognome><end>
</span>
<div></div>
Vengono inoltre mostrati i valori dei due tag <span style="font-family: monospace;"><nomi></span> e <span style="font-family: monospace;"><cognome></span> per il nominativo preso come caso di studio in fase iniziale, ossia ''Amorosa Lorenzo Mario''. Si ottiene:<div></div>
<span style="font-family: monospace;"><nomi> = L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = A((?i)morosa)</span>
<div></div>
Infine, per completezza, viene mostrata la ''regular expression'', associata a quest'ultimo nominativo, risolvendo tutti i tag che la compongono:
<div></div>
<span style="font-family: monospace;">
<regex> = (?<=[^A-Za-zÀ-ÖØ-öø-ÿĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ]|^)(A((?i)morosa)\s+(L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario))|(L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario))\s+A((?i)morosa))(?=[^A-Za-zÀ-ÖØ-öø-ÿĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ]|$)
</span>
<div></div>

====Gestione delle omonimie====

Nei ragionamenti che hanno portato alla formulazione della ''regular expression'' associata ai nominativi, si è tenuto conto di possibili ambiguità con termini appartenenti al linguaggio comune, risolte con l'introduzione nel pattern di stringhe ''case-sensitive'', e di possibili nominativi posti in sequenza parzialmente omonimi (ossia aventi un nome o il cognome in comune tra loro), gestite con l'imposizione dei soli caratteri separatori non visibili come delimitatori delle parole componenti un nominativo. Per rendere l'analisi completa occorre valutare come ci si debba comportare in altri possibili casi di omonimia. Si osserva, per inciso, che nel pattern individuato nella sezione precedente il tag <span style="font-family: monospace;"><nomi></span> è stato l'unico non definito formalmente. La definizione di tale tag infatti dipende, oltre che dai nomi del nominativo, anche dall'insieme complessivo dei nominativi da trattare presenti nel documento.<div></div>
Il caso più semplice di omonimia, che si verifica quando un solo nome o il solo cognome di un nominativo coincide con un nome o il cognome di un altro (come nel caso di ''Lorenzo Mario Amorosa'' e ''Stefano Amorosa''), risulta già ben gestito dall'attuale formulazione del pattern. Infatti, un riconoscimento è determinato quando almeno un nome e il cognome del nominativo appaiono in sequenza.<div></div>
Il problema si complica quando un nominativo ha due o più componenti in comune con un altro. Si osserva che se l'omonimia riguarda solo i nomi dei nominativi, ciò non risulta problematico, in quanto il cognome, supposto sempre presente nel pattern, funge da elemento di disambiguazione. Si considera da ora, quindi, che i nominativi abbiano il medesimo cognome e si analizzano i casi in cui anche uno o più nomi risultano in comune, attraverso degli esempi:
* Nomi_A = {"Lorenzo", "Mario", "Luca"}; Nomi_B = {"Stefano", "Mario"}
<div></div>(QUI IMG [0F01])<div></div>
In questo caso sono elementi di disambiguazione i nomi ''Lorenzo'' e ''Luca'' per il primo nominativo e ''Stefano'' per il secondo, bisognerà quindi far sì che almeno uno tra tali nomi compaia sempre nelle ''regex'' associate ai nominativi in questione. L'occorrenza ''Mario <cognome>'' rimane ambigua e non può essere trattata.
* Nomi_A = {"Lorenzo", "Mario", "Luca"}; Nomi_B = {"Mario", "Luca"}
<div></div>(QUI IMG [0F02])<div></div>
L'insieme Nomi_B risulta un sottoinsieme di Nomi_A, di conseguenza solo il primo nominativo presenta degli elementi utili per risolvere l'ambiguità. Nel pattern relativo al primo nominativo dovrà essere presente almeno un tra i nomi non in comune, mentre il pattern del secondo nominativo rappresenterà inevitabilmente espressioni ambigue poiché riconducibili all'altro. Le soluzioni possibili sono due: rifiutarsi di effettuare il trattamento del secondo nominativo oppure decretare che esso è riconosciuto se e solo se appare nella sua forma estesa, presentando quindi tutti i nomi. Quest'ultima soluzione è ragionevole e la si sceglie, poiché così si aumentano, per quanto possibile, le sequenze "minimizzabili", e viene inoltre messo in conto di informare l'utente opportunamente sulla gestione di questo genere di omonimia per rendere le operazioni trasparenti.
* Nomi_A = Nomi_B = {"Lorenzo", "Mario", "Luca"}
<div></div>(QUI IMG [0F03])<div></div>
Qualora l'insieme dei nomi dei due nominativi sia identico risulta impossibile distinguerli e non possono in alcun modo essere trattati, poiché l'ordine con cui compaiono i nomi di un nominativo non rappresenta un elemento di disambiguità. I dati appartenenti a persone completamente omonime contenuti in uno stesso documento, quindi, non sono "minimizzabili" distintamente.<div></div>
Si osserva che è di fondamentale importanza che i documenti che gli utenti forniscono siano grammaticalmente corretti, in quanto un errato uso dei segni di interpunzione può rendere impossibile l'applicazione delle ''regular expression''. Si prenda ad esempio una sequenza anomala di caratteri in cui non è corretto l'uso delle virgole, come "''Amorosa Mario Rossi Giacomo''": supponendo che nel documento si vogliano trattare i nominativi ''Amorosa Mario'', ''Rossi Mario'' e ''Rossi Giacomo'', risulta impossibile identificare quali tra questi siano rappresentatati nella sequenza.<div></div>
In conclusione, risultano quindi individuate le strategie che permettono di formulare ''regular expressions'' anche per i nominativi soggetti ad omonimia.

====Formattazione dei documenti====

I documenti prodotti in enti ed organizzazioni presentano generalmente formattazioni e non sono puramente testuali. Si vuole qui considerare quale debbano essere le interpretazioni più adatte da dare agli elementi grafici per rendere sempre efficace il riconoscimento dei nominativi. In particolare, quindi, non si tratteranno gli elementi di punteggiatura, come parentesi o virgolette, poiché già compresi nelle ''regex'', bensì tutti gli elementi che in un pattern composto da caratteri non sono espressi. Si inizia dunque la rassegna:
* Elementi di formattazione del testo
I font, la dimensione dei caratteri, il grassetto, il corsivo, l'evidenziazione e tutti i possibili elementi di modifica della apparizione grafica del testo non alterano il significato dei lessemi coinvolti. Se il cognome di un nominativo è posto in grassetto ed il nome no, ad esempio, la coppia nome-cognome rappresenta sempre il nominativo iniziale; lo stesso vale per gli altri elementi citati.
* Aree di comparizione del testo
In genere ogni documento è formato da più sezioni, ha un corpo principale ed eventuali titoli, note a piè pagina, intestazioni ed altre possibili aree. Il trattamento di "minimizzazione", secondo il ''GDPR'', deve essere effettuato al documento in ogni sua parte, ma ogni sezione deve essere elaborata in maniera indipendente dalle altre sezioni in quanto rappresenta un blocco logico a sé. Ciò significa che, ad esempio, bisogna individuare eventuali nominativi presenti nel titolo, ma non bisogna considerare nominativo una sequenza di parole che è posta in parte nel titolo e in parte nel primo paragrafo del testo.
* Elementi blocco
Gli elementi blocco, come ad esempio le immagini, possono causare un'interruzione netta in un paragrafo, suddividendolo quindi in più blocchi logici, che devono essere analizzati separatamente; tuttavia nel caso in cui questi elementi siano posti ''fluttuanti'', ossia ancorati ai bordi della pagina, il testo scorre in un unico flusso e forma quindi un unico blocco logico.
* Divisione in sillabe
Un problema rilevante nella formattazione del documento è che spesso, per esigenze estetiche, contiene delle parole divise in sillabe poste su righe diverse e separate da un trattino. Ovviamente se un nome va a capo a fine linea non perde il suo significato semantico, bisognerà quindi continuare a riconoscerlo.
* Tabelle
Molti documenti, specialmente quelli contenenti ingenti quantità di nominativi, possono essere strutturati in forma tabellare. Trascurando una trattazione per esteso delle modalità con cui i nominativi potrebbero comparire nelle tabelle, si considera esclusivamente il caso di gran lunga più ricorrente. In genere, infatti, in una tabella contenente dei nominativi, essi sono presenti nella stessa colonna o in colonne contigue: l'una contenente i nomi, l'altra il cognome, o viceversa. Senza basarsi sull'intestazione delle colonne, si può valutare se il contenuto di due celle adiacenti poste su di una stessa riga faccia match con il pattern di un nominativo, ed in caso ciò accada si può affermare la coppia di celle individuata rappresenta un nominativo.<div></div>
Si osserva che si sono fornite solamente le interpretazioni più plausibili e comuni a questi elementi grafici e non si è ideato alcun particolare algoritmo per la loro elaborazione. L'espressione di tali strutture, infatti, è fortemente determinata dal formato in cui il documento è redatto. Si rimanda, quindi, ai capitoli successivi per specificazioni ulteriori della soluzione. Occorre notare, infine, che gli elementi di formattazione non sono descritti da stringhe nel formato delle ''regular expressions'': bisognerà quindi integrare gli elementi presentati in questa sezione con l'approccio ''pattern-based'' adottato.

===Analisi dell'usabilità===

====Elenco dei nominativi da trattare esplicitamente espressi come dati in input====

In questo caso, per usufruire del servizio, l'utente deve fornire un documento contenente una serie di nominativi da trattare. Una garanzia della corretta elaborazione del documento si ha richiedendo all'utente stesso quali siano i nominativi da trattare: in questo modo potranno essere "minimizzati" i dati (cioè i nominativi) di tutte e sole le persone espressamente richieste. In molti plausibili scenari, infatti, è necessario anonimizzare solo alcuni dei nominativi presenti nel documento; ad esempio in un atto giudiziario serve anonimizzare le parti in causa ma non i magistrati.

Questa configurazione del servizio permette quindi all'utente di avere il massimo controllo possibile del risultato. Tuttavia questo approccio è poco pratico nel caso in cui i documenti da trattare contengano grandi quantità di nominativi diversi e, magari, l'utente che ne richiede il trattamento non li conosce; si pensi ad esempio a lunghe graduatorie di concorsi o altro. Si osserva inoltre che anche per pochi nominativi l'usabilità può degradare, se l'inserimento viene fatto con estemporanea digitazione, esposta anche al rischio di possibili errori di battitura, con conseguenti noiose ripetizioni delle operazioni.

Si osserva, infine, che il sistema progettato è sufficientemente robusto nel trattare i nominativi in input espressi da un utente che ha digitato caratteri maiuscoli o minuscoli violando le convenzioni grammaticali. Supposto che il documento trattato debba essere grammaticalmente corretto, infatti, si ha la garanzia che i nomi ivi presenti comincino con una maiuscola; è sufficiente, quindi, forzare una conversione ''to-upper-case'' dei nomi inseriti dall'utente e le ''regex'' progettate funzionano correttamente. Un discorso a parte va fatto per i cognomi inseriti dall'utente, in quanto essi possono comparire con la prima lettera sia maiuscola che minuscola. L'inserimento di un cognome iniziante con una minuscola non crea grossi problemi, in quanto in tal caso la ''regex'' risultante sarebbe totalmente ''case-insensitive'' per il cognome, mentre l'aggiunta di un cognome cominciante con una maiuscola determina una ''regex'' ''case-insensitive'' per la prima lettera del cognome; qualora quindi un utente inserisse un nominativo tutto in maiuscolo, le occorrenze del cognome, presenti nel documento, inizianti con una lettera minuscola non verrebbero riconosciute.
Per le altre lettere dopo la prima, sia per i nomi che per i cognomi, il pattern è stato progettato ''case-insensitive'', quindi non emergono problemi. <div></div>
In sintesi, il rischio che vengano introdotte delle ambiguità lessicali, incaricando l'utente dell'inserimento dei nominativi, è piuttosto basso ed il controllo che si ha sui nominativi è il massimo desiderabile, mentre i requisiti di usabilità risultano penalizzati.

====Elenco dei nominativi da trattare dedotti automaticamente da un dizionario====

Se si desidera privilegiare la tematica dell'usabilità nella progettazione del servizio, risulta necessario individuare delle strategie che semplifichino il più possibile i compiti che devono essere svolti dall'utente. L'unica operazione che inevitabilmente resta a suo carico è l'upload del documento da trattare; non è infatti necessario richiedergli l'elencazione dei nominativi dei nominativi da trattare, in quanto questi possono essere dedotti automaticamente impiegando dei dizionari, dei quali va quindi valutato il contenuto e le modalità di utilizzo. <div></div>

Si scarta subito l'ipotesi di dedurre automaticamente i nominativi basandosi unicamente sul fatto che le iniziali di nomi e cognomi siano maiuscole; come già argomentato infatti l'uso delle lettere maiuscole non è limitato solo a questi usi e, inoltre, non si può avere la certezza che un cognome inizi con una maiuscola.

Sono disponibili fortunatamente alcuni dizionari di nomi ed altri di cognomi, in diverse lingue; si fa qui riferimento a quelli di "Data World" (un'azienda focalizzata sulla raccolta, produzione e pubblicazione di dataset: https://data.world) ([0037]).

Si inizia l'analisi inquadrando le dimensioni che un dizionario contenente nomi o cognomi avrebbe. Risalta subito all'occhio la differenza tra il numero di termini contenuti nei due casi: facendo riferimento ai soli nomi e cognomi italiani, risultano esistenti circa 350.000 cognomi ([0036]) e circa 9.000 nomi, dei quale circa 5.000 maschili e circa 4.000 femminili ([0037]); il numero dei cognomi è quindi quasi 40 volte più grande del numero dei nomi.<div></div>
Si ipotizza, per chiarire le idee, di applicare questi dizionari in uno scenario reale, in cui, ad esempio, si vuole trattare un documento di 10 pagine contenente 5.000 parole. Si trascurano inoltre i meccanismi che permettono di ricondurre un nome od un cognome ad un nominativo per concentrarsi unicamente sul numero di confronti necessari da effettuare nell'elaborazione. Nel peggiore dei casi possibili, ossia quando nessuna parola del documento compare tra i termini del dizionari, e dove occorre quindi confrontare ogni singola parola del documento con tutti i termini del dizionario, per semplice moltiplicazione si ottiene che l'impiego di un dizionario di nomi darebbe luogo a 45.000.000 confronti, mentre un dizionario di cognomi ben a 1.750.000.000 confronti. Se invece le parole nel documento fossero 50.000 si avrebbero 450.000.000 di confronti nel primo caso e 10.750.000.000 nel secondo. In sintesi, sebbene il rapporto tra il numero di confronti nei due casi rimanga sempre costante (circa 1:40) indipendentemente dalla lunghezza del documento, la differenza tra il numero di confronti cresce proporzionalmente al numero di parole che vengono sottoposte all'elaborazione. Per quantificare, infine, attraverso un unità di tempo, la differenza esistente tra l'impiego delle due diverse tipologie di dizionario, si realizza un semplice programma java, di cui si riporta qui sotto il contenuto del metodo principale, che realizza i confronti necessari attraverso l'uso di ''regular expression'':
<div></div>
<div style="font-family: monospace;">
final String regex = "\bLorenzo\b";<br/>
final String string = ... //testo di prova<br/>
<br/>
final Pattern pattern = Pattern.compile(regex, Pattern.MULTILINE);<br/>
final Matcher matcher = pattern.matcher(string);<br/>
int start, total;
<br/>
start = System.currentTimeMillis();
while (matcher.find()) {
System.out.println("Full match: " + matcher.group(0));
for (int i = 1; i <= matcher.groupCount(); i++) {
System.out.println("Group " + i + ": " + matcher.group(i));
}
} <br/>
total = System.currentTimeMillis() - start;
System.out.println("Total: " + total + " ms");
</div>
<div></div>
Eseguendo il test più volte, inserendo fino a 10 occorrenze della parola "Lorenzo" nel testo, si ha un tempo di elaborazione medio di circa 3 ms, con prestazioni di picco di 2 ms, ottenibili con poche occorrenze del nome presenti, e tempo di attesa massimo di 6 ms, dovuto alla presenza invece a una presenza più frequente del nome nel testo.
Questo fenomeno si comprende meglio ricordando che, come spiegato nel capitolo precedente, le ''regular expressions'' ottimizzano la ricerca, considerano le stringhe del testo trattato solo finché necessario, ossia fino a quando non vi è certezza che esse corrispondano o non corrispondano ad un match. Ogni volta che nel testo si presenta una parola che inizia con una lettera diversa dalla 'L' di "Lorenzo", la ricerca procede direttamente con la valutazione della parola successiva, ignorando i rimanenti caratteri della parola.

Risulta, invece, più onerosa la verifica della corrispondenza tra una stringa ed il pattern desiderato, poiché in questo caso vanno elaborati tutti i caratteri della parola. Come caso limite, si è posta come stringa da elaborare la sequenza di caratteri "Lorenzo " ripetuta 500 volte: il tempo di esecuzione medio del programma risultante, a parità di piattaforma, è stato di circa 25 ms.

Un'altra diretta conseguenza di questo meccanismo di confronto è che all'aumentare del numero di parole nel documento non corrisponde un eccessivo aumento del tempo di esecuzione: considerando un documento di 5000 parole, con 0 occorrenze del nome "Lorenzo" il tempo di esecuzione medio risulta di 9 ms, con 10 occorrenze di 10 ms, con 100 occorrenze di 15 ms.

Occorre precisare, prima di formulare ulteriori ragionamenti, che in documento di 5.000 parole potranno essere presenti al più 2500 coppie nome-cognome; in un dizionario con più di 2.500 termini almeno uno di questi non contribuirà nell'individuazione di un nominativo. Se poi sono presenti altre parole oltre ai nominativi nel documento, la percentuale di nomi che presenterà 0 occorrenze crescerà di conseguenza. Ad ogni modo, si sceglie di sviluppare i ragionamenti considerando necessario il tempo medio di 10 ms per individuare le occorrenze di un termine di un dizionario in un documento di 5.000 parole; questo tempo è sicuramente maggiore rispetto al caso reale, ma valutando per eccesso questo valore è possibile trascurare il tempo impiegato nelle altre operazioni di routine a supporto dell'algoritmo di ricerca.

Ritornando all'esempio di partenza, considerando quindi necessari 10 ms per individuare le occorrenze di un termine di un dizionario in un documento di 5.000 parole, risulta che l'identificazione di tutti i cognomi contenuti nel testo richieda circa 3.500 secondi, (quasi un'ora!), mentre l'individuazione dei nomi "solo" 90 secondi.
I tempi di attesa che l'utente dovrebbe aspettare sono estremamente elevati e irragionevoli, specialmente se calati nel contesto nelle ''web application''. Come primo espediente per ovviare al problema si decide di abbandonare completamente l'idea di impiegare un dizionario di cognomi, in quanto, seppur si individuassero delle soluzioni in grado di effettuare il riconoscimento di tutte le occorrenze di un termine in un documento indipendentemente dalla lunghezza in solo 1 ms (irreale), sarebbero comunque necessari 3 minuti e 50 secondi per l'elaborazione. Non verranno quindi neppure trattate possibili soluzioni che prevedono l'applicazione di entrambi i dizionari.

I 90 secondi richiesti dal dizionario di nomi, invece, risultano anch'essi eccessivi, ma attraverso opportune valutazioni si possono individuare delle strategie che consentono la minimizzazione del tempo necessario all'elaborazione dei documenti. Tali metodi di ottimizzazione saranno trattati in un successivo capitolo, mentre ora ci si continua a concentrare sulle modalità di impiego del dizionario.

Per inciso, si osserva che i problemi di efficienza sono strettamente legati al riconoscimento automatico dei nominativi, in quanto in questo caso devono essere applicate quasi una decina di migliaia di ''regex'' diverse; nel caso in cui i nominativi da elaborare e le ''regex'' a loro associate siano noti, si ha a che fare con un numero esiguo di pattern da trattare e l'esecuzione del programma risulta infinitamente più rapida.<div></div>

Per migliorare l'efficacia del servizio sarebbe opportuno introdurre nel dizionario anche nomi stranieri, sempre più diffusi in una società sempre più globalizzata. Il tempo di esecuzione medio del riconoscimento, già critico, crescerebbe ulteriormente: si decide allora di introdurre nel dizionario i soli nomi inglesi, in totale quasi 5500 ([0037]). Considerando sempre un tempo medio di esecuzione di 10 ms per nome, con un dizionario di circa 14.500 termini si avrebbe un tempo di esecuzione medio complessivo di 145 secondi, ossia pari a 2 minuti e 25 secondi, e risulta ancora possibile effettuare alcune ottimizzazioni che lo riducono ad un livello accettabile.

Una volta individuati i nomi contenuti nel documento occorre stabilire se essi fanno parte di un nominativo, progettando un'opportuna ''regular expression''. È importante notare che per conseguire questo scopo bisogna individuare la soluzione più efficiente possibile.

Un nominativo, come già ripetuto più volte, è composto da uno o più nomi e da un cognome. Individuato un nome, la priorità che si ha è verificare se accanto ad esso sia presente un cognome. Finora i cognomi sono stati supposti non regolamentati da alcun pattern specifico, ma è necessario formularne almeno uno per consentirne il riconoscimento automatico. È ragionevole supporre che un cognome sia formato da massimo due parole, separate da spazio o apostrofo, sempre inizianti entrambe con una maiuscola, fatta eccezione per la prima parola laddove essa sia una preposizione semplice o articolata oppure un articolo, tenendo conto dei possibili troncamenti, come <i>d'</i> e <i>dell'</i>. Inoltre per verificare se un termine adiacente al nome trovato rappresenti un nome si evita di impiegare nuovamente il dizionario per non gravare ulteriormente sul tempo di esecuzione. Inoltre, si nota che avendo supposto un cognome composto da massimo due parole inizianti con una lettera maiuscola, un altro nome, oltre quello trovato dal dizionario, viene già automaticamente riconosciuto qualora il cognome sia composto da una sola parola. Rinunciando ad individuare nominativi composti da tre nomi o più, si formula una ''regular expression'' per il riconoscimento automatico in seguito al identificazione di un nome, qui indicato con il tag <span style="font-family: monospace;"><nome></span>, supponendo il cognome come precedentemente indicato e ipotizzando la presenza di un ulteriore nominativo.
<div></div>
<div style="font-family: monospace;">
<prep> := d((a|e)(l(l[aeo]?)?|i|gli?)?|i)?|(ne|a|su)(l(l[aeo]?)?|i|gli)?|l[aeo]?|co[iln]?|i[ln]?|gli|per

<cognome> := (([A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]*|<prep>)('|\s))?[A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]+

<second_name> := [A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]+

<regex> := (<second_name>\s)?(<nome>)\s<cognome>|<cognome>\s(<nome>)(\s<second_name>)?
</div>
<div></div>
Nella scrittura della ''regex'' si è prestata particolare attenzione all'utilizzo della simbologia per rendere l'espressione il più performante possibile, attraverso il massimo sfruttamento dei cortocircuiti logici e l'opportuno ordinamento dei caratteri (sono stati anteposti i caratteri comuni a più preposizioni od articoli). Inoltre, per alleggerire la ''regex'' si è rinunciato all'utilizzo dei caratteri dell'alfabeto latino non appartenenti ai primi due blocchi Unicode.
<div></div>
È mostrata in figura la corretta elaborazione di 57 possibili casi di cognomi diversi
<div></div>(QUI IMG [0F04])<div></div>
Si osserva tuttavia che in alcune circostanze, come nella frase "''di Amorosa Lorenzo non si hanno notizie''", accade che un parola ("''di''" in questo caso), non sia parte del cognome ma il programma non è in grado di riconoscerlo. Questa ambiguità è fortemente dipendente dal contesto e non è possibile trattarla senza significativi degradi delle performance; quindi è necessario rinunciare a trattarla, accettando riconoscimenti erronei. In altre situazioni, invece, dove magari si sta elaborando la stringa contenente il nominativo ''Mario Lorenzo'', risulta impossibile determinare quale tra i due termini sia il nome e quale il cognome; cioè significa che l'unico trattamento di "minimizzazione" automatico che risulta ragionevole applicare è la sostituzione del nominativo con uno pseudonimo, non il troncamento o l'alterazione dei nomi.
In conclusione, con il riconoscimento automatico dei nominativi si migliora complessivamente l'usabilità del servizio, in quanto l'utente non deve digitare i nominativi, ma la latenza introdotta è notevole, si è soggetti a rischi di ambiguità e non è in alcun modo esprimibile la preferenza su quali nominativi si desidera "minimizzare" o meno. La soluzione così ideata non risulta quindi adeguata.

====Soluzione ibrida adottata====
Entrambe le tipologie di riconoscimento prima individuate hanno significativi problemi, si cerca quindi di sintetizzare una soluzione in grado di trarre i vantaggi dell'una e dell'altra. Risulta efficace, in particolare, che il documento venga inizialmente trattato tramite dizionari, evitando all'utente l'onere di specificare i nominativi, e che in seguito venga lasciata all'utente la possibilità di intervenire.
Infatti, esso potrebbe voler esprimere delle preferenze su quali nominativi debbano essere trattati tra quelli individuati e gestire gli eventuali errori di riconoscimento dovuti a richieste di trattamento di nominativi aventi un nome non presente nel dizionario o anche dovuti a casi di ambiguità lessicale già presentati.

Una volta inserito il documento e terminata l'elaborazione tramite il dizionario, l'utente può sia richiedere l'immediato download del file ed effettuare le operazioni prima definite, attraverso un'opportuna interfaccia. Per fornire il supporto alle esigenze più disparate, si prevede la possibilità di:
# eseguire download del file trattato unicamente con il dizionario
# ripetere la "minimizzazione" del documento, specificando:
## nuovi nominativi
## quali nominativi tra quelli precedentemente individuati ''non'' si vogliono trattare
## quale parola/e dei nominativi individuati rappresenta il cognome (in tal caso, si possono utilizzare altri metodi, oltre alla sostituzione con pseudonimo, per il trattamento)
## quale parola/e dei nominativi individuati non compone il nominativo (situazione che si verifica quando ci si imbatte in una ambiguità).

Senza soffermarsi in questo momento sull'intera sequenza concreta di interazioni tra utente e servizio, si osserva che l'unico vincolo non funzionale da valutare resta il tempo medio di attesa dell'utente. L'usabilità complessiva è molto buona ed i vincoli funzionali sono soddisfatti.

===Scelta dei formati da trattare===

Una considerazione intuitiva, ed una buona prassi, è che un documento contenente dati personali sia pseudonimizzato o anonimizzato quanto prima possibile e cioè quando è ancora solo nelle mani del suo autore: questo approccio scongiura che informazioni sensibili e dati personali in chiaro ''sfuggano'' in rete.
Si può per questo ragionevolmente ipotizzare che i naturali destinatari del servizio siano gli stessi autori (creatori) che redigono il documento. Nello scenario tipico di utilizzo, infatti, il fruitore del servizio procederà al trattamento dei dati non appena avrà finito di scrivere il documento del quale, essendone autore, potrà scegliere il formato. Si osserva che potrebbe accadere che il documento sia redatto da terzi: in tal caso l'utente che richiede il trattamento può scegliere il formato in maniera indiretta concordandolo con il redattore. Avendo quindi l'utente la possibilità di stabilire il formato del proprio documento, risulta ragionevole progettare un servizio che lavori su un solo formato.
A questo punto occorre individuare quale sia il formato che maggiormente si presta alle finalità del servizio.<div></div>
Una possibilità è quella di richiedere all'utente di inserire come documento da trattare un semplice file di testo in formato ''txt'': in questo modo ci sarebbe il grande vantaggio di trattare file molto semplici, riducendo così al minimo la complessità realizzativa, e inoltre si avrebbe l'indipendenza dagli editor di testo utilizzati, in quanto tutti supportano i file in formato ''txt''.
Risulta tuttavia sconveniente utilizzare questo formato, poiché non ha alcuna capacità espressiva per gestire elementi complessi come tabelle, modifiche allo stile del testo e così via.
Bisogna quindi optare per un formato in grado di gestire questi elementi, al costo di aumentare la complessità della progettazione, ricordando sempre che è necessario allo stesso tempo che tale formato sia supportato da tutti i principali editor di testo.<div></div>
Con facilità è possibile individuare quali sono i formati di testo più comuni oltre al ''txt'': ''doc'', ''docx'', ''odt'', ''pdf'', ''pages'', ''rtf'', ''tex''. Si passa ora dunque a valutare quale tra questi formati potrebbe meglio soddisfare i requisiti prima enunciati.
Facendo una cernita iniziale sulla base delle finalità per le quali un formato è utilizzato, si può immediatamente escludere ''tex'', che trova impiego principalmente in ambito scientifico e matematico. In questo settore, infatti, non è richiesta generalmente l'applicazione delle procedura di trattamento dei dati. <div></div>
Si può inoltre abbandonare l'idea di trattare documenti con estensione ''pages'', formato proprietario di Apple, poiché utilizzati esclusivamente dall'omonimo editor di testo anch'esso proprietario, e i documenti con estensione ''rtf'', acronimo di ''Rich Text Format'', formato proprietario di Microsoft che supporta una formattazione avanzata, poiché, pur gestito da vari editor, è un formato decisamente datato (ultima versione 1.9.1 risalente a marzo 2008 ([0009])). <div></div>
Si esclude inoltre il formato ''pdf'' per motivi di usabilità: molti editor, infatti, consentono di esportare un documento in questo formato ma non permettono di importarlo. Un utente dopo aver effettuato l'anonimizzazione di un documento non può quindi proseguire modificandolo ulteriormente. Il ''Portable Document Format'', infatti, è ideato per realizzare dei documenti destinati alla sola lettura.
L'ultima esclusione, piuttosto immediata da effettuare, riguarda il formato ''doc'', binario e proprietario di Microsoft. Esso infatti risulta, a partire dal 2006, soppiantato dal formato ''docx'', sempre proprietario di Microsoft.

Si giunge infine a valutare quale tra gli ultimi due possibili formati rimanenti, ossia ''docx'' e ''odt'', si presta meglio alle finalità del servizio. In via preliminare si osserva che entrambi i formati possiedono ottime capacità espressive, hanno una struttura interna di simile complessità e sono entrambi supportati dai principali editor di testo. È necessario quindi effettuare delle analisi più approfondite per poter sceglierne uno tra i due.
La struttura del formato ''docx'', sviluppato da Microsoft e formalmente denominato ''Office Open XML Document (OOXML Document)'', è costituita da un file compresso .zip contenente un insieme di file ''XML''. Il formato ''OOXML'' permette la rappresentazione, oltre che di documenti testuali, anche di fogli elettronici (formato ''OOXML 'Workbook'', noto anche come ''xslx'') e di presentazioni (formato ''OOXML Presentation'', noto anche come ''pptx'') ([0008], [0013]).
Il formato inoltre è stato inizialmente standardizzato nel 2006 dall'<i>ECMA</i> (come ''ECMA-376'') e successivamente nel 2008 dall'<i>ISO</i> e dall'<i>IEC</i> (come ''ISO/IEC 29500'') in una versione ''transitional'', retrocompatibile con alcune versioni precedenti del formato contenenti elementi deprecati, e in una versione ''strict'', dove tali elementi non sono ammessi. I due standard sono stati poi successivamente aggiornati e sono tutt'ora oggetto di revisioni ([0002]).

Anche la struttura del formato open source ''odt'', sviluppato dall'<i>OASIS</i> e formalmente denominato ''OpenDocument Text'', è basata su uno zip contenente un insieme di file ''XML''. Inoltre, il formato ''OpenDocument Format (ODF)'' permette di trattare fogli elettronici (formato ''OpenDocument Spreadsheet'', noto anche come ''ods'') e presentazioni (formato ''OpenDocument Presentation'', noto anche come ''odp'') ([0007]). Anche ''OpenDocument Text'' è stato standardizzato, in particolare dall'<i>OASIS</i> stesso nel 2005 e dall'<i>ISO/IEC</i> nel 2006, ed è soggetto a revisioni e aggiornamenti ([0003]).

In sintesi, basandosi sulla struttura dei documenti e sulla standardizzazione dei formati, non è ancora possibile individuare quale sia il formato migliore. L'unico elemento che potrebbe portare punti a favore del formato ''odt'' è che esso, a differenza del formato ''docx'', è aperto, tuttavia, essendo le specifiche di entrambi i formati pubbliche, ciò non rappresenta un fattore determinante nell'elezione del formato.
Entrambi i formati, inoltre, sono largamente supportati dai word processors.

Le seguenti tabelle riepilogano il supporto all'uno ed all'altro formato dei ''word-processors'' più usati, ossia ''Microsoft Office Word'', ''LibreOffice Writer'', ''OpenOffice Writer'' e ''Pages''.
Le tabelle sono tratte da wikipedia ([0000], [0001], [0006]). <div></div>

<center><i>Supporto fornito dagli editor di testo al formato docx</i></center>
{| class="wikitable"
|-
! !! Microsoft Office Word !! LibreOffice Writer !! OpenOffice Writer !! Pages
|-
! Version
|| 2013, 2011 for Mac || All versions || 3.0 || '08
|-
! Operating systems
|| Windows, Mac OS X || Windows, OS X, Linux, Unix, Android || Windows, Linux, Unix, Mac OS X || Mac OS X
|-
! Office suite
|| Microsoft Office || || OpenOffice.org || iWork
|-
! Developer
|| Microsoft || The Document Foundation || Apache OpenOffice || Apple Inc.
|-
! License
|| proprietary || MPL || LGPL || proprietary
|-
! ECMA-376
|| yes || yes || yes || yes
|-
! ISO/IEC 29500:2008
|| yes || yes || ||
|-
! Notes
|| || || Import only ||
|}

<div></div>
<center><i>Supporto fornito dagli editor di testo al formato odt</i></center>
{| class="wikitable"
|-
! !! Microsoft Office Word !! LibreOffice Writer !! OpenOffice Writer
|-
! Version
|| 2007 SP2 || 4.0.3 || 3.0.0
|-
! Operating systems
|| Windows || Unix-based systems, Mac OS X, Solaris || Windows, Linux, Unix-based systems, Mac OS X, Solaris
|-
! Office suite
|| Microsoft Office || || OpenOffice.org
|-
! Developer
|| Microsoft || The Document Foundation || Apache OpenOffice
|-
! License
|| Proprietary || MPL || LGPL
|-
! ISO/IEC 26300:2006
|| yes || yes || yes
|-
! Notes
|| some limitations || Multiple ODF versions supported (ISO/ODF 1.0/1.1/1.2/1.2 Extended) || adjustable ODF version (ISO/ODF 1.2)
|}
<div></div>

Si possono effettuare le seguenti osservazioni:
* ''Microsoft Office Word'' è, in ambiente Microsoft, il word processor maggiormente usato; è molto usato anche in ambiente Apple Mac. Esso offre il pieno supporto al formato ''OOXML Document''; solo parzialmente invece gestisce il formato ''OpenDocument Text'': il processamento di file con estensione ''odt'' con questo editor comporta la perdita di alcune informazioni secondarie.
* ''LibreOffice Writer'', l'editor open source maggiormente utilizzato, supporta pienamente entrambi formati. Nato con lo scopo di gestire i file con formato ''OpenDocument Text'', attualmente supporta completamente anche il formato ''OOXML Document''.
* ''OpenOffice Writer'', un altro degli editor di testo tra i più utilizzati, supporta pienamente ''odt'', mentre è solo in grado di importare i file con estensione ''docx''.
* ''Pages'', il word process installato a default sui Mac della Apple e, di conseguenza anche maggiormente usato su questi dispositivi, non offre supporto al formato ''odt'', ma elabora correttamente i documenti con estensione ''docx'' ([0005],[0004]). <div></div>
Queste osservazioni evidenziano che quindi è impossibile adottare un formato supportato da tutti gli editor; la scelta va allora indirizzata verso quello maggiormente supportato dai word processor più popolari.
Per avere un'indicazione di ''popolarità'', e quindi per poter comprendere meglio quali tra gli editor prima citati siano i più usati, si può fare un'analisi, tramite motori di ricerca, di quanti file con una certa estensione siano presenti in rete.
È possibile, ad esempio, ricercare su Google i file che contengono nel proprio nome una determinata sequenza di caratteri o aventi una certa estensione (''filetype''). Sono qui presentati i risultati delle interrogazioni riguardo ai file aventi formato ''docx'', ''doc'' e ''odt'' ed il cui nome contiene uno dei caratteri, fra i più frequenti, "1" o "a" o "e". L'investigazione è stata effettuata inserendo nella barra di ricerca di Google le stringhe ''1 filetype:docx'', ''a filetype:docx'' e così via.

{| class="wikitable"
|-
! Formato cercato !! Documenti con "1" nel nome !! Documenti con "a" nel nome !! Documenti con "e" nel nome
|-
| docx || 16.900.000 || 12.800.000 || 8.730.000
|-
| odt || 736.000 || 667.000 || 507.000
|-
| doc || 32.300.000 || 26.300.000 || 21.500.000
|}

Effettivamente il formato più diffuso è il ''doc''; tuttavia esso è supportato per retro-compatibilità anche dagli editor che supportano formati ''OOXML'', con i quali non si ha difficoltà nel convertire i documenti dal formato ''doc'' al ''docx''. In conclusione, quale che sia l'editor più diffuso, è ragionevole adottare il formato ''OOXML Document'' per le finalità del servizio, in quanto molto diffuso, ben supportato dagli editor e avente ottime capacità espressive. Di conseguenza i documenti che saranno elaborati dovranno essere forniti dall'utente in tale formato. In successive sezioni verrà approfondita la struttura dei documenti ''OOXML''.

===Privacy by design===

L'Art. 25 del ''GDPR'', con i Considerando 75 e 78, ha per titolo e per oggetto la "protezione dei dati fin dalla progettazione e protezione per impostazione predefinita" ([0035]), perfettamente in linea con i concetti di "minimizzazione", già richiamati.<div></div>
Il senso dell'Art. 25 viene spesso sintetizzato con l'espressione "''PbD - privacy by design, privacy by default''" ([0035]). Il principio fissato nell'Art. 25 dovrà sempre più essere tenuto ben presente nell'ambito dell'ingegneria del software, in quanto impone di adottare nuove cautele nella realizzazione delle applicazioni software.<div></div>
Del principio ''PbD'' si è ben tenuto conto nella progettazione descritta in questa tesi. In particolare, relativamente alla ''privacy by design'', si è fatto in modo che nessun dato personale permanga registrato sul sistema di esecuzione, o altrove, al termine dell'applicazione. Anche laddove l'applicazione termini in modo anomale non vi sono strutture dati superstiti, che restano memorizzate sul sistema.<div></div>
Marginale in questa tesi è la nozione di ''privacy by default'', giacché l'applicazione non offre all'utente alcuna opzione che possa indurlo in errore ed acconsentire a trattamenti dei dati personali, oltre quello realizzato dall'applicazione.<div></div>
È utile osservare quanto sia importante esprimere queste impostazioni di progettazione fra le condizioni d'uso presentate all'utente: esse costituiscono uno dei presupposti affinché l'utente abbia piena fiducia (''trust'') nel servizio, lo utilizzi, lo divulghi, lo renda un servizio di successo.

==Architettura del servizio==

===I componenti software nell'architettura LAMP===

Il servizio è realizzato in forma di ''web-based application'' poiché, come già illustrato nell'introduzione, si intende renderlo disponibile per il massimo numero di utenti possibili. Nella progettazione e realizzazione dell'architettura web si adotta la piattaforma ''LAMP'', il cui nome deriva dall'acronimo dei componenti open source che la realizzano (il sistema operativo Linux, il server HTTP Apache, il sistema per la gestione di database relazionali MySQL ed il linguaggio di programmazione PHP). Poichè il modello è composto da quattro livelli, spesso si parla anche di ''stack LAMP''. Uno degli elementi di forza del modello ''LAMP'' è che i componenti dei vari ''layer'' sono sostituibili, a seconda delle esigenze, con dei componenti più adatti, tipicamente open source ([0015], [0018], [0019]). Basando la piattaforma su un sistema operativo della famiglia di Microsoft Windows, ad esempio, si ottiene uno ''stack WAMP'', mentre se si usa un sistema operativo Mac OS si realizza uno ''stack MAMP''. Un'architettura web basata sul modello ''LAMP'' può, inoltre, essere integrata con software open source che offre utili funzionalità, come, ad esempio, il monitoraggio (''Nagios''), il load balancing (''Linux Virtual Server''), la rilevazione di accessi illeciti (''Snort'') e il security testing (''netsniff-ng''). <div></div>
Si valutano ora brevemente la diffusione dei componenti tradizionali dello ''stack LAMP'' e le alternative maggiormente usate per i vari ''layer''.
Le distribuzioni Linux risultano essere la scelta più comune per l'ultimo ''layer'' dello ''stack''. Secondo W3Techs, infatti, nell'ottobre del 2013, il 58.5% dei web server a livello globale avevano come sistema operativo la distribuzione Debian o Ubuntu, mentre il 37.3% una tra RHEL, Fedora e CentOS([0016]). <div></div>
Tra i web server, Apache risulta essere maggiormente usato. Secondo le stime fatte da Netcraft, a giugno del 2014 circa il 51.9% del milione di siti web più trafficati al mondo usavano un web server Apache, il 19.2% nginx ed il 12.4% Microsoft ([0017]). <div></div>
I principali ''DBMS'' relazionali, oltre a MySQL, che possono essere presenti nello ''stack LAMP'' sono MariaDB e PostgreSQL, mentre tra i ''DBMS NoSQL'' MongoDB risulta essere il più comune. <div></div>
Nello stack, infine, il ruolo di linguaggio di programmazione, solitamente svolto dal linguaggio PHP, spesso è ricoperto dai linguaggi Perl o Python. <div></div>
Si osserva, ad ogni modo, che le informazioni sulla diffusione delle tecnologie non rappresentano un fattore vincolante nella scelta delle stesse, in quanto la piattaforma ''LAMP'' è anche aperta verso molti altri componenti oltre quelli citati; di conseguenza la scelta delle tecnologie da impiegare può essere effettuata basandosi principalmente sui requisiti e sulle specifiche del servizio. <div></div>

===Principi di progettazione per l'architettura===

====Single Responsibility Principle====

Per rendere il servizio maggiormente manutenibile ed estensibile, si presta particolare attenzione al rispetto del ''Single Responsibility Principle'' (''SRP'') ([0020]). Si cerca, quindi, di fattorizzare il software in più moduli, suddividendo tra questi le elaborazioni da svolgere. Un altro importante beneficio che si ottiene dalla fattorizzazione del codice è la riusabilità dei componenti. Ogni singolo modulo, infatti, svolge il proprio compito in maniera indipendente dal resto della applicazione ed è, quindi, riutilizzabile in altri scenari simili senza dover essere re-implementato. Inquadrando meglio questa metodologia di progettazione con i requisiti del servizio e la piattaforma web ''LAMP'', si individuano i due principali compiti a carico dell'applicazione:
* La gestione dell'interazione web con l'utente per la trasmissione del documento e dei nominativi da trattare
* Il processamento del documento per effettuare la "minimizzazione" dei dati.
Questi due differenti ''task'' saranno, quindi, portate a termine da componenti diversi.<div></div>
Progettando la struttura dell'applicazione in questo modo, si disaccoppia completamente la logica di business del servizio dalle interfacce web di comunicazione con l'utente. In un futuro sviluppo sarà possibile, quindi, realizzare nuove interfacce utilizzando altre tecnologie senza dover modificare la logica applicativa.

====Dependency Inversion Principle====

Un altro principio di design architetturale che risulta importante nella progettazione è il ''Dependency Inversion Principle'' (''DIP'') ([0038]). Esso si traduce nella realizzazione di componenti che non dipendono dalle specifiche implementazioni degli altri moduli del sistema, bensì dalle loro ''astrazioni''.
In relazione all'estensibilità e manutenibilità del prodotto software, infatti, l'impiego di moduli dipendenti direttamente dalla definizione dei metodi presenti in altri componenti risulta problematica: il modulo dipendente deve essere re-implementato ad ogni variazione del modulo da cui dipende.
Nella programmazione orientata agli oggetti, per rispettare questo principio, si su può fare uso di classi astratte o interfacce, costrutti che definiscono i moduli senza implementarli completamente o senza implementarli affatto.

===Stile architetturale REST===

Il modello architetturale del servizio che si sta definendo presenta una serie di caratteristiche, come ad esempio l'indipendenza dei moduli, che permettono di realizzarlo secondo il paradigma delle ''RESTful API''. L'espressione "Representational State Transfer" e il suo acronimo "REST" furono introdotti nel 2000 nella tesi di dottorato di Roy Fielding ([0021]), uno dei principali autori delle specifiche dell'Hypertext Transfer Protocol (HTTP). Roy Fielding descrive il ''Representational State Transfer'' come uno stile architetturale ("''architectural style''"), ovvero un'astrazione degli elementi di un'architettura all'interno di un sistema hypermedia distribuito. ''REST'' non specifica i dettagli dell'implementazione dei componenti e della sintassi del protocollo, ma definisce i ruoli dei componenti, i vincoli sulla loro modalità di interazione e la loro interpretazione.
Riassumiamo quindi i principi che deve rispettare una architettura ''REST'':
# Architettura Client-Server <br/>In una architettura ''REST'' viene data particolare importanza ai principi ''SRP'' e ''DIP'' prima citati, più generale si può affermare che l'architettura sposi il paradigma noto con il termine di "''Separation of Concerns''". Una ''Restful API'' applica questi principi in un architettura Client-Server, capace di supportare l'evoluzione indipendente della logica lato client e della logica lato server.
# Stateless <br/>La comunicazione tra utente e fornitore del servizio deve essere senza stato, quindi ogni richiesta del client deve contenere tutte le informazioni di cui il fornitore necessita per l'erogazione del servizio offerto. Questa ipotesi viene fatta per rendere una ''Restful API'' facilmente scalabile orizzontalmente.
# Uso della cache <br/>In un Architettura ''REST'' i messaggi di risposta inviati dal server devono esplicitamente indicare se possono essere memorizzati nella cache del client o di componenti middleware per il riutilizzo nelle richieste successive.
# Interfaccia uniforme <br/>I componenti devono essere in grado di comunicare attraverso un'interfaccia uniforme e le risorse devono essere trasferite in un formato standard. Inoltre l'utente deve poter effettuare la navigazione tra le risorse di suo interesse tramite collegamenti ipertestuali. Per inciso, si osserva che il protocollo HTTP usato correttamente rispetta i requisiti di un architettura ''REST'' e che nelle implementazioni delle ''RESTful API'' il formato più usato per la modellazione dei dati è JSON.
# Layered System <br/>In un sistema a livelli, componenti intermedi (come i proxy) possono essere collocati tra client e server per intercettare il traffico per scopi specifici; ad esempio il caching o la sicurezza. Una soluzione basata su ''REST'' può essere composta da più livelli architettonici, indipendenti l'uno dall'altro.
# Code on Demand <br/>Questo vincolo facoltativo è inteso principalmente a consentire aggiornamenti alla logica all'interno dei client (come i browser Web) indipendentemente dalla logica lato server. Una ''single page application'', ad esempio, rispetta in pieno questo punto.

Un'applicazione progettata sul modello dell'architettura ''REST'' ha quindi gli indiscutibili vantaggi di:
* consentire l'evoluzione indipendente delle diverse componenti
* avere un'interfaccia utente portabile con altri tipi di piattaforme
* permettere agevolmente la replicazione delle macchine server
* non vincolare moduli server e client a linguaggi e tecnologie specifiche.

L'architettura del servizio oggetto di questa tesi si trova già perfettamente in linea con alcuni dei vincoli discussi, ma sono necessarie alcune considerazioni. Il punto 1 ("architettura Client-Server") è chiaramente soddisfatto.
Il punto 2 ("Stateless"), direttamente collegato con i punti 3 e 5 ("Uso della cache", "Layered System"), può essere rispettato con facilità; a ogni richiesta di "minimizzazione" del client corrisponde la restituzione del documento trattato dal server, non c'è quindi necessita di avere uno stato nell'interazione.

Analizzando le caratteristiche di una applicazione stateless in relazione al principio ''privacy by design'' illustrato in precedenza, si osserva che l'assenza di stato determina la semplificazione delle problematiche critiche relative al principio. Non vengono conservate, infatti, informazioni contenenti dati sensibili, poiché dopo aver effettuato l'invio della risposta, sarà subito eliminato sul server il file elaborato.

Nei capitoli precedenti tuttavia si è detto che l'utente può ripetere più volte il trattamento di uno stesso documento nella stessa sessione di interazione; essendo il vincolo dell'efficienza già difficile da rispettare per via dell'elaborazione onerosa del documento, si può progettare una modalità alternativa del funzionamento con stato del servizio, applicabile in assenza di replicazione delle macchine server e sfruttando le ripetute richieste di trattamento per uno stesso documento.
Si può infatti memorizzare lato server il documento inviato dal client inizialmente e, alle successive richieste di trattamento del medesimo documento, evitarne la ritrasmissione da client a server. Per rispettare il ''PbD'', al termine della sessione di interazione il documento verrà rimosso dal server. Si nota, inoltre, che per predisporre il servizio alla gestione delle due diverse modalità di funzionamento si può utilizzare un parametro di configurazione a livello applicativo.
I punti 4 e 6 infine ("Interfaccia uniforme", "Code on Demand") si possono rispettare utilizzando il formato JSON per la trasmissione dei documenti e dei nominativi, e usando localmente sul client Javascript per offrire tutte le funzionalità del servizio in un'unica pagina html.

===Moduli software del servizio===

====Scelta dei componenti software====

Si opera ora la scelta delle tecnologie da utilizzare per i componenti dei 4 layer dello ''stack LAMP''. Per i due layer inferiori risulta piuttosto immediato decidere di usare le tecnologie presenti per default. Un sistema operativo Linux ed un web server Apache sono adatti all'architettura del servizio.
Inoltre anche il linguaggio di programmazione PHP può essere usato senza significativi problemi, anche se verranno fatte in seguito, in una sezione di questo capitolo, alcune considerazioni sulle problematiche di esecuzioni concorrenti di script PHP. Il linguaggio sarà impiegato in particolare per la realizzazione della logica necessaria a gestire l'interazione web con il cliente, mentre l'elaborazione del documento OOXML lato server sarà effettuata da un programma Java.

I due ''task'' principali del servizio sono delegati, quindi, a due programmi distinti realizzati con tecnologie diverse. Si concretizza in questo modo il principio ''SRP'' e, sfruttando l'<i>openness</i> della piattaforma LAMP, le funzionalità necessarie vengono realizzate attraverso i linguaggi più adatti.
La scelta del linguaggio Java per l'implementazione del ''main core'' della logica di business è dovuta alla libreria open source in ambiente java Docx4j ([40],[41]). Questa libreria è realizzata per il processamento delle tre tipologie di formati OOXML (''docx'', ''xslx'', ''pptx'') e permette tutte le possibili operazioni di creazione, lettura e modifica su questo tipo di documenti. Anche questa libreria sarà approfondita in sezioni successive. Si osserva, per inciso, che esistono altre librerie equivalenti in ambiente .NET.

Nella scelta del linguaggio di programmazione usato per elaborare i documenti ed effettuare i confronti tramite ''regular expressions'', un dato non di poco conto da considerare è l'encoding delle stringhe. In Java, in particolare, una stringa è rappresentata internamente come un array di char, ognuno codificato da 2 byte in formato UTF-16 ([0042]); la codifica esprime in 16 bit tutti i caratteri definiti dallo standard Unicode, quindi è possibile scegliere Java.

Per il ''layer'' della persistenza, infine, l'impiego di un database MySql risulta una buona scelta. Si osserva che questo livello non verrà utilizzato nella tradizionale maniera prevista dallo ''stack LAMP''. Infatti, generalmente, la base di dati viene interrogata direttamente dal componente che si occupa dell'interazione con l'utente (PHP) per il reperimento delle informazioni utili da restituire al client; nel servizio, invece, la base di dati sarà a supporto unicamente del programma Java, poiché gli unici dati persistenti da gestire sono i nomi del dizionario (si ricordi sempre il ''PbD'') e solo i moduli dell'eseguibile Java devono utilizzarli. Se il dizionario contenessero unicamente i nomi (senza informazioni accessorie correlate) e fossero usati in sola lettura, un semplice file di testo poteva essere sufficiente per la rappresentazione. Tuttavia, poiché saranno individuate tecniche di ottimizzazione nell'impiego dei dizionari che richiedono operazioni di scrittura e ordinamento dei dati, risulta opportuno usare un database relazionale.

====Logica di business e dinamiche di interazione====

Vengono presentati in questa sezione gli aspetti principali dei funzionamenti dei moduli del servizio. Per mettere bene a fuoco quali siano le meccaniche di interazione e i flussi di esecuzione dei programmi, si propone il diagramma di sequenza del tipico scenario di utilizzo. In questo schema UML si descrive il caso d'uso dove un utente, dopo aver inserito un documento ed averlo ricevuto "minimizzato", esprime delle preferenze e richiede poi un secondo trattamento.<div></div>
<div></div>(QUI IMG [0F00])<div></div>
Si descrivono quindi ora le principali operazioni che vengono eseguite.
All'avvio dell'interazione viene presentata una pagina PHP di benvenuto contenente le informazioni su come i dati personali vengano elaborati ed un ''file-picker'' per consentire l'upload di un documento ''OOXML''; nel momento in cui l'utente confermerà il caricamento del documento, esso verrà trasferito sul server.
Bisogna prestare particolare attenzione al comportamento del sistema nel caso in cui più utenti richiedano contemporaneamente l'esecuzione del servizio, e cioè alle problematiche di esecuzioni concorrenti di script PHP; è necessario, in particolare, evitare situazioni in cui i nomi dei file inviati dagli utenti siano in conflitto. Analizzando più in dettaglio il problema, ogniqualvolta un web server Apache riceve una richiesta HTTP per una pagina PHP, si ha la generazione di un nuovo processo che esegue il codice presentato nella pagina PHP richiesta. Supponendo quindi che N utenti eseguano l'invio del file contemporaneamente, si avrebbe che sul server N processi diversi dovrebbero procedere con la scrittura di un file. Ovviamente se due o più file condividono il nome almeno uno di essi sarà sovrascritto. Per risolvere questo problema, supponendo di voler salvare tutti i documenti in una cartella temporanea, occorre modificare il filename dei documenti inviati dagli utenti per esser certi di non incorrere in sovrascritture o altri tipi di errori correlati.
Una valida possibilità è l'inserimento di un ''prefisso'' univoco nel filename. Per la generazione di una stringa univoca da anteporre al filename, che permetta di distinguere file caricati da utenti diversi, si può direttamente usare il ''session id'' dell'utente. In PHP esso è determinato casualmente combinando ([0043]): l'IP del cliente, orario di attribuzione dell'id, un numero pseudo-casuale (con il ''PHP Linear Congruence Generator'') e, se presente un "''random source''" sul sistema operativo del Client (spesso chiamato impropriamente "''seme''"), un ulteriore numero pseudo-casuale.
Per introdurre ulteriore alea, necessaria se, ad esempio, un utente tenti l'upload di file omonimi (con contenuto interno diverso) e mantenga il medesimo ''session id'', si utilizza un ulteriore generatore pseudo-casuale per produrre un altro numero con cui comporre il prefisso.
Concatenando i due numeri generati si ha praticamente certezza di aver individuato un numero univoco nel sistema per il tempo in cui il servizio sarà erogato al cliente.

Una volta memorizzato il file, lo script PHP dovrà ricorrere all'invocazione del modulo Java, delegato al vero e proprio processamento del documento. Occorre quindi individuare un set di opzioni che consenta al modulo che gestisce l'interazione con il cliente di sfruttare al meglio il componente delegato all'elaborazione del documento, in qualunque circostanza; la totale indipendenza dei moduli, la loro sostituibilità e la replicazione possibile di macchine server sono solo alcuni dei fattori che rendono mutevole la configurazione del sistema. Va definito un protocollo di comunicazione, quindi, che astragga completamente dall'implementazione dei moduli o dalla locazione dei file.

Valutando i possibili flussi logici, anche con l'ausilio del diagramma di sequenza, si ha che i tipi di esecuzione sono due:
* "minimizzazione" con dizionario
* "minimizzazione" di specifici nominativi
Il protocollo di comunicazione tra i due moduli è costituito in entrambi i casi di una singola richiesta a cui segue una singola risposta. Più in particolare, lo script PHP invoca il comando Java esprimendo obbligatoriamente il path del file da trattare e opzionalmente l'elenco dei nominativi. A suo volta, il modulo Java restituisce i nominativi trovati, qualora non espressamente richiesti dallo script, e segnala la corretta terminazione dell'elaborazione.
Si definiscono come canali di comunicazione standard del protocollo gli argomenti presi in input dal modulo di processamento del documento e lo standard output del processo che esegue tale programma. Inoltre è importante definire un formato standard per la comunicazione dei nominativi tra moduli; è necessario quindi scegliere un pattern che permetta di determinare univocamente la composizione dei nominativi. Un possibile formato, espresso tramite ''regex'', è il seguente:
<div></div>
<span style="font-family: monospace;"> <nominativo> = ^(<nome>:)*<nome>;<cognome>$</span>
<div></div>
<span style="font-family: monospace;"> <nominativi> = ^(<nominativo>\s+)+$</span>
<div></div>
Dove nome e cognome sono una sequenza di caratteri Unicode come già discusso. Ulteriori opzioni importanti da definire nel protocollo per l'invocazione del programma che si occupa delle funzionalità di elaborazione sono le seguenti:
* path file da elaborare (opzione "-i <file_path>", obbligatoria)
* path con cui salvare il file elaborato (opzione "-o <file_path>", opzionale: per default viene creato un nuovo file automaticamente)
* abilitazione stampe verbose, da usare solo in fase di debug (opzione "-d", opzionale)
<div></div>
Una volta terminato il processamento, il modulo di gestione dell'interazione con l'utente dovrà accertarsi che l'<i>exit status</i> sia 0 e leggere dallo standard output del processo appena terminato, qualora si sia stata eseguita la "minimizzazione" con dizionario, l'elenco dei nominativi trovati. Se invece la "minimimizzazione" ha avuto luogo con i nominativi già specificati non sarà scritto nulla sullo standard output.
A margine si osserva che l'impiego dell'opzione "-d" deve sempre consentire una semplice individuazione dei nominativi trovati; in particolare, se tale opzione è specificata, nello standard output i nominativi compariranno con un ''header'' riconoscibile ("''NOMINATIVO=''").
Ritornando alla descrizione del flusso di esecuzione tipo, una volta che il modulo Java ha completato il trattamento del documento, lo script PHP ne effettuerà l'upload sul client e presenterà all'utente le opzioni già descritte nel capitolo sull'usabilità.
A questo punto l'interazione con client potrebbe concludersi, qualora si eseguisse il download e si chiudesse il browser, o continuare elaborando i ''suggerimenti'' dell'utente espressi dopo il primo trattamento. Le modalità di comunicazione dei moduli varierebbero leggermente come appena illustrato, mentre, a seconda della configurazione stateful o stateless del servizio, verrebbe eseguito o meno un nuovo upload del file dal client al server.<div></div>

Si osserva infine che, per predisporre a successivi studi di ottimizzazione il servizio e per agevolare tutti i possibili sviluppi futuri, si applica largamente nella progettazione del modulo di elaborazione Java il ''Dependency Inversion Principle'', in quanto si desidera realizzare classi estendibili ed intercambiabili.
In particolare, si introducono delle classi astratte per rappresentare in maniera generica il concetto di "''persona''" e "''minimizzatore''". È possibile infatti realizzare successivi studi per trattare ulteriori dati personali oltre che ai nomi e cognomi; inoltre, in base ai tipi di documenti trattati o eventuali altri fattori utili, è possibile studiare differenti tecniche di "minimizzazione" realizzate da differenti algoritmi "''minimizzatori''".
In particolare una "''persona''" dovrà sempre esporre un metodo "''minimizza''" che prende in input una stringa, la "minimizza" e la restituisce; il pattern con il quale si effettua la "minimizzazione" sarà fornito in implementazione a seconda dei dati sensibili di interesse.
Un "''minimizzatore''" esporrà sempre un metodo "''work''" che, presa in input una lista di persone ed un documento ''OXML'', con l'ausilio della libreria Docx4j, fornirà in output un documento del tutto "minimizzato"; la definizione delle modalità con cui si estrapolano le informazioni dal documento e con cui si invoca il metodo "''minimizza''" della classe persona sono confinate nell'implementazione.
Definendo delle classi astratte risulta, quindi, più veloce la realizzazione dei futuri componenti e si svincola il processo di "minimizzazione" dal tipo di dati che si "minimizzano" e viceversa.

====Le classi principali del progetto====
Le classi principali del progetto vengono quindi presentate in appendice. Esse sono:
* App.java, contenente il main
* Elaborator.java, che presenta il metodo "''work''"
* Persona.java, che presenta il metodo "''minimizza''"
* Testing.java, contenente alcune funzioni usate in fase di debug.

Gli script in PHP sono stati forniti dall'azienda come implementazione minimale e provvisoria, da perfezionare a seguito della eventuale definizione sulle modalità di presentazione del servizio su Internet.

Una considerazione di implementazione comune a tutte le classi deriva del principio ''Privacy by Design'', indifferentemente dalla modalità di configurazione stateful o stateless del servizio: è di fondamentale importanza che nel sistema non siano memorizzati permanentemente in alcun caso i documenti inviati dagli utenti del servizio.
Per realizzare un sistema robusto, per fronteggiare crash improvvisi del client o congestioni della rete, è opportuno impostare dei timeout lato server che procedano automaticamente alla eliminazione dei documenti degli utenti dopo un periodo di inattività troppo prolungato. Qualora invece si dovesse verificare un interruzione critica del servizio a causa di un errore logico del server o semplicemente per via di un'interruzione dell'alimentazione della macchina server, bisogna considerare altri metodi; essendo il servizio realizzato con un sistema operativo Linux, si può configurare il demone ''crond'' per eseguire a ogni reboot e, per sicurezza, una volta al giorno l'eliminazione dei file usati dall'applicazione tutti contenuti all'interno della cartella temporanea.

==Approfondimenti tecnologici==

===Analisi della struttura del formato OOXML===

Come argomentato, il formato dei documenti elaborati dal servizio progettato dovrà essere ''Office Open XML'', o ''OOXML''; si tratta di un formato ''XML-based'' per documenti di testo, fogli elettronici e presentazioni, in grado di rappresentare grafici, diagrammi, immagini e altro materiale grafico. La specifica fu sviluppata da Microsoft e adottata dall'<i>ECMA International</i> come standard ''ECMA-376'' nel 2006. Una seconda versione fu rilasciata nel 2008, una terza nel 2011, una quarta nel 2012 ed una quinta tra il 2015 ed il 2016 ([0010]). La specifica è stata adottata, inoltre dall'<i>ISO</i> e dall'<i>IEC</i> come standard ''ISO/IEC 29500'' a partire dal 2008 ([0011], [0012]).

====Linguaggi di markup====

Lo standard ''ECMA-376'' ([0010]) include tre differenti specifiche di linguaggio per ognuna delle tre principali categorie di documenti:
* ''WordprocessingML'' per i documenti testuali
* ''SpreadsheetML'' per i fogli elettronici
* ''PresentationML'' per le presentazioni elettroniche
* ''DrawingML'' ed altri linguaggi di markup di supporto per la rappresentazione di disegni, forme e diagrammi.
<div></div>
La specifica include sia gli schemi ''XML'' sia i vincoli espressi per iscritto. Ogni documento conforme al formato dovrà, quindi, rispettare gli schemi ''XML'' e dovrà essere codificato in ''UTF-8'' o ''UTF-16''. La specifica, inoltre, permette l'aggiunta di ''custom tag XML'' a supporto dei linguaggi di markup dati, per default nel formato ''OOXML'', consentendo quindi la libera personalizzazione dei documenti.

====File packaging====

Oltre alla specifiche relative ai linguaggi di markup, la seconda parte dell'<i>ECMA-376</i> ([0010]) definisce la struttura gerarchica dei file del formato adottando le ''Open Packaging Conventions'' (''OPC''). ''OPC'', una tecnologia ''file-container'' basata sul comune formato compresso ''zip'', che stabilisce che tutti i file che riguardano una stessa entità devono essere raggruppati in un unico package ([0014]). Un documento ''OOXML'' è, infatti, un archivio ''zip'' contenente alcuni files ''XML'' (detti anche ''parti'') organizzati in un singolo package. Questa frammentazione dei dati in più files rende più semplice e veloce l'accesso ai dati stessi e riduce le possibilità di una loro corruzione. Le ''parti'' possono contenere qualsiasi tipo di dato; per tenere traccia della relazione tra una ''parte'' e la sua tipologia di contenuto, senza basarsi sull'estensione del file, è presente nel package, nella cartella radice della gerarchia, il file denominato ''[Content_Types].xml'', il quale mappa appunto queste associazioni. È mostrata qui ad esempio l'associazione tra la ''parte'' rappresentante il documento principale e il suo ''ContentType''.
<div style="font-family: monospace;">
<Override PartName="/word/document.xml" ContentType="application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml"/>
</div>
Le informazioni relative alle relazioni che ogni ''parte'' ha con le altre ''parti'', con risorse esterne e con il package in sé sono mantenute separatamente dal contenuto della ''parte'' stessa. Tali informazioni sono presenti, infatti, all'interno delle cartelle denominate ''_rels'': ne esiste una per il package nel suo complesso e una per ogni sotto-cartella del package contenente delle ''parti'' coinvolte in delle relazioni. In questo modo i riferimenti che una ''parte'' ha verso altre ''parti'' o risorse sono salvati una sola volta e possono essere aggiornati con semplicità se necessario, senza dover modificare il contenuto stesso delle ''parti'' coinvolte. È mostrato qui un esempio di relazione contenuta in ''_rels/.rels'' relativa al documento principale e al suo schema.
<div style="font-family: monospace;">
<Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument" Target="word/document.xml"/>
</div>
Il documento principale, ossia il file ''word/document.xml'', ha inoltre numerose relazioni con altre ''parti'', come ad esempio ''word/styles.xml'' e ''word/footer.xml'', e risorse esterne collegate con degli URI. Per descrivere queste relazioni si usa la cartella ''word/_rels''.

====Parti di un Documento OOXML====

Vengono qui presentate le ''parti'' che sono caratteristiche esclusive di un ''WordprocessingML package'', non presenti quindi negli altri due formati ''OOXML''. È importante osservare che alcune di esse sono facoltative e sono presenti nel package solo se necessario.

Le ''parti'' relative al vero e proprio contenuto testuale sono:
* ''Main Document'', contiene le informazioni principali ed è salvata come ''word/document.xml''
* ''Header'', contiene i dati relativi alle intestazioni ed è salvata in ''word/header.xml''. Ogni sezione del documento può avere intestazioni diverse per la prima pagina, per le pagine pari e per le dispari, quindi possono esserci molteplici ''parti header''
* ''Footer'', contiene le informazione relative al piè pagina ed è salvata in ''word/footer.xml''. Può essere presente più volte, per motivi analoghi alla ''parte header''
* ''Footnotes'', contiene le eventuali note a piè pagina del documento ed è salvata come ''word/footnotes.xml''
* ''Endnotes'', contiene le note di chiusura del documento ed è salvata in ''word/endnotes.xml''.

Sono presenti poi delle ''parti'' relative allo stile e alle impostazioni del documento:
* ''Style Definitions'', contiene la definizione di un insieme di stili usati dal documento, salvata in ''word/styles.xml''
* ''Font Table'', contiene informazioni riguardo i font usati, salvata in ''word/fontTable.xml''
* ''Numbering Definitions'', contiene le definizioni sulla struttura delle liste contenute nel documento, salvata in ''word/numbering.xml''
* ''Document Settings'', specifica come il word processor debba trattare il documento (spell checking, gestione delle revisioni, etc.), contenuta in ''word/settings.xml''
* ''Web Settings'', contiene informazioni su come il documento debba essere convertito in ''HTML'' se richiesto, contenuta in ''word/webSettings.xml''.

Sono presenti anche delle ''parti'' che rappresentano testo secondario:
* ''Comments'', contiene i commenti sul documento inseriti attraverso un word processor
* ''Glossary'', contiene dati testuali aggiuntivi secondari, ne è permessa una sola. Tutte le ''parti'' prima elencate, tranne il ''Main Document'', possono comparire una seconda volta in relazione alla ''parte glossary''.

====Analisi del Main Document====

Il file ''document.xml'', elemento principale di un documento ''WordprocessingML'', è costituito da due tipi di informazioni:
* ''properties'', che definiscono lo stile e la formattazione del testo
* ''stories'', che rappresentano il contenuto testuale delle varie parti del documento.

Le ''properties'' verranno trattate in misura minore. Queste informazioni sono espresse attraverso una struttura XML gerarchica che ha come elemento radice il nodo ''document''. Esso ha due nodi figli:
* ''background'', che contiene alcune ''properties'' che descrivono lo sfondo del documento
* ''body'', che contiene tutti i rimanenti contenuti ed è potenzialmente molto complesso.

Si osserva che per le finalità del trattamento dei dati risultano di primario interesse le ''stories'' e che è opportuno effettuare un'analisi ''bottom-up'' del problema: anziché considerare la gerarchia a partire dal ''body'' (nodo padre) partiremo dalla rappresentazione più semplice del testo contenuta nel documento (nodi figli).

Facendo direttamente riferimento allo standard ''ECMA-376'' ([0010]), si evince che l'unico nodo che contiene puro testo ha il nome ''t'' (''Text''). Questo elemento contiene una stringa rappresentante gli esatti caratteri che vengono poi mostrati negli editor a video. Il nodo ''Text'' non presenta figli e l'unico nodo padre che può avere è ''r'' (''Run''). Quest'altro nodo definisce una regione di testo con comuni proprietà (ad esempio l'uso del grassetto). Attraverso l'uso di tag ''t'' ed ''r'' quindi si rappresenta una regione di testo formattata con differenti elementi stilistici.
Occorre però evidenziare che un nodo ''r'' può presentare molti altri figli oltre a ''t'', come ad esempio immagini, in quanto rappresenta un'area generica del documento.
Si supponga quindi di avere due nodi ''Text'' fratelli, ossia figli dello stesso nodo ''r'': essi rappresenteranno semanticamente un unico blocco logico se e solo se compariranno a video come una sequenza di parole continua. Questo fenomeno è facilmente identificabile anche nel file ''XML'' descrittivo: due sequenze di parole mostrate a video adiacenti compaiono infatti nel file ''XML'' in due righe consecutive; se invece due parti di testo dovessero essere intervallate ad es. da un'immagine nel documento ''XML'' ci sarebbe un tag ''drawing'' a dividere i due tag ''t''. Dalla consecutività dei nodi ''Text'' nel file ''document.xml'' si può determinare quali siano i blocchi logici da trattare.
Un insieme di ''Run'' infine può essere figlio di diversi nodi, ma ciò non è di rilevante importanza, in quanto ogni area di testo individuata dal nodo ''Run'' rappresenta già un blocco logico a sé e, di conseguenza, contiene sufficienti informazioni per la "minimizzazione".
L'unico caso di rilievo nel quale bisogna valutare quale sia la gerarchia a monte di un nodo ''Run'' è nell'elaborazione di una tabella. In tal caso, in realtà, occorre verificare opportunamente la strutturazione della gerarchia processata. Per chiarezza espositiva viene mostrata la rappresentazione in formato ''OOXML'' di una tabella con una riga e due colonne (senza l'uso di ''properties'' per la formattazione stilistica).
<br/>
<div style="font-family: monospace;">
<w:tbl>
<w:tr>
<w:tc>
<w:p>
<w:r>
<w:t>Cella A</w:t>
</w:r>
</w:p>
</w:tc>
<w:tc>
<w:p>
<w:r>
<w:t>Cella B</w:t>
</w:r>
</w:p>
</w:tc>
</w:tr>
</w:tbl>
</div>

Come si osserva in figura, in una tabella il nodo ''r'' sarà figlio del nodo ''p'' (''Paragraph''), il quale a sua volta sarà contenuto in un noto ''tc'' (''Table Cell''). Celle di una tabella appartenenti ad una stessa riga saranno presenti all'interno dello stesso ''tr'' (''Table Row'') ed infine tutte le righe della tabella saranno inserite del tag ''tbl'' (''Table'').

Per determinare quindi se due nodi ''Text'' sono scritti in due colonne adiacenti di una stessa riga (e quindi costituiscono un unico blocco logico) è necessario verificare che per i due nodi ''Text'':
# il nodo "padre" '''non sia''' in comune
# il nodo "padre di 2° livello" sia ''Paragraph'' e '''non sia''' in comune
# il nodo "padre di 3° livello" sia ''Table Cell'' e '''non sia''' in comune
# il nodo "padre di 4° livello" sia ''Table Row'' e '''sia''' in comune
# i nodi "padre di 3° livello" '''siano''' consecutivi.
Se tutte queste ipotesi sono soddisfatte, le due celle vanno "minimizzate" come unico blocco logico.

Si valutano infine gli ultimi vincoli emersi nell'analisi sull'interpretazione della formattazione di un documento.
In particolare, descrivendo le parti che compongo un documento ''OOXML'', era già emerso che alcune sezioni di testo, ossia note a piè pagina ed intestazioni, compaiono in altri file ''XML'' e non in ''document.xml''. Questi file (''header.xml'', ''footer.xml'', ''endnotes.xml'', etc.) sono tutti raccolti in un package ("''word''") e la grammatica ''XML'' è la stessa usata per il Main Document.
Si conclude osservando che il problema della divisione in sillabe delle parole non si pone, in quanto la divisione sillabica mostrata a video dai word-processors è calcolata dinamicamente; in particolare, su una porzione di testo viene applicata la sillabazione (ove necessario) se è presente tra le ''properties'' di quella regione di documento il tag ''hyphenationZone''.

====La libreria in ambiente java open source Docx4j====

La libreria Docx4j offre completo supporto alla manipolazione di documenti ''docx'' (compressione e decompressione archivio zip, generazione file ''XML'' necessari, etc.). Offre inoltre un'utile mappatura in specifici oggetti Java della gerarchia ''XML'' presente nei vari file del formato.
Uno tra gli elementi più interessanti è la tecnica con cui vengono recuperati i nodi dai file ''XML'', in quanto si fa impiego del linguaggio standard W3C ''XPath'' ([0044], [0045]). Con ''XPath'' è possibile esprimere con una stringa un sottoinsieme di nodi presenti in una gerarchia ''XML'' non solo in base al loro nome o valore, ma anche in relazione alla posizione reciproca rispetto agli altri nodi. Riferendoci alle problematiche del servizio risulta, ad esempio, significativamente agevolato il trattamento di dati personali in forma tabellare.
Si osserva infine che la libreria attribuisce un id univoco ad ogni nodo del documento, di conseguenza se ne può trarre vantaggio nei confronti tra i nodi.

===Ottimizzazioni del processo di minimizzazione===

Durante l'analisi dei requisiti è emerso che l'efficienza costituisce un aspetto problematico del servizio. Si ricorda di aver stimato la durata di una prestazione media di circa 145 secondi, considerando dati:
* un documento di medie dimensioni (10 pagine ~ 5000 parole)
* tempo medio di 10 ms per individuare le occorrenze di un nome
* un dizionario di circa 14.500 parole

In linea di massima si individuano due generi di strategie che consentirebbero la riduzione del tempo medio di esecuzione: uno mirato a ridurre il più possibile il testo da sottoporre a "minimizzazione" automatica, l'altro a ottimizzare l'impiego del dizionario e dell'algoritmo di ricerca.

====Riduzione del testo da trattare====

Come già spiegato, l'approccio di ricerca ''pattern-based'' è poco sensibile all'aumentare della lunghezza del documento, ma da questo valore ha una dipendenza non trascurabile.

Nel documento è altamente probabile che ci siano interi periodi, se non pagine, dove non sia presente alcun nominativo. Anche all'interno di una frase che necessita di ''minimizzazione'' è plausibile che siano sono poche le coppie (al più le terne) di parole riconducibili ad una sequenza nome-cognome. È inessenziale che sezioni di testo che non necessitano di "minimizzazione" vengano processate. Si osserva per inciso che, ovviamente, questo ragionamento è corretto per via dell'indipendenza dal contesto di un approccio ''pattern-based''.

Il pattern definito per la ricerca di un nominativo è molto restrittivo, in quanto accetta solo sequenze di parole costituenti un nominativo contenente un nome specifico; d'altronde la progettazione del pattern è stata effettuata mirando ad identificare il più accuratamente possibile le sequenze da anonimizzare.

Analizzando attentamente il problema, si può fare il seguente ragionamento: per ridurre il più possibile il numero di parole da processare a ogni iterazione di ricerca del pattern di un nome, è possibile individuare preliminarmente tutte le sequenze di parole del documento che ''potrebbero essere'' dei nominativi e ''potrebbero'' fare match.

L'operazione di "pre-filtraggio" si applica processando il documento con un ''pattern'' che presenta un'espressione più generale e permissiva delle ''regex'' definite per i nomi del dizionario. Si osserva che una qualunque successione di caratteri ''alfabetici'' iniziante con un carattere maiuscolo ''potrebbe'' rappresentare un nome. Per realizzare un espressione adatta si parte dalla definizione della ''regular expression'' già data ai nomi del dizionario:

<div style="font-family: monospace;">
<regex> := (<second_name>\s)?(<nome>)\s<cognome>|<cognome>\s(<nome>)(\s<second_name>)?
</div>

Nell'uso fatto finora di questa espressione, al tag <span style="font-family: monospace;"><nome></span> viene attributo, ciclio dopo ciclio, una parola del dizionario diversa. È possibile definire una variante più generale dell'espressione appena presentata:

<div style="font-family: monospace;">
<nome_pre> := [A-Z][a-zA-ZÀ-ÖØ-öø-ÿ<extra>]+

<regex_pre> := (<second_name>\s)?(<nome_pre>)\s<cognome>|<cognome>\s(<nome_pre>)(\s<second_name>)?
</div>

Con questa ''regex'' si identifica una qualunque sequenza che rappresenta un nominativo, ma allo stesso tempo anche, ad esempio, tutte le parole consecutive inizianti con una maiuscola. È importante sottolineare che questo pattern presenta tutte le caratteristiche già ampiamente discusse sul formato delle ''regex'' per riconoscimenti automatici (gestione dei delimitatori, posizione relativa tra i nomi ed il cognome, etc.).
Il processamento di una ''regex'' generale inoltre sarà inevitabilmente più lento di quello di ''regex'' aventi i nomi specificati, in quanto molte più sequenze faranno match essendo l'espressione più permissiva. La mancanza di accuratezza va rapportata all'impiego della ''regular expression'': fornendo essa un semplice "pre-filtraggio" del documento non risulta necessario nè che individui esclusivamente nominativi nè che sia in grado di distinguerli gli uni dagli altri. Il leggero ritardo introdotto viene valutato sperimentalmente, applicando lo stesso l'algoritmo già usato in precedenza ed elaborando gli stessi documenti, sempre a parità di piattaforma.

Partendo dall'elaborazione di un documento contenente 10 nominativi ed in totale 5.000 parole, si misura che tempo il processamento medio della ''regex'' di "pre-filtraggio" è di circa 36 ms; si ricorda che per lo stesso documento il tempo di esecuzione medio per il processamento di un nominativo non presente è di circa 9 ms, se le occorrenze salgono a 10, il tempo è in media di circa 10 ms.
Sebbene l'elaborazione di questa ''regex'' sia circa 4 volte più lenta dell'elaborazione di ''regex'' più specifiche, un ritardo introdotto dell'ordine dei millisecondi è trascurabile rispetto al tempo di processamento complessivo (stimato di circa 145 second).
Si osserva, per inciso, che nell'elaborazione di questo particolare documento sono stati individuati altre 21 sequenze che rispettavano il pattern che non costituivano dei nominativi.

Terminata l'esecuzione dell'operazione di prefiltraggio, occorre sfruttare opportunamente le informazioni ottenute: in particolare, si possono elaborare con le ''regex'' dei nomi le sole sotto-stringhe che hanno fatto match con la ''regular expression'' nell'operazione preliminare. In altri termini, con questo metodo si effettua una sola elaborazione del testo completo e molteplici processamenti delle sotto-stringhe che ''potrebbero'' contenere nominativi.
Si osserva inoltre che, conoscendo con certezza gli indici di inizio e fine delle sotto-stringhe che ''potenzialmente'' contengono nominativi, è possibile "alleggerire" la ''regex'' associata ai nomi del dizionario: si possono rimuovere i costrutti ''lookahead'' e ''lookbehind'' in quanto la sotto-stringa è stata già rimossa dal contesto e quindi rappresenta esclusivamente i caratteri individuati dalla ''regular expression'' di "pre-filtraggio".

A questo punto occorre valutare sperimentalmente l'ottimizzazione ottenuta. Si misura che sono sufficienti 2 ms di elaborazione in media per nome, mentre, nel caso raro in cui tutti i 10 nominativi presenti si riconducano ad un unico nome, il tempo medio di esecuzione tende verso i 3 ms. Si osserva che questo è possibile perchè le parole nelle sotto-stringhe sono poco meno di 50, ossia si è ridotta di oltre il 99% la dimensione complessiva di dati da processare!
Valutando l'ottimizzazione complessiva in termini di tempo si ha che, processando un dizionario di circa 14.500 termini, sono necessari in media 29 secondi.

Ovviamente questo dato è fortemente dipendente dal contenuto del documento. Vanno effettuate opportune misurazioni nel caso in cui la percentuale di nominativi presenti rispetto alle parole complessive nel documento sia maggiore. Si considera un documento di 5.000 parole contenente 200 sequenze riconosciute dall'algoritmo di "pre-filtraggio" delle quali 100 costituiscono dei nominativi.
Si misura che il tempo di esecuzione medio è di 6 ms nel caso generale del processamento di un nome con poche occorenze e tenderà verso i 10 ms nel caso sporadico in cui le occorrenze del nome saranno proprio 100 o poco meno. Il tempo di esecuzione del "pre-filtraggio" è di circa 48 ms.
Per inciso, si osserva che la ragione per cui il tempo necessario al "pre-filtraggio" non aumenta esageratamente è dovuta al pattern della ''regex''. La ''regular expression'' impiegata infatti, facendo principalmente uso di caratteri espressi in un range unitamente al quantificatore "+", risulta particolarmente efficiente da elaborare.
Nel caso di documenti più "ricchi" di nomi si stima l'elaborazione media complessiva di circa 1 minuto e 27 secondi.

Facendo il punto della situazione, si è ridotto di circa 5 volte il tempo di esecuzione complessivo nel caso di documenti "scarsamente popolati" da nominativi e quasi dimezzato il tempo necessario nell'elaborazione di documenti contenenti molte coppie nome-cognome. Occorre proseguire nello studio per migliorare l'ottimizzazione, considerando dove l'algoritmo di ricerca e l'impiego del dizionario possono essere migliorati.

====Ordinamento del dizionario====

Viene posta una semplice domanda sulle modalità di ricerca dei nominativi nell'insieme delle sotto-stringhe del documento: è computazionalmente equivalente prendere una ad una le sotto-stringhe e confrontarle con le ''regex'' dei nomi rispetto che prendere una ad una le ''regex'' dei nomi e confrontarle con le sotto-stringhe?

Si fornisce una spiegazione formale alla domanda.

Si definiscono due insiemi:
* A = {a_1, a_2, ... a_n}
* B = {b_1, b_2, ... b_m}

Gli elementi dell'insieme A rappresentano le sotto-stringhe (cardinalità N), mentre gli elementi dell'insieme di B indicano le ''regex'' dei nomi (cardinalità M). È importante considerare che per il secondo insieme è definita una relazione di unicità che lega il valore degli elementi: per ogni ''b_i'' appartenente a B non esiste un indice ''j'', ''j'' compreso tra 1 ed M, tale che il testo del nodo ''i'' sia uguale al testo del nodo ''j'' (tranne se ''i'' = ''j''); in altre parole gli elementi rappresentanti le ''regex'' (''b_i'') per definizione sono posti univoci in B.

Si presti attenzione al fatto che l'insieme delle sotto-stringhe presenta N elementi distinti tra loro in identità ("id nodo"), ma il cui contenuto testuale può essere equivalente a quello di altre sotto-stringhe. L'equivalenza tra due sotto-stringhe sussiste, in questo particolare contesto, qualora i contenuti testuali di entrambe facciano match con una stessa ''regex'' presente nell'insieme B. L'insieme delle ''regex'', invece, presentano elementi i cui valori testuali sono sempre univoci, in quanto ottenuti da nomi sempre diversi.

Definiti gli insiemi si procede alla formulazione della risposta alla domanda precedente. Per chiarezza espositiva indicheremo con "A->B" la procedura con cui si opera il confronto prendendo una ad una le sotto-stringhe per poi confrontarle con le ''regex'', mentre indicheremo con "B->A" la procedura con cui si opera il confronto prendendo una ad una le ''regex'' dei nomi per poi confrontarle con le sotto-stringhe.

Nel caso in cui l'insieme delle sotto-stringhe non contenga alcun nominativo, si ha una complessità computazionale equivalente per "A->B" e per "B->A". Viene mostrato nei calcoli in figura che il numero di confronti necessari ''C_1'' è dato dal prodotto delle cardinalità degli insiemi, ossia ''C_1 = N · M''.

(QUI FIG[0F07])

Si suppone ora che il testo della sotto-stringa di posizione ''r'' faccia match con la ''regex'' in posizione ''k''; si applica "A->B". Come si mostra attraverso i calcoli in figura, il numero totale di confronti ''C_2'' sarà inferiore a ''C_1'' poichè, quando la sotta-stringa in posizione ''r'' risulta equivalente alla ''regex'' in posizione ''k'' si può direttamente passare alla valutazione della stringa in posizione ''r + 1'' e non svolgere i rimanenti ''m - k" confronti per la stringa in posizione ''r''. Si calcola che ''C_2 = k + m · (n -1)''.

(QUI FIG[0F08])

Supponendo sempre che il testo della sotto-stringa di posizione ''r'' faccia match con la ''regex'' in posizione ''k'', si applica "B->A". Similmente al caso precedente, quando la sotta-stringa in posizione ''r'' risulta equivalente alla ''regex'' in posizione ''k'' si può direttamente passare alla valutazione della ''regex'' in posizione ''k + 1'' e non svolgere i rimanenti ''n - r" confronti per la ''regex'' in posizione ''k''. Si osserva inoltre che è inutile confrontare le rimanenti ''m - k'' ''regex'' con la sottostringa di posizione ''r'': essa è risultata già equivalente ad una ''regex'' e, essendo le ''regex'' poste per definizione diverse tra loro, è di conseguenza impossibile che soddisfi un'altra uguaglianza.
Per inciso si osserva che nel calcolo di ''C_2'' un ragionamento di questo genere non è applicabile: ogni sotto-stringa può potenzialmente fare match con una qualsiasi ''regex''.
Il numero totale di confronti ''C_3'' viene calcolato come mostrato, si ottiene ''C_3 = k + m · (n -1) - n + r''.

(QUI FIG[0F09])

Si osserva che ''C_3 = C_2 - n + r'' e, essendo ''r'' la posizione della sotto-stringa coinvolta nel match, si ha che ''C_3'' è sempre minore di ''C_2'' qualunque sia la posizione della sotto-stringa. L'unico caso in cui ''C_3 = C_2'' si verifica quando la ''r = n'', ossia se la sotto-stringa è l'ultima dell'insieme.

Per estendere il ragionamento, si prende la ''regex'' di posizione ''k'' e si indica con ''T'' il numero di sotto-stringhe che sono già risultate equivalenti ad una ''regex'' nelle elaborazioni precedenti. Risulta che, per il ragionamento spiegato nel calcolo di ''C_3'', potranno essere risparmiati almeno ''N - T'' confronti per la ''regex'' ''k'' e per ogni ''regex'' in posizioni successive. In generale, maggiore è il numero di nominativi nel documento, maggiore sarebbe l'ottimizzazione della procedura.

Le conclusioni che si traggono sono due:
* indipendentemente dal numero o dalla posizione dei nominativi nelle sotto-stringhe, nell'algoritmo di minimizzazione è più efficiente prendere una ad una le ''regex'' dei nomi e con ognuna trattare l'insieme delle sotto-stringhe
* un efficace ordine di elaborazione delle ''regex'' può introdurre ottimizzazioni

Va eseguita ora una valutazione sperimentale dei tempi di esecuzione del processo di "minimizzazione" tenendo conto di questi elementi. Le ''regex'' che fanno match con i nominativi presenti nel testo, quindi, vengono trattate tra le prime. Risulta di interesse principalmente valutare i miglioramenti ottenibili nel caso di documenti ''molto popolati'' da nominativi, poichè è questo il caso in cui l'ottimizzazione entra in gioco.
Si esegue il test sullo stesso documento trattato precedentemente con la sola tecnica di "pre-filtraggio". Esso è composto da 5.000 parole, dal "pre-filtraggio" sono individuate 200 sotto-stringhe delle quali 100 costituiscono dei nominativi.
Nel test si è fatto riferimento a dati Istat ([0046]) per stabilire, quanto più realisticamente possibile, il miglior ordine di elaborazione delle ''regex'' associate ai nomi; risulta che circa il 25% dei nominativi è individuato entro i primi 15 cicli di esecuzione; circa il 35% entro i primi 50 ed il 100% entro circa i primi 3000. Per inciso, si osserva che un altro documento può dare origine a tempi significativamente peggiori qualora presenti molti nominativi con nomi desueti e presenti in fondo al dizionario.
Si misura che, dopo il "transitorio iniziale" (ossia dalla 51° ''regex'' in poi), il tempo medio è di 5 ms per l'elaborazione di una ''regex''. Si osserva che, una volta che sono state elaborate circa le prime 3000 ''regex'', il tempo medio di elaborazione di una ''regex'' scende a 4 ms. Per completezza, si riporta anche il tempo medio per la fase di "transitorio iniziale", che si misura di circa 8 ms; il tempo di "pre-filtraggio", già precedentemente calcolato, risulta di 48 ms.
Calcolando complessivamente la durata del processamento si ottiene che l'elaborazione media complessiva è di circa 61 secondi, si ottiene quindi una riduzione significativa rispetto al tempo di 1 minuto e 27 prima individuato.

Si considerano, in relazione alle conclusioni della discussione teorica prima formalizzata, le implicazioni realizzative: in primis che l'imposizione del verso con cui eseguire la "minimizzazione" non determina particolari problemi implementativi, in secundis che l'ordinamento efficiente dei nomi del dizionario può essere trattato attraverso una tecnica di ''machine learning''.

La tecnica di apprendimento che si realizza si basa sull'estrapolazione di informazioni utili nei documenti inviati dagli utenti. Si tiene traccia, infatti, della ''frequenza'' con cui un nome appare in diversi processamenti. Alla fine di ogni "minimizzazione", dopo aver concluso il salvataggio del nuovo file ''OOXML'', il programma Java eseguira l'update sul database MySql delle frequenze dei nomi trovate, incrementandole.
Nell'interrogazione al database per l'ottenimento dell'insieme dei nomi, di conseguenza, si richiederà l'ordinamento per frequenza delle tuple restituite. In questo modo, più volte un nome compare nei documenti, più incrementi riceverà il suo campo frequenza, più avrà la probabilità di comparire in cima al dizionario.
Si progetta inoltre l'inserimento di un campo "ultimo utilizzo", associato ai nomi sul database, che permette di avere un secondo criterio di ordinamento utile. Tale campo viene impiegato anche per evitare una crescita esagerata del valore della frequenza; periodicamente, con ''crond'' ad esempio, si decrementano i valori del campo "frequenza" dei nomi il cui "ultimo utilizzo" è troppo vecchio. Si osserva che i valori di configurazione per la gestione di queste elementi dipendono dal carico medio del sistema, noto solo dopo la progettazione, andranno valutati con precisione in fasi future. Ovviamente l'aggiornamento del campo "ultimo utilizzo" sarà contestuale all'aggiornamento della ''frequenza''.
Si osserva, per inciso, che l'impiego di un dizionario di cognomi sarebbe stato problematico per l'aggiornamento delle frequenze. Per via del principio ''Privacy by Design'', infatti, aggiornando la frequenza per la entry del cognome di una persona, indirettamente si sarebbe tenuto traccia di un dato sensibile, specialmente nel caso in cui il cognome risulti "raro".
Una valutazione rilevante da fare è sulle implicazioni relative agli accessi concorrenti al dizionario, dovute all'introduzione dell'algoritmo appena spiegato, che esegue scrittura di "frequenza" e ''ultimo utilizzo'' sul database. Si osserva che non sono problematiche le "letture sporche", poichè, se si verificano, al più risulta alterato l'ordine di qualche nome; inoltre nemmeno un "lost update" risulta eccessivamente problematico, poichè l'ultimo utilizzo risulta sempre aggiornato e la perdita di un incremento delle frequenza di un nome non rappresenta in linea di massima un problema. Questi scenari presentati vanno valutati complessivamente, però, una volta che si realizza il reale carico del sistema: perdere molti update risulta critico per l'ottimizzazione del processamento. Conviene in linea precauzionale prevedere una semantica transazionale per l'interazione tra modulo Java e database. Per inciso, eseguire l'update finale con una transazione non influenza il tempo di attesa dell'utente, poichè il documento è stato già elaborato per intero.

Si fa infine un'ultima osservazione che consente di abbattere i tempi di attesa enormemente, a costo di perdere dell'accuratezza nel processamento automatico: ridurre il numero di nomi del dizionario processato, elaborando solo quelli in cima.
Si osserva che questa soluzione è ancor più efficace se i nomi contenuti nel documento sono pochi. In questo caso, infatti, il processamento dei nomi durante la fase di "transitorio iniziale" richiede lo stesso tempo del processamento di nomi "a regime", ossia dopo l'avvenuta riduzione del numero di sotto-stringhe da elaborare. Nei documenti "ricchi" di nominativi, come già spiegato, ciò non avviene.
Per concludere, si usano i risultati dei test sperimentali precedentemente misurati per stimare il tempo di processamento complessivo, supponendo di:
* applicare la tecnica di "pre-filtraggio"
* usare i primi 1.500 nomi di un dizionario ordinato per frequenza

Caso A:
* documento contenente 10 nominativi ed un totale di 5.000 parole
* processamento medio della ''regex'' di "pre-filtraggio" di circa 36 ms
* individuazione di 31 sotto-stringhe totali
* durata elaborazione in media per nome di circa 2 ms

Durata esecuzione senza troncamento: 29 secondi circa

Durata esecuzione con troncamento: 3 secondi circa

Caso B:
* documento contenente 100 nominativi ed un totale di 5.000 parole
* processamento medio della ''regex'' di "pre-filtraggio" di circa 48 ms
* individuazione di 200 sotto-stringhe totali
* durata elaborazione in media per nome di circa 8 ms per prime 50 iterazioni
* durata elaborazione in media per nome di circa 5 ms per successive

Durata esecuzione con solo "pre-filtraggio" : 1 minuto e 27 secondi

Durata esecuzione senza troncamento: 61 secondi circa

Durata esecuzione con troncamento: 7.7 secondi circa

I tempi a cui si giunge risultano soddisfacenti in entrambi i casi. Si prevede di lasciare all'utente la possibilità di scegliere di ricevere un servizio o più veloce o più accurato, in base alle sue esigenze.

===Tecnologie complementari===

La redazione di questa tesi è avvenuta su Mediawiki, la più importante fra le piattaforme wiki essendo il motore di Wikipedia.

Le piattaforme wiki sono riconosciute come elemento caratterizzante dell’evoluzione Internet al Web 2.0, cioè al web nel quale gli utenti-navigatori, fino ad allora "''consumatori"'' ("''consumers"'') di contenuti si sono trasformati essi stessi in "''produttori"'' ("''producers"''), e cioè in "''prosumers"''.

Un ''wiki'' è fondamentalmente un sito web che contiene informazioni e che consente agli utenti di editare facilmente il suo contenuto.

Nel redigere una pagina wiki si utilizza ciò che è chiamato ''wikitext" per definire capitoli, paragrafi, hyperlinks, elementi di formattazione della pagina, etc.; sebbene il ''wikitext" risulti non difficile da apprendere, quasi ogni piattaforma wiki è corredata da editor di tipo visuale, che non richiede alcuna conoscenza della sintassi del ''wikitext"; tuttavia è esperienza comune che utilizzare direttamente il ''wikitext" induce a concentrarsi maggiormente sui contenuti e non sulla formattazione. Il linguaggio ''wikitext'' è strettamente correlato con il linguaggio HTML, infatti nella scrittura è possibile utilizzare tag come h1, span, div e così via, oltre che la sintassi esclusiva di ''wikitext''; simmetricamente una pagina prodotta da media wiki è costituita da HTML ben formato e direttamente importabile in ogni word processor.

I wiki presentano una funzionalità di grande utilità nella redazione di documenti articolati: la tracciatura delle successive revisioni ("''Cronologia"''). La possibilità di ripercorrere l’evoluzione del testo è davvero d’aiuto quando si fissano idee originali in uno scritto, cercando di definirle, precisarle, chiarirle, come è avvenuto in effetti, anche nella redazione di questa tesi. Per curiosità, si segnala che, pur avendo redatto la maggior parte del testo off-line, la pagina wiki di questa tesi conta oltre 50 revisioni.

Per inciso, si osserva che è stata molto utile la funzionalità di "ricerca nel codice" offerta dalla piattaforma di revisione online GitHub nella corretta comprensione della libreria Docx4j, il cui codice sorgente è ivi rilasciato.

Si conclude infine dicendo che per ottimizzare le procedure di debug del codice sono stati realizzati utili tool a riga di comando per Linux per la rapida estrazione-modifica-ricompattazione di documenti ''OOXML''. Si propone in appendice un comando bash per questi scopi.

==Sviluppi futuri==

In questa sezione si fa cenno, senza poterle approfondire, ad alcune interessanti questioni emerse nello svolgimento della tesi.

===Accesso al servizio web===

In fase iniziale, il servizio web potrà essere reso accessibile in forma completamente aperta, senza richiedere cioè la registrazione dell’utente o l’autenticazione dell’utente già registrato. In questo modo, in effetti, si premia la facilità d’uso, ma si incorre nella nota problematica di un uso malevolo, costituito da accessi a raffica, finalizzati a saturare il server e generare una condizione di ''DoS – Denial of Service''. Diverse sono le tecniche che possono essere adottate per contrastare questo tipo di accessi malevoli, come richiedere di superare "''captcha''" e/o introdurre ritardi crescenti ed eventualmente blocchi in risposta ad accessi prevenienti con alta frequenza dallo stesso indirizzo IP.
È possibile anche pensare ad un accesso previa registrazione ed autenticazione dell’utente, penalizzando l’immediatezza di utilizzo del servizio, ma eventualmente ottenendo l’indirizzo email degli utenti che acconsentono a lasciarlo per successive finalità marketing.
È possibile, infine, un utilizzo misto, contando in un cookie il numero di accessi eseguiti e richiedendo all’utente di registrarsi per continuare ad utilizzare il servizio, dopo qualche accesso.

===Ampliamento dinamico del dizionario===

Nel restituire il documento elaborato all'utente, gli si da la possibilità di richiedere una nuova elaborazione, dopo aver indicato i nominativi che fossero sfuggiti; pare inesauribile, infatti, la "fantasia" dei genitori nel dare nome ai propri figlioli!
I nominativi indicati dall'utente sono sfuggiti al servizio perché non presenti nel dizionario: facilmente viene in mente l’idea di arricchire il dizionario con i nominativi indicati dall’utente. Va però considerato il caso che l’utente in malafede indichi nominativi fasulli al fine di inquinare il dizionario.
Il caso malevolo può essere affrontato attraverso una strategia che preveda non direttamente l'inserimento del nuovo nominativo nel dizionario, ma invece l'utilizzo di un concetto di "candidatura": il nuovo nominativo viene registrato, ma si attende di avere un certo numero di utenti che lo propongono prima di approvarne l'inserimento nel dizionario.
Può anche essere utilizzato un concetto di "attendibilità" della candidatura di un nuovo nominativo, verificando ad esempio l'utente che lo propone scarichi effettivamente il file rielaborato.
Nel caso l'accesso avvenga con autenticazione, e cioè identificando gli utenti, si apre la possibilità di individuare e bannare gli utenti malevoli.

===Natura del documento e ricorrenza del nominativo===

Si coglie facilmente la differenza di formato fra un documento in forma di elenco (es. una graduatoria) da un documento in forma di relazione (es. una sentenza giudiziaria). Differenze di questo tipo potrebbero essere utilizzate per escludere o ammettere la ripetizione dei nominativi.
Per meglio dire: in un elenco la ripetizione di un nominativo è di fatto da escludersi o va trattata come omonimia. In una relazione, l’individuazione di un nominativo può essere utilizzata per ricercarlo direttamente in altri punti del documento stesso.

===Altri dati personali===

Altri dati personali sono trattabili con le stesse tecniche analizzate in questa tesi: date e luoghi di nascita, codici fiscali, indirizzi, email, numeri di telefono, sesso etc. In qualche caso, come per i codici fiscali, l’individuazione del pattern da trattare è persino più semplice.
Diversi studi ([0039]) hanno dimostrato che, utilizzando set di dati personali parziali, è possibile la re-identificazione dei soggetti, pur in documenti pseudonimizzati. È questo un altro motivo per estendere i trattamenti descritti anche agli altri dati personali richiamati.

===Altri alfabeti===

È possibile estendere il sotto-insieme di caratteri Unicode utilizzati nelle ''regex'' per elaborare documenti scritti in altri alfabeti non latini.

==Conclusioni==

Questa tesi è partita da un problema basilare, quasi scolastico, dell'informatica: la ricerca di un testo in un documento, al fine della sua cancellazione o modifica.

Il problema si è subito discostato dalla sua formulazione basilare, principalmente perché, nei casi d'uso, il documento da ricercare non è un semplice testo ("''plain text''") ma invece è il prodotto di un ''word-processor'': quindi è costituito da una struttura XML più o meno complessa, rappresentante formattazioni, riferimenti interni o esterni, note, etc. La ricerca deve avvenire nei soli nodi di puro testo, individuando ed escludendo dall'analisi lessicale gli elementi testuali di mark-up che non costituiscono contenuto informativo. Nell'approfondire le strutture ed i concetti XML ho potuto notare quanto essi siano ricorrenti in molti ambiti dell'informatica.

Nell'analisi delle specifiche, un'altra complicazione si è presto aggiunta: l'usabilità del servizio cresce drasticamente se si evita di chiedere all'utente, come si era pensato in un primo tempo di fare, quali siano le stringhe (i nominativi) da ricercare e trattare; è nata allora l'idea di reperire queste stringhe in un dizionario di nomi ed in un dizionario di cognomi, considerando anche le permutazioni dei lemmi reperiti. Ho così dovuto approfondire alcuni problemi tipici dei dizionari, come il loro ampliamento automatico con tecniche oggi comprese nel ''machine-learning''. Non ho potuto "resistere" alla tentazione di ''formalizzare la matematica'' in base alla quale ho costruito le strategie di ricerca.

Spunto per la tesi è stata la recente legislazione in materia di dati personali, il GDPR. Esaminandone gli articoli pertinenti, ho maturato una riflessione generale: sempre più il software dovrà essere progettato e realizzato anche alla luce di altre discipline, non solo di quelle informatiche, come le discipline giuridiche ed il diritto.

Durante la fase iniziale della collaborazione con l'azienda mi sono dedicato alla messa a punto delle specifiche; ciò mi ha permesso di comprendere quanto questa fase sia importante e come completezza e precisione delle specifiche siano alla base di un progetto efficace.

Molto importanti sono state la analisi relative al tipo e formato dei documenti da assumere come input ed alla presentazione ottimale del servizio rispetto all'usabilità.

Centrale nel lavoro ed avvincente è stata la definizione della strategia per il riconoscimento dei lessemi attraverso la costruzione dinamica di ''regex'' idonee. In questo fase del lavoro, anche per passione personale, ho approfondito le questioni del riconoscimento "di testi nei testi" che legano, fin dalle origini, l'informatica e la linguistica.

La fase di definizione dell'architettura del servizio mi ha permesso di ripercorrere molte le materie studiate nei tre anni del Corso di Ingegneria Informatica, affrontando argomenti come il Single Responsibility Principle, il Dependency Inversion Principle, lo "stile" architetturale REST. Molto istruttiva è stata anche la riflessione sulla scomposizione del servizio in moduli software.

Come sempre accade nell'affrontare un progetto nuovo, sono nate molte nuove idee; ho così immaginato numerosi sviluppi futuri, sia a perfezionamento funzionale dell'accesso web al servizio, sia ad estensione delle specifiche per coprire casi applicativi contigui (es. quando il dato che si vuole trattare è un codice fiscale). Dovendo necessariamente tener presente che questo lavoro è una tesi, verificherò con il supporto del mio relatore come poterne proseguire lo sviluppo.

==Bibliografia==

<div></div>[0000]https://en.wikipedia.org/wiki/Comparison_of_Office_Open_XML_software
<div></div>[0001]https://en.wikipedia.org/wiki/Comparison_of_OpenDocument_software
<div></div>[0002]https://en.wikipedia.org/wiki/Standardization_of_Office_Open_XML
<div></div>[0003]https://en.wikipedia.org/wiki/OpenDocument_standardization
<div></div>[0004]https://support.apple.com/en-us/HT202227
<div></div>[0005]https://en.wikipedia.org/wiki/Pages_(word_processor)
<div></div>[0006]https://en.wikipedia.org/wiki/Comparison_of_word_processors
<div></div>[0007]https://en.wikipedia.org/wiki/OpenDocument
<div></div>[0008]https://en.wikipedia.org/wiki/Office_Open_XML_file_formats
<div></div>[0009]https://en.wikipedia.org/wiki/Rich_Text_Format
<div></div>[0010]https://www.ecma-international.org/publications/standards/Ecma-376.htm
<div></div>[0011]https://www.iso.org/standard/51463.html
<div></div>[0012]https://www.iso.org/standard/71691.html
<div></div>[0013]https://en.wikipedia.org/wiki/Office_Open_XML
<div></div>[0014]https://en.wikipedia.org/wiki/Open_Packaging_Conventions
<div></div>[0015]https://en.wikipedia.org/wiki/LAMP_(software_bundle)
<div></div>[0016]https://w3techs.com/blog/entry/debian_ubuntu_extend_the_dominance_in_the_linux_web_server_market_at_the_expense_of_red_hat_centos
<div></div>[0017]https://news.netcraft.com/archives/2014/06/06/june-2014-web-server-survey.html
<div></div>[0018]https://whatis.techtarget.com/definition/LAMP-Linux-Apache-MySQL-PHP
<div></div>[0019]https://www.ibm.com/cloud/learn/lamp-stack-explained
<div></div>[0020]https://en.wikipedia.org/wiki/Single_responsibility_principle
<div></div>[0021]https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
<div></div>[0022]https://en.wikipedia.org/wiki/Latin_script_in_Unicode
<div></div>[0023]https://it.wikipedia.org/wiki/ISO/IEC_8859-1
<div></div>[0024]http://www.treccani.it/enciclopedia/uso-delle-maiuscole_%28La-grammatica-italiana%29/
<div></div>[0025]https://en.wikipedia.org/wiki/Ambiguity#Linguistic_forms
<div></div>[0026]Steven L. Small; Garrison W Cottrell; Michael K Tanenhaus (22 October 2013). Lexical Ambiguity Resolution: Perspective from Psycholinguistics, Neuropsychology and Artificial Intelligence. Elsevier Science. ISBN 978-0-08-051013-2.
<div></div>[0027]http://www.treccani.it/vocabolario/disambiguazione/
<div></div>[0028]R. Navigli, K. Litkowski, O. Hargraves. 2007. SemEval-2007 Task 07: Coarse-Grained English All-Words Task. Proc. of Semeval-2007 Workshop (SemEval), in the 45th Annual Meeting of the Association for Computational Linguistics (ACL 2007), Prague, Czech Republic, pp. 30–35 http://www.aclweb.org/anthology/S/S07/S07-1006.pdf
<div></div>[0029]https://wordnet.princeton.edu/
<div></div>[0030]R. Navigli, S. P. Ponzetto. BabelNet: Building a Very Large Multilingual Semantic Network. Proc. of the 48th Annual Meeting of the Association for Computational Linguistics (ACL 2010), Uppsala, Sweden, July 11-16, 2010, pp. 216-225. http://aclweb.org/anthology/P/P10/P10-1023.pdf
<div></div>[0031]Roventini A., Alonge A., Calzolari N., Magnini B., Bertagna F. (2000), "ItalWordNet: a Large Semantic Database for Italian", Proc. of the 2nd International Conference on Language Resources and Evaluation (LREC 2000), Athens, Greece, 2000, pp. 783-790.
<div></div>[0032]E. Pianta, L. Bentivogli, C. Girardi. MultiWordNet: developing an aligned multilingual database, Proc. of the First International Conference on Global WordNet, Mysore, India, January 21-25, 2002. http://multiwordnet.fbk.eu/paper/MWN-India-published.pdf
<div></div>[0033]https://www.iso.org/standard/28245.html
<div></div>[0034]https://www.gpdp.it/web/guest/regolamentoue
<div></div>[0035]https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=uriserv:OJ.L_.2016.119.01.0001.01.ITA&toc=OJ:L:2016:119:TOC
<div></div>[0036]https://www.corriere.it/Primo_Piano/Cronache/2006/09_Settembre/15/cognomi.shtml
<div></div>[0037]https://data.world/axtscz/italian-first-names
<div></div>[0038]https://en.wikipedia.org/wiki/Dependency_inversion_principle
<div></div>[0039]https://imperialcollegelondon.app.box.com/s/lqqcugie51pllz26uixjvx0uio8qxgo5/file/493461282808
<div></div>[0040https://www.docx4java.org/trac/docx4j]
<div></div>[0041]https://github.com/plutext/docx4j
<div></div>[0042]https://docs.oracle.com/javase/9/docs/api/java/lang/String.html
<div></div>[0043]https://github.com/php/php-src/blob/master/ext/session/session.c
<div></div>[0044]https://github.com/plutext/docx4j/search?q=getJAXBNodesViaXPath+in%3Afile&type=Code
<div></div>[0045]https://www.w3.org/TR/xpath-30/
<div></div>[0046]https://www.istat.it/it/dati-analisi-e-prodotti/contenuti-interattivi/contanomi
<div></div>[0047]
<div></div>[0048]

==Indice delle figure==

[0F00]https://en.wikipedia.org/wiki/Latin_script


[0F01]Diagramma di Venn 1

[0F02]Diagramma di Venn 2

[0F03]Diagramma di Venn 3

[0F04]Esito unit test regex (cartella immagini)

[0F05]Inforgrafica GDPR

[0F06]Diagramma di sequenza UML

[0F07]Primo calcolo valutazione algoritmo

[0F08]Secondo calcolo valutazione algoritmo

[0F09]Terzo calcolo valutazione algoritmo

Servizio web per il trattamento dei dati personali contenuti in documenti OOXML complessi

2019-09-30T03:49:28Z

Lorenzo.amorosa: /* Ottimizzazioni del processo di minimizzazione */

==Introduzione==

Il recente Regolamento Generale europeo sulla Protezione dei Dati (UE) 2016/679 ([0034], [0035]) o ''GDPR'' (''General Data Protection Regulation'', come nel seguito sarà chiamato) ha modernizzato significativamente la normativa in materia di protezione dei dati personali, rendendola omogenea fra tutti gli stati membri. È bene notare che, fin dal titolo, il ''GDPR'' non riduce gli spazi per i trattamenti di dati personali, ma anzi ne protegge la "libera circolazione", dettando, però, regole definite e certe. Rinunciando ad una presentazione più completa del ''GDPR'', saranno riportati nei successivi capitoli i concetti necessari alla discussione dell'argomento.<div></div>
Enti ed organizzazioni, aventi a che fare con documenti contenenti dati sensibili, devono operare in maniera conforme al ''GDPR''; potrebbero, di conseguenza, trarre beneficio da servizi specifici in grado di supportarli in queste esigenze.<div></div>
L'oggetto principale della tesi sarà dunque, come riportato dal titolo, la progettazione e la realizzazione di un servizio per la gestione di dati personali.
<div></div>(QUI IMG [0F05])<div></div>

La larga maggioranza dei documenti testuali viene generata con strumenti cosiddetti di "produttività individuale", cioè da ''word-processors''. L'osservazione, ovvia nella sua evidenza, consente di introdurre una riflessione: quando un documento è generato da un'elaborazione automatica, magari per composizione di ''template'' con dati estratti da un database, l'individuazione dei "dati personali" nel documento prodotto può avvenire in modo rigoroso e senza incertezze, sulla base degli elementi di composizione del documento; ad es.: i campi del documento estratti da una anagrafica di soggetti sono certamente dati personali e come tali possono essere opportunamente trattati nel processo di elaborazione automatica (ad es. cancellati).

Ma, in quella larga maggioranza di documenti testuali generata con ''word-processors'' l'individuazione ed il trattamento dei dati personali vanno affrontati con altri approcci, discussi in questa tesi.

==Scenario di lavoro==

===Minimizzazione dei dati personali===

Un concetto espresso in modo pervasivo dal ''GDPR'' è quello della "''minimizzazione''" dei dati personali trattati ed a maggior ragione dei dati personali pubblicati. In particolare l'Art. 5 ed il Considerando 39 prescrivono che i dati personali trattati siano "''adeguati, pertinenti e limitati a quanto necessario rispetto alle finalità per le quali sono trattati («minimizzazione dei dati»)''" ([0035]).<div></div>
Con questo fine, il GDPR delinea due possibilità organizzative e tecniche di "''minimizzazione''": l'anonimizzazione e la psedonimizzazione.

====Anonimizzazione====

Sono anonimizzati i dati personali non (più) riferibili alle persone a cui sono appartenuti; si tratta di serie di dati, spesso ingenti, che sono stati definitivamente ed irreversibilmente separati da ogni riferimento alle persone che caratterizzavano. Sono le serie di dati utilizzate per fini statistici, scientifici, etc. E' importante notare che, come fissato dal Considerando 26 del ''GDPR'', il Regolamento non si applica al "''trattamento di tali informazioni anonime''" ([0035]). Per questo, sottoporre database e documenti ad un procedimento, cioè un trattamento, di anonimizzazione consente di non doversi più preoccupare del ''GDPR''.

====Pseudonimizzazione====

Fra le definizioni dell'Art. 4 del ''GDPR'', la "pseudonimizzazione" viene indicata come "''il trattamento tale che i dati personali non possano più essere attribuiti a un interessato specifico senza l’utilizzo di informazioni aggiuntive, a condizione che tali informazioni aggiuntive siano conservate separatamente''" ([0035]).<div></div>
Traducendo in termini "operativi", si tratta del procedimento che, dal "record" dei dati di un interessato, separa i campi che caratterizzano l'interessato stesso da quelli che lo identificano, trasferendo questi ultimi in una nuova distinta tabella; nelle due tabelle vengono aggiunti i riferimenti che permettono la ricostruzione del record originario; il procedimento è completo quando la nuova tabella con gli identificativi viene archiviata separatamente ed eventualmente cifrata. In margine si annota che in molti casi, come molti studi dimostrano, è possibile identificare, quindi "riconoscere", gli interessati utilizzando la sola tabella con i dati pseudonimizzati.

====Altri trattamenti di "minimizzazione" ====

Un problema pratico che si incontra di frequente è quello di dover pubblicare documenti più o meno ampi che contengono dati personali. Spesso la pubblicazione è obbligatoria per legge: si pensi alle graduatorie relative a concorsi pubblici, alle sentenze dei tribunali, etc.<div></div>
In questi frequenti casi, analizzando meglio le finalità per le quali sono pubblicati quei dati personali, si osserva che sono possibili e legittimi almeno due approcci per "minimizzare" il dato nel "trattamento di pubblicazione" e, dunque, per minimizzarne la propagazione, ad esempio attraverso motori di ricerca, ben oltre ogni ragionevole finalità. I contesti ed i corrispondenti approcci sono:
# Situazioni in cui è necessario che l'interessato possa riconoscersi nel documento ed essere riconosciuto dagli altri soggetti menzionati nel contesto, ma non è plausibile la necessità di identificazione dell'interessato al di fuori di quel contesto specifico. A questo caso si riconducono le graduatorie di concorsi, gli elenchi per la formazione di classi, gli elenchi per convocazioni, etc. In tutti questi casi, nel processo di redazione del documento è più pratico trattare internamente i dati personali in forma completa; ma praticamente mai è necessario pubblicarli per intero, esponendo al pubblico accesso codici fiscali, indirizzi, recapiti telefonici etc. Per di più, nella maggior parte delle volte, è sufficiente pubblicare il solo cognome perché l'interessato conosca la sua posizione in graduatoria; ciò è spesso sufficiente anche a trasmettere l'informazione necessaria ai colleghi dell'interessato nella medesima graduatoria, o nella medesima classe, etc. Notare che, pubblicando il solo cognome, viene di fatto oscurato anche il sesso. Dunque, in questi casi è auspicabile cancellare una larga parte dei dati personali presenti nel documento.
# Situazioni in cui il documento deve essere pubblicato affinché siano rese note le motivazioni che lo hanno originato, senza che sia necessaria la precisa identificazione dei soggetti che vi compaiono. Questo è il caso della pubblicazione di sentenze giudiziarie di ogni grado. Le sentenze vengono notificate direttamente agli "aventi causa"; ma anche, come la legge prescrive, pubblicate al fine di costituire giurisprudenza. In questo secondo caso, risulta del tutto eccedente la pubblicazione dei reali nominativi degli interessati, che troverebbero verosimilmente la propria vicenda inutilmente indicizzata dai motori di ricerca negli anni a venire. Nella pubblicazione delle sentenze appare un approccio ottimale quello di sostituire con pseudonimi o con iniziali alterate i veri nominativi degli interessati presenti: il senso e le argomentazioni della sentenza restano pienamente comprensibili, come è necessario; il dato personale, del tutto superfluo ai fini della giurisprudenza, viene protetto.
In questi casi appare opportuno sostituire i dati identificativi dell'interessato, ed in particolare il nome e cognome, con pseudonimi o, ancora, con iniziali alterate, cioè non coincidenti con le iniziali reali. <div></div>
Proprio questi tipi di trattamenti di "minimizzazione" sono l'oggetto di questa tesi.

===Punti di partenza per la progettazione del servizio===

La tesi è stata svolta in collaborazione con l'azienda AFA Systems (www.afasystems.it/gdpr) con la quale si sono discusse le problematiche di progettazione e realizzazione di un servizio generalizzato di minimizzazione dei dati personali presenti in un documento.
Con l'intenzione di fornire il servizio ad un bacino d'utenza il più vasto e variegato possibile, si è pensato ad un'applicazione ''web-based'', indipendente così dai singoli devices sui quali poi sarà utilizzata.
L'attenzione è stata concentrata sul trattamento dei nomi e dei cognomi (che da qui chiameremo nominativi), poiché sono quelli sempre presenti nei documenti (ad es. gli indirizzi sono presenti solo a volte), rappresentano gli elementi tramite i quali è immediato il riconoscimento della persone, non hanno formato predefinito (come ad es. i codici fiscali); altri dati personali (indirizzi, codici fiscali, etc.), potranno essere considerati in successive evoluzioni del progetto.
È utile notare che la parte iniziale della collaborazione con l'azienda è stata dedicata alla discussione delle specifiche, la cui più precisa definizione è parte rilevante di questa tesi.<div></div>
Tra i requisiti che necessitano di un opportuno studio troviamo ad esempio:
* L'individuazione di metodi efficaci per il riconoscimento dei nominativi nei documenti
* L'identificazione delle migliori procedure di interazione con l'utente
* La scelta dei formati da trattare
* I vincoli non funzionali legati al rispetto del ''GDPR''.

==Definizione delle specifiche==

===Riconoscimento dei nominativi===

====Scelta della strategia di riconoscimento====

Le difficoltà principali con cui ci si imbatte nel processo di riconoscimento dei nominativi riguardano la complessità strutturale dei documenti di testo, ma soprattutto l'intrinseca ambiguità del linguaggio naturale. <div></div>
Le variabili ed impredicibili strutture e formattazioni dei documenti introducono alcuni problemi significativi. Rendendo fortemente eterogeneo il contenuto dei documenti, infatti, esse non consentono di ricondurre il problema del riconoscimento dei nominativi ad uno o a pochi singoli casi, ma comportano lo studio di tutte le strutture e formattazioni possibili, rendendo quindi l'analisi molto generale. L'altra rilevante difficoltà presente sta nella complessità di effettuare il riconoscimento di una stringa testuale immersa in un insieme di elementi non tutti testuali. Ogni elemento di formattazione, che sia una tabella o una barra orizzontale, introduce infatti un proprio significato logico e semantico nel documento di cui bisogna tenere conto.<div></div>
Il linguaggio naturale introduce anch'esso complessità: si pensi alle molteplici tipologie di proposizioni con cui possono essere articolati i periodi; ma i problemi principali derivano dalle sue ambiguità. Esse vengono classificate in diverse tipologie ([0025]); le principali sono le ambiguità sintattiche e lessicali.<div></div>
Si ha ambiguità sintattica quando la sintassi di una frase può essere interpretata in diversi modi e, di conseguenza, la frase stessa assume significati diversi. Essa è presente, ad esempio, nelle seguenti frasi:<div></div>
* "''Rapina in banca con rivoltella da centomila euro''"
* "''Luigi ha visto un uomo nel parco con il binocolo''"
<div></div>
L'esasperazione massima della problematica delle ambiguità sintattiche si presenta con l'<i>antinomia</i>, ossia un particolare tipo di paradosso che indica la compresenza di due affermazioni contraddittorie che possono essere entrambe dimostrate o giustificate.
L'antinomia di Epimenide o ''Paradosso del mentitore'', nota fin dal VI secolo, è probabilmente uno dei più noti esempi: "''il cretese Epimenide afferma che tutti i cretesi mentono''". Se la proposizione è vera (i cretesi mentono) allora il suo significato implica che sia falsa (Epimenide mente e quindi i cretesi dicono la verità), ma se è falsa (i cretesi dicono la verità) ciò significa che è vera (Epimenide dice la verità e quindi i cretesi mentono). La proposizione appare contemporaneamente vera e falsa. A partire dagli anni venti del '900, sono state elaborate varie teorie per la risoluzione delle contraddizioni provocate dalle antinomie, soprattutto attraverso l'elaborazione di linguaggi multilivello o attraverso l'elaborazione di logiche polivalenti (quindi non-booleane).<div></div>
Si ha ambiguità lessicale, invece, quando una parola possiede più di un significato nella lingua a cui appartiene ([0026]), in tal caso la parola è definita ''polisemica''. In italiano, alcuni termini soggetti a questo tipo di ambiguità sono, ad esempio "''acuto''" o "''venti''". È questo genere di ambiguità che risulta critico per il riconoscimento dei nominativi. La difficoltà determinata dalle ambiguità sintattiche, infatti, riguarda l'individuazione corretta di soggetti, predicati e complementi di un periodo, mentre le ambiguità lessicali ostacolano la comprensione del significato del singolo lessema. Nel processo di riconoscimento è irrilevante determinare la funzione logica che il nominativo svolge nella frase, mentre è necessario essere certi che i termini che compongono il nominativo siano effettivamente dei nomi propri di persona o dei cognomi, non altri vocaboli del lessico comune. <div></div>
In linguistica, l'intervento con cui si toglie ambiguità a una parola o a una frase prende il nome di "disambiguazione" ([0027]). Il problema della disambiguazione automatica (in inglese ''Word Sense Disambiguation'' o, abbreviato, ''WSD'') riveste particolare importanza nelle ricerche sull'intelligenza artificiale e, in particolare, nell'elaborazione del linguaggio naturale. Si prevedono benefici della disambiguazione, ad esempio, in programmi di traduzione automatica, recupero dell'informazione o estrazione automatica di informazioni. Nell'analisi delle soluzioni esistenti in letteratura per la risoluzione delle ambiguità, ci si sofferma specialmente sulle ricerche incentrate sul trattamento dell'ambiguità lessicale, essendo essa la più rilevante per i nostri interessi.<div></div>
La ''WSD'' richiede due input necessariamente: un dizionario per specificare i sensi che devono essere disambiguati e un corpus di dati linguistici da disambiguare. Nello scenario più realistico, si trattano testi le cui parole non sono note a priori e risulta molto onerosa la produzione del corpus, essendo infatti necessaria la valutazione di un operatore umano per verificare la correttezza delle disambiguazioni effettuate dagli algoritmi (''supervised learning'').<div></div>
Uno tra i principali dizionari semantici-lessicali utilizzati della lingua inglese è ''WordNet'' ([0029]), mentre alcuni dei database equivalenti che trattano l'italiano sono ''BabelNet'' ([0030]), ''ItalWordNet'' ([0031]) e ''MultiWordNet'' ([0032]).
Un elemento importante da considerare è che le prestazioni di disambiguazione per la lingua inglese, impiegando ''WordNet'', risultano corrette tra l'80% e il 90% delle volte ([0028]), percentuali discrete ma non sufficienti per avere la totale garanzia.<div></div>
I fattori che ostacolano la realizzazione di algoritmi di intelligenza artificiale per la disambiguazione sono molteplici:
# Differenze tra dizionari impiegati: i database prima citati si basano su varie fonti che raggruppano semanticamente in maniera diversa i vocaboli, quindi programmi sviluppati con dizionari diversi generalmente hanno performance differenti.
# Complessità della codifica di parte del discorso: per poter disambiguare correttamente un termine è importante riuscire a comprendere correttamente il contesto in cui è inserito, operazione non banale.
# Varianza tra giudici: i supervisori dell'apprendimento degli algoritmi possono avere opinioni diverse, o semplicemente sbagliare, nella valutazione delle disambiguazioni, ciò porta ad algoritmi che hanno comportamenti diversi.
# Impossibilità di applicare la disciplina della ''pragmatica'', ossia la logica del ''buon senso'': per identificare correttamente il senso di alcune parole, ad esempio nella comprensioni di anafore e catafore, è necessario applicare il buon senso.
# Dipendenza del senso delle parole dai contesti: ogni scenario richiede la propria divisione del significato delle parole in sensi rilevanti. In un contesto informatico, ad esempio, il termine "''mouse''" deve essere ricondotto al dispositivo di puntamento, non al cognome del celebre personaggio Disney ''Mickey Mouse''; viceversa dovrà invece avvenire in un contesto di letteratura a fumetti.<div></div>
Laddove la ''WSD'' è una tecnica molto generale e che mira a risolvere un'ambiguità riguardante una qualunque parola, per le finalità del servizio oggetto di questa tesi è sufficiente risolvere le ambiguità dei nomi e dei cognomi.
Uno dei difetti che il servizio presenterebbe adottando un approccio ''WDS'' è legato alla impredicibile formattazione dei documenti, che aggiunge informazione semantica al testo ma introduce complessità nella individuazione automatica delle parti che formano il contesto; un altro difetto dipende dalla vastità del lessico da elaborare, essendo i documenti da trattare forniti dai più disparati utenti, su qualunque genere di argomento e relativi ai più vari ambiti.<div></div>

La strategia che sarà adottata per risolvere la problematica del riconoscimento dei nominativi sarà impostata attraverso un modello ''pattern-based'', impiegando le ''regular expressions'' (''regex''). Esse risultano comunemente usate per effettuare operazioni di ricerca o sostituzione in un testo, di conseguenza se si riesce ad individuare un pattern associato ad un nominativo dato, allora sarà possibile processare il documento ricercando le occorrenze del nominativo e "minimizzarlo" opportunamente.<div></div>

Le ''regular expressions'' risultano particolarmente efficaci poiché, se opportunamente progettate, possono identificare un nominativo indipendentemente dal significato linguistico del contesto in cui è calato, basandosi piuttosto sui singoli caratteri che compongono i lessemi analizzati; permettono, di conseguenza, di effettuare una valutazione estremamente minuziosa, riducendo al minimo le possibilità di errori.<div></div>
Un algoritmo di risoluzione ''pattern-based'' risulta, inoltre, più efficiente nell'esecuzione, in generale, di un algoritmo di intelligenza artificiale; per fornire la risposta il più velocemente possibile ad un utente, fruitore del servizio via web, l'approccio di riconoscimento tramite pattern è il più indicato.<div></div>

====Definizione dei pattern====
Nella progettazione del servizio si adotta, come detto, un approccio ''pattern-based'' per il riconoscimento dei nominativi. In linea di massima è opportuno che vengano riconosciuti più nominativi possibili e allo stesso tempo che la correttezza dell'identificazione di un nominativo sia garantita, quindi bisogna individuare dei pattern non troppo stringenti ma neppure troppo laschi. Per analizzare come i pattern devono essere strutturati si prende come caso di studio un generico nominativo, ad esempio ''Lorenzo Mario Amorosa''. Nel documento esso può comparire esattamente come appena indicato, ma anche in altre plausibili varianti, in cui l'ordine dei termini viene alterato, si pensi ad esempio ad "Amorosa Lorenzo Mario" o "Mario Lorenzo Amorosa", o in altre varianti ancora in cui alcuni nomi non compaiono, come in "Lorenzo Amorosa". Bisogna tuttavia supporre un limite alla variabilità: si osserva infatti che il cognome deve sempre comparire (il solo nome ''Lorenzo'' non è riconducibile a ''Lorenzo Mario Amorosa'') e che esso inoltre deve essere necessariamente anteposto o posposto, ma non interposto, ai nomi (è poco ragionevole ricondurre "Lorenzo Amorosa Mario" a "Lorenzo Mario Amorosa'').<div></div>
Questa prima specifica permette di ricondursi a una soluzione generale, sufficiente nella maggior parte dei casi, ma che non risolve alcune criticità. Un nominativo può, in alcuni documenti, comparire manifestandosi unicamente attraverso il cognome (riferendoci all'esempio precedente, ''Lorenzo Mario Amorosa'' apparirebbe nella forma ''Amorosa''). Sorge qui il problema che molti dei cognomi italiani hanno un significato proprio nel linguaggio comune; ad es., nella frase ''una relazione amorosa è bella'' è errato considerare la parola ''amorosa'' come cognome di un nominativo. Per risolvere questo genere di ambiguità si potrebbe pensare che per stabilire che il termine ''Amorosa'' sia un cognome sia sufficiente verificare che esso inizi con una lettera maiuscola, ma ciò può verificarsi anche perché la parola si trova ad inizio di frase. Inoltre, vari cognomi italiani possono iniziare con una lettera minuscola (''de Angelis'', ''d'Onofrio'', etc.), quindi basare l'identificazione di un cognome sul fatto che la sua prima lettera sia in maiuscolo non è in generale un metodo valido. Volendo in maniera prioritaria garantire il corretto funzionamento del servizio, e quindi attuare le procedure di anonimizzazione solo sui nominativi senza applicarle erroneamente ad altri termini, risulta necessario evitare il trattamento dei nominativi che si manifestano con i soli cognomi. Per via del contesto e dei significati che i cognomi possono assumere, infatti, risulta spesso impossibile distinguerli da parole del linguaggio comune.

Ci si concentra, quindi, nello studio di nominativi composti da un cognome seguito o preceduto da uno o più nomi.<div></div>
Si rappresenta dunque in formato di ''regular expression'' il pattern attualmente ideato. Per semplicità espositiva, si definisce il tag <span style="font-family: monospace;"><nomi></span> come l'insieme delle permutazioni di tutti i nomi del nominativo più l'insieme delle permutazioni di tutti i possibili sottoinsiemi di nomi del nominativo. Considerando il nominativo preso precedentemente come caso di studio, ad esempio, si avrebbe:
<div></div>
<span style="font-family: monospace;"> <nomi> = Lorenzo Mario|Mario Lorenzo|Lorenzo|Mario</span>
<div></div>
Posto inoltre il tag <span style="font-family: monospace;"><cognome></span> ad indicare il cognome contenuto nel nominativo e il tag <span style="font-family: monospace;"><regex></span> ad indicare la ''regular expression'' associata al nominativo, si ottiene:
<div></div>
<span style="font-family: monospace;"> <regex> := <cognome> (<nomi>)|(<nomi>) <cognome></span>
<div></div>
Una osservazione sottile ma di fondamentale importanza per la corretta progettazione delle ''regular expressions'' sta nella piena comprensione della semantica dell'operatore di scelta, espresso con il carattere ''pipe'' ("|"). Un qualunque ''engine'' di elaborazione delle ''regex'', infatti, interrompe la valutazione di una stringa non appena può stabilire se tale stringa fa match o meno con il pattern dato, senza quindi necessariamente valutarlo nella sua interezza, come parimenti avviene nelle valutazioni ''a corto circuito'' delle espressioni logiche nei linguaggi di programmazione. Ogni nominativo avrà a sè associato un pattern che lo rappresenta in più possibili sequenze di caratteri; per effettuare una corretta "minimizzazione" dei dati è necessario che le sequenze contenenti tutti i nomi sia poste per prime, mentre quelle contenenti un singolo nome per ultime.<div></div>
In questa prima formulazione della ''regex'', inoltre, si è posto come separatore unicamente lo spazio bianco, ma alcuni documenti potrebbero contenere dei nominativi i cui termini sono separati da altri caratteri, come ad esempio una virgola nel caso di "Amorosa, Lorenzo Mario". Per poter quindi identificare un nominativo anche in questi casi, si potrebbe considerare un qualunque carattere di interpunzione come possibile separatore dei termini del nominativo.
Adottando questa soluzione si ha però come effetto collaterale che risultano critici i casi in cui nel testo sono presenti dei nominativi soggetti ad omonimia. Si consideri una generica frase contenente una sequenza di nominativi, ad esempio ''Amorosa Lorenzo, Mario Giacomo e Fabio Rossi'', e si supponga che i nominativi da trattare siano ''Amorosa Lorenzo Mario'', ''Mario Giacomo'' (in cui la parola ''Mario'' è il cognome) e ''Fabio Rossi''. Gli ultimi due nominativi compaiono nella frase nella loro forma estesa, mentre il primo compare con il solo nome ''Lorenzo'' (eventualità possibile considerando la definizione del pattern precedentemente data). Considerando la virgola come carattere separatore dei termini del nominativo, la sequenza di parole ''Amorosa Lorenzo, Mario'' sarebbe ricondotta, venendo elaborata per prima, ad ''Amorosa Lorenzo Mario'', mentre rimarrebbe non trattata la parola ''Giacomo'', in quanto il cognome ''Mario'' che gli era associato è stato già identificato come un nome del nominativo ''Amorosa Lorenzo Mario'' ed il termine ''Giacomo'' preso singolarmente non rappresenta un nominativo.<div></div>
Prima di valutare ulteriormente le problematiche relative alle omonimie, si possono scegliere due approcci per risolvere questo specifico caso:
# Si riconduce una sequenza di parole ad un nominativo se e solo se tutti i suoi nomi sono contenuti nella sequenza
# Si considerano come separatori dei termini contenuti nei nominativi solo spazi bianchi, tabulazioni e a capo, non gli altri segni di punteggiatura.
<div></div>
Entrambe le strategie sono valide, in quanto risolvono il problema garantendo la corretta identificazione dei nominativi, ma allo stesso tempo entrambe presentano lo svantaggio di ridurre le sequenze di parole riconducibili a dei nominativi, aumentando le possibilità che alcuni di essi non vengano trattati.
Si consideri nuovamente il nominativo preso come caso di studio ''Amorosa Lorenzo Mario'': applicando la prima strategia, non sarebbe possibile ricondurgli la sequenza ''Amorosa Lorenzo'', mentre applicando il secondo metodo non sarebbe riconducibile la sequenza ''Amorosa, Lorenzo Mario''.
Si decide di attuare la seconda strategia, in quanto è opportuno non imporre vincoli troppo stringenti sui nomi e poiché nella gran parte dei casi i termini dei nominativi nei documenti sono separati tra loro da caratteri quali spazi bianchi, tabulazioni ed a capo.<div></div>
Un altro elemento su cui porre l'attenzione è la possibilità che i documenti da trattare contengano dei nominativi scritti interamente in maiuscolo o minuscolo, di conseguenza è conveniente che le ''regular expressions'' siano progettate ''case-insensitive''.<div></div>
Un ulteriore punto su cui bisogna soffermarsi è la posizione all'interno di un periodo in cui un nominativo può comparire, in particolare si vogliono evitare quei casi critici in cui uno dei termini del nominativo è una sotto-stringa di un'altra parola del testo (si pensi ad ''amorosa'' in ''clamorosa''). Come regola generale si può stabilire che è sempre necessario che un nominativo sia preceduto e seguito da un ''carattere non alfabetico''. Un caso particolare si presenta quando il nominativo è posto ad inizio o a fine documento, situazione in cui quindi esso non è preceduto o non è seguito da alcun carattere: entrambe le posizioni sono da considerare corrette.<div></div>
È opportuno ora definire il concetto di ''carattere non alfabetico'', e ciò si può fare più facilmente ragionando sul problema in logica positiva; infatti risulta più semplice individuare quei caratteri che rappresentano lettere piuttosto che quelli che rappresentano segni di interpunzione ed individuare ogni altro carattere che non può mai comporre una parola.

Inquadrando lo scenario di applicazione del servizio, molto probabilmente l'utente vorrà trattare un documento scritto nella lingua di uno dei paesi dell'Unione Europea, poiché il ''GDPR'' vige nei soli paesi membri dell'Unione.
Si può, quindi, ipotizzare che i documenti trattati possono sì contenere parole e nominativi stranieri, ma che i caratteri contenuti siano appartenenti all'alfabeto latino (''Latin script''), usato in molti stati nel mondo e da tutti i principali stati europei (fatta eccezione per la Grecia ed alcuni stati che scrivono in caratteri cirillici).
Inoltre, testi scritti in altri alfabeti, come esempio il cinese, l'arabo o il cirillico, vengono generalmente traslitterati. Considerare, quindi, ''caratteri non alfabetici'' tutti i caratteri diversi dalle lettere contenute nell'alfabeto latino sarebbe di conseguenza estremamente riduttivo ed inoltre in questo modo non si terrebbe conto delle lettere accentate, molto utilizzate anche nella lingua italiana.
<div></div>(XXXX QUI IMG [0F00])<div></div>
Per risolvere il problema facciamo riferimento alla codifica standard Unicode dell'alfabeto latino ([0022]); in essa è possibile individuare, oltre ai caratteri rappresentanti le lettere nella codifica ''ASCII'' classica, i caratteri rappresentanti le lettere nella codifica standard ''ISO/IEC 8859-1'' ([0023]), encoding orientato principalmente alla rappresentazione delle lingue dell'Europa occidentale.

<div></div>
<center><i>Caratteri latini nei primi due blocchi dello standard Unicode</i></center>
{| class="nounderlines" border="1" cellpadding="2" cellspacing="0" style="border-collapse:collapse"
|----- align="center"
!style="background:#ccf; text-align:center; font-weight: bold;"|U+
!style="text-align:center; font-weight: bold;"|0||style="text-align: center; font-weight: bold;"|1||style="text-align: center; font-weight: bold;"|2||style="text-align: center; font-weight: bold;"|3||style="text-align: center; font-weight: bold;"|4||style="text-align: center; font-weight: bold;"|5||style="text-align: center; font-weight: bold;"|6||style="text-align: center; font-weight: bold;"|7||style="text-align: center; font-weight: bold;"|8||style="text-align: center; font-weight: bold;"|9||style="text-align: center; font-weight: bold;"|A||style="text-align: center; font-weight: bold;"|B||style="text-align: center; font-weight: bold;"|C||style="text-align: center; font-weight: bold;"|D||style="text-align: center; font-weight: bold;"|E||style="text-align: center; font-weight: bold;"|F||style="text-align: center; font-weight: bold;"|Block||style="text-align: center; font-weight: bold;"|#
|-
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0040
|style="background:#fff"|@||A||B||C||D||E||F||G||H||I||J||K||L||M||N||O
|rowspan="4" style="background:#fff" align:"center"|C0 Controls and Basic Latin<br>0000–007F<br>(identical to ASCII)
|rowspan="4" style="background:#fff"|52
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0050
|P||Q||R||S||T||U||V||W||X||Y||Z||style="background:#fff"|[||style="background:#fff"|\||style="background:#fff"|]||style="background:#fff"|^||style="background:#fff"|_
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0060
|style="background:#fff"|`||a||b||c||d||e||f||g||h||i||j||k||l||m||n||o
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0070
|p||q||r||s||t||u||v||w||x||y||z||style="background:#fff"|{||style="background:#fff"||||style="background:#fff"|}||style="background:#fff"|~||style="background:#fff; font-size:75%"|DEL
|-
!colspan="19"|
|----- align="center" style="background:#fff"
!style="background:#fff; text-align:center; font-weight: bold;"|00A0
| ||¡||¢||£||¤||¥||¦||§||¨||©||ª||«||¬||||®||¯
|rowspan="6" style="background:#fff" align="center"|C1 Controls and Latin-1 Supplement<br>0080–00FF<br>(identical to ISO/IEC 8859-1)
|rowspan="6" style="background:#fff"|62
|----- align="center" style="background:#fff"
!style="background:#fff; text-align:center; font-weight: bold;"|00B0
|°||±||²||³||´||µ||¶||·||¸||¹||º||»||¼||½||¾||¿
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00C0
|À||Á||Â||Ã||Ä||Å||Æ||Ç||È||É||Ê||Ë||Ì||Í||Î||Ï
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00D0
|Ð||Ñ||Ò||Ó||Ô||Õ||Ö||style="background:#fff"|×||Ø||Ù||Ú||Û||Ü||Ý||Þ||ß
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00E0
|à||á||â||ã||ä||å||æ||ç||è||é||ê||ë||ì||í||î||ï
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00F0
|ð||ñ||ò||ó||ô||õ||ö||style="background:#fff"|÷||ø||ù||ú||û||ü||ý||þ||ÿ
|---- align="center" style="background:#f66"
|}
<div></div>

I caratteri indicati in rosso nella tabella sono tutti i possibili ''caratteri alfabetici'' che compaiono nei documenti scritti in 29 lingue diverse ([0023]), tra le quali sono presenti l'italiano, l'inglese, lo spagnolo, il tedesco e il portoghese.
Aggiungendo pochi altri caratteri all'insieme dei ''caratteri alfabetici'' appena mostrati, si riesce a rappresentare ogni parola di altre 12 lingue ([0023]), tra cui il francese, l'olandese, il ceco e il turco.<div></div>
I caratteri mostrati in tabella corrispondono ad una parte dei primi due blocchi dello standard Unicode che codificano l'alfabeto latino e, come già accennato in precedenza, essi sono presenti negli standard ''ASCII'' e ''ISO/IEC 8859-1''. I rimanenti ''caratteri alfabetici'', invece, sono presenti in estensioni dello standard Unicode per il ''Latin script''. Queste estensioni sono state realizzate per fornire il massimo supporto a tutte le lingue e contenenti molti simboli ad uso speciale, come ad esempio per la rappresentazione dei fonemi. Si osserva, inoltre, che i ''caratteri alfabetici'' definiti nelle estensioni dello standard Unicode sono presenti anche nella codifica ''ISO/IEC 8859-2'' o nelle versioni successive ([0023]).<div></div>
Definiti i ''caratteri non alfabetici'' come elementi di separazione tra un nominativo ed il testo in cui esso è inserito, occorre definire opportunamente la ''regex'' che al nominativo è associata.

Utili strumenti messi a disposizione dalle ''regular expressions'' sono i gruppi speciali ''lookahead'' e ''lookbehind''. Un pattern di un nominativo deve essere preceduto o seguito da una prestabilita sequenza di caratteri, la quale però non è parte del nominativo. Utilizzando i due costrutti citati, è possibile far sì che nell'elaborazione di una stringa facciano match solamente le parole effettivamente appartenenti al nominativo, non i caratteri che lo delimitano dal resto del testo, e allo stesso tempo che un nominativo faccia match se e solo se preceduto o seguito da una certa sequenza di caratteri. <div></div>
Per esprimere nella sintassi delle ''regex'' un carattere letterale in un qualunque alfabeto si può utilizzare il costrutto ''\p{L}'', che però risulta molto generale e troppo lasco per i requisiti considerati. Si può piuttosto valutare l'impiego del costrutto ''\p{Latin}'', il quale identifica un qualunque carattere alfabetico presente nell'alfabeto latino. Tra i caratteri corrispondenti al costrutto, però, ve ne sono alcuni che per le specifiche del servizio devono essere considerati ''caratteri non alfabetici'', come ad esempio i caratteri dei fonemi, i segni diacritici e gli indicatori ordinali; di conseguenza è necessario individuare una strategia ad hoc per risolvere questa problematica.<div></div>
Per chiarezza espositiva, si definisce il tag <span style="font-family: monospace;"><start></span>, per indicare un qualunque carattere non alfabetico o l'inizio stringa, il tag <span style="font-family: monospace;"><end></span>, per indicare un qualunque carattere non alfabetico o il fine stringa, ed il tag <extra>, per indicare i ''caratteri alfabetici'' non presenti negli standard ''ASCII'' o ''ISO/IEC 8859-1'':<div></div>
<span style="font-family: monospace;">
<extra> := ĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ
<br/>
<start> := (?<=[^A-Za-zÀ-ÖØ-öø-ÿ<extra>]|^)
<br/>
<end> := (?=[^A-Za-zÀ-ÖØ-öø-ÿ<extra>]|$)
</span>
<div></div>
Si osserva che si sono utilizzati i gruppi speciali prima descritti e che si sono inseriti i caratteri dello standard Unicode presentati in precedenza. Si definisce nuovamente la ''regular expression'' associata ad un generico nominativo. Applicando i tag appena definiti, il costrutto ''(?i)'' che rende il pattern ''case-insensitive'' ed il costrutto ''\s'' che rappresenta un carattere qualunque tra i separatori non visibili, ossia ''\r \n \t \f \v'' e lo spazio bianco, si ottiene:<div></div>
<span style="font-family: monospace;">
<regex> := (?i)(<start><cognome>\s+(<nomi>)|(<nomi>)\s+<cognome><end>)
</span>
<div></div>
Si osserva, inoltre, che in questa nuova formulazione della ''regular expression'' i nomi sono da intendersi separati tra loro da ''\s+''.<div></div>
A questo punto si è quasi giunti alla formulazione finale del pattern da associare ad un nominativo, rimangono solo da trattare alcuni casi critici non ancora risolti.<div></div>
Si è già presentato in precedenza il problema legato al fatto che alcuni cognomi possono avere un significato proprio nel lessico comune e che ciò costringeva, quindi, ad abbandonare l'idea di trattare nominativi formati dal solo cognome. Questa problematica di ambiguità si presenta anche con alcuni nomi (si pensi, ad esempio, al nome ''Gioia''). Ciò non rappresenta generalmente un problema, in quanto la coppia nome-cognome che forma il nominativo, presa complessivamente, non è soggetta ad ambiguità. Esistono, però, dei casi in cui questo non è vero. Si prenda in analisi il nominativo ''Gioia Grande'': risulta evidentemente soggetto a rischio di ambiguità. Una soluzione che si può adottare, per risolvere questo caso critico, si basa sull'associazione di un pattern più stringente ai nominativi. In particolare, si osserva che i nomi propri di persona compaiono sempre ed obbligatoriamente, in un documento grammaticalmente corretto, con la prima lettera maiuscola ([0024]). I cognomi, invece, non sono soggetti ad una regola così stringente: un cognome iniziante con una lettera minuscola (come ''de Rosa'') in alcuni casi, ad esempio se posto dopo un punto fermo, può comparire scritto con la prima lettera sia maiuscola che minuscola; naturalmente, in nessuna occorrenza un cognome che inizi con una lettera maiuscola potrà comparire con una minuscola. <div></div>
Occorre quindi ridefinire, alla luce di queste osservazioni, la ''regex'' associata ad un nominativo, poiché precedentemente era stata posta interamente ''case-insensitive''. Nel pattern, in particolare, i nomi dovranno sempre iniziare con una maiuscola, mentre i cognomi avranno questo vincolo solo se nel nominativo compaiono con la prima lettera maiuscola. Si mostra quindi quali sono i tag <span style="font-family: monospace;"><nomi></span> e <span style="font-family: monospace;"><cognome></span> associati a due nominativi, ad esempio ''Gioia Grande'' e ''Antonio de Rosa''. <div></div>
Per ''Gioia Grande'' si ha:<div></div>
<span style="font-family: monospace;"><nomi> = G((?i)ioia)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = G((?i)rande)</span>
<div></div>
Per ''Antonio de Rosa'' si ha:<div></div>
<span style="font-family: monospace;"><nomi> = A((?i)ntonio)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = (?i)de Rosa</span>
<div></div>
Si presenta dunque la definizione finale del tag <span style="font-family: monospace;"><regex></span>. Nella definizione il tag <span style="font-family: monospace;"><nomi></span> è definito il base al numero di nomi del nominativo ed il tag <span style="font-family: monospace;"><cognome></span> è definito in base al carattere iniziale del cognome.<div></div>
<span style="font-family: monospace;">
<regex> := <start><cognome>\s+(<nomi>)|(<nomi>)\s+<cognome><end>
</span>
<div></div>
Vengono inoltre mostrati i valori dei due tag <span style="font-family: monospace;"><nomi></span> e <span style="font-family: monospace;"><cognome></span> per il nominativo preso come caso di studio in fase iniziale, ossia ''Amorosa Lorenzo Mario''. Si ottiene:<div></div>
<span style="font-family: monospace;"><nomi> = L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = A((?i)morosa)</span>
<div></div>
Infine, per completezza, viene mostrata la ''regular expression'', associata a quest'ultimo nominativo, risolvendo tutti i tag che la compongono:
<div></div>
<span style="font-family: monospace;">
<regex> = (?<=[^A-Za-zÀ-ÖØ-öø-ÿĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ]|^)(A((?i)morosa)\s+(L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario))|(L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario))\s+A((?i)morosa))(?=[^A-Za-zÀ-ÖØ-öø-ÿĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ]|$)
</span>
<div></div>

====Gestione delle omonimie====

Nei ragionamenti che hanno portato alla formulazione della ''regular expression'' associata ai nominativi, si è tenuto conto di possibili ambiguità con termini appartenenti al linguaggio comune, risolte con l'introduzione nel pattern di stringhe ''case-sensitive'', e di possibili nominativi posti in sequenza parzialmente omonimi (ossia aventi un nome o il cognome in comune tra loro), gestite con l'imposizione dei soli caratteri separatori non visibili come delimitatori delle parole componenti un nominativo. Per rendere l'analisi completa occorre valutare come ci si debba comportare in altri possibili casi di omonimia. Si osserva, per inciso, che nel pattern individuato nella sezione precedente il tag <span style="font-family: monospace;"><nomi></span> è stato l'unico non definito formalmente. La definizione di tale tag infatti dipende, oltre che dai nomi del nominativo, anche dall'insieme complessivo dei nominativi da trattare presenti nel documento.<div></div>
Il caso più semplice di omonimia, che si verifica quando un solo nome o il solo cognome di un nominativo coincide con un nome o il cognome di un altro (come nel caso di ''Lorenzo Mario Amorosa'' e ''Stefano Amorosa''), risulta già ben gestito dall'attuale formulazione del pattern. Infatti, un riconoscimento è determinato quando almeno un nome e il cognome del nominativo appaiono in sequenza.<div></div>
Il problema si complica quando un nominativo ha due o più componenti in comune con un altro. Si osserva che se l'omonimia riguarda solo i nomi dei nominativi, ciò non risulta problematico, in quanto il cognome, supposto sempre presente nel pattern, funge da elemento di disambiguazione. Si considera da ora, quindi, che i nominativi abbiano il medesimo cognome e si analizzano i casi in cui anche uno o più nomi risultano in comune, attraverso degli esempi:
* Nomi_A = {"Lorenzo", "Mario", "Luca"}; Nomi_B = {"Stefano", "Mario"}
<div></div>(QUI IMG [0F01])<div></div>
In questo caso sono elementi di disambiguazione i nomi ''Lorenzo'' e ''Luca'' per il primo nominativo e ''Stefano'' per il secondo, bisognerà quindi far sì che almeno uno tra tali nomi compaia sempre nelle ''regex'' associate ai nominativi in questione. L'occorrenza ''Mario <cognome>'' rimane ambigua e non può essere trattata.
* Nomi_A = {"Lorenzo", "Mario", "Luca"}; Nomi_B = {"Mario", "Luca"}
<div></div>(QUI IMG [0F02])<div></div>
L'insieme Nomi_B risulta un sottoinsieme di Nomi_A, di conseguenza solo il primo nominativo presenta degli elementi utili per risolvere l'ambiguità. Nel pattern relativo al primo nominativo dovrà essere presente almeno un tra i nomi non in comune, mentre il pattern del secondo nominativo rappresenterà inevitabilmente espressioni ambigue poiché riconducibili all'altro. Le soluzioni possibili sono due: rifiutarsi di effettuare il trattamento del secondo nominativo oppure decretare che esso è riconosciuto se e solo se appare nella sua forma estesa, presentando quindi tutti i nomi. Quest'ultima soluzione è ragionevole e la si sceglie, poiché così si aumentano, per quanto possibile, le sequenze "minimizzabili", e viene inoltre messo in conto di informare l'utente opportunamente sulla gestione di questo genere di omonimia per rendere le operazioni trasparenti.
* Nomi_A = Nomi_B = {"Lorenzo", "Mario", "Luca"}
<div></div>(QUI IMG [0F03])<div></div>
Qualora l'insieme dei nomi dei due nominativi sia identico risulta impossibile distinguerli e non possono in alcun modo essere trattati, poiché l'ordine con cui compaiono i nomi di un nominativo non rappresenta un elemento di disambiguità. I dati appartenenti a persone completamente omonime contenuti in uno stesso documento, quindi, non sono "minimizzabili" distintamente.<div></div>
Si osserva che è di fondamentale importanza che i documenti che gli utenti forniscono siano grammaticalmente corretti, in quanto un errato uso dei segni di interpunzione può rendere impossibile l'applicazione delle ''regular expression''. Si prenda ad esempio una sequenza anomala di caratteri in cui non è corretto l'uso delle virgole, come "''Amorosa Mario Rossi Giacomo''": supponendo che nel documento si vogliano trattare i nominativi ''Amorosa Mario'', ''Rossi Mario'' e ''Rossi Giacomo'', risulta impossibile identificare quali tra questi siano rappresentatati nella sequenza.<div></div>
In conclusione, risultano quindi individuate le strategie che permettono di formulare ''regular expressions'' anche per i nominativi soggetti ad omonimia.

====Formattazione dei documenti====

I documenti prodotti in enti ed organizzazioni presentano generalmente formattazioni e non sono puramente testuali. Si vuole qui considerare quale debbano essere le interpretazioni più adatte da dare agli elementi grafici per rendere sempre efficace il riconoscimento dei nominativi. In particolare, quindi, non si tratteranno gli elementi di punteggiatura, come parentesi o virgolette, poiché già compresi nelle ''regex'', bensì tutti gli elementi che in un pattern composto da caratteri non sono espressi. Si inizia dunque la rassegna:
* Elementi di formattazione del testo
I font, la dimensione dei caratteri, il grassetto, il corsivo, l'evidenziazione e tutti i possibili elementi di modifica della apparizione grafica del testo non alterano il significato dei lessemi coinvolti. Se il cognome di un nominativo è posto in grassetto ed il nome no, ad esempio, la coppia nome-cognome rappresenta sempre il nominativo iniziale; lo stesso vale per gli altri elementi citati.
* Aree di comparizione del testo
In genere ogni documento è formato da più sezioni, ha un corpo principale ed eventuali titoli, note a piè pagina, intestazioni ed altre possibili aree. Il trattamento di "minimizzazione", secondo il ''GDPR'', deve essere effettuato al documento in ogni sua parte, ma ogni sezione deve essere elaborata in maniera indipendente dalle altre sezioni in quanto rappresenta un blocco logico a sé. Ciò significa che, ad esempio, bisogna individuare eventuali nominativi presenti nel titolo, ma non bisogna considerare nominativo una sequenza di parole che è posta in parte nel titolo e in parte nel primo paragrafo del testo.
* Elementi blocco
Gli elementi blocco, come ad esempio le immagini, possono causare un'interruzione netta in un paragrafo, suddividendolo quindi in più blocchi logici, che devono essere analizzati separatamente; tuttavia nel caso in cui questi elementi siano posti ''fluttuanti'', ossia ancorati ai bordi della pagina, il testo scorre in un unico flusso e forma quindi un unico blocco logico.
* Divisione in sillabe
Un problema rilevante nella formattazione del documento è che spesso, per esigenze estetiche, contiene delle parole divise in sillabe poste su righe diverse e separate da un trattino. Ovviamente se un nome va a capo a fine linea non perde il suo significato semantico, bisognerà quindi continuare a riconoscerlo.
* Tabelle
Molti documenti, specialmente quelli contenenti ingenti quantità di nominativi, possono essere strutturati in forma tabellare. Trascurando una trattazione per esteso delle modalità con cui i nominativi potrebbero comparire nelle tabelle, si considera esclusivamente il caso di gran lunga più ricorrente. In genere, infatti, in una tabella contenente dei nominativi, essi sono presenti nella stessa colonna o in colonne contigue: l'una contenente i nomi, l'altra il cognome, o viceversa. Senza basarsi sull'intestazione delle colonne, si può valutare se il contenuto di due celle adiacenti poste su di una stessa riga faccia match con il pattern di un nominativo, ed in caso ciò accada si può affermare la coppia di celle individuata rappresenta un nominativo.<div></div>
Si osserva che si sono fornite solamente le interpretazioni più plausibili e comuni a questi elementi grafici e non si è ideato alcun particolare algoritmo per la loro elaborazione. L'espressione di tali strutture, infatti, è fortemente determinata dal formato in cui il documento è redatto. Si rimanda, quindi, ai capitoli successivi per specificazioni ulteriori della soluzione. Occorre notare, infine, che gli elementi di formattazione non sono descritti da stringhe nel formato delle ''regular expressions'': bisognerà quindi integrare gli elementi presentati in questa sezione con l'approccio ''pattern-based'' adottato.

===Analisi dell'usabilità===

====Elenco dei nominativi da trattare esplicitamente espressi come dati in input====

In questo caso, per usufruire del servizio, l'utente deve fornire un documento contenente una serie di nominativi da trattare. Una garanzia della corretta elaborazione del documento si ha richiedendo all'utente stesso quali siano i nominativi da trattare: in questo modo potranno essere "minimizzati" i dati (cioè i nominativi) di tutte e sole le persone espressamente richieste. In molti plausibili scenari, infatti, è necessario anonimizzare solo alcuni dei nominativi presenti nel documento; ad esempio in un atto giudiziario serve anonimizzare le parti in causa ma non i magistrati.

Questa configurazione del servizio permette quindi all'utente di avere il massimo controllo possibile del risultato. Tuttavia questo approccio è poco pratico nel caso in cui i documenti da trattare contengano grandi quantità di nominativi diversi e, magari, l'utente che ne richiede il trattamento non li conosce; si pensi ad esempio a lunghe graduatorie di concorsi o altro. Si osserva inoltre che anche per pochi nominativi l'usabilità può degradare, se l'inserimento viene fatto con estemporanea digitazione, esposta anche al rischio di possibili errori di battitura, con conseguenti noiose ripetizioni delle operazioni.

Si osserva, infine, che il sistema progettato è sufficientemente robusto nel trattare i nominativi in input espressi da un utente che ha digitato caratteri maiuscoli o minuscoli violando le convenzioni grammaticali. Supposto che il documento trattato debba essere grammaticalmente corretto, infatti, si ha la garanzia che i nomi ivi presenti comincino con una maiuscola; è sufficiente, quindi, forzare una conversione ''to-upper-case'' dei nomi inseriti dall'utente e le ''regex'' progettate funzionano correttamente. Un discorso a parte va fatto per i cognomi inseriti dall'utente, in quanto essi possono comparire con la prima lettera sia maiuscola che minuscola. L'inserimento di un cognome iniziante con una minuscola non crea grossi problemi, in quanto in tal caso la ''regex'' risultante sarebbe totalmente ''case-insensitive'' per il cognome, mentre l'aggiunta di un cognome cominciante con una maiuscola determina una ''regex'' ''case-insensitive'' per la prima lettera del cognome; qualora quindi un utente inserisse un nominativo tutto in maiuscolo, le occorrenze del cognome, presenti nel documento, inizianti con una lettera minuscola non verrebbero riconosciute.
Per le altre lettere dopo la prima, sia per i nomi che per i cognomi, il pattern è stato progettato ''case-insensitive'', quindi non emergono problemi. <div></div>
In sintesi, il rischio che vengano introdotte delle ambiguità lessicali, incaricando l'utente dell'inserimento dei nominativi, è piuttosto basso ed il controllo che si ha sui nominativi è il massimo desiderabile, mentre i requisiti di usabilità risultano penalizzati.

====Elenco dei nominativi da trattare dedotti automaticamente da un dizionario====

Se si desidera privilegiare la tematica dell'usabilità nella progettazione del servizio, risulta necessario individuare delle strategie che semplifichino il più possibile i compiti che devono essere svolti dall'utente. L'unica operazione che inevitabilmente resta a suo carico è l'upload del documento da trattare; non è infatti necessario richiedergli l'elencazione dei nominativi dei nominativi da trattare, in quanto questi possono essere dedotti automaticamente impiegando dei dizionari, dei quali va quindi valutato il contenuto e le modalità di utilizzo. <div></div>

Si scarta subito l'ipotesi di dedurre automaticamente i nominativi basandosi unicamente sul fatto che le iniziali di nomi e cognomi siano maiuscole; come già argomentato infatti l'uso delle lettere maiuscole non è limitato solo a questi usi e, inoltre, non si può avere la certezza che un cognome inizi con una maiuscola.

Sono disponibili fortunatamente alcuni dizionari di nomi ed altri di cognomi, in diverse lingue; si fa qui riferimento a quelli di "Data World" (un'azienda focalizzata sulla raccolta, produzione e pubblicazione di dataset: https://data.world) ([0037]).

Si inizia l'analisi inquadrando le dimensioni che un dizionario contenente nomi o cognomi avrebbe. Risalta subito all'occhio la differenza tra il numero di termini contenuti nei due casi: facendo riferimento ai soli nomi e cognomi italiani, risultano esistenti circa 350.000 cognomi ([0036]) e circa 9.000 nomi, dei quale circa 5.000 maschili e circa 4.000 femminili ([0037]); il numero dei cognomi è quindi quasi 40 volte più grande del numero dei nomi.<div></div>
Si ipotizza, per chiarire le idee, di applicare questi dizionari in uno scenario reale, in cui, ad esempio, si vuole trattare un documento di 10 pagine contenente 5.000 parole. Si trascurano inoltre i meccanismi che permettono di ricondurre un nome od un cognome ad un nominativo per concentrarsi unicamente sul numero di confronti necessari da effettuare nell'elaborazione. Nel peggiore dei casi possibili, ossia quando nessuna parola del documento compare tra i termini del dizionari, e dove occorre quindi confrontare ogni singola parola del documento con tutti i termini del dizionario, per semplice moltiplicazione si ottiene che l'impiego di un dizionario di nomi darebbe luogo a 45.000.000 confronti, mentre un dizionario di cognomi ben a 1.750.000.000 confronti. Se invece le parole nel documento fossero 50.000 si avrebbero 450.000.000 di confronti nel primo caso e 10.750.000.000 nel secondo. In sintesi, sebbene il rapporto tra il numero di confronti nei due casi rimanga sempre costante (circa 1:40) indipendentemente dalla lunghezza del documento, la differenza tra il numero di confronti cresce proporzionalmente al numero di parole che vengono sottoposte all'elaborazione. Per quantificare, infine, attraverso un unità di tempo, la differenza esistente tra l'impiego delle due diverse tipologie di dizionario, si realizza un semplice programma java, di cui si riporta qui sotto il contenuto del metodo principale, che realizza i confronti necessari attraverso l'uso di ''regular expression'':
<div></div>
<div style="font-family: monospace;">
final String regex = "\bLorenzo\b";<br/>
final String string = ... //testo di prova<br/>
<br/>
final Pattern pattern = Pattern.compile(regex, Pattern.MULTILINE);<br/>
final Matcher matcher = pattern.matcher(string);<br/>
int start, total;
<br/>
start = System.currentTimeMillis();
while (matcher.find()) {
System.out.println("Full match: " + matcher.group(0));
for (int i = 1; i <= matcher.groupCount(); i++) {
System.out.println("Group " + i + ": " + matcher.group(i));
}
} <br/>
total = System.currentTimeMillis() - start;
System.out.println("Total: " + total + " ms");
</div>
<div></div>
Eseguendo il test più volte, inserendo fino a 10 occorrenze della parola "Lorenzo" nel testo, si ha un tempo di elaborazione medio di circa 3 ms, con prestazioni di picco di 2 ms, ottenibili con poche occorrenze del nome presenti, e tempo di attesa massimo di 6 ms, dovuto alla presenza invece a una presenza più frequente del nome nel testo.
Questo fenomeno si comprende meglio ricordando che, come spiegato nel capitolo precedente, le ''regular expressions'' ottimizzano la ricerca, considerano le stringhe del testo trattato solo finché necessario, ossia fino a quando non vi è certezza che esse corrispondano o non corrispondano ad un match. Ogni volta che nel testo si presenta una parola che inizia con una lettera diversa dalla 'L' di "Lorenzo", la ricerca procede direttamente con la valutazione della parola successiva, ignorando i rimanenti caratteri della parola.

Risulta, invece, più onerosa la verifica della corrispondenza tra una stringa ed il pattern desiderato, poiché in questo caso vanno elaborati tutti i caratteri della parola. Come caso limite, si è posta come stringa da elaborare la sequenza di caratteri "Lorenzo " ripetuta 500 volte: il tempo di esecuzione medio del programma risultante, a parità di piattaforma, è stato di circa 25 ms.

Un'altra diretta conseguenza di questo meccanismo di confronto è che all'aumentare del numero di parole nel documento non corrisponde un eccessivo aumento del tempo di esecuzione: considerando un documento di 5000 parole, con 0 occorrenze del nome "Lorenzo" il tempo di esecuzione medio risulta di 9 ms, con 10 occorrenze di 10 ms, con 100 occorrenze di 15 ms.

Occorre precisare, prima di formulare ulteriori ragionamenti, che in documento di 5.000 parole potranno essere presenti al più 2500 coppie nome-cognome; in un dizionario con più di 2.500 termini almeno uno di questi non contribuirà nell'individuazione di un nominativo. Se poi sono presenti altre parole oltre ai nominativi nel documento, la percentuale di nomi che presenterà 0 occorrenze crescerà di conseguenza. Ad ogni modo, si sceglie di sviluppare i ragionamenti considerando necessario il tempo medio di 10 ms per individuare le occorrenze di un termine di un dizionario in un documento di 5.000 parole; questo tempo è sicuramente maggiore rispetto al caso reale, ma valutando per eccesso questo valore è possibile trascurare il tempo impiegato nelle altre operazioni di routine a supporto dell'algoritmo di ricerca.

Ritornando all'esempio di partenza, considerando quindi necessari 10 ms per individuare le occorrenze di un termine di un dizionario in un documento di 5.000 parole, risulta che l'identificazione di tutti i cognomi contenuti nel testo richieda circa 3.500 secondi, (quasi un'ora!), mentre l'individuazione dei nomi "solo" 90 secondi.
I tempi di attesa che l'utente dovrebbe aspettare sono estremamente elevati e irragionevoli, specialmente se calati nel contesto nelle ''web application''. Come primo espediente per ovviare al problema si decide di abbandonare completamente l'idea di impiegare un dizionario di cognomi, in quanto, seppur si individuassero delle soluzioni in grado di effettuare il riconoscimento di tutte le occorrenze di un termine in un documento indipendentemente dalla lunghezza in solo 1 ms (irreale), sarebbero comunque necessari 3 minuti e 50 secondi per l'elaborazione. Non verranno quindi neppure trattate possibili soluzioni che prevedono l'applicazione di entrambi i dizionari.

I 90 secondi richiesti dal dizionario di nomi, invece, risultano anch'essi eccessivi, ma attraverso opportune valutazioni si possono individuare delle strategie che consentono la minimizzazione del tempo necessario all'elaborazione dei documenti. Tali metodi di ottimizzazione saranno trattati in un successivo capitolo, mentre ora ci si continua a concentrare sulle modalità di impiego del dizionario.

Per inciso, si osserva che i problemi di efficienza sono strettamente legati al riconoscimento automatico dei nominativi, in quanto in questo caso devono essere applicate quasi una decina di migliaia di ''regex'' diverse; nel caso in cui i nominativi da elaborare e le ''regex'' a loro associate siano noti, si ha a che fare con un numero esiguo di pattern da trattare e l'esecuzione del programma risulta infinitamente più rapida.<div></div>

Per migliorare l'efficacia del servizio sarebbe opportuno introdurre nel dizionario anche nomi stranieri, sempre più diffusi in una società sempre più globalizzata. Il tempo di esecuzione medio del riconoscimento, già critico, crescerebbe ulteriormente: si decide allora di introdurre nel dizionario i soli nomi inglesi, in totale quasi 5500 ([0037]). Considerando sempre un tempo medio di esecuzione di 10 ms per nome, con un dizionario di circa 14.500 termini si avrebbe un tempo di esecuzione medio complessivo di 145 secondi, ossia pari a 2 minuti e 25 secondi, e risulta ancora possibile effettuare alcune ottimizzazioni che lo riducono ad un livello accettabile.

Una volta individuati i nomi contenuti nel documento occorre stabilire se essi fanno parte di un nominativo, progettando un'opportuna ''regular expression''. È importante notare che per conseguire questo scopo bisogna individuare la soluzione più efficiente possibile.

Un nominativo, come già ripetuto più volte, è composto da uno o più nomi e da un cognome. Individuato un nome, la priorità che si ha è verificare se accanto ad esso sia presente un cognome. Finora i cognomi sono stati supposti non regolamentati da alcun pattern specifico, ma è necessario formularne almeno uno per consentirne il riconoscimento automatico. È ragionevole supporre che un cognome sia formato da massimo due parole, separate da spazio o apostrofo, sempre inizianti entrambe con una maiuscola, fatta eccezione per la prima parola laddove essa sia una preposizione semplice o articolata oppure un articolo, tenendo conto dei possibili troncamenti, come <i>d'</i> e <i>dell'</i>. Inoltre per verificare se un termine adiacente al nome trovato rappresenti un nome si evita di impiegare nuovamente il dizionario per non gravare ulteriormente sul tempo di esecuzione. Inoltre, si nota che avendo supposto un cognome composto da massimo due parole inizianti con una lettera maiuscola, un altro nome, oltre quello trovato dal dizionario, viene già automaticamente riconosciuto qualora il cognome sia composto da una sola parola. Rinunciando ad individuare nominativi composti da tre nomi o più, si formula una ''regular expression'' per il riconoscimento automatico in seguito al identificazione di un nome, qui indicato con il tag <span style="font-family: monospace;"><nome></span>, supponendo il cognome come precedentemente indicato e ipotizzando la presenza di un ulteriore nominativo.
<div></div>
<div style="font-family: monospace;">
<prep> := d((a|e)(l(l[aeo]?)?|i|gli?)?|i)?|(ne|a|su)(l(l[aeo]?)?|i|gli)?|l[aeo]?|co[iln]?|i[ln]?|gli|per

<cognome> := (([A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]*|<prep>)('|\s))?[A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]+

<second_name> := [A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]+

<regex> := (<second_name>\s)?(<nome>)\s<cognome>|<cognome>\s(<nome>)(\s<second_name>)?
</div>
<div></div>
Nella scrittura della ''regex'' si è prestata particolare attenzione all'utilizzo della simbologia per rendere l'espressione il più performante possibile, attraverso il massimo sfruttamento dei cortocircuiti logici e l'opportuno ordinamento dei caratteri (sono stati anteposti i caratteri comuni a più preposizioni od articoli). Inoltre, per alleggerire la ''regex'' si è rinunciato all'utilizzo dei caratteri dell'alfabeto latino non appartenenti ai primi due blocchi Unicode.
<div></div>
È mostrata in figura la corretta elaborazione di 57 possibili casi di cognomi diversi
<div></div>(QUI IMG [0F04])<div></div>
Si osserva tuttavia che in alcune circostanze, come nella frase "''di Amorosa Lorenzo non si hanno notizie''", accade che un parola ("''di''" in questo caso), non sia parte del cognome ma il programma non è in grado di riconoscerlo. Questa ambiguità è fortemente dipendente dal contesto e non è possibile trattarla senza significativi degradi delle performance; quindi è necessario rinunciare a trattarla, accettando riconoscimenti erronei. In altre situazioni, invece, dove magari si sta elaborando la stringa contenente il nominativo ''Mario Lorenzo'', risulta impossibile determinare quale tra i due termini sia il nome e quale il cognome; cioè significa che l'unico trattamento di "minimizzazione" automatico che risulta ragionevole applicare è la sostituzione del nominativo con uno pseudonimo, non il troncamento o l'alterazione dei nomi.
In conclusione, con il riconoscimento automatico dei nominativi si migliora complessivamente l'usabilità del servizio, in quanto l'utente non deve digitare i nominativi, ma la latenza introdotta è notevole, si è soggetti a rischi di ambiguità e non è in alcun modo esprimibile la preferenza su quali nominativi si desidera "minimizzare" o meno. La soluzione così ideata non risulta quindi adeguata.

====Soluzione ibrida adottata====
Entrambe le tipologie di riconoscimento prima individuate hanno significativi problemi, si cerca quindi di sintetizzare una soluzione in grado di trarre i vantaggi dell'una e dell'altra. Risulta efficace, in particolare, che il documento venga inizialmente trattato tramite dizionari, evitando all'utente l'onere di specificare i nominativi, e che in seguito venga lasciata all'utente la possibilità di intervenire.
Infatti, esso potrebbe voler esprimere delle preferenze su quali nominativi debbano essere trattati tra quelli individuati e gestire gli eventuali errori di riconoscimento dovuti a richieste di trattamento di nominativi aventi un nome non presente nel dizionario o anche dovuti a casi di ambiguità lessicale già presentati.

Una volta inserito il documento e terminata l'elaborazione tramite il dizionario, l'utente può sia richiedere l'immediato download del file ed effettuare le operazioni prima definite, attraverso un'opportuna interfaccia. Per fornire il supporto alle esigenze più disparate, si prevede la possibilità di:
# eseguire download del file trattato unicamente con il dizionario
# ripetere la "minimizzazione" del documento, specificando:
## nuovi nominativi
## quali nominativi tra quelli precedentemente individuati ''non'' si vogliono trattare
## quale parola/e dei nominativi individuati rappresenta il cognome (in tal caso, si possono utilizzare altri metodi, oltre alla sostituzione con pseudonimo, per il trattamento)
## quale parola/e dei nominativi individuati non compone il nominativo (situazione che si verifica quando ci si imbatte in una ambiguità).

Senza soffermarsi in questo momento sull'intera sequenza concreta di interazioni tra utente e servizio, si osserva che l'unico vincolo non funzionale da valutare resta il tempo medio di attesa dell'utente. L'usabilità complessiva è molto buona ed i vincoli funzionali sono soddisfatti.

===Scelta dei formati da trattare===

Una considerazione intuitiva, ed una buona prassi, è che un documento contenente dati personali sia pseudonimizzato o anonimizzato quanto prima possibile e cioè quando è ancora solo nelle mani del suo autore: questo approccio scongiura che informazioni sensibili e dati personali in chiaro ''sfuggano'' in rete.
Si può per questo ragionevolmente ipotizzare che i naturali destinatari del servizio siano gli stessi autori (creatori) che redigono il documento. Nello scenario tipico di utilizzo, infatti, il fruitore del servizio procederà al trattamento dei dati non appena avrà finito di scrivere il documento del quale, essendone autore, potrà scegliere il formato. Si osserva che potrebbe accadere che il documento sia redatto da terzi: in tal caso l'utente che richiede il trattamento può scegliere il formato in maniera indiretta concordandolo con il redattore. Avendo quindi l'utente la possibilità di stabilire il formato del proprio documento, risulta ragionevole progettare un servizio che lavori su un solo formato.
A questo punto occorre individuare quale sia il formato che maggiormente si presta alle finalità del servizio.<div></div>
Una possibilità è quella di richiedere all'utente di inserire come documento da trattare un semplice file di testo in formato ''txt'': in questo modo ci sarebbe il grande vantaggio di trattare file molto semplici, riducendo così al minimo la complessità realizzativa, e inoltre si avrebbe l'indipendenza dagli editor di testo utilizzati, in quanto tutti supportano i file in formato ''txt''.
Risulta tuttavia sconveniente utilizzare questo formato, poiché non ha alcuna capacità espressiva per gestire elementi complessi come tabelle, modifiche allo stile del testo e così via.
Bisogna quindi optare per un formato in grado di gestire questi elementi, al costo di aumentare la complessità della progettazione, ricordando sempre che è necessario allo stesso tempo che tale formato sia supportato da tutti i principali editor di testo.<div></div>
Con facilità è possibile individuare quali sono i formati di testo più comuni oltre al ''txt'': ''doc'', ''docx'', ''odt'', ''pdf'', ''pages'', ''rtf'', ''tex''. Si passa ora dunque a valutare quale tra questi formati potrebbe meglio soddisfare i requisiti prima enunciati.
Facendo una cernita iniziale sulla base delle finalità per le quali un formato è utilizzato, si può immediatamente escludere ''tex'', che trova impiego principalmente in ambito scientifico e matematico. In questo settore, infatti, non è richiesta generalmente l'applicazione delle procedura di trattamento dei dati. <div></div>
Si può inoltre abbandonare l'idea di trattare documenti con estensione ''pages'', formato proprietario di Apple, poiché utilizzati esclusivamente dall'omonimo editor di testo anch'esso proprietario, e i documenti con estensione ''rtf'', acronimo di ''Rich Text Format'', formato proprietario di Microsoft che supporta una formattazione avanzata, poiché, pur gestito da vari editor, è un formato decisamente datato (ultima versione 1.9.1 risalente a marzo 2008 ([0009])). <div></div>
Si esclude inoltre il formato ''pdf'' per motivi di usabilità: molti editor, infatti, consentono di esportare un documento in questo formato ma non permettono di importarlo. Un utente dopo aver effettuato l'anonimizzazione di un documento non può quindi proseguire modificandolo ulteriormente. Il ''Portable Document Format'', infatti, è ideato per realizzare dei documenti destinati alla sola lettura.
L'ultima esclusione, piuttosto immediata da effettuare, riguarda il formato ''doc'', binario e proprietario di Microsoft. Esso infatti risulta, a partire dal 2006, soppiantato dal formato ''docx'', sempre proprietario di Microsoft.

Si giunge infine a valutare quale tra gli ultimi due possibili formati rimanenti, ossia ''docx'' e ''odt'', si presta meglio alle finalità del servizio. In via preliminare si osserva che entrambi i formati possiedono ottime capacità espressive, hanno una struttura interna di simile complessità e sono entrambi supportati dai principali editor di testo. È necessario quindi effettuare delle analisi più approfondite per poter sceglierne uno tra i due.
La struttura del formato ''docx'', sviluppato da Microsoft e formalmente denominato ''Office Open XML Document (OOXML Document)'', è costituita da un file compresso .zip contenente un insieme di file ''XML''. Il formato ''OOXML'' permette la rappresentazione, oltre che di documenti testuali, anche di fogli elettronici (formato ''OOXML 'Workbook'', noto anche come ''xslx'') e di presentazioni (formato ''OOXML Presentation'', noto anche come ''pptx'') ([0008], [0013]).
Il formato inoltre è stato inizialmente standardizzato nel 2006 dall'<i>ECMA</i> (come ''ECMA-376'') e successivamente nel 2008 dall'<i>ISO</i> e dall'<i>IEC</i> (come ''ISO/IEC 29500'') in una versione ''transitional'', retrocompatibile con alcune versioni precedenti del formato contenenti elementi deprecati, e in una versione ''strict'', dove tali elementi non sono ammessi. I due standard sono stati poi successivamente aggiornati e sono tutt'ora oggetto di revisioni ([0002]).

Anche la struttura del formato open source ''odt'', sviluppato dall'<i>OASIS</i> e formalmente denominato ''OpenDocument Text'', è basata su uno zip contenente un insieme di file ''XML''. Inoltre, il formato ''OpenDocument Format (ODF)'' permette di trattare fogli elettronici (formato ''OpenDocument Spreadsheet'', noto anche come ''ods'') e presentazioni (formato ''OpenDocument Presentation'', noto anche come ''odp'') ([0007]). Anche ''OpenDocument Text'' è stato standardizzato, in particolare dall'<i>OASIS</i> stesso nel 2005 e dall'<i>ISO/IEC</i> nel 2006, ed è soggetto a revisioni e aggiornamenti ([0003]).

In sintesi, basandosi sulla struttura dei documenti e sulla standardizzazione dei formati, non è ancora possibile individuare quale sia il formato migliore. L'unico elemento che potrebbe portare punti a favore del formato ''odt'' è che esso, a differenza del formato ''docx'', è aperto, tuttavia, essendo le specifiche di entrambi i formati pubbliche, ciò non rappresenta un fattore determinante nell'elezione del formato.
Entrambi i formati, inoltre, sono largamente supportati dai word processors.

Le seguenti tabelle riepilogano il supporto all'uno ed all'altro formato dei ''word-processors'' più usati, ossia ''Microsoft Office Word'', ''LibreOffice Writer'', ''OpenOffice Writer'' e ''Pages''.
Le tabelle sono tratte da wikipedia ([0000], [0001], [0006]). <div></div>

<center><i>Supporto fornito dagli editor di testo al formato docx</i></center>
{| class="wikitable"
|-
! !! Microsoft Office Word !! LibreOffice Writer !! OpenOffice Writer !! Pages
|-
! Version
|| 2013, 2011 for Mac || All versions || 3.0 || '08
|-
! Operating systems
|| Windows, Mac OS X || Windows, OS X, Linux, Unix, Android || Windows, Linux, Unix, Mac OS X || Mac OS X
|-
! Office suite
|| Microsoft Office || || OpenOffice.org || iWork
|-
! Developer
|| Microsoft || The Document Foundation || Apache OpenOffice || Apple Inc.
|-
! License
|| proprietary || MPL || LGPL || proprietary
|-
! ECMA-376
|| yes || yes || yes || yes
|-
! ISO/IEC 29500:2008
|| yes || yes || ||
|-
! Notes
|| || || Import only ||
|}

<div></div>
<center><i>Supporto fornito dagli editor di testo al formato odt</i></center>
{| class="wikitable"
|-
! !! Microsoft Office Word !! LibreOffice Writer !! OpenOffice Writer
|-
! Version
|| 2007 SP2 || 4.0.3 || 3.0.0
|-
! Operating systems
|| Windows || Unix-based systems, Mac OS X, Solaris || Windows, Linux, Unix-based systems, Mac OS X, Solaris
|-
! Office suite
|| Microsoft Office || || OpenOffice.org
|-
! Developer
|| Microsoft || The Document Foundation || Apache OpenOffice
|-
! License
|| Proprietary || MPL || LGPL
|-
! ISO/IEC 26300:2006
|| yes || yes || yes
|-
! Notes
|| some limitations || Multiple ODF versions supported (ISO/ODF 1.0/1.1/1.2/1.2 Extended) || adjustable ODF version (ISO/ODF 1.2)
|}
<div></div>

Si possono effettuare le seguenti osservazioni:
* ''Microsoft Office Word'' è, in ambiente Microsoft, il word processor maggiormente usato; è molto usato anche in ambiente Apple Mac. Esso offre il pieno supporto al formato ''OOXML Document''; solo parzialmente invece gestisce il formato ''OpenDocument Text'': il processamento di file con estensione ''odt'' con questo editor comporta la perdita di alcune informazioni secondarie.
* ''LibreOffice Writer'', l'editor open source maggiormente utilizzato, supporta pienamente entrambi formati. Nato con lo scopo di gestire i file con formato ''OpenDocument Text'', attualmente supporta completamente anche il formato ''OOXML Document''.
* ''OpenOffice Writer'', un altro degli editor di testo tra i più utilizzati, supporta pienamente ''odt'', mentre è solo in grado di importare i file con estensione ''docx''.
* ''Pages'', il word process installato a default sui Mac della Apple e, di conseguenza anche maggiormente usato su questi dispositivi, non offre supporto al formato ''odt'', ma elabora correttamente i documenti con estensione ''docx'' ([0005],[0004]). <div></div>
Queste osservazioni evidenziano che quindi è impossibile adottare un formato supportato da tutti gli editor; la scelta va allora indirizzata verso quello maggiormente supportato dai word processor più popolari.
Per avere un'indicazione di ''popolarità'', e quindi per poter comprendere meglio quali tra gli editor prima citati siano i più usati, si può fare un'analisi, tramite motori di ricerca, di quanti file con una certa estensione siano presenti in rete.
È possibile, ad esempio, ricercare su Google i file che contengono nel proprio nome una determinata sequenza di caratteri o aventi una certa estensione (''filetype''). Sono qui presentati i risultati delle interrogazioni riguardo ai file aventi formato ''docx'', ''doc'' e ''odt'' ed il cui nome contiene uno dei caratteri, fra i più frequenti, "1" o "a" o "e". L'investigazione è stata effettuata inserendo nella barra di ricerca di Google le stringhe ''1 filetype:docx'', ''a filetype:docx'' e così via.

{| class="wikitable"
|-
! Formato cercato !! Documenti con "1" nel nome !! Documenti con "a" nel nome !! Documenti con "e" nel nome
|-
| docx || 16.900.000 || 12.800.000 || 8.730.000
|-
| odt || 736.000 || 667.000 || 507.000
|-
| doc || 32.300.000 || 26.300.000 || 21.500.000
|}

Effettivamente il formato più diffuso è il ''doc''; tuttavia esso è supportato per retro-compatibilità anche dagli editor che supportano formati ''OOXML'', con i quali non si ha difficoltà nel convertire i documenti dal formato ''doc'' al ''docx''. In conclusione, quale che sia l'editor più diffuso, è ragionevole adottare il formato ''OOXML Document'' per le finalità del servizio, in quanto molto diffuso, ben supportato dagli editor e avente ottime capacità espressive. Di conseguenza i documenti che saranno elaborati dovranno essere forniti dall'utente in tale formato. In successive sezioni verrà approfondita la struttura dei documenti ''OOXML''.

===Privacy by design===

L'Art. 25 del ''GDPR'', con i Considerando 75 e 78, ha per titolo e per oggetto la "protezione dei dati fin dalla progettazione e protezione per impostazione predefinita" ([0035]), perfettamente in linea con i concetti di "minimizzazione", già richiamati.<div></div>
Il senso dell'Art. 25 viene spesso sintetizzato con l'espressione "''PbD - privacy by design, privacy by default''" ([0035]). Il principio fissato nell'Art. 25 dovrà sempre più essere tenuto ben presente nell'ambito dell'ingegneria del software, in quanto impone di adottare nuove cautele nella realizzazione delle applicazioni software.<div></div>
Del principio ''PbD'' si è ben tenuto conto nella progettazione descritta in questa tesi. In particolare, relativamente alla ''privacy by design'', si è fatto in modo che nessun dato personale permanga registrato sul sistema di esecuzione, o altrove, al termine dell'applicazione. Anche laddove l'applicazione termini in modo anomale non vi sono strutture dati superstiti, che restano memorizzate sul sistema.<div></div>
Marginale in questa tesi è la nozione di ''privacy by default'', giacché l'applicazione non offre all'utente alcuna opzione che possa indurlo in errore ed acconsentire a trattamenti dei dati personali, oltre quello realizzato dall'applicazione.<div></div>
È utile osservare quanto sia importante esprimere queste impostazioni di progettazione fra le condizioni d'uso presentate all'utente: esse costituiscono uno dei presupposti affinché l'utente abbia piena fiducia (''trust'') nel servizio, lo utilizzi, lo divulghi, lo renda un servizio di successo.

==Architettura del servizio==

===I componenti software nell'architettura LAMP===

Il servizio è realizzato in forma di ''web-based application'' poiché, come già illustrato nell'introduzione, si intende renderlo disponibile per il massimo numero di utenti possibili. Nella progettazione e realizzazione dell'architettura web si adotta la piattaforma ''LAMP'', il cui nome deriva dall'acronimo dei componenti open source che la realizzano (il sistema operativo Linux, il server HTTP Apache, il sistema per la gestione di database relazionali MySQL ed il linguaggio di programmazione PHP). Poichè il modello è composto da quattro livelli, spesso si parla anche di ''stack LAMP''. Uno degli elementi di forza del modello ''LAMP'' è che i componenti dei vari ''layer'' sono sostituibili, a seconda delle esigenze, con dei componenti più adatti, tipicamente open source ([0015], [0018], [0019]). Basando la piattaforma su un sistema operativo della famiglia di Microsoft Windows, ad esempio, si ottiene uno ''stack WAMP'', mentre se si usa un sistema operativo Mac OS si realizza uno ''stack MAMP''. Un'architettura web basata sul modello ''LAMP'' può, inoltre, essere integrata con software open source che offre utili funzionalità, come, ad esempio, il monitoraggio (''Nagios''), il load balancing (''Linux Virtual Server''), la rilevazione di accessi illeciti (''Snort'') e il security testing (''netsniff-ng''). <div></div>
Si valutano ora brevemente la diffusione dei componenti tradizionali dello ''stack LAMP'' e le alternative maggiormente usate per i vari ''layer''.
Le distribuzioni Linux risultano essere la scelta più comune per l'ultimo ''layer'' dello ''stack''. Secondo W3Techs, infatti, nell'ottobre del 2013, il 58.5% dei web server a livello globale avevano come sistema operativo la distribuzione Debian o Ubuntu, mentre il 37.3% una tra RHEL, Fedora e CentOS([0016]). <div></div>
Tra i web server, Apache risulta essere maggiormente usato. Secondo le stime fatte da Netcraft, a giugno del 2014 circa il 51.9% del milione di siti web più trafficati al mondo usavano un web server Apache, il 19.2% nginx ed il 12.4% Microsoft ([0017]). <div></div>
I principali ''DBMS'' relazionali, oltre a MySQL, che possono essere presenti nello ''stack LAMP'' sono MariaDB e PostgreSQL, mentre tra i ''DBMS NoSQL'' MongoDB risulta essere il più comune. <div></div>
Nello stack, infine, il ruolo di linguaggio di programmazione, solitamente svolto dal linguaggio PHP, spesso è ricoperto dai linguaggi Perl o Python. <div></div>
Si osserva, ad ogni modo, che le informazioni sulla diffusione delle tecnologie non rappresentano un fattore vincolante nella scelta delle stesse, in quanto la piattaforma ''LAMP'' è anche aperta verso molti altri componenti oltre quelli citati; di conseguenza la scelta delle tecnologie da impiegare può essere effettuata basandosi principalmente sui requisiti e sulle specifiche del servizio. <div></div>

===Principi di progettazione per l'architettura===

====Single Responsibility Principle====

Per rendere il servizio maggiormente manutenibile ed estensibile, si presta particolare attenzione al rispetto del ''Single Responsibility Principle'' (''SRP'') ([0020]). Si cerca, quindi, di fattorizzare il software in più moduli, suddividendo tra questi le elaborazioni da svolgere. Un altro importante beneficio che si ottiene dalla fattorizzazione del codice è la riusabilità dei componenti. Ogni singolo modulo, infatti, svolge il proprio compito in maniera indipendente dal resto della applicazione ed è, quindi, riutilizzabile in altri scenari simili senza dover essere re-implementato. Inquadrando meglio questa metodologia di progettazione con i requisiti del servizio e la piattaforma web ''LAMP'', si individuano i due principali compiti a carico dell'applicazione:
* La gestione dell'interazione web con l'utente per la trasmissione del documento e dei nominativi da trattare
* Il processamento del documento per effettuare la "minimizzazione" dei dati.
Questi due differenti ''task'' saranno, quindi, portate a termine da componenti diversi.<div></div>
Progettando la struttura dell'applicazione in questo modo, si disaccoppia completamente la logica di business del servizio dalle interfacce web di comunicazione con l'utente. In un futuro sviluppo sarà possibile, quindi, realizzare nuove interfacce utilizzando altre tecnologie senza dover modificare la logica applicativa.

====Dependency Inversion Principle====

Un altro principio di design architetturale che risulta importante nella progettazione è il ''Dependency Inversion Principle'' (''DIP'') ([0038]). Esso si traduce nella realizzazione di componenti che non dipendono dalle specifiche implementazioni degli altri moduli del sistema, bensì dalle loro ''astrazioni''.
In relazione all'estensibilità e manutenibilità del prodotto software, infatti, l'impiego di moduli dipendenti direttamente dalla definizione dei metodi presenti in altri componenti risulta problematica: il modulo dipendente deve essere re-implementato ad ogni variazione del modulo da cui dipende.
Nella programmazione orientata agli oggetti, per rispettare questo principio, si su può fare uso di classi astratte o interfacce, costrutti che definiscono i moduli senza implementarli completamente o senza implementarli affatto.

===Stile architetturale REST===

Il modello architetturale del servizio che si sta definendo presenta una serie di caratteristiche, come ad esempio l'indipendenza dei moduli, che permettono di realizzarlo secondo il paradigma delle ''RESTful API''. L'espressione "Representational State Transfer" e il suo acronimo "REST" furono introdotti nel 2000 nella tesi di dottorato di Roy Fielding ([0021]), uno dei principali autori delle specifiche dell'Hypertext Transfer Protocol (HTTP). Roy Fielding descrive il ''Representational State Transfer'' come uno stile architetturale ("''architectural style''"), ovvero un'astrazione degli elementi di un'architettura all'interno di un sistema hypermedia distribuito. ''REST'' non specifica i dettagli dell'implementazione dei componenti e della sintassi del protocollo, ma definisce i ruoli dei componenti, i vincoli sulla loro modalità di interazione e la loro interpretazione.
Riassumiamo quindi i principi che deve rispettare una architettura ''REST'':
# Architettura Client-Server <br/>In una architettura ''REST'' viene data particolare importanza ai principi ''SRP'' e ''DIP'' prima citati, più generale si può affermare che l'architettura sposi il paradigma noto con il termine di "''Separation of Concerns''". Una ''Restful API'' applica questi principi in un architettura Client-Server, capace di supportare l'evoluzione indipendente della logica lato client e della logica lato server.
# Stateless <br/>La comunicazione tra utente e fornitore del servizio deve essere senza stato, quindi ogni richiesta del client deve contenere tutte le informazioni di cui il fornitore necessita per l'erogazione del servizio offerto. Questa ipotesi viene fatta per rendere una ''Restful API'' facilmente scalabile orizzontalmente.
# Uso della cache <br/>In un Architettura ''REST'' i messaggi di risposta inviati dal server devono esplicitamente indicare se possono essere memorizzati nella cache del client o di componenti middleware per il riutilizzo nelle richieste successive.
# Interfaccia uniforme <br/>I componenti devono essere in grado di comunicare attraverso un'interfaccia uniforme e le risorse devono essere trasferite in un formato standard. Inoltre l'utente deve poter effettuare la navigazione tra le risorse di suo interesse tramite collegamenti ipertestuali. Per inciso, si osserva che il protocollo HTTP usato correttamente rispetta i requisiti di un architettura ''REST'' e che nelle implementazioni delle ''RESTful API'' il formato più usato per la modellazione dei dati è JSON.
# Layered System <br/>In un sistema a livelli, componenti intermedi (come i proxy) possono essere collocati tra client e server per intercettare il traffico per scopi specifici; ad esempio il caching o la sicurezza. Una soluzione basata su ''REST'' può essere composta da più livelli architettonici, indipendenti l'uno dall'altro.
# Code on Demand <br/>Questo vincolo facoltativo è inteso principalmente a consentire aggiornamenti alla logica all'interno dei client (come i browser Web) indipendentemente dalla logica lato server. Una ''single page application'', ad esempio, rispetta in pieno questo punto.

Un'applicazione progettata sul modello dell'architettura ''REST'' ha quindi gli indiscutibili vantaggi di:
* consentire l'evoluzione indipendente delle diverse componenti
* avere un'interfaccia utente portabile con altri tipi di piattaforme
* permettere agevolmente la replicazione delle macchine server
* non vincolare moduli server e client a linguaggi e tecnologie specifiche.

L'architettura del servizio oggetto di questa tesi si trova già perfettamente in linea con alcuni dei vincoli discussi, ma sono necessarie alcune considerazioni. Il punto 1 ("architettura Client-Server") è chiaramente soddisfatto.
Il punto 2 ("Stateless"), direttamente collegato con i punti 3 e 5 ("Uso della cache", "Layered System"), può essere rispettato con facilità; a ogni richiesta di "minimizzazione" del client corrisponde la restituzione del documento trattato dal server, non c'è quindi necessita di avere uno stato nell'interazione.

Analizzando le caratteristiche di una applicazione stateless in relazione al principio ''privacy by design'' illustrato in precedenza, si osserva che l'assenza di stato determina la semplificazione delle problematiche critiche relative al principio. Non vengono conservate, infatti, informazioni contenenti dati sensibili, poiché dopo aver effettuato l'invio della risposta, sarà subito eliminato sul server il file elaborato.

Nei capitoli precedenti tuttavia si è detto che l'utente può ripetere più volte il trattamento di uno stesso documento nella stessa sessione di interazione; essendo il vincolo dell'efficienza già difficile da rispettare per via dell'elaborazione onerosa del documento, si può progettare una modalità alternativa del funzionamento con stato del servizio, applicabile in assenza di replicazione delle macchine server e sfruttando le ripetute richieste di trattamento per uno stesso documento.
Si può infatti memorizzare lato server il documento inviato dal client inizialmente e, alle successive richieste di trattamento del medesimo documento, evitarne la ritrasmissione da client a server. Per rispettare il ''PbD'', al termine della sessione di interazione il documento verrà rimosso dal server. Si nota, inoltre, che per predisporre il servizio alla gestione delle due diverse modalità di funzionamento si può utilizzare un parametro di configurazione a livello applicativo.
I punti 4 e 6 infine ("Interfaccia uniforme", "Code on Demand") si possono rispettare utilizzando il formato JSON per la trasmissione dei documenti e dei nominativi, e usando localmente sul client Javascript per offrire tutte le funzionalità del servizio in un'unica pagina html.

===Moduli software del servizio===

====Scelta dei componenti software====

Si opera ora la scelta delle tecnologie da utilizzare per i componenti dei 4 layer dello ''stack LAMP''. Per i due layer inferiori risulta piuttosto immediato decidere di usare le tecnologie presenti per default. Un sistema operativo Linux ed un web server Apache sono adatti all'architettura del servizio.
Inoltre anche il linguaggio di programmazione PHP può essere usato senza significativi problemi, anche se verranno fatte in seguito, in una sezione di questo capitolo, alcune considerazioni sulle problematiche di esecuzioni concorrenti di script PHP. Il linguaggio sarà impiegato in particolare per la realizzazione della logica necessaria a gestire l'interazione web con il cliente, mentre l'elaborazione del documento OOXML lato server sarà effettuata da un programma Java.

I due ''task'' principali del servizio sono delegati, quindi, a due programmi distinti realizzati con tecnologie diverse. Si concretizza in questo modo il principio ''SRP'' e, sfruttando l'<i>openness</i> della piattaforma LAMP, le funzionalità necessarie vengono realizzate attraverso i linguaggi più adatti.
La scelta del linguaggio Java per l'implementazione del ''main core'' della logica di business è dovuta alla libreria open source in ambiente java Docx4j ([40],[41]). Questa libreria è realizzata per il processamento delle tre tipologie di formati OOXML (''docx'', ''xslx'', ''pptx'') e permette tutte le possibili operazioni di creazione, lettura e modifica su questo tipo di documenti. Anche questa libreria sarà approfondita in sezioni successive. Si osserva, per inciso, che esistono altre librerie equivalenti in ambiente .NET.

Nella scelta del linguaggio di programmazione usato per elaborare i documenti ed effettuare i confronti tramite ''regular expressions'', un dato non di poco conto da considerare è l'encoding delle stringhe. In Java, in particolare, una stringa è rappresentata internamente come un array di char, ognuno codificato da 2 byte in formato UTF-16 ([0042]); la codifica esprime in 16 bit tutti i caratteri definiti dallo standard Unicode, quindi è possibile scegliere Java.

Per il ''layer'' della persistenza, infine, l'impiego di un database MySql risulta una buona scelta. Si osserva che questo livello non verrà utilizzato nella tradizionale maniera prevista dallo ''stack LAMP''. Infatti, generalmente, la base di dati viene interrogata direttamente dal componente che si occupa dell'interazione con l'utente (PHP) per il reperimento delle informazioni utili da restituire al client; nel servizio, invece, la base di dati sarà a supporto unicamente del programma Java, poiché gli unici dati persistenti da gestire sono i nomi del dizionario (si ricordi sempre il ''PbD'') e solo i moduli dell'eseguibile Java devono utilizzarli. Se il dizionario contenessero unicamente i nomi (senza informazioni accessorie correlate) e fossero usati in sola lettura, un semplice file di testo poteva essere sufficiente per la rappresentazione. Tuttavia, poiché saranno individuate tecniche di ottimizzazione nell'impiego dei dizionari che richiedono operazioni di scrittura e ordinamento dei dati, risulta opportuno usare un database relazionale.

====Logica di business e dinamiche di interazione====

Vengono presentati in questa sezione gli aspetti principali dei funzionamenti dei moduli del servizio. Per mettere bene a fuoco quali siano le meccaniche di interazione e i flussi di esecuzione dei programmi, si propone il diagramma di sequenza del tipico scenario di utilizzo. In questo schema UML si descrive il caso d'uso dove un utente, dopo aver inserito un documento ed averlo ricevuto "minimizzato", esprime delle preferenze e richiede poi un secondo trattamento.<div></div>
<div></div>(QUI IMG [0F00])<div></div>
Si descrivono quindi ora le principali operazioni che vengono eseguite.
All'avvio dell'interazione viene presentata una pagina PHP di benvenuto contenente le informazioni su come i dati personali vengano elaborati ed un ''file-picker'' per consentire l'upload di un documento ''OOXML''; nel momento in cui l'utente confermerà il caricamento del documento, esso verrà trasferito sul server.
Bisogna prestare particolare attenzione al comportamento del sistema nel caso in cui più utenti richiedano contemporaneamente l'esecuzione del servizio, e cioè alle problematiche di esecuzioni concorrenti di script PHP; è necessario, in particolare, evitare situazioni in cui i nomi dei file inviati dagli utenti siano in conflitto. Analizzando più in dettaglio il problema, ogniqualvolta un web server Apache riceve una richiesta HTTP per una pagina PHP, si ha la generazione di un nuovo processo che esegue il codice presentato nella pagina PHP richiesta. Supponendo quindi che N utenti eseguano l'invio del file contemporaneamente, si avrebbe che sul server N processi diversi dovrebbero procedere con la scrittura di un file. Ovviamente se due o più file condividono il nome almeno uno di essi sarà sovrascritto. Per risolvere questo problema, supponendo di voler salvare tutti i documenti in una cartella temporanea, occorre modificare il filename dei documenti inviati dagli utenti per esser certi di non incorrere in sovrascritture o altri tipi di errori correlati.
Una valida possibilità è l'inserimento di un ''prefisso'' univoco nel filename. Per la generazione di una stringa univoca da anteporre al filename, che permetta di distinguere file caricati da utenti diversi, si può direttamente usare il ''session id'' dell'utente. In PHP esso è determinato casualmente combinando ([0043]): l'IP del cliente, orario di attribuzione dell'id, un numero pseudo-casuale (con il ''PHP Linear Congruence Generator'') e, se presente un "''random source''" sul sistema operativo del Client (spesso chiamato impropriamente "''seme''"), un ulteriore numero pseudo-casuale.
Per introdurre ulteriore alea, necessaria se, ad esempio, un utente tenti l'upload di file omonimi (con contenuto interno diverso) e mantenga il medesimo ''session id'', si utilizza un ulteriore generatore pseudo-casuale per produrre un altro numero con cui comporre il prefisso.
Concatenando i due numeri generati si ha praticamente certezza di aver individuato un numero univoco nel sistema per il tempo in cui il servizio sarà erogato al cliente.

Una volta memorizzato il file, lo script PHP dovrà ricorrere all'invocazione del modulo Java, delegato al vero e proprio processamento del documento. Occorre quindi individuare un set di opzioni che consenta al modulo che gestisce l'interazione con il cliente di sfruttare al meglio il componente delegato all'elaborazione del documento, in qualunque circostanza; la totale indipendenza dei moduli, la loro sostituibilità e la replicazione possibile di macchine server sono solo alcuni dei fattori che rendono mutevole la configurazione del sistema. Va definito un protocollo di comunicazione, quindi, che astragga completamente dall'implementazione dei moduli o dalla locazione dei file.

Valutando i possibili flussi logici, anche con l'ausilio del diagramma di sequenza, si ha che i tipi di esecuzione sono due:
* "minimizzazione" con dizionario
* "minimizzazione" di specifici nominativi
Il protocollo di comunicazione tra i due moduli è costituito in entrambi i casi di una singola richiesta a cui segue una singola risposta. Più in particolare, lo script PHP invoca il comando Java esprimendo obbligatoriamente il path del file da trattare e opzionalmente l'elenco dei nominativi. A suo volta, il modulo Java restituisce i nominativi trovati, qualora non espressamente richiesti dallo script, e segnala la corretta terminazione dell'elaborazione.
Si definiscono come canali di comunicazione standard del protocollo gli argomenti presi in input dal modulo di processamento del documento e lo standard output del processo che esegue tale programma. Inoltre è importante definire un formato standard per la comunicazione dei nominativi tra moduli; è necessario quindi scegliere un pattern che permetta di determinare univocamente la composizione dei nominativi. Un possibile formato, espresso tramite ''regex'', è il seguente:
<div></div>
<span style="font-family: monospace;"> <nominativo> = ^(<nome>:)*<nome>;<cognome>$</span>
<div></div>
<span style="font-family: monospace;"> <nominativi> = ^(<nominativo>\s+)+$</span>
<div></div>
Dove nome e cognome sono una sequenza di caratteri Unicode come già discusso. Ulteriori opzioni importanti da definire nel protocollo per l'invocazione del programma che si occupa delle funzionalità di elaborazione sono le seguenti:
* path file da elaborare (opzione "-i <file_path>", obbligatoria)
* path con cui salvare il file elaborato (opzione "-o <file_path>", opzionale: per default viene creato un nuovo file automaticamente)
* abilitazione stampe verbose, da usare solo in fase di debug (opzione "-d", opzionale)
<div></div>
Una volta terminato il processamento, il modulo di gestione dell'interazione con l'utente dovrà accertarsi che l'<i>exit status</i> sia 0 e leggere dallo standard output del processo appena terminato, qualora si sia stata eseguita la "minimizzazione" con dizionario, l'elenco dei nominativi trovati. Se invece la "minimimizzazione" ha avuto luogo con i nominativi già specificati non sarà scritto nulla sullo standard output.
A margine si osserva che l'impiego dell'opzione "-d" deve sempre consentire una semplice individuazione dei nominativi trovati; in particolare, se tale opzione è specificata, nello standard output i nominativi compariranno con un ''header'' riconoscibile ("''NOMINATIVO=''").
Ritornando alla descrizione del flusso di esecuzione tipo, una volta che il modulo Java ha completato il trattamento del documento, lo script PHP ne effettuerà l'upload sul client e presenterà all'utente le opzioni già descritte nel capitolo sull'usabilità.
A questo punto l'interazione con client potrebbe concludersi, qualora si eseguisse il download e si chiudesse il browser, o continuare elaborando i ''suggerimenti'' dell'utente espressi dopo il primo trattamento. Le modalità di comunicazione dei moduli varierebbero leggermente come appena illustrato, mentre, a seconda della configurazione stateful o stateless del servizio, verrebbe eseguito o meno un nuovo upload del file dal client al server.<div></div>

Si osserva infine che, per predisporre a successivi studi di ottimizzazione il servizio e per agevolare tutti i possibili sviluppi futuri, si applica largamente nella progettazione del modulo di elaborazione Java il ''Dependency Inversion Principle'', in quanto si desidera realizzare classi estendibili ed intercambiabili.
In particolare, si introducono delle classi astratte per rappresentare in maniera generica il concetto di "''persona''" e "''minimizzatore''". È possibile infatti realizzare successivi studi per trattare ulteriori dati personali oltre che ai nomi e cognomi; inoltre, in base ai tipi di documenti trattati o eventuali altri fattori utili, è possibile studiare differenti tecniche di "minimizzazione" realizzate da differenti algoritmi "''minimizzatori''".
In particolare una "''persona''" dovrà sempre esporre un metodo "''minimizza''" che prende in input una stringa, la "minimizza" e la restituisce; il pattern con il quale si effettua la "minimizzazione" sarà fornito in implementazione a seconda dei dati sensibili di interesse.
Un "''minimizzatore''" esporrà sempre un metodo "''work''" che, presa in input una lista di persone ed un documento ''OXML'', con l'ausilio della libreria Docx4j, fornirà in output un documento del tutto "minimizzato"; la definizione delle modalità con cui si estrapolano le informazioni dal documento e con cui si invoca il metodo "''minimizza''" della classe persona sono confinate nell'implementazione.
Definendo delle classi astratte risulta, quindi, più veloce la realizzazione dei futuri componenti e si svincola il processo di "minimizzazione" dal tipo di dati che si "minimizzano" e viceversa.

====Le classi principali del progetto====
Le classi principali del progetto vengono quindi presentate in appendice. Esse sono:
* App.java, contenente il main
* Elaborator.java, che presenta il metodo "''work''"
* Persona.java, che presenta il metodo "''minimizza''"
* Testing.java, contenente alcune funzioni usate in fase di debug.

Gli script in PHP sono stati forniti dall'azienda come implementazione minimale e provvisoria, da perfezionare a seguito della eventuale definizione sulle modalità di presentazione del servizio su Internet.

Una considerazione di implementazione comune a tutte le classi deriva del principio ''Privacy by Design'', indifferentemente dalla modalità di configurazione stateful o stateless del servizio: è di fondamentale importanza che nel sistema non siano memorizzati permanentemente in alcun caso i documenti inviati dagli utenti del servizio.
Per realizzare un sistema robusto, per fronteggiare crash improvvisi del client o congestioni della rete, è opportuno impostare dei timeout lato server che procedano automaticamente alla eliminazione dei documenti degli utenti dopo un periodo di inattività troppo prolungato. Qualora invece si dovesse verificare un interruzione critica del servizio a causa di un errore logico del server o semplicemente per via di un'interruzione dell'alimentazione della macchina server, bisogna considerare altri metodi; essendo il servizio realizzato con un sistema operativo Linux, si può configurare il demone ''crond'' per eseguire a ogni reboot e, per sicurezza, una volta al giorno l'eliminazione dei file usati dall'applicazione tutti contenuti all'interno della cartella temporanea.

==Approfondimenti tecnologici==

===Analisi della struttura del formato OOXML===

Come argomentato, il formato dei documenti elaborati dal servizio progettato dovrà essere ''Office Open XML'', o ''OOXML''; si tratta di un formato ''XML-based'' per documenti di testo, fogli elettronici e presentazioni, in grado di rappresentare grafici, diagrammi, immagini e altro materiale grafico. La specifica fu sviluppata da Microsoft e adottata dall'<i>ECMA International</i> come standard ''ECMA-376'' nel 2006. Una seconda versione fu rilasciata nel 2008, una terza nel 2011, una quarta nel 2012 ed una quinta tra il 2015 ed il 2016 ([0010]). La specifica è stata adottata, inoltre dall'<i>ISO</i> e dall'<i>IEC</i> come standard ''ISO/IEC 29500'' a partire dal 2008 ([0011], [0012]).

====Linguaggi di markup====

Lo standard ''ECMA-376'' ([0010]) include tre differenti specifiche di linguaggio per ognuna delle tre principali categorie di documenti:
* ''WordprocessingML'' per i documenti testuali
* ''SpreadsheetML'' per i fogli elettronici
* ''PresentationML'' per le presentazioni elettroniche
* ''DrawingML'' ed altri linguaggi di markup di supporto per la rappresentazione di disegni, forme e diagrammi.
<div></div>
La specifica include sia gli schemi ''XML'' sia i vincoli espressi per iscritto. Ogni documento conforme al formato dovrà, quindi, rispettare gli schemi ''XML'' e dovrà essere codificato in ''UTF-8'' o ''UTF-16''. La specifica, inoltre, permette l'aggiunta di ''custom tag XML'' a supporto dei linguaggi di markup dati, per default nel formato ''OOXML'', consentendo quindi la libera personalizzazione dei documenti.

====File packaging====

Oltre alla specifiche relative ai linguaggi di markup, la seconda parte dell'<i>ECMA-376</i> ([0010]) definisce la struttura gerarchica dei file del formato adottando le ''Open Packaging Conventions'' (''OPC''). ''OPC'', una tecnologia ''file-container'' basata sul comune formato compresso ''zip'', che stabilisce che tutti i file che riguardano una stessa entità devono essere raggruppati in un unico package ([0014]). Un documento ''OOXML'' è, infatti, un archivio ''zip'' contenente alcuni files ''XML'' (detti anche ''parti'') organizzati in un singolo package. Questa frammentazione dei dati in più files rende più semplice e veloce l'accesso ai dati stessi e riduce le possibilità di una loro corruzione. Le ''parti'' possono contenere qualsiasi tipo di dato; per tenere traccia della relazione tra una ''parte'' e la sua tipologia di contenuto, senza basarsi sull'estensione del file, è presente nel package, nella cartella radice della gerarchia, il file denominato ''[Content_Types].xml'', il quale mappa appunto queste associazioni. È mostrata qui ad esempio l'associazione tra la ''parte'' rappresentante il documento principale e il suo ''ContentType''.
<div style="font-family: monospace;">
<Override PartName="/word/document.xml" ContentType="application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml"/>
</div>
Le informazioni relative alle relazioni che ogni ''parte'' ha con le altre ''parti'', con risorse esterne e con il package in sé sono mantenute separatamente dal contenuto della ''parte'' stessa. Tali informazioni sono presenti, infatti, all'interno delle cartelle denominate ''_rels'': ne esiste una per il package nel suo complesso e una per ogni sotto-cartella del package contenente delle ''parti'' coinvolte in delle relazioni. In questo modo i riferimenti che una ''parte'' ha verso altre ''parti'' o risorse sono salvati una sola volta e possono essere aggiornati con semplicità se necessario, senza dover modificare il contenuto stesso delle ''parti'' coinvolte. È mostrato qui un esempio di relazione contenuta in ''_rels/.rels'' relativa al documento principale e al suo schema.
<div style="font-family: monospace;">
<Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument" Target="word/document.xml"/>
</div>
Il documento principale, ossia il file ''word/document.xml'', ha inoltre numerose relazioni con altre ''parti'', come ad esempio ''word/styles.xml'' e ''word/footer.xml'', e risorse esterne collegate con degli URI. Per descrivere queste relazioni si usa la cartella ''word/_rels''.

====Parti di un Documento OOXML====

Vengono qui presentate le ''parti'' che sono caratteristiche esclusive di un ''WordprocessingML package'', non presenti quindi negli altri due formati ''OOXML''. È importante osservare che alcune di esse sono facoltative e sono presenti nel package solo se necessario.

Le ''parti'' relative al vero e proprio contenuto testuale sono:
* ''Main Document'', contiene le informazioni principali ed è salvata come ''word/document.xml''
* ''Header'', contiene i dati relativi alle intestazioni ed è salvata in ''word/header.xml''. Ogni sezione del documento può avere intestazioni diverse per la prima pagina, per le pagine pari e per le dispari, quindi possono esserci molteplici ''parti header''
* ''Footer'', contiene le informazione relative al piè pagina ed è salvata in ''word/footer.xml''. Può essere presente più volte, per motivi analoghi alla ''parte header''
* ''Footnotes'', contiene le eventuali note a piè pagina del documento ed è salvata come ''word/footnotes.xml''
* ''Endnotes'', contiene le note di chiusura del documento ed è salvata in ''word/endnotes.xml''.

Sono presenti poi delle ''parti'' relative allo stile e alle impostazioni del documento:
* ''Style Definitions'', contiene la definizione di un insieme di stili usati dal documento, salvata in ''word/styles.xml''
* ''Font Table'', contiene informazioni riguardo i font usati, salvata in ''word/fontTable.xml''
* ''Numbering Definitions'', contiene le definizioni sulla struttura delle liste contenute nel documento, salvata in ''word/numbering.xml''
* ''Document Settings'', specifica come il word processor debba trattare il documento (spell checking, gestione delle revisioni, etc.), contenuta in ''word/settings.xml''
* ''Web Settings'', contiene informazioni su come il documento debba essere convertito in ''HTML'' se richiesto, contenuta in ''word/webSettings.xml''.

Sono presenti anche delle ''parti'' che rappresentano testo secondario:
* ''Comments'', contiene i commenti sul documento inseriti attraverso un word processor
* ''Glossary'', contiene dati testuali aggiuntivi secondari, ne è permessa una sola. Tutte le ''parti'' prima elencate, tranne il ''Main Document'', possono comparire una seconda volta in relazione alla ''parte glossary''.

====Analisi del Main Document====

Il file ''document.xml'', elemento principale di un documento ''WordprocessingML'', è costituito da due tipi di informazioni:
* ''properties'', che definiscono lo stile e la formattazione del testo
* ''stories'', che rappresentano il contenuto testuale delle varie parti del documento.

Le ''properties'' verranno trattate in misura minore. Queste informazioni sono espresse attraverso una struttura XML gerarchica che ha come elemento radice il nodo ''document''. Esso ha due nodi figli:
* ''background'', che contiene alcune ''properties'' che descrivono lo sfondo del documento
* ''body'', che contiene tutti i rimanenti contenuti ed è potenzialmente molto complesso.

Si osserva che per le finalità del trattamento dei dati risultano di primario interesse le ''stories'' e che è opportuno effettuare un'analisi ''bottom-up'' del problema: anziché considerare la gerarchia a partire dal ''body'' (nodo padre) partiremo dalla rappresentazione più semplice del testo contenuta nel documento (nodi figli).

Facendo direttamente riferimento allo standard ''ECMA-376'' ([0010]), si evince che l'unico nodo che contiene puro testo ha il nome ''t'' (''Text''). Questo elemento contiene una stringa rappresentante gli esatti caratteri che vengono poi mostrati negli editor a video. Il nodo ''Text'' non presenta figli e l'unico nodo padre che può avere è ''r'' (''Run''). Quest'altro nodo definisce una regione di testo con comuni proprietà (ad esempio l'uso del grassetto). Attraverso l'uso di tag ''t'' ed ''r'' quindi si rappresenta una regione di testo formattata con differenti elementi stilistici.
Occorre però evidenziare che un nodo ''r'' può presentare molti altri figli oltre a ''t'', come ad esempio immagini, in quanto rappresenta un'area generica del documento.
Si supponga quindi di avere due nodi ''Text'' fratelli, ossia figli dello stesso nodo ''r'': essi rappresenteranno semanticamente un unico blocco logico se e solo se compariranno a video come una sequenza di parole continua. Questo fenomeno è facilmente identificabile anche nel file ''XML'' descrittivo: due sequenze di parole mostrate a video adiacenti compaiono infatti nel file ''XML'' in due righe consecutive; se invece due parti di testo dovessero essere intervallate ad es. da un'immagine nel documento ''XML'' ci sarebbe un tag ''drawing'' a dividere i due tag ''t''. Dalla consecutività dei nodi ''Text'' nel file ''document.xml'' si può determinare quali siano i blocchi logici da trattare.
Un insieme di ''Run'' infine può essere figlio di diversi nodi, ma ciò non è di rilevante importanza, in quanto ogni area di testo individuata dal nodo ''Run'' rappresenta già un blocco logico a sé e, di conseguenza, contiene sufficienti informazioni per la "minimizzazione".
L'unico caso di rilievo nel quale bisogna valutare quale sia la gerarchia a monte di un nodo ''Run'' è nell'elaborazione di una tabella. In tal caso, in realtà, occorre verificare opportunamente la strutturazione della gerarchia processata. Per chiarezza espositiva viene mostrata la rappresentazione in formato ''OOXML'' di una tabella con una riga e due colonne (senza l'uso di ''properties'' per la formattazione stilistica).
<br/>
<div style="font-family: monospace;">
<w:tbl>
<w:tr>
<w:tc>
<w:p>
<w:r>
<w:t>Cella A</w:t>
</w:r>
</w:p>
</w:tc>
<w:tc>
<w:p>
<w:r>
<w:t>Cella B</w:t>
</w:r>
</w:p>
</w:tc>
</w:tr>
</w:tbl>
</div>

Come si osserva in figura, in una tabella il nodo ''r'' sarà figlio del nodo ''p'' (''Paragraph''), il quale a sua volta sarà contenuto in un noto ''tc'' (''Table Cell''). Celle di una tabella appartenenti ad una stessa riga saranno presenti all'interno dello stesso ''tr'' (''Table Row'') ed infine tutte le righe della tabella saranno inserite del tag ''tbl'' (''Table'').

Per determinare quindi se due nodi ''Text'' sono scritti in due colonne adiacenti di una stessa riga (e quindi costituiscono un unico blocco logico) è necessario verificare che per i due nodi ''Text'':
# il nodo "padre" '''non sia''' in comune
# il nodo "padre di 2° livello" sia ''Paragraph'' e '''non sia''' in comune
# il nodo "padre di 3° livello" sia ''Table Cell'' e '''non sia''' in comune
# il nodo "padre di 4° livello" sia ''Table Row'' e '''sia''' in comune
# i nodi "padre di 3° livello" '''siano''' consecutivi.
Se tutte queste ipotesi sono soddisfatte, le due celle vanno "minimizzate" come unico blocco logico.

Si valutano infine gli ultimi vincoli emersi nell'analisi sull'interpretazione della formattazione di un documento.
In particolare, descrivendo le parti che compongo un documento ''OOXML'', era già emerso che alcune sezioni di testo, ossia note a piè pagina ed intestazioni, compaiono in altri file ''XML'' e non in ''document.xml''. Questi file (''header.xml'', ''footer.xml'', ''endnotes.xml'', etc.) sono tutti raccolti in un package ("''word''") e la grammatica ''XML'' è la stessa usata per il Main Document.
Si conclude osservando che il problema della divisione in sillabe delle parole non si pone, in quanto la divisione sillabica mostrata a video dai word-processors è calcolata dinamicamente; in particolare, su una porzione di testo viene applicata la sillabazione (ove necessario) se è presente tra le ''properties'' di quella regione di documento il tag ''hyphenationZone''.

====La libreria in ambiente java open source Docx4j====

La libreria Docx4j offre completo supporto alla manipolazione di documenti ''docx'' (compressione e decompressione archivio zip, generazione file ''XML'' necessari, etc.). Offre inoltre un'utile mappatura in specifici oggetti Java della gerarchia ''XML'' presente nei vari file del formato.
Uno tra gli elementi più interessanti è la tecnica con cui vengono recuperati i nodi dai file ''XML'', in quanto si fa impiego del linguaggio standard W3C ''XPath'' ([0044], [0045]). Con ''XPath'' è possibile esprimere con una stringa un sottoinsieme di nodi presenti in una gerarchia ''XML'' non solo in base al loro nome o valore, ma anche in relazione alla posizione reciproca rispetto agli altri nodi. Riferendoci alle problematiche del servizio risulta, ad esempio, significativamente agevolato il trattamento di dati personali in forma tabellare.
Si osserva infine che la libreria attribuisce un id univoco ad ogni nodo del documento, di conseguenza se ne può trarre vantaggio nei confronti tra i nodi.

===Ottimizzazioni del processo di minimizzazione===

Durante l'analisi dei requisiti è emerso che l'efficienza costituisce un aspetto problematico del servizio. Si ricorda di aver stimato la durata di una prestazione media di circa 145 secondi, considerando dati:
* un documento di medie dimensioni (10 pagine ~ 5000 parole)
* tempo medio di 10 ms per individuare le occorrenze di un nome
* un dizionario di circa 14.500 parole

In linea di massima si individuano due generi di strategie che consentirebbero la riduzione del tempo medio di esecuzione: uno mirato a ridurre il più possibile il testo da sottoporre a "minimizzazione" automatica, l'altro a ottimizzare l'impiego del dizionario e dell'algoritmo di ricerca.

Come già spiegato, l'approccio di ricerca ''pattern-based'' è poco sensibile all'aumentare della lunghezza del documento, ma da questo valore ha una dipendenza non trascurabile.

Nel documento è altamente probabile che ci siano interi periodi, se non pagine, dove non sia presente alcun nominativo. Anche all'interno di una frase che necessita di ''minimizzazione'' è plausibile che siano sono poche le coppie (al più le terne) di parole riconducibili ad una sequenza nome-cognome. È inessenziale che sezioni di testo che non necessitano di "minimizzazione" vengano processate. Si osserva per inciso che, ovviamente, questo ragionamento è corretto per via dell'indipendenza dal contesto di un approccio ''pattern-based''.

Il pattern definito per la ricerca di un nominativo è molto restrittivo, in quanto accetta solo sequenze di parole costituenti un nominativo contenente un nome specifico; d'altronde la progettazione del pattern è stata effettuata mirando ad identificare il più accuratamente possibile le sequenze da anonimizzare.

Analizzando attentamente il problema, si può fare il seguente ragionamento: per ridurre il più possibile il numero di parole da processare a ogni iterazione di ricerca del pattern di un nome, è possibile individuare preliminarmente tutte le sequenze di parole del documento che ''potrebbero essere'' dei nominativi e ''potrebbero'' fare match.

L'operazione di "pre-filtraggio" si applica processando il documento con un ''pattern'' che presenta un'espressione più generale e permissiva delle ''regex'' definite per i nomi del dizionario. Si osserva che una qualunque successione di caratteri ''alfabetici'' iniziante con un carattere maiuscolo ''potrebbe'' rappresentare un nome. Per realizzare un espressione adatta si parte dalla definizione della ''regular expression'' già data ai nomi del dizionario:

<div style="font-family: monospace;">
<regex> := (<second_name>\s)?(<nome>)\s<cognome>|<cognome>\s(<nome>)(\s<second_name>)?
</div>

Nell'uso fatto finora di questa espressione, al tag <span style="font-family: monospace;"><nome></span> viene attributo, ciclio dopo ciclio, una parola del dizionario diversa. È possibile definire una variante più generale dell'espressione appena presentata:

<div style="font-family: monospace;">
<nome_pre> := [A-Z][a-zA-ZÀ-ÖØ-öø-ÿ<extra>]+

<regex_pre> := (<second_name>\s)?(<nome_pre>)\s<cognome>|<cognome>\s(<nome_pre>)(\s<second_name>)?
</div>

Con questa ''regex'' si identifica una qualunque sequenza che rappresenta un nominativo, ma allo stesso tempo anche, ad esempio, tutte le parole consecutive inizianti con una maiuscola. È importante sottolineare che questo pattern presenta tutte le caratteristiche già ampiamente discusse sul formato delle ''regex'' per riconoscimenti automatici (gestione dei delimitatori, posizione relativa tra i nomi ed il cognome, etc.).
Il processamento di una ''regex'' generale inoltre sarà inevitabilmente più lento di quello di ''regex'' aventi i nomi specificati, in quanto molte più sequenze faranno match essendo l'espressione più permissiva. La mancanza di accuratezza va rapportata all'impiego della ''regular expression'': fornendo essa un semplice "pre-filtraggio" del documento non risulta necessario nè che individui esclusivamente nominativi nè che sia in grado di distinguerli gli uni dagli altri. Il leggero ritardo introdotto viene valutato sperimentalmente, applicando lo stesso l'algoritmo già usato in precedenza ed elaborando gli stessi documenti, sempre a parità di piattaforma.

Partendo dall'elaborazione di un documento contenente 10 nominativi ed in totale 5.000 parole, si misura che tempo il processamento medio della ''regex'' di "pre-filtraggio" è di circa 36 ms; si ricorda che per lo stesso documento il tempo di esecuzione medio per il processamento di un nominativo non presente è di circa 9 ms, se le occorrenze salgono a 10, il tempo è in media di circa 10 ms.
Sebbene l'elaborazione di questa ''regex'' sia circa 4 volte più lenta dell'elaborazione di ''regex'' più specifiche, un ritardo introdotto dell'ordine dei millisecondi è trascurabile rispetto al tempo di processamento complessivo (stimato di circa 145 second).
Si osserva, per inciso, che nell'elaborazione di questo particolare documento sono stati individuati altre 21 sequenze che rispettavano il pattern che non costituivano dei nominativi.

Terminata l'esecuzione dell'operazione di prefiltraggio, occorre sfruttare opportunamente le informazioni ottenute: in particolare, si possono elaborare con le ''regex'' dei nomi le sole sotto-stringhe che hanno fatto match con la ''regular expression'' nell'operazione preliminare. In altri termini, con questo metodo si effettua una sola elaborazione del testo completo e molteplici processamenti delle sotto-stringhe che ''potrebbero'' contenere nominativi.
Si osserva inoltre che, conoscendo con certezza gli indici di inizio e fine delle sotto-stringhe che ''potenzialmente'' contengono nominativi, è possibile "alleggerire" la ''regex'' associata ai nomi del dizionario: si possono rimuovere i costrutti ''lookahead'' e ''lookbehind'' in quanto la sotto-stringa è stata già rimossa dal contesto e quindi rappresenta esclusivamente i caratteri individuati dalla ''regular expression'' di "pre-filtraggio".

A questo punto occorre valutare sperimentalmente l'ottimizzazione ottenuta. Si misura che sono sufficienti 2 ms di elaborazione in media per nome, mentre, nel caso raro in cui tutti i 10 nominativi presenti si riconducano ad un unico nome, il tempo medio di esecuzione tende verso i 3 ms. Si osserva che questo è possibile perchè le parole nelle sotto-stringhe sono poco meno di 50, ossia si è ridotta di oltre il 99% la dimensione complessiva di dati da processare!
Valutando l'ottimizzazione complessiva in termini di tempo si ha che, processando un dizionario di circa 14.500 termini, sono necessari in media 29 secondi.

Ovviamente questo dato è fortemente dipendente dal contenuto del documento. Vanno effettuate opportune misurazioni nel caso in cui la percentuale di nominativi presenti rispetto alle parole complessive nel documento sia maggiore. Si considera un documento di 5.000 parole contenente 200 sequenze riconosciute dall'algoritmo di "pre-filtraggio" delle quali 100 costituiscono dei nominativi.
Si misura che il tempo di esecuzione medio è di 6 ms nel caso generale del processamento di un nome con poche occorenze e tenderà verso i 10 ms nel caso sporadico in cui le occorrenze del nome saranno proprio 100 o poco meno. Il tempo di esecuzione del "pre-filtraggio" è di circa 48 ms.
Per inciso, si osserva che la ragione per cui il tempo necessario al "pre-filtraggio" non aumenta esageratamente è dovuta al pattern della ''regex''. La ''regular expression'' impiegata infatti, facendo principalmente uso di caratteri espressi in un range unitamente al quantificatore "+", risulta particolarmente efficiente da elaborare.
Nel caso di documenti più "ricchi" di nomi si stima l'elaborazione media complessiva di circa 1 minuto e 27 secondi.

Facendo il punto della situazione, si è ridotto di circa 5 volte il tempo di esecuzione complessivo nel caso di documenti "scarsamente popolati" da nominativi e quasi dimezzato il tempo necessario nell'elaborazione di documenti contenenti molte coppie nome-cognome. Occorre proseguire nello studio per migliorare l'ottimizzazione, considerando dove l'algoritmo di ricerca e l'impiego del dizionario possono essere migliorati.

Viene posta una semplice domanda sulle modalità di ricerca dei nominativi nell'insieme delle sotto-stringhe del documento: è computazionalmente equivalente prendere una ad una le sotto-stringhe e confrontarle con le ''regex'' dei nomi rispetto che prendere una ad una le ''regex'' dei nomi e confrontarle con le sotto-stringhe?

Si fornisce una spiegazione formale alla domanda.

Si definiscono due insiemi:
* A = {a_1, a_2, ... a_n}
* B = {b_1, b_2, ... b_m}

Gli elementi dell'insieme A rappresentano le sotto-stringhe (cardinalità N), mentre gli elementi dell'insieme di B indicano le ''regex'' dei nomi (cardinalità M). È importante considerare che per il secondo insieme è definita una relazione di unicità che lega il valore degli elementi: per ogni ''b_i'' appartenente a B non esiste un indice ''j'', ''j'' compreso tra 1 ed M, tale che il testo del nodo ''i'' sia uguale al testo del nodo ''j'' (tranne se ''i'' = ''j''); in altre parole gli elementi rappresentanti le ''regex'' (''b_i'') per definizione sono posti univoci in B.

Si presti attenzione al fatto che l'insieme delle sotto-stringhe presenta N elementi distinti tra loro in identità ("id nodo"), ma il cui contenuto testuale può essere equivalente a quello di altre sotto-stringhe. L'equivalenza tra due sotto-stringhe sussiste, in questo particolare contesto, qualora i contenuti testuali di entrambe facciano match con una stessa ''regex'' presente nell'insieme B. L'insieme delle ''regex'', invece, presentano elementi i cui valori testuali sono sempre univoci, in quanto ottenuti da nomi sempre diversi.

Definiti gli insiemi si procede alla formulazione della risposta alla domanda precedente. Per chiarezza espositiva indicheremo con "A->B" la procedura con cui si opera il confronto prendendo una ad una le sotto-stringhe per poi confrontarle con le ''regex'', mentre indicheremo con "B->A" la procedura con cui si opera il confronto prendendo una ad una le ''regex'' dei nomi per poi confrontarle con le sotto-stringhe.

Nel caso in cui l'insieme delle sotto-stringhe non contenga alcun nominativo, si ha una complessità computazionale equivalente per "A->B" e per "B->A". Viene mostrato nei calcoli in figura che il numero di confronti necessari ''C_1'' è dato dal prodotto delle cardinalità degli insiemi, ossia ''C_1 = N · M''.

(QUI FIG[0F07])

Si suppone ora che il testo della sotto-stringa di posizione ''r'' faccia match con la ''regex'' in posizione ''k''; si applica "A->B". Come si mostra attraverso i calcoli in figura, il numero totale di confronti ''C_2'' sarà inferiore a ''C_1'' poichè, quando la sotta-stringa in posizione ''r'' risulta equivalente alla ''regex'' in posizione ''k'' si può direttamente passare alla valutazione della stringa in posizione ''r + 1'' e non svolgere i rimanenti ''m - k" confronti per la stringa in posizione ''r''. Si calcola che ''C_2 = k + m · (n -1)''.

(QUI FIG[0F08])

Supponendo sempre che il testo della sotto-stringa di posizione ''r'' faccia match con la ''regex'' in posizione ''k'', si applica "B->A". Similmente al caso precedente, quando la sotta-stringa in posizione ''r'' risulta equivalente alla ''regex'' in posizione ''k'' si può direttamente passare alla valutazione della ''regex'' in posizione ''k + 1'' e non svolgere i rimanenti ''n - r" confronti per la ''regex'' in posizione ''k''. Si osserva inoltre che è inutile confrontare le rimanenti ''m - k'' ''regex'' con la sottostringa di posizione ''r'': essa è risultata già equivalente ad una ''regex'' e, essendo le ''regex'' poste per definizione diverse tra loro, è di conseguenza impossibile che soddisfi un'altra uguaglianza.
Per inciso si osserva che nel calcolo di ''C_2'' un ragionamento di questo genere non è applicabile: ogni sotto-stringa può potenzialmente fare match con una qualsiasi ''regex''.
Il numero totale di confronti ''C_3'' viene calcolato come mostrato, si ottiene ''C_3 = k + m · (n -1) - n + r''.

(QUI FIG[0F09])

Si osserva che ''C_3 = C_2 - n + r'' e, essendo ''r'' la posizione della sotto-stringa coinvolta nel match, si ha che ''C_3'' è sempre minore di ''C_2'' qualunque sia la posizione della sotto-stringa. L'unico caso in cui ''C_3 = C_2'' si verifica quando la ''r = n'', ossia se la sotto-stringa è l'ultima dell'insieme.

Per estendere il ragionamento, si prende la ''regex'' di posizione ''k'' e si indica con ''T'' il numero di sotto-stringhe che sono già risultate equivalenti ad una ''regex'' nelle elaborazioni precedenti. Risulta che, per il ragionamento spiegato nel calcolo di ''C_3'', potranno essere risparmiati almeno ''N - T'' confronti per la ''regex'' ''k'' e per ogni ''regex'' in posizioni successive. In generale, maggiore è il numero di nominativi nel documento, maggiore sarebbe l'ottimizzazione della procedura.

Le conclusioni che si traggono sono due:
* indipendentemente dal numero o dalla posizione dei nominativi nelle sotto-stringhe, nell'algoritmo di minimizzazione è più efficiente prendere una ad una le ''regex'' dei nomi e con ognuna trattare l'insieme delle sotto-stringhe
* un efficace ordine di elaborazione delle ''regex'' può introdurre ottimizzazioni

Va eseguita ora una valutazione sperimentale dei tempi di esecuzione del processo di "minimizzazione" tenendo conto di questi elementi. Le ''regex'' che fanno match con i nominativi presenti nel testo, quindi, vengono trattate tra le prime. Risulta di interesse principalmente valutare i miglioramenti ottenibili nel caso di documenti ''molto popolati'' da nominativi, poichè è questo il caso in cui l'ottimizzazione entra in gioco.
Si esegue il test sullo stesso documento trattato precedentemente con la sola tecnica di "pre-filtraggio". Esso è composto da 5.000 parole, dal "pre-filtraggio" sono individuate 200 sotto-stringhe delle quali 100 costituiscono dei nominativi.
Nel test si è fatto riferimento a dati Istat ([0046]) per stabilire, quanto più realisticamente possibile, il miglior ordine di elaborazione delle ''regex'' associate ai nomi; risulta che circa il 25% dei nominativi è individuato entro i primi 15 cicli di esecuzione; circa il 35% entro i primi 50 ed il 100% entro circa i primi 3000. Per inciso, si osserva che un altro documento può dare origine a tempi significativamente peggiori qualora presenti molti nominativi con nomi desueti e presenti in fondo al dizionario.
Si misura che, dopo il "transitorio iniziale" (ossia dalla 51° ''regex'' in poi), il tempo medio è di 5 ms per l'elaborazione di una ''regex''. Si osserva che, una volta che sono state elaborate circa le prime 3000 ''regex'', il tempo medio di elaborazione di una ''regex'' scende a 4 ms. Per completezza, si riporta anche il tempo medio per la fase di "transitorio iniziale", che si misura di circa 8 ms; il tempo di "pre-filtraggio", già precedentemente calcolato, risulta di 48 ms.
Calcolando complessivamente la durata del processamento si ottiene che l'elaborazione media complessiva è di circa 61 secondi, si ottiene quindi una riduzione significativa rispetto al tempo di 1 minuto e 27 prima individuato.

Si considerano, in relazione alle conclusioni della discussione teorica prima formalizzata, le implicazioni realizzative: in primis che l'imposizione del verso con cui eseguire la "minimizzazione" non determina particolari problemi implementativi, in secundis che l'ordinamento efficiente dei nomi del dizionario può essere trattato attraverso una tecnica di ''machine learning''.

La tecnica di apprendimento che si realizza si basa sull'estrapolazione di informazioni utili nei documenti inviati dagli utenti. Si tiene traccia, infatti, della ''frequenza'' con cui un nome appare in diversi processamenti. Alla fine di ogni "minimizzazione", dopo aver concluso il salvataggio del nuovo file ''OOXML'', il programma Java eseguira l'update sul database MySql delle frequenze dei nomi trovate, incrementandole.
Nell'interrogazione al database per l'ottenimento dell'insieme dei nomi, di conseguenza, si richiederà l'ordinamento per frequenza delle tuple restituite. In questo modo, più volte un nome compare nei documenti, più incrementi riceverà il suo campo frequenza, più avrà la probabilità di comparire in cima al dizionario.
Si progetta inoltre l'inserimento di un campo "ultimo utilizzo", associato ai nomi sul database, che permette di avere un secondo criterio di ordinamento utile. Tale campo viene impiegato anche per evitare una crescita esagerata del valore della frequenza; periodicamente, con ''crond'' ad esempio, si decrementano i valori del campo "frequenza" dei nomi il cui "ultimo utilizzo" è troppo vecchio. Si osserva che i valori di configurazione per la gestione di queste elementi dipendono dal carico medio del sistema, noto solo dopo la progettazione, andranno valutati con precisione in fasi future. Ovviamente l'aggiornamento del campo "ultimo utilizzo" sarà contestuale all'aggiornamento della ''frequenza''.
Si osserva, per inciso, che l'impiego di un dizionario di cognomi sarebbe stato problematico per l'aggiornamento delle frequenze. Per via del principio ''Privacy by Design'', infatti, aggiornando la frequenza per la entry del cognome di una persona, indirettamente si sarebbe tenuto traccia di un dato sensibile, specialmente nel caso in cui il cognome risulti "raro".
Una valutazione rilevante da fare è sulle implicazioni relative agli accessi concorrenti al dizionario, dovute all'introduzione dell'algoritmo appena spiegato, che esegue scrittura di "frequenza" e ''ultimo utilizzo'' sul database. Si osserva che non sono problematiche le "letture sporche", poichè, se si verificano, al più risulta alterato l'ordine di qualche nome; inoltre nemmeno un "lost update" risulta eccessivamente problematico, poichè l'ultimo utilizzo risulta sempre aggiornato e la perdita di un incremento delle frequenza di un nome non rappresenta in linea di massima un problema. Questi scenari presentati vanno valutati complessivamente, però, una volta che si realizza il reale carico del sistema: perdere molti update risulta critico per l'ottimizzazione del processamento. Conviene in linea precauzionale prevedere una semantica transazionale per l'interazione tra modulo Java e database. Per inciso, eseguire l'update finale con una transazione non influenza il tempo di attesa dell'utente, poichè il documento è stato già elaborato per intero.

Si fa infine un'ultima osservazione che consente di abbattere i tempi di attesa enormemente, a costo di perdere dell'accuratezza nel processamento automatico: ridurre il numero di nomi del dizionario processato, elaborando solo quelli in cima.
Si osserva che questa soluzione è ancor più efficace se i nomi contenuti nel documento sono pochi. In questo caso, infatti, il processamento dei nomi durante la fase di "transitorio iniziale" richiede lo stesso tempo del processamento di nomi "a regime", ossia dopo l'avvenuta riduzione del numero di sotto-stringhe da elaborare. Nei documenti "ricchi" di nominativi, come già spiegato, ciò non avviene.
Per concludere, si usano i risultati dei test sperimentali precedentemente misurati per stimare il tempo di processamento complessivo, supponendo di:
* applicare la tecnica di "pre-filtraggio"
* usare i primi 1.500 nomi di un dizionario ordinato per frequenza

Caso A:
* documento contenente 10 nominativi ed un totale di 5.000 parole
* processamento medio della ''regex'' di "pre-filtraggio" di circa 36 ms
* individuazione di 31 sotto-stringhe totali
* durata elaborazione in media per nome di circa 2 ms

Durata esecuzione senza troncamento: 29 secondi circa

Durata esecuzione con troncamento: 3 secondi circa

Caso B:
* documento contenente 100 nominativi ed un totale di 5.000 parole
* processamento medio della ''regex'' di "pre-filtraggio" di circa 48 ms
* individuazione di 200 sotto-stringhe totali
* durata elaborazione in media per nome di circa 8 ms per prime 50 iterazioni
* durata elaborazione in media per nome di circa 5 ms per successive

Durata esecuzione con solo "pre-filtraggio" : 1 minuto e 27 secondi

Durata esecuzione senza troncamento: 61 secondi circa

Durata esecuzione con troncamento: 7.7 secondi circa

I tempi a cui si giunge risultano soddisfacenti in entrambi i casi. Si prevede di lasciare all'utente la possibilità di scegliere di ricevere un servizio o più veloce o più accurato, in base alle sue esigenze.

===Tecnologie complementari===

La redazione di questa tesi è avvenuta su Mediawiki, la più importante fra le piattaforme wiki essendo il motore di Wikipedia.

Le piattaforme wiki sono riconosciute come elemento caratterizzante dell’evoluzione Internet al Web 2.0, cioè al web nel quale gli utenti-navigatori, fino ad allora "''consumatori"'' ("''consumers"'') di contenuti si sono trasformati essi stessi in "''produttori"'' ("''producers"''), e cioè in "''prosumers"''.

Un ''wiki'' è fondamentalmente un sito web che contiene informazioni e che consente agli utenti di editare facilmente il suo contenuto.

Nel redigere una pagina wiki si utilizza ciò che è chiamato ''wikitext" per definire capitoli, paragrafi, hyperlinks, elementi di formattazione della pagina, etc.; sebbene il ''wikitext" risulti non difficile da apprendere, quasi ogni piattaforma wiki è corredata da editor di tipo visuale, che non richiede alcuna conoscenza della sintassi del ''wikitext"; tuttavia è esperienza comune che utilizzare direttamente il ''wikitext" induce a concentrarsi maggiormente sui contenuti e non sulla formattazione. Il linguaggio ''wikitext'' è strettamente correlato con il linguaggio HTML, infatti nella scrittura è possibile utilizzare tag come h1, span, div e così via, oltre che la sintassi esclusiva di ''wikitext''; simmetricamente una pagina prodotta da media wiki è costituita da HTML ben formato e direttamente importabile in ogni word processor.

I wiki presentano una funzionalità di grande utilità nella redazione di documenti articolati: la tracciatura delle successive revisioni ("''Cronologia"''). La possibilità di ripercorrere l’evoluzione del testo è davvero d’aiuto quando si fissano idee originali in uno scritto, cercando di definirle, precisarle, chiarirle, come è avvenuto in effetti, anche nella redazione di questa tesi. Per curiosità, si segnala che, pur avendo redatto la maggior parte del testo off-line, la pagina wiki di questa tesi conta oltre 50 revisioni.

Per inciso, si osserva che è stata molto utile la funzionalità di "ricerca nel codice" offerta dalla piattaforma di revisione online GitHub nella corretta comprensione della libreria Docx4j, il cui codice sorgente è ivi rilasciato.

Si conclude infine dicendo che per ottimizzare le procedure di debug del codice sono stati realizzati utili tool a riga di comando per Linux per la rapida estrazione-modifica-ricompattazione di documenti ''OOXML''. Si propone in appendice un comando bash per questi scopi.

==Sviluppi futuri==

In questa sezione si fa cenno, senza poterle approfondire, ad alcune interessanti questioni emerse nello svolgimento della tesi.

===Accesso al servizio web===

In fase iniziale, il servizio web potrà essere reso accessibile in forma completamente aperta, senza richiedere cioè la registrazione dell’utente o l’autenticazione dell’utente già registrato. In questo modo, in effetti, si premia la facilità d’uso, ma si incorre nella nota problematica di un uso malevolo, costituito da accessi a raffica, finalizzati a saturare il server e generare una condizione di ''DoS – Denial of Service''. Diverse sono le tecniche che possono essere adottate per contrastare questo tipo di accessi malevoli, come richiedere di superare "''captcha''" e/o introdurre ritardi crescenti ed eventualmente blocchi in risposta ad accessi prevenienti con alta frequenza dallo stesso indirizzo IP.
È possibile anche pensare ad un accesso previa registrazione ed autenticazione dell’utente, penalizzando l’immediatezza di utilizzo del servizio, ma eventualmente ottenendo l’indirizzo email degli utenti che acconsentono a lasciarlo per successive finalità marketing.
È possibile, infine, un utilizzo misto, contando in un cookie il numero di accessi eseguiti e richiedendo all’utente di registrarsi per continuare ad utilizzare il servizio, dopo qualche accesso.

===Ampliamento dinamico del dizionario===

Nel restituire il documento elaborato all'utente, gli si da la possibilità di richiedere una nuova elaborazione, dopo aver indicato i nominativi che fossero sfuggiti; pare inesauribile, infatti, la "fantasia" dei genitori nel dare nome ai propri figlioli!
I nominativi indicati dall'utente sono sfuggiti al servizio perché non presenti nel dizionario: facilmente viene in mente l’idea di arricchire il dizionario con i nominativi indicati dall’utente. Va però considerato il caso che l’utente in malafede indichi nominativi fasulli al fine di inquinare il dizionario.
Il caso malevolo può essere affrontato attraverso una strategia che preveda non direttamente l'inserimento del nuovo nominativo nel dizionario, ma invece l'utilizzo di un concetto di "candidatura": il nuovo nominativo viene registrato, ma si attende di avere un certo numero di utenti che lo propongono prima di approvarne l'inserimento nel dizionario.
Può anche essere utilizzato un concetto di "attendibilità" della candidatura di un nuovo nominativo, verificando ad esempio l'utente che lo propone scarichi effettivamente il file rielaborato.
Nel caso l'accesso avvenga con autenticazione, e cioè identificando gli utenti, si apre la possibilità di individuare e bannare gli utenti malevoli.

===Natura del documento e ricorrenza del nominativo===

Si coglie facilmente la differenza di formato fra un documento in forma di elenco (es. una graduatoria) da un documento in forma di relazione (es. una sentenza giudiziaria). Differenze di questo tipo potrebbero essere utilizzate per escludere o ammettere la ripetizione dei nominativi.
Per meglio dire: in un elenco la ripetizione di un nominativo è di fatto da escludersi o va trattata come omonimia. In una relazione, l’individuazione di un nominativo può essere utilizzata per ricercarlo direttamente in altri punti del documento stesso.

===Altri dati personali===

Altri dati personali sono trattabili con le stesse tecniche analizzate in questa tesi: date e luoghi di nascita, codici fiscali, indirizzi, email, numeri di telefono, sesso etc. In qualche caso, come per i codici fiscali, l’individuazione del pattern da trattare è persino più semplice.
Diversi studi ([0039]) hanno dimostrato che, utilizzando set di dati personali parziali, è possibile la re-identificazione dei soggetti, pur in documenti pseudonimizzati. È questo un altro motivo per estendere i trattamenti descritti anche agli altri dati personali richiamati.

===Altri alfabeti===

È possibile estendere il sotto-insieme di caratteri Unicode utilizzati nelle ''regex'' per elaborare documenti scritti in altri alfabeti non latini.

==Conclusioni==

Questa tesi è partita da un problema basilare, quasi scolastico, dell'informatica: la ricerca di un testo in un documento, al fine della sua cancellazione o modifica.

Il problema si è subito discostato dalla sua formulazione basilare, principalmente perché, nei casi d'uso, il documento da ricercare non è un semplice testo ("''plain text''") ma invece è il prodotto di un ''word-processor'': quindi è costituito da una struttura XML più o meno complessa, rappresentante formattazioni, riferimenti interni o esterni, note, etc. La ricerca deve avvenire nei soli nodi di puro testo, individuando ed escludendo dall'analisi lessicale gli elementi testuali di mark-up che non costituiscono contenuto informativo. Nell'approfondire le strutture ed i concetti XML ho potuto notare quanto essi siano ricorrenti in molti ambiti dell'informatica.

Nell'analisi delle specifiche, un'altra complicazione si è presto aggiunta: l'usabilità del servizio cresce drasticamente se si evita di chiedere all'utente, come si era pensato in un primo tempo di fare, quali siano le stringhe (i nominativi) da ricercare e trattare; è nata allora l'idea di reperire queste stringhe in un dizionario di nomi ed in un dizionario di cognomi, considerando anche le permutazioni dei lemmi reperiti. Ho così dovuto approfondire alcuni problemi tipici dei dizionari, come il loro ampliamento automatico con tecniche oggi comprese nel ''machine-learning''. Non ho potuto "resistere" alla tentazione di ''formalizzare la matematica'' in base alla quale ho costruito le strategie di ricerca.

Spunto per la tesi è stata la recente legislazione in materia di dati personali, il GDPR. Esaminandone gli articoli pertinenti, ho maturato una riflessione generale: sempre più il software dovrà essere progettato e realizzato anche alla luce di altre discipline, non solo di quelle informatiche, come le discipline giuridiche ed il diritto.

Durante la fase iniziale della collaborazione con l'azienda mi sono dedicato alla messa a punto delle specifiche; ciò mi ha permesso di comprendere quanto questa fase sia importante e come completezza e precisione delle specifiche siano alla base di un progetto efficace.

Molto importanti sono state la analisi relative al tipo e formato dei documenti da assumere come input ed alla presentazione ottimale del servizio rispetto all'usabilità.

Centrale nel lavoro ed avvincente è stata la definizione della strategia per il riconoscimento dei lessemi attraverso la costruzione dinamica di ''regex'' idonee. In questo fase del lavoro, anche per passione personale, ho approfondito le questioni del riconoscimento "di testi nei testi" che legano, fin dalle origini, l'informatica e la linguistica.

La fase di definizione dell'architettura del servizio mi ha permesso di ripercorrere molte le materie studiate nei tre anni del Corso di Ingegneria Informatica, affrontando argomenti come il Single Responsibility Principle, il Dependency Inversion Principle, lo "stile" architetturale REST. Molto istruttiva è stata anche la riflessione sulla scomposizione del servizio in moduli software.

Come sempre accade nell'affrontare un progetto nuovo, sono nate molte nuove idee; ho così immaginato numerosi sviluppi futuri, sia a perfezionamento funzionale dell'accesso web al servizio, sia ad estensione delle specifiche per coprire casi applicativi contigui (es. quando il dato che si vuole trattare è un codice fiscale). Dovendo necessariamente tener presente che questo lavoro è una tesi, verificherò con il supporto del mio relatore come poterne proseguire lo sviluppo.

==Bibliografia==

<div></div>[0000]https://en.wikipedia.org/wiki/Comparison_of_Office_Open_XML_software
<div></div>[0001]https://en.wikipedia.org/wiki/Comparison_of_OpenDocument_software
<div></div>[0002]https://en.wikipedia.org/wiki/Standardization_of_Office_Open_XML
<div></div>[0003]https://en.wikipedia.org/wiki/OpenDocument_standardization
<div></div>[0004]https://support.apple.com/en-us/HT202227
<div></div>[0005]https://en.wikipedia.org/wiki/Pages_(word_processor)
<div></div>[0006]https://en.wikipedia.org/wiki/Comparison_of_word_processors
<div></div>[0007]https://en.wikipedia.org/wiki/OpenDocument
<div></div>[0008]https://en.wikipedia.org/wiki/Office_Open_XML_file_formats
<div></div>[0009]https://en.wikipedia.org/wiki/Rich_Text_Format
<div></div>[0010]https://www.ecma-international.org/publications/standards/Ecma-376.htm
<div></div>[0011]https://www.iso.org/standard/51463.html
<div></div>[0012]https://www.iso.org/standard/71691.html
<div></div>[0013]https://en.wikipedia.org/wiki/Office_Open_XML
<div></div>[0014]https://en.wikipedia.org/wiki/Open_Packaging_Conventions
<div></div>[0015]https://en.wikipedia.org/wiki/LAMP_(software_bundle)
<div></div>[0016]https://w3techs.com/blog/entry/debian_ubuntu_extend_the_dominance_in_the_linux_web_server_market_at_the_expense_of_red_hat_centos
<div></div>[0017]https://news.netcraft.com/archives/2014/06/06/june-2014-web-server-survey.html
<div></div>[0018]https://whatis.techtarget.com/definition/LAMP-Linux-Apache-MySQL-PHP
<div></div>[0019]https://www.ibm.com/cloud/learn/lamp-stack-explained
<div></div>[0020]https://en.wikipedia.org/wiki/Single_responsibility_principle
<div></div>[0021]https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
<div></div>[0022]https://en.wikipedia.org/wiki/Latin_script_in_Unicode
<div></div>[0023]https://it.wikipedia.org/wiki/ISO/IEC_8859-1
<div></div>[0024]http://www.treccani.it/enciclopedia/uso-delle-maiuscole_%28La-grammatica-italiana%29/
<div></div>[0025]https://en.wikipedia.org/wiki/Ambiguity#Linguistic_forms
<div></div>[0026]Steven L. Small; Garrison W Cottrell; Michael K Tanenhaus (22 October 2013). Lexical Ambiguity Resolution: Perspective from Psycholinguistics, Neuropsychology and Artificial Intelligence. Elsevier Science. ISBN 978-0-08-051013-2.
<div></div>[0027]http://www.treccani.it/vocabolario/disambiguazione/
<div></div>[0028]R. Navigli, K. Litkowski, O. Hargraves. 2007. SemEval-2007 Task 07: Coarse-Grained English All-Words Task. Proc. of Semeval-2007 Workshop (SemEval), in the 45th Annual Meeting of the Association for Computational Linguistics (ACL 2007), Prague, Czech Republic, pp. 30–35 http://www.aclweb.org/anthology/S/S07/S07-1006.pdf
<div></div>[0029]https://wordnet.princeton.edu/
<div></div>[0030]R. Navigli, S. P. Ponzetto. BabelNet: Building a Very Large Multilingual Semantic Network. Proc. of the 48th Annual Meeting of the Association for Computational Linguistics (ACL 2010), Uppsala, Sweden, July 11-16, 2010, pp. 216-225. http://aclweb.org/anthology/P/P10/P10-1023.pdf
<div></div>[0031]Roventini A., Alonge A., Calzolari N., Magnini B., Bertagna F. (2000), "ItalWordNet: a Large Semantic Database for Italian", Proc. of the 2nd International Conference on Language Resources and Evaluation (LREC 2000), Athens, Greece, 2000, pp. 783-790.
<div></div>[0032]E. Pianta, L. Bentivogli, C. Girardi. MultiWordNet: developing an aligned multilingual database, Proc. of the First International Conference on Global WordNet, Mysore, India, January 21-25, 2002. http://multiwordnet.fbk.eu/paper/MWN-India-published.pdf
<div></div>[0033]https://www.iso.org/standard/28245.html
<div></div>[0034]https://www.gpdp.it/web/guest/regolamentoue
<div></div>[0035]https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=uriserv:OJ.L_.2016.119.01.0001.01.ITA&toc=OJ:L:2016:119:TOC
<div></div>[0036]https://www.corriere.it/Primo_Piano/Cronache/2006/09_Settembre/15/cognomi.shtml
<div></div>[0037]https://data.world/axtscz/italian-first-names
<div></div>[0038]https://en.wikipedia.org/wiki/Dependency_inversion_principle
<div></div>[0039]https://imperialcollegelondon.app.box.com/s/lqqcugie51pllz26uixjvx0uio8qxgo5/file/493461282808
<div></div>[0040https://www.docx4java.org/trac/docx4j]
<div></div>[0041]https://github.com/plutext/docx4j
<div></div>[0042]https://docs.oracle.com/javase/9/docs/api/java/lang/String.html
<div></div>[0043]https://github.com/php/php-src/blob/master/ext/session/session.c
<div></div>[0044]https://github.com/plutext/docx4j/search?q=getJAXBNodesViaXPath+in%3Afile&type=Code
<div></div>[0045]https://www.w3.org/TR/xpath-30/
<div></div>[0046]https://www.istat.it/it/dati-analisi-e-prodotti/contenuti-interattivi/contanomi
<div></div>[0047]
<div></div>[0048]

==Indice delle figure==

[0F00]https://en.wikipedia.org/wiki/Latin_script


[0F01]Diagramma di Venn 1

[0F02]Diagramma di Venn 2

[0F03]Diagramma di Venn 3

[0F04]Esito unit test regex (cartella immagini)

[0F05]Inforgrafica GDPR

[0F06]Diagramma di sequenza UML

[0F07]Primo calcolo valutazione algoritmo

[0F08]Secondo calcolo valutazione algoritmo

[0F09]Terzo calcolo valutazione algoritmo

Servizio web per il trattamento dei dati personali contenuti in documenti OOXML complessi

2019-09-30T03:47:50Z

Lorenzo.amorosa: /* Ottimizzazioni del processo di minimizzazione */ - fine

==Introduzione==

Il recente Regolamento Generale europeo sulla Protezione dei Dati (UE) 2016/679 ([0034], [0035]) o ''GDPR'' (''General Data Protection Regulation'', come nel seguito sarà chiamato) ha modernizzato significativamente la normativa in materia di protezione dei dati personali, rendendola omogenea fra tutti gli stati membri. È bene notare che, fin dal titolo, il ''GDPR'' non riduce gli spazi per i trattamenti di dati personali, ma anzi ne protegge la "libera circolazione", dettando, però, regole definite e certe. Rinunciando ad una presentazione più completa del ''GDPR'', saranno riportati nei successivi capitoli i concetti necessari alla discussione dell'argomento.<div></div>
Enti ed organizzazioni, aventi a che fare con documenti contenenti dati sensibili, devono operare in maniera conforme al ''GDPR''; potrebbero, di conseguenza, trarre beneficio da servizi specifici in grado di supportarli in queste esigenze.<div></div>
L'oggetto principale della tesi sarà dunque, come riportato dal titolo, la progettazione e la realizzazione di un servizio per la gestione di dati personali.
<div></div>(QUI IMG [0F05])<div></div>

La larga maggioranza dei documenti testuali viene generata con strumenti cosiddetti di "produttività individuale", cioè da ''word-processors''. L'osservazione, ovvia nella sua evidenza, consente di introdurre una riflessione: quando un documento è generato da un'elaborazione automatica, magari per composizione di ''template'' con dati estratti da un database, l'individuazione dei "dati personali" nel documento prodotto può avvenire in modo rigoroso e senza incertezze, sulla base degli elementi di composizione del documento; ad es.: i campi del documento estratti da una anagrafica di soggetti sono certamente dati personali e come tali possono essere opportunamente trattati nel processo di elaborazione automatica (ad es. cancellati).

Ma, in quella larga maggioranza di documenti testuali generata con ''word-processors'' l'individuazione ed il trattamento dei dati personali vanno affrontati con altri approcci, discussi in questa tesi.

==Scenario di lavoro==

===Minimizzazione dei dati personali===

Un concetto espresso in modo pervasivo dal ''GDPR'' è quello della "''minimizzazione''" dei dati personali trattati ed a maggior ragione dei dati personali pubblicati. In particolare l'Art. 5 ed il Considerando 39 prescrivono che i dati personali trattati siano "''adeguati, pertinenti e limitati a quanto necessario rispetto alle finalità per le quali sono trattati («minimizzazione dei dati»)''" ([0035]).<div></div>
Con questo fine, il GDPR delinea due possibilità organizzative e tecniche di "''minimizzazione''": l'anonimizzazione e la psedonimizzazione.

====Anonimizzazione====

Sono anonimizzati i dati personali non (più) riferibili alle persone a cui sono appartenuti; si tratta di serie di dati, spesso ingenti, che sono stati definitivamente ed irreversibilmente separati da ogni riferimento alle persone che caratterizzavano. Sono le serie di dati utilizzate per fini statistici, scientifici, etc. E' importante notare che, come fissato dal Considerando 26 del ''GDPR'', il Regolamento non si applica al "''trattamento di tali informazioni anonime''" ([0035]). Per questo, sottoporre database e documenti ad un procedimento, cioè un trattamento, di anonimizzazione consente di non doversi più preoccupare del ''GDPR''.

====Pseudonimizzazione====

Fra le definizioni dell'Art. 4 del ''GDPR'', la "pseudonimizzazione" viene indicata come "''il trattamento tale che i dati personali non possano più essere attribuiti a un interessato specifico senza l’utilizzo di informazioni aggiuntive, a condizione che tali informazioni aggiuntive siano conservate separatamente''" ([0035]).<div></div>
Traducendo in termini "operativi", si tratta del procedimento che, dal "record" dei dati di un interessato, separa i campi che caratterizzano l'interessato stesso da quelli che lo identificano, trasferendo questi ultimi in una nuova distinta tabella; nelle due tabelle vengono aggiunti i riferimenti che permettono la ricostruzione del record originario; il procedimento è completo quando la nuova tabella con gli identificativi viene archiviata separatamente ed eventualmente cifrata. In margine si annota che in molti casi, come molti studi dimostrano, è possibile identificare, quindi "riconoscere", gli interessati utilizzando la sola tabella con i dati pseudonimizzati.

====Altri trattamenti di "minimizzazione" ====

Un problema pratico che si incontra di frequente è quello di dover pubblicare documenti più o meno ampi che contengono dati personali. Spesso la pubblicazione è obbligatoria per legge: si pensi alle graduatorie relative a concorsi pubblici, alle sentenze dei tribunali, etc.<div></div>
In questi frequenti casi, analizzando meglio le finalità per le quali sono pubblicati quei dati personali, si osserva che sono possibili e legittimi almeno due approcci per "minimizzare" il dato nel "trattamento di pubblicazione" e, dunque, per minimizzarne la propagazione, ad esempio attraverso motori di ricerca, ben oltre ogni ragionevole finalità. I contesti ed i corrispondenti approcci sono:
# Situazioni in cui è necessario che l'interessato possa riconoscersi nel documento ed essere riconosciuto dagli altri soggetti menzionati nel contesto, ma non è plausibile la necessità di identificazione dell'interessato al di fuori di quel contesto specifico. A questo caso si riconducono le graduatorie di concorsi, gli elenchi per la formazione di classi, gli elenchi per convocazioni, etc. In tutti questi casi, nel processo di redazione del documento è più pratico trattare internamente i dati personali in forma completa; ma praticamente mai è necessario pubblicarli per intero, esponendo al pubblico accesso codici fiscali, indirizzi, recapiti telefonici etc. Per di più, nella maggior parte delle volte, è sufficiente pubblicare il solo cognome perché l'interessato conosca la sua posizione in graduatoria; ciò è spesso sufficiente anche a trasmettere l'informazione necessaria ai colleghi dell'interessato nella medesima graduatoria, o nella medesima classe, etc. Notare che, pubblicando il solo cognome, viene di fatto oscurato anche il sesso. Dunque, in questi casi è auspicabile cancellare una larga parte dei dati personali presenti nel documento.
# Situazioni in cui il documento deve essere pubblicato affinché siano rese note le motivazioni che lo hanno originato, senza che sia necessaria la precisa identificazione dei soggetti che vi compaiono. Questo è il caso della pubblicazione di sentenze giudiziarie di ogni grado. Le sentenze vengono notificate direttamente agli "aventi causa"; ma anche, come la legge prescrive, pubblicate al fine di costituire giurisprudenza. In questo secondo caso, risulta del tutto eccedente la pubblicazione dei reali nominativi degli interessati, che troverebbero verosimilmente la propria vicenda inutilmente indicizzata dai motori di ricerca negli anni a venire. Nella pubblicazione delle sentenze appare un approccio ottimale quello di sostituire con pseudonimi o con iniziali alterate i veri nominativi degli interessati presenti: il senso e le argomentazioni della sentenza restano pienamente comprensibili, come è necessario; il dato personale, del tutto superfluo ai fini della giurisprudenza, viene protetto.
In questi casi appare opportuno sostituire i dati identificativi dell'interessato, ed in particolare il nome e cognome, con pseudonimi o, ancora, con iniziali alterate, cioè non coincidenti con le iniziali reali. <div></div>
Proprio questi tipi di trattamenti di "minimizzazione" sono l'oggetto di questa tesi.

===Punti di partenza per la progettazione del servizio===

La tesi è stata svolta in collaborazione con l'azienda AFA Systems (www.afasystems.it/gdpr) con la quale si sono discusse le problematiche di progettazione e realizzazione di un servizio generalizzato di minimizzazione dei dati personali presenti in un documento.
Con l'intenzione di fornire il servizio ad un bacino d'utenza il più vasto e variegato possibile, si è pensato ad un'applicazione ''web-based'', indipendente così dai singoli devices sui quali poi sarà utilizzata.
L'attenzione è stata concentrata sul trattamento dei nomi e dei cognomi (che da qui chiameremo nominativi), poiché sono quelli sempre presenti nei documenti (ad es. gli indirizzi sono presenti solo a volte), rappresentano gli elementi tramite i quali è immediato il riconoscimento della persone, non hanno formato predefinito (come ad es. i codici fiscali); altri dati personali (indirizzi, codici fiscali, etc.), potranno essere considerati in successive evoluzioni del progetto.
È utile notare che la parte iniziale della collaborazione con l'azienda è stata dedicata alla discussione delle specifiche, la cui più precisa definizione è parte rilevante di questa tesi.<div></div>
Tra i requisiti che necessitano di un opportuno studio troviamo ad esempio:
* L'individuazione di metodi efficaci per il riconoscimento dei nominativi nei documenti
* L'identificazione delle migliori procedure di interazione con l'utente
* La scelta dei formati da trattare
* I vincoli non funzionali legati al rispetto del ''GDPR''.

==Definizione delle specifiche==

===Riconoscimento dei nominativi===

====Scelta della strategia di riconoscimento====

Le difficoltà principali con cui ci si imbatte nel processo di riconoscimento dei nominativi riguardano la complessità strutturale dei documenti di testo, ma soprattutto l'intrinseca ambiguità del linguaggio naturale. <div></div>
Le variabili ed impredicibili strutture e formattazioni dei documenti introducono alcuni problemi significativi. Rendendo fortemente eterogeneo il contenuto dei documenti, infatti, esse non consentono di ricondurre il problema del riconoscimento dei nominativi ad uno o a pochi singoli casi, ma comportano lo studio di tutte le strutture e formattazioni possibili, rendendo quindi l'analisi molto generale. L'altra rilevante difficoltà presente sta nella complessità di effettuare il riconoscimento di una stringa testuale immersa in un insieme di elementi non tutti testuali. Ogni elemento di formattazione, che sia una tabella o una barra orizzontale, introduce infatti un proprio significato logico e semantico nel documento di cui bisogna tenere conto.<div></div>
Il linguaggio naturale introduce anch'esso complessità: si pensi alle molteplici tipologie di proposizioni con cui possono essere articolati i periodi; ma i problemi principali derivano dalle sue ambiguità. Esse vengono classificate in diverse tipologie ([0025]); le principali sono le ambiguità sintattiche e lessicali.<div></div>
Si ha ambiguità sintattica quando la sintassi di una frase può essere interpretata in diversi modi e, di conseguenza, la frase stessa assume significati diversi. Essa è presente, ad esempio, nelle seguenti frasi:<div></div>
* "''Rapina in banca con rivoltella da centomila euro''"
* "''Luigi ha visto un uomo nel parco con il binocolo''"
<div></div>
L'esasperazione massima della problematica delle ambiguità sintattiche si presenta con l'<i>antinomia</i>, ossia un particolare tipo di paradosso che indica la compresenza di due affermazioni contraddittorie che possono essere entrambe dimostrate o giustificate.
L'antinomia di Epimenide o ''Paradosso del mentitore'', nota fin dal VI secolo, è probabilmente uno dei più noti esempi: "''il cretese Epimenide afferma che tutti i cretesi mentono''". Se la proposizione è vera (i cretesi mentono) allora il suo significato implica che sia falsa (Epimenide mente e quindi i cretesi dicono la verità), ma se è falsa (i cretesi dicono la verità) ciò significa che è vera (Epimenide dice la verità e quindi i cretesi mentono). La proposizione appare contemporaneamente vera e falsa. A partire dagli anni venti del '900, sono state elaborate varie teorie per la risoluzione delle contraddizioni provocate dalle antinomie, soprattutto attraverso l'elaborazione di linguaggi multilivello o attraverso l'elaborazione di logiche polivalenti (quindi non-booleane).<div></div>
Si ha ambiguità lessicale, invece, quando una parola possiede più di un significato nella lingua a cui appartiene ([0026]), in tal caso la parola è definita ''polisemica''. In italiano, alcuni termini soggetti a questo tipo di ambiguità sono, ad esempio "''acuto''" o "''venti''". È questo genere di ambiguità che risulta critico per il riconoscimento dei nominativi. La difficoltà determinata dalle ambiguità sintattiche, infatti, riguarda l'individuazione corretta di soggetti, predicati e complementi di un periodo, mentre le ambiguità lessicali ostacolano la comprensione del significato del singolo lessema. Nel processo di riconoscimento è irrilevante determinare la funzione logica che il nominativo svolge nella frase, mentre è necessario essere certi che i termini che compongono il nominativo siano effettivamente dei nomi propri di persona o dei cognomi, non altri vocaboli del lessico comune. <div></div>
In linguistica, l'intervento con cui si toglie ambiguità a una parola o a una frase prende il nome di "disambiguazione" ([0027]). Il problema della disambiguazione automatica (in inglese ''Word Sense Disambiguation'' o, abbreviato, ''WSD'') riveste particolare importanza nelle ricerche sull'intelligenza artificiale e, in particolare, nell'elaborazione del linguaggio naturale. Si prevedono benefici della disambiguazione, ad esempio, in programmi di traduzione automatica, recupero dell'informazione o estrazione automatica di informazioni. Nell'analisi delle soluzioni esistenti in letteratura per la risoluzione delle ambiguità, ci si sofferma specialmente sulle ricerche incentrate sul trattamento dell'ambiguità lessicale, essendo essa la più rilevante per i nostri interessi.<div></div>
La ''WSD'' richiede due input necessariamente: un dizionario per specificare i sensi che devono essere disambiguati e un corpus di dati linguistici da disambiguare. Nello scenario più realistico, si trattano testi le cui parole non sono note a priori e risulta molto onerosa la produzione del corpus, essendo infatti necessaria la valutazione di un operatore umano per verificare la correttezza delle disambiguazioni effettuate dagli algoritmi (''supervised learning'').<div></div>
Uno tra i principali dizionari semantici-lessicali utilizzati della lingua inglese è ''WordNet'' ([0029]), mentre alcuni dei database equivalenti che trattano l'italiano sono ''BabelNet'' ([0030]), ''ItalWordNet'' ([0031]) e ''MultiWordNet'' ([0032]).
Un elemento importante da considerare è che le prestazioni di disambiguazione per la lingua inglese, impiegando ''WordNet'', risultano corrette tra l'80% e il 90% delle volte ([0028]), percentuali discrete ma non sufficienti per avere la totale garanzia.<div></div>
I fattori che ostacolano la realizzazione di algoritmi di intelligenza artificiale per la disambiguazione sono molteplici:
# Differenze tra dizionari impiegati: i database prima citati si basano su varie fonti che raggruppano semanticamente in maniera diversa i vocaboli, quindi programmi sviluppati con dizionari diversi generalmente hanno performance differenti.
# Complessità della codifica di parte del discorso: per poter disambiguare correttamente un termine è importante riuscire a comprendere correttamente il contesto in cui è inserito, operazione non banale.
# Varianza tra giudici: i supervisori dell'apprendimento degli algoritmi possono avere opinioni diverse, o semplicemente sbagliare, nella valutazione delle disambiguazioni, ciò porta ad algoritmi che hanno comportamenti diversi.
# Impossibilità di applicare la disciplina della ''pragmatica'', ossia la logica del ''buon senso'': per identificare correttamente il senso di alcune parole, ad esempio nella comprensioni di anafore e catafore, è necessario applicare il buon senso.
# Dipendenza del senso delle parole dai contesti: ogni scenario richiede la propria divisione del significato delle parole in sensi rilevanti. In un contesto informatico, ad esempio, il termine "''mouse''" deve essere ricondotto al dispositivo di puntamento, non al cognome del celebre personaggio Disney ''Mickey Mouse''; viceversa dovrà invece avvenire in un contesto di letteratura a fumetti.<div></div>
Laddove la ''WSD'' è una tecnica molto generale e che mira a risolvere un'ambiguità riguardante una qualunque parola, per le finalità del servizio oggetto di questa tesi è sufficiente risolvere le ambiguità dei nomi e dei cognomi.
Uno dei difetti che il servizio presenterebbe adottando un approccio ''WDS'' è legato alla impredicibile formattazione dei documenti, che aggiunge informazione semantica al testo ma introduce complessità nella individuazione automatica delle parti che formano il contesto; un altro difetto dipende dalla vastità del lessico da elaborare, essendo i documenti da trattare forniti dai più disparati utenti, su qualunque genere di argomento e relativi ai più vari ambiti.<div></div>

La strategia che sarà adottata per risolvere la problematica del riconoscimento dei nominativi sarà impostata attraverso un modello ''pattern-based'', impiegando le ''regular expressions'' (''regex''). Esse risultano comunemente usate per effettuare operazioni di ricerca o sostituzione in un testo, di conseguenza se si riesce ad individuare un pattern associato ad un nominativo dato, allora sarà possibile processare il documento ricercando le occorrenze del nominativo e "minimizzarlo" opportunamente.<div></div>

Le ''regular expressions'' risultano particolarmente efficaci poiché, se opportunamente progettate, possono identificare un nominativo indipendentemente dal significato linguistico del contesto in cui è calato, basandosi piuttosto sui singoli caratteri che compongono i lessemi analizzati; permettono, di conseguenza, di effettuare una valutazione estremamente minuziosa, riducendo al minimo le possibilità di errori.<div></div>
Un algoritmo di risoluzione ''pattern-based'' risulta, inoltre, più efficiente nell'esecuzione, in generale, di un algoritmo di intelligenza artificiale; per fornire la risposta il più velocemente possibile ad un utente, fruitore del servizio via web, l'approccio di riconoscimento tramite pattern è il più indicato.<div></div>

====Definizione dei pattern====
Nella progettazione del servizio si adotta, come detto, un approccio ''pattern-based'' per il riconoscimento dei nominativi. In linea di massima è opportuno che vengano riconosciuti più nominativi possibili e allo stesso tempo che la correttezza dell'identificazione di un nominativo sia garantita, quindi bisogna individuare dei pattern non troppo stringenti ma neppure troppo laschi. Per analizzare come i pattern devono essere strutturati si prende come caso di studio un generico nominativo, ad esempio ''Lorenzo Mario Amorosa''. Nel documento esso può comparire esattamente come appena indicato, ma anche in altre plausibili varianti, in cui l'ordine dei termini viene alterato, si pensi ad esempio ad "Amorosa Lorenzo Mario" o "Mario Lorenzo Amorosa", o in altre varianti ancora in cui alcuni nomi non compaiono, come in "Lorenzo Amorosa". Bisogna tuttavia supporre un limite alla variabilità: si osserva infatti che il cognome deve sempre comparire (il solo nome ''Lorenzo'' non è riconducibile a ''Lorenzo Mario Amorosa'') e che esso inoltre deve essere necessariamente anteposto o posposto, ma non interposto, ai nomi (è poco ragionevole ricondurre "Lorenzo Amorosa Mario" a "Lorenzo Mario Amorosa'').<div></div>
Questa prima specifica permette di ricondursi a una soluzione generale, sufficiente nella maggior parte dei casi, ma che non risolve alcune criticità. Un nominativo può, in alcuni documenti, comparire manifestandosi unicamente attraverso il cognome (riferendoci all'esempio precedente, ''Lorenzo Mario Amorosa'' apparirebbe nella forma ''Amorosa''). Sorge qui il problema che molti dei cognomi italiani hanno un significato proprio nel linguaggio comune; ad es., nella frase ''una relazione amorosa è bella'' è errato considerare la parola ''amorosa'' come cognome di un nominativo. Per risolvere questo genere di ambiguità si potrebbe pensare che per stabilire che il termine ''Amorosa'' sia un cognome sia sufficiente verificare che esso inizi con una lettera maiuscola, ma ciò può verificarsi anche perché la parola si trova ad inizio di frase. Inoltre, vari cognomi italiani possono iniziare con una lettera minuscola (''de Angelis'', ''d'Onofrio'', etc.), quindi basare l'identificazione di un cognome sul fatto che la sua prima lettera sia in maiuscolo non è in generale un metodo valido. Volendo in maniera prioritaria garantire il corretto funzionamento del servizio, e quindi attuare le procedure di anonimizzazione solo sui nominativi senza applicarle erroneamente ad altri termini, risulta necessario evitare il trattamento dei nominativi che si manifestano con i soli cognomi. Per via del contesto e dei significati che i cognomi possono assumere, infatti, risulta spesso impossibile distinguerli da parole del linguaggio comune.

Ci si concentra, quindi, nello studio di nominativi composti da un cognome seguito o preceduto da uno o più nomi.<div></div>
Si rappresenta dunque in formato di ''regular expression'' il pattern attualmente ideato. Per semplicità espositiva, si definisce il tag <span style="font-family: monospace;"><nomi></span> come l'insieme delle permutazioni di tutti i nomi del nominativo più l'insieme delle permutazioni di tutti i possibili sottoinsiemi di nomi del nominativo. Considerando il nominativo preso precedentemente come caso di studio, ad esempio, si avrebbe:
<div></div>
<span style="font-family: monospace;"> <nomi> = Lorenzo Mario|Mario Lorenzo|Lorenzo|Mario</span>
<div></div>
Posto inoltre il tag <span style="font-family: monospace;"><cognome></span> ad indicare il cognome contenuto nel nominativo e il tag <span style="font-family: monospace;"><regex></span> ad indicare la ''regular expression'' associata al nominativo, si ottiene:
<div></div>
<span style="font-family: monospace;"> <regex> := <cognome> (<nomi>)|(<nomi>) <cognome></span>
<div></div>
Una osservazione sottile ma di fondamentale importanza per la corretta progettazione delle ''regular expressions'' sta nella piena comprensione della semantica dell'operatore di scelta, espresso con il carattere ''pipe'' ("|"). Un qualunque ''engine'' di elaborazione delle ''regex'', infatti, interrompe la valutazione di una stringa non appena può stabilire se tale stringa fa match o meno con il pattern dato, senza quindi necessariamente valutarlo nella sua interezza, come parimenti avviene nelle valutazioni ''a corto circuito'' delle espressioni logiche nei linguaggi di programmazione. Ogni nominativo avrà a sè associato un pattern che lo rappresenta in più possibili sequenze di caratteri; per effettuare una corretta "minimizzazione" dei dati è necessario che le sequenze contenenti tutti i nomi sia poste per prime, mentre quelle contenenti un singolo nome per ultime.<div></div>
In questa prima formulazione della ''regex'', inoltre, si è posto come separatore unicamente lo spazio bianco, ma alcuni documenti potrebbero contenere dei nominativi i cui termini sono separati da altri caratteri, come ad esempio una virgola nel caso di "Amorosa, Lorenzo Mario". Per poter quindi identificare un nominativo anche in questi casi, si potrebbe considerare un qualunque carattere di interpunzione come possibile separatore dei termini del nominativo.
Adottando questa soluzione si ha però come effetto collaterale che risultano critici i casi in cui nel testo sono presenti dei nominativi soggetti ad omonimia. Si consideri una generica frase contenente una sequenza di nominativi, ad esempio ''Amorosa Lorenzo, Mario Giacomo e Fabio Rossi'', e si supponga che i nominativi da trattare siano ''Amorosa Lorenzo Mario'', ''Mario Giacomo'' (in cui la parola ''Mario'' è il cognome) e ''Fabio Rossi''. Gli ultimi due nominativi compaiono nella frase nella loro forma estesa, mentre il primo compare con il solo nome ''Lorenzo'' (eventualità possibile considerando la definizione del pattern precedentemente data). Considerando la virgola come carattere separatore dei termini del nominativo, la sequenza di parole ''Amorosa Lorenzo, Mario'' sarebbe ricondotta, venendo elaborata per prima, ad ''Amorosa Lorenzo Mario'', mentre rimarrebbe non trattata la parola ''Giacomo'', in quanto il cognome ''Mario'' che gli era associato è stato già identificato come un nome del nominativo ''Amorosa Lorenzo Mario'' ed il termine ''Giacomo'' preso singolarmente non rappresenta un nominativo.<div></div>
Prima di valutare ulteriormente le problematiche relative alle omonimie, si possono scegliere due approcci per risolvere questo specifico caso:
# Si riconduce una sequenza di parole ad un nominativo se e solo se tutti i suoi nomi sono contenuti nella sequenza
# Si considerano come separatori dei termini contenuti nei nominativi solo spazi bianchi, tabulazioni e a capo, non gli altri segni di punteggiatura.
<div></div>
Entrambe le strategie sono valide, in quanto risolvono il problema garantendo la corretta identificazione dei nominativi, ma allo stesso tempo entrambe presentano lo svantaggio di ridurre le sequenze di parole riconducibili a dei nominativi, aumentando le possibilità che alcuni di essi non vengano trattati.
Si consideri nuovamente il nominativo preso come caso di studio ''Amorosa Lorenzo Mario'': applicando la prima strategia, non sarebbe possibile ricondurgli la sequenza ''Amorosa Lorenzo'', mentre applicando il secondo metodo non sarebbe riconducibile la sequenza ''Amorosa, Lorenzo Mario''.
Si decide di attuare la seconda strategia, in quanto è opportuno non imporre vincoli troppo stringenti sui nomi e poiché nella gran parte dei casi i termini dei nominativi nei documenti sono separati tra loro da caratteri quali spazi bianchi, tabulazioni ed a capo.<div></div>
Un altro elemento su cui porre l'attenzione è la possibilità che i documenti da trattare contengano dei nominativi scritti interamente in maiuscolo o minuscolo, di conseguenza è conveniente che le ''regular expressions'' siano progettate ''case-insensitive''.<div></div>
Un ulteriore punto su cui bisogna soffermarsi è la posizione all'interno di un periodo in cui un nominativo può comparire, in particolare si vogliono evitare quei casi critici in cui uno dei termini del nominativo è una sotto-stringa di un'altra parola del testo (si pensi ad ''amorosa'' in ''clamorosa''). Come regola generale si può stabilire che è sempre necessario che un nominativo sia preceduto e seguito da un ''carattere non alfabetico''. Un caso particolare si presenta quando il nominativo è posto ad inizio o a fine documento, situazione in cui quindi esso non è preceduto o non è seguito da alcun carattere: entrambe le posizioni sono da considerare corrette.<div></div>
È opportuno ora definire il concetto di ''carattere non alfabetico'', e ciò si può fare più facilmente ragionando sul problema in logica positiva; infatti risulta più semplice individuare quei caratteri che rappresentano lettere piuttosto che quelli che rappresentano segni di interpunzione ed individuare ogni altro carattere che non può mai comporre una parola.

Inquadrando lo scenario di applicazione del servizio, molto probabilmente l'utente vorrà trattare un documento scritto nella lingua di uno dei paesi dell'Unione Europea, poiché il ''GDPR'' vige nei soli paesi membri dell'Unione.
Si può, quindi, ipotizzare che i documenti trattati possono sì contenere parole e nominativi stranieri, ma che i caratteri contenuti siano appartenenti all'alfabeto latino (''Latin script''), usato in molti stati nel mondo e da tutti i principali stati europei (fatta eccezione per la Grecia ed alcuni stati che scrivono in caratteri cirillici).
Inoltre, testi scritti in altri alfabeti, come esempio il cinese, l'arabo o il cirillico, vengono generalmente traslitterati. Considerare, quindi, ''caratteri non alfabetici'' tutti i caratteri diversi dalle lettere contenute nell'alfabeto latino sarebbe di conseguenza estremamente riduttivo ed inoltre in questo modo non si terrebbe conto delle lettere accentate, molto utilizzate anche nella lingua italiana.
<div></div>(XXXX QUI IMG [0F00])<div></div>
Per risolvere il problema facciamo riferimento alla codifica standard Unicode dell'alfabeto latino ([0022]); in essa è possibile individuare, oltre ai caratteri rappresentanti le lettere nella codifica ''ASCII'' classica, i caratteri rappresentanti le lettere nella codifica standard ''ISO/IEC 8859-1'' ([0023]), encoding orientato principalmente alla rappresentazione delle lingue dell'Europa occidentale.

<div></div>
<center><i>Caratteri latini nei primi due blocchi dello standard Unicode</i></center>
{| class="nounderlines" border="1" cellpadding="2" cellspacing="0" style="border-collapse:collapse"
|----- align="center"
!style="background:#ccf; text-align:center; font-weight: bold;"|U+
!style="text-align:center; font-weight: bold;"|0||style="text-align: center; font-weight: bold;"|1||style="text-align: center; font-weight: bold;"|2||style="text-align: center; font-weight: bold;"|3||style="text-align: center; font-weight: bold;"|4||style="text-align: center; font-weight: bold;"|5||style="text-align: center; font-weight: bold;"|6||style="text-align: center; font-weight: bold;"|7||style="text-align: center; font-weight: bold;"|8||style="text-align: center; font-weight: bold;"|9||style="text-align: center; font-weight: bold;"|A||style="text-align: center; font-weight: bold;"|B||style="text-align: center; font-weight: bold;"|C||style="text-align: center; font-weight: bold;"|D||style="text-align: center; font-weight: bold;"|E||style="text-align: center; font-weight: bold;"|F||style="text-align: center; font-weight: bold;"|Block||style="text-align: center; font-weight: bold;"|#
|-
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0040
|style="background:#fff"|@||A||B||C||D||E||F||G||H||I||J||K||L||M||N||O
|rowspan="4" style="background:#fff" align:"center"|C0 Controls and Basic Latin<br>0000–007F<br>(identical to ASCII)
|rowspan="4" style="background:#fff"|52
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0050
|P||Q||R||S||T||U||V||W||X||Y||Z||style="background:#fff"|[||style="background:#fff"|\||style="background:#fff"|]||style="background:#fff"|^||style="background:#fff"|_
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0060
|style="background:#fff"|`||a||b||c||d||e||f||g||h||i||j||k||l||m||n||o
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0070
|p||q||r||s||t||u||v||w||x||y||z||style="background:#fff"|{||style="background:#fff"||||style="background:#fff"|}||style="background:#fff"|~||style="background:#fff; font-size:75%"|DEL
|-
!colspan="19"|
|----- align="center" style="background:#fff"
!style="background:#fff; text-align:center; font-weight: bold;"|00A0
| ||¡||¢||£||¤||¥||¦||§||¨||©||ª||«||¬||||®||¯
|rowspan="6" style="background:#fff" align="center"|C1 Controls and Latin-1 Supplement<br>0080–00FF<br>(identical to ISO/IEC 8859-1)
|rowspan="6" style="background:#fff"|62
|----- align="center" style="background:#fff"
!style="background:#fff; text-align:center; font-weight: bold;"|00B0
|°||±||²||³||´||µ||¶||·||¸||¹||º||»||¼||½||¾||¿
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00C0
|À||Á||Â||Ã||Ä||Å||Æ||Ç||È||É||Ê||Ë||Ì||Í||Î||Ï
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00D0
|Ð||Ñ||Ò||Ó||Ô||Õ||Ö||style="background:#fff"|×||Ø||Ù||Ú||Û||Ü||Ý||Þ||ß
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00E0
|à||á||â||ã||ä||å||æ||ç||è||é||ê||ë||ì||í||î||ï
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00F0
|ð||ñ||ò||ó||ô||õ||ö||style="background:#fff"|÷||ø||ù||ú||û||ü||ý||þ||ÿ
|---- align="center" style="background:#f66"
|}
<div></div>

I caratteri indicati in rosso nella tabella sono tutti i possibili ''caratteri alfabetici'' che compaiono nei documenti scritti in 29 lingue diverse ([0023]), tra le quali sono presenti l'italiano, l'inglese, lo spagnolo, il tedesco e il portoghese.
Aggiungendo pochi altri caratteri all'insieme dei ''caratteri alfabetici'' appena mostrati, si riesce a rappresentare ogni parola di altre 12 lingue ([0023]), tra cui il francese, l'olandese, il ceco e il turco.<div></div>
I caratteri mostrati in tabella corrispondono ad una parte dei primi due blocchi dello standard Unicode che codificano l'alfabeto latino e, come già accennato in precedenza, essi sono presenti negli standard ''ASCII'' e ''ISO/IEC 8859-1''. I rimanenti ''caratteri alfabetici'', invece, sono presenti in estensioni dello standard Unicode per il ''Latin script''. Queste estensioni sono state realizzate per fornire il massimo supporto a tutte le lingue e contenenti molti simboli ad uso speciale, come ad esempio per la rappresentazione dei fonemi. Si osserva, inoltre, che i ''caratteri alfabetici'' definiti nelle estensioni dello standard Unicode sono presenti anche nella codifica ''ISO/IEC 8859-2'' o nelle versioni successive ([0023]).<div></div>
Definiti i ''caratteri non alfabetici'' come elementi di separazione tra un nominativo ed il testo in cui esso è inserito, occorre definire opportunamente la ''regex'' che al nominativo è associata.

Utili strumenti messi a disposizione dalle ''regular expressions'' sono i gruppi speciali ''lookahead'' e ''lookbehind''. Un pattern di un nominativo deve essere preceduto o seguito da una prestabilita sequenza di caratteri, la quale però non è parte del nominativo. Utilizzando i due costrutti citati, è possibile far sì che nell'elaborazione di una stringa facciano match solamente le parole effettivamente appartenenti al nominativo, non i caratteri che lo delimitano dal resto del testo, e allo stesso tempo che un nominativo faccia match se e solo se preceduto o seguito da una certa sequenza di caratteri. <div></div>
Per esprimere nella sintassi delle ''regex'' un carattere letterale in un qualunque alfabeto si può utilizzare il costrutto ''\p{L}'', che però risulta molto generale e troppo lasco per i requisiti considerati. Si può piuttosto valutare l'impiego del costrutto ''\p{Latin}'', il quale identifica un qualunque carattere alfabetico presente nell'alfabeto latino. Tra i caratteri corrispondenti al costrutto, però, ve ne sono alcuni che per le specifiche del servizio devono essere considerati ''caratteri non alfabetici'', come ad esempio i caratteri dei fonemi, i segni diacritici e gli indicatori ordinali; di conseguenza è necessario individuare una strategia ad hoc per risolvere questa problematica.<div></div>
Per chiarezza espositiva, si definisce il tag <span style="font-family: monospace;"><start></span>, per indicare un qualunque carattere non alfabetico o l'inizio stringa, il tag <span style="font-family: monospace;"><end></span>, per indicare un qualunque carattere non alfabetico o il fine stringa, ed il tag <extra>, per indicare i ''caratteri alfabetici'' non presenti negli standard ''ASCII'' o ''ISO/IEC 8859-1'':<div></div>
<span style="font-family: monospace;">
<extra> := ĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ
<br/>
<start> := (?<=[^A-Za-zÀ-ÖØ-öø-ÿ<extra>]|^)
<br/>
<end> := (?=[^A-Za-zÀ-ÖØ-öø-ÿ<extra>]|$)
</span>
<div></div>
Si osserva che si sono utilizzati i gruppi speciali prima descritti e che si sono inseriti i caratteri dello standard Unicode presentati in precedenza. Si definisce nuovamente la ''regular expression'' associata ad un generico nominativo. Applicando i tag appena definiti, il costrutto ''(?i)'' che rende il pattern ''case-insensitive'' ed il costrutto ''\s'' che rappresenta un carattere qualunque tra i separatori non visibili, ossia ''\r \n \t \f \v'' e lo spazio bianco, si ottiene:<div></div>
<span style="font-family: monospace;">
<regex> := (?i)(<start><cognome>\s+(<nomi>)|(<nomi>)\s+<cognome><end>)
</span>
<div></div>
Si osserva, inoltre, che in questa nuova formulazione della ''regular expression'' i nomi sono da intendersi separati tra loro da ''\s+''.<div></div>
A questo punto si è quasi giunti alla formulazione finale del pattern da associare ad un nominativo, rimangono solo da trattare alcuni casi critici non ancora risolti.<div></div>
Si è già presentato in precedenza il problema legato al fatto che alcuni cognomi possono avere un significato proprio nel lessico comune e che ciò costringeva, quindi, ad abbandonare l'idea di trattare nominativi formati dal solo cognome. Questa problematica di ambiguità si presenta anche con alcuni nomi (si pensi, ad esempio, al nome ''Gioia''). Ciò non rappresenta generalmente un problema, in quanto la coppia nome-cognome che forma il nominativo, presa complessivamente, non è soggetta ad ambiguità. Esistono, però, dei casi in cui questo non è vero. Si prenda in analisi il nominativo ''Gioia Grande'': risulta evidentemente soggetto a rischio di ambiguità. Una soluzione che si può adottare, per risolvere questo caso critico, si basa sull'associazione di un pattern più stringente ai nominativi. In particolare, si osserva che i nomi propri di persona compaiono sempre ed obbligatoriamente, in un documento grammaticalmente corretto, con la prima lettera maiuscola ([0024]). I cognomi, invece, non sono soggetti ad una regola così stringente: un cognome iniziante con una lettera minuscola (come ''de Rosa'') in alcuni casi, ad esempio se posto dopo un punto fermo, può comparire scritto con la prima lettera sia maiuscola che minuscola; naturalmente, in nessuna occorrenza un cognome che inizi con una lettera maiuscola potrà comparire con una minuscola. <div></div>
Occorre quindi ridefinire, alla luce di queste osservazioni, la ''regex'' associata ad un nominativo, poiché precedentemente era stata posta interamente ''case-insensitive''. Nel pattern, in particolare, i nomi dovranno sempre iniziare con una maiuscola, mentre i cognomi avranno questo vincolo solo se nel nominativo compaiono con la prima lettera maiuscola. Si mostra quindi quali sono i tag <span style="font-family: monospace;"><nomi></span> e <span style="font-family: monospace;"><cognome></span> associati a due nominativi, ad esempio ''Gioia Grande'' e ''Antonio de Rosa''. <div></div>
Per ''Gioia Grande'' si ha:<div></div>
<span style="font-family: monospace;"><nomi> = G((?i)ioia)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = G((?i)rande)</span>
<div></div>
Per ''Antonio de Rosa'' si ha:<div></div>
<span style="font-family: monospace;"><nomi> = A((?i)ntonio)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = (?i)de Rosa</span>
<div></div>
Si presenta dunque la definizione finale del tag <span style="font-family: monospace;"><regex></span>. Nella definizione il tag <span style="font-family: monospace;"><nomi></span> è definito il base al numero di nomi del nominativo ed il tag <span style="font-family: monospace;"><cognome></span> è definito in base al carattere iniziale del cognome.<div></div>
<span style="font-family: monospace;">
<regex> := <start><cognome>\s+(<nomi>)|(<nomi>)\s+<cognome><end>
</span>
<div></div>
Vengono inoltre mostrati i valori dei due tag <span style="font-family: monospace;"><nomi></span> e <span style="font-family: monospace;"><cognome></span> per il nominativo preso come caso di studio in fase iniziale, ossia ''Amorosa Lorenzo Mario''. Si ottiene:<div></div>
<span style="font-family: monospace;"><nomi> = L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = A((?i)morosa)</span>
<div></div>
Infine, per completezza, viene mostrata la ''regular expression'', associata a quest'ultimo nominativo, risolvendo tutti i tag che la compongono:
<div></div>
<span style="font-family: monospace;">
<regex> = (?<=[^A-Za-zÀ-ÖØ-öø-ÿĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ]|^)(A((?i)morosa)\s+(L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario))|(L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario))\s+A((?i)morosa))(?=[^A-Za-zÀ-ÖØ-öø-ÿĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ]|$)
</span>
<div></div>

====Gestione delle omonimie====

Nei ragionamenti che hanno portato alla formulazione della ''regular expression'' associata ai nominativi, si è tenuto conto di possibili ambiguità con termini appartenenti al linguaggio comune, risolte con l'introduzione nel pattern di stringhe ''case-sensitive'', e di possibili nominativi posti in sequenza parzialmente omonimi (ossia aventi un nome o il cognome in comune tra loro), gestite con l'imposizione dei soli caratteri separatori non visibili come delimitatori delle parole componenti un nominativo. Per rendere l'analisi completa occorre valutare come ci si debba comportare in altri possibili casi di omonimia. Si osserva, per inciso, che nel pattern individuato nella sezione precedente il tag <span style="font-family: monospace;"><nomi></span> è stato l'unico non definito formalmente. La definizione di tale tag infatti dipende, oltre che dai nomi del nominativo, anche dall'insieme complessivo dei nominativi da trattare presenti nel documento.<div></div>
Il caso più semplice di omonimia, che si verifica quando un solo nome o il solo cognome di un nominativo coincide con un nome o il cognome di un altro (come nel caso di ''Lorenzo Mario Amorosa'' e ''Stefano Amorosa''), risulta già ben gestito dall'attuale formulazione del pattern. Infatti, un riconoscimento è determinato quando almeno un nome e il cognome del nominativo appaiono in sequenza.<div></div>
Il problema si complica quando un nominativo ha due o più componenti in comune con un altro. Si osserva che se l'omonimia riguarda solo i nomi dei nominativi, ciò non risulta problematico, in quanto il cognome, supposto sempre presente nel pattern, funge da elemento di disambiguazione. Si considera da ora, quindi, che i nominativi abbiano il medesimo cognome e si analizzano i casi in cui anche uno o più nomi risultano in comune, attraverso degli esempi:
* Nomi_A = {"Lorenzo", "Mario", "Luca"}; Nomi_B = {"Stefano", "Mario"}
<div></div>(QUI IMG [0F01])<div></div>
In questo caso sono elementi di disambiguazione i nomi ''Lorenzo'' e ''Luca'' per il primo nominativo e ''Stefano'' per il secondo, bisognerà quindi far sì che almeno uno tra tali nomi compaia sempre nelle ''regex'' associate ai nominativi in questione. L'occorrenza ''Mario <cognome>'' rimane ambigua e non può essere trattata.
* Nomi_A = {"Lorenzo", "Mario", "Luca"}; Nomi_B = {"Mario", "Luca"}
<div></div>(QUI IMG [0F02])<div></div>
L'insieme Nomi_B risulta un sottoinsieme di Nomi_A, di conseguenza solo il primo nominativo presenta degli elementi utili per risolvere l'ambiguità. Nel pattern relativo al primo nominativo dovrà essere presente almeno un tra i nomi non in comune, mentre il pattern del secondo nominativo rappresenterà inevitabilmente espressioni ambigue poiché riconducibili all'altro. Le soluzioni possibili sono due: rifiutarsi di effettuare il trattamento del secondo nominativo oppure decretare che esso è riconosciuto se e solo se appare nella sua forma estesa, presentando quindi tutti i nomi. Quest'ultima soluzione è ragionevole e la si sceglie, poiché così si aumentano, per quanto possibile, le sequenze "minimizzabili", e viene inoltre messo in conto di informare l'utente opportunamente sulla gestione di questo genere di omonimia per rendere le operazioni trasparenti.
* Nomi_A = Nomi_B = {"Lorenzo", "Mario", "Luca"}
<div></div>(QUI IMG [0F03])<div></div>
Qualora l'insieme dei nomi dei due nominativi sia identico risulta impossibile distinguerli e non possono in alcun modo essere trattati, poiché l'ordine con cui compaiono i nomi di un nominativo non rappresenta un elemento di disambiguità. I dati appartenenti a persone completamente omonime contenuti in uno stesso documento, quindi, non sono "minimizzabili" distintamente.<div></div>
Si osserva che è di fondamentale importanza che i documenti che gli utenti forniscono siano grammaticalmente corretti, in quanto un errato uso dei segni di interpunzione può rendere impossibile l'applicazione delle ''regular expression''. Si prenda ad esempio una sequenza anomala di caratteri in cui non è corretto l'uso delle virgole, come "''Amorosa Mario Rossi Giacomo''": supponendo che nel documento si vogliano trattare i nominativi ''Amorosa Mario'', ''Rossi Mario'' e ''Rossi Giacomo'', risulta impossibile identificare quali tra questi siano rappresentatati nella sequenza.<div></div>
In conclusione, risultano quindi individuate le strategie che permettono di formulare ''regular expressions'' anche per i nominativi soggetti ad omonimia.

====Formattazione dei documenti====

I documenti prodotti in enti ed organizzazioni presentano generalmente formattazioni e non sono puramente testuali. Si vuole qui considerare quale debbano essere le interpretazioni più adatte da dare agli elementi grafici per rendere sempre efficace il riconoscimento dei nominativi. In particolare, quindi, non si tratteranno gli elementi di punteggiatura, come parentesi o virgolette, poiché già compresi nelle ''regex'', bensì tutti gli elementi che in un pattern composto da caratteri non sono espressi. Si inizia dunque la rassegna:
* Elementi di formattazione del testo
I font, la dimensione dei caratteri, il grassetto, il corsivo, l'evidenziazione e tutti i possibili elementi di modifica della apparizione grafica del testo non alterano il significato dei lessemi coinvolti. Se il cognome di un nominativo è posto in grassetto ed il nome no, ad esempio, la coppia nome-cognome rappresenta sempre il nominativo iniziale; lo stesso vale per gli altri elementi citati.
* Aree di comparizione del testo
In genere ogni documento è formato da più sezioni, ha un corpo principale ed eventuali titoli, note a piè pagina, intestazioni ed altre possibili aree. Il trattamento di "minimizzazione", secondo il ''GDPR'', deve essere effettuato al documento in ogni sua parte, ma ogni sezione deve essere elaborata in maniera indipendente dalle altre sezioni in quanto rappresenta un blocco logico a sé. Ciò significa che, ad esempio, bisogna individuare eventuali nominativi presenti nel titolo, ma non bisogna considerare nominativo una sequenza di parole che è posta in parte nel titolo e in parte nel primo paragrafo del testo.
* Elementi blocco
Gli elementi blocco, come ad esempio le immagini, possono causare un'interruzione netta in un paragrafo, suddividendolo quindi in più blocchi logici, che devono essere analizzati separatamente; tuttavia nel caso in cui questi elementi siano posti ''fluttuanti'', ossia ancorati ai bordi della pagina, il testo scorre in un unico flusso e forma quindi un unico blocco logico.
* Divisione in sillabe
Un problema rilevante nella formattazione del documento è che spesso, per esigenze estetiche, contiene delle parole divise in sillabe poste su righe diverse e separate da un trattino. Ovviamente se un nome va a capo a fine linea non perde il suo significato semantico, bisognerà quindi continuare a riconoscerlo.
* Tabelle
Molti documenti, specialmente quelli contenenti ingenti quantità di nominativi, possono essere strutturati in forma tabellare. Trascurando una trattazione per esteso delle modalità con cui i nominativi potrebbero comparire nelle tabelle, si considera esclusivamente il caso di gran lunga più ricorrente. In genere, infatti, in una tabella contenente dei nominativi, essi sono presenti nella stessa colonna o in colonne contigue: l'una contenente i nomi, l'altra il cognome, o viceversa. Senza basarsi sull'intestazione delle colonne, si può valutare se il contenuto di due celle adiacenti poste su di una stessa riga faccia match con il pattern di un nominativo, ed in caso ciò accada si può affermare la coppia di celle individuata rappresenta un nominativo.<div></div>
Si osserva che si sono fornite solamente le interpretazioni più plausibili e comuni a questi elementi grafici e non si è ideato alcun particolare algoritmo per la loro elaborazione. L'espressione di tali strutture, infatti, è fortemente determinata dal formato in cui il documento è redatto. Si rimanda, quindi, ai capitoli successivi per specificazioni ulteriori della soluzione. Occorre notare, infine, che gli elementi di formattazione non sono descritti da stringhe nel formato delle ''regular expressions'': bisognerà quindi integrare gli elementi presentati in questa sezione con l'approccio ''pattern-based'' adottato.

===Analisi dell'usabilità===

====Elenco dei nominativi da trattare esplicitamente espressi come dati in input====

In questo caso, per usufruire del servizio, l'utente deve fornire un documento contenente una serie di nominativi da trattare. Una garanzia della corretta elaborazione del documento si ha richiedendo all'utente stesso quali siano i nominativi da trattare: in questo modo potranno essere "minimizzati" i dati (cioè i nominativi) di tutte e sole le persone espressamente richieste. In molti plausibili scenari, infatti, è necessario anonimizzare solo alcuni dei nominativi presenti nel documento; ad esempio in un atto giudiziario serve anonimizzare le parti in causa ma non i magistrati.

Questa configurazione del servizio permette quindi all'utente di avere il massimo controllo possibile del risultato. Tuttavia questo approccio è poco pratico nel caso in cui i documenti da trattare contengano grandi quantità di nominativi diversi e, magari, l'utente che ne richiede il trattamento non li conosce; si pensi ad esempio a lunghe graduatorie di concorsi o altro. Si osserva inoltre che anche per pochi nominativi l'usabilità può degradare, se l'inserimento viene fatto con estemporanea digitazione, esposta anche al rischio di possibili errori di battitura, con conseguenti noiose ripetizioni delle operazioni.

Si osserva, infine, che il sistema progettato è sufficientemente robusto nel trattare i nominativi in input espressi da un utente che ha digitato caratteri maiuscoli o minuscoli violando le convenzioni grammaticali. Supposto che il documento trattato debba essere grammaticalmente corretto, infatti, si ha la garanzia che i nomi ivi presenti comincino con una maiuscola; è sufficiente, quindi, forzare una conversione ''to-upper-case'' dei nomi inseriti dall'utente e le ''regex'' progettate funzionano correttamente. Un discorso a parte va fatto per i cognomi inseriti dall'utente, in quanto essi possono comparire con la prima lettera sia maiuscola che minuscola. L'inserimento di un cognome iniziante con una minuscola non crea grossi problemi, in quanto in tal caso la ''regex'' risultante sarebbe totalmente ''case-insensitive'' per il cognome, mentre l'aggiunta di un cognome cominciante con una maiuscola determina una ''regex'' ''case-insensitive'' per la prima lettera del cognome; qualora quindi un utente inserisse un nominativo tutto in maiuscolo, le occorrenze del cognome, presenti nel documento, inizianti con una lettera minuscola non verrebbero riconosciute.
Per le altre lettere dopo la prima, sia per i nomi che per i cognomi, il pattern è stato progettato ''case-insensitive'', quindi non emergono problemi. <div></div>
In sintesi, il rischio che vengano introdotte delle ambiguità lessicali, incaricando l'utente dell'inserimento dei nominativi, è piuttosto basso ed il controllo che si ha sui nominativi è il massimo desiderabile, mentre i requisiti di usabilità risultano penalizzati.

====Elenco dei nominativi da trattare dedotti automaticamente da un dizionario====

Se si desidera privilegiare la tematica dell'usabilità nella progettazione del servizio, risulta necessario individuare delle strategie che semplifichino il più possibile i compiti che devono essere svolti dall'utente. L'unica operazione che inevitabilmente resta a suo carico è l'upload del documento da trattare; non è infatti necessario richiedergli l'elencazione dei nominativi dei nominativi da trattare, in quanto questi possono essere dedotti automaticamente impiegando dei dizionari, dei quali va quindi valutato il contenuto e le modalità di utilizzo. <div></div>

Si scarta subito l'ipotesi di dedurre automaticamente i nominativi basandosi unicamente sul fatto che le iniziali di nomi e cognomi siano maiuscole; come già argomentato infatti l'uso delle lettere maiuscole non è limitato solo a questi usi e, inoltre, non si può avere la certezza che un cognome inizi con una maiuscola.

Sono disponibili fortunatamente alcuni dizionari di nomi ed altri di cognomi, in diverse lingue; si fa qui riferimento a quelli di "Data World" (un'azienda focalizzata sulla raccolta, produzione e pubblicazione di dataset: https://data.world) ([0037]).

Si inizia l'analisi inquadrando le dimensioni che un dizionario contenente nomi o cognomi avrebbe. Risalta subito all'occhio la differenza tra il numero di termini contenuti nei due casi: facendo riferimento ai soli nomi e cognomi italiani, risultano esistenti circa 350.000 cognomi ([0036]) e circa 9.000 nomi, dei quale circa 5.000 maschili e circa 4.000 femminili ([0037]); il numero dei cognomi è quindi quasi 40 volte più grande del numero dei nomi.<div></div>
Si ipotizza, per chiarire le idee, di applicare questi dizionari in uno scenario reale, in cui, ad esempio, si vuole trattare un documento di 10 pagine contenente 5.000 parole. Si trascurano inoltre i meccanismi che permettono di ricondurre un nome od un cognome ad un nominativo per concentrarsi unicamente sul numero di confronti necessari da effettuare nell'elaborazione. Nel peggiore dei casi possibili, ossia quando nessuna parola del documento compare tra i termini del dizionari, e dove occorre quindi confrontare ogni singola parola del documento con tutti i termini del dizionario, per semplice moltiplicazione si ottiene che l'impiego di un dizionario di nomi darebbe luogo a 45.000.000 confronti, mentre un dizionario di cognomi ben a 1.750.000.000 confronti. Se invece le parole nel documento fossero 50.000 si avrebbero 450.000.000 di confronti nel primo caso e 10.750.000.000 nel secondo. In sintesi, sebbene il rapporto tra il numero di confronti nei due casi rimanga sempre costante (circa 1:40) indipendentemente dalla lunghezza del documento, la differenza tra il numero di confronti cresce proporzionalmente al numero di parole che vengono sottoposte all'elaborazione. Per quantificare, infine, attraverso un unità di tempo, la differenza esistente tra l'impiego delle due diverse tipologie di dizionario, si realizza un semplice programma java, di cui si riporta qui sotto il contenuto del metodo principale, che realizza i confronti necessari attraverso l'uso di ''regular expression'':
<div></div>
<div style="font-family: monospace;">
final String regex = "\bLorenzo\b";<br/>
final String string = ... //testo di prova<br/>
<br/>
final Pattern pattern = Pattern.compile(regex, Pattern.MULTILINE);<br/>
final Matcher matcher = pattern.matcher(string);<br/>
int start, total;
<br/>
start = System.currentTimeMillis();
while (matcher.find()) {
System.out.println("Full match: " + matcher.group(0));
for (int i = 1; i <= matcher.groupCount(); i++) {
System.out.println("Group " + i + ": " + matcher.group(i));
}
} <br/>
total = System.currentTimeMillis() - start;
System.out.println("Total: " + total + " ms");
</div>
<div></div>
Eseguendo il test più volte, inserendo fino a 10 occorrenze della parola "Lorenzo" nel testo, si ha un tempo di elaborazione medio di circa 3 ms, con prestazioni di picco di 2 ms, ottenibili con poche occorrenze del nome presenti, e tempo di attesa massimo di 6 ms, dovuto alla presenza invece a una presenza più frequente del nome nel testo.
Questo fenomeno si comprende meglio ricordando che, come spiegato nel capitolo precedente, le ''regular expressions'' ottimizzano la ricerca, considerano le stringhe del testo trattato solo finché necessario, ossia fino a quando non vi è certezza che esse corrispondano o non corrispondano ad un match. Ogni volta che nel testo si presenta una parola che inizia con una lettera diversa dalla 'L' di "Lorenzo", la ricerca procede direttamente con la valutazione della parola successiva, ignorando i rimanenti caratteri della parola.

Risulta, invece, più onerosa la verifica della corrispondenza tra una stringa ed il pattern desiderato, poiché in questo caso vanno elaborati tutti i caratteri della parola. Come caso limite, si è posta come stringa da elaborare la sequenza di caratteri "Lorenzo " ripetuta 500 volte: il tempo di esecuzione medio del programma risultante, a parità di piattaforma, è stato di circa 25 ms.

Un'altra diretta conseguenza di questo meccanismo di confronto è che all'aumentare del numero di parole nel documento non corrisponde un eccessivo aumento del tempo di esecuzione: considerando un documento di 5000 parole, con 0 occorrenze del nome "Lorenzo" il tempo di esecuzione medio risulta di 9 ms, con 10 occorrenze di 10 ms, con 100 occorrenze di 15 ms.

Occorre precisare, prima di formulare ulteriori ragionamenti, che in documento di 5.000 parole potranno essere presenti al più 2500 coppie nome-cognome; in un dizionario con più di 2.500 termini almeno uno di questi non contribuirà nell'individuazione di un nominativo. Se poi sono presenti altre parole oltre ai nominativi nel documento, la percentuale di nomi che presenterà 0 occorrenze crescerà di conseguenza. Ad ogni modo, si sceglie di sviluppare i ragionamenti considerando necessario il tempo medio di 10 ms per individuare le occorrenze di un termine di un dizionario in un documento di 5.000 parole; questo tempo è sicuramente maggiore rispetto al caso reale, ma valutando per eccesso questo valore è possibile trascurare il tempo impiegato nelle altre operazioni di routine a supporto dell'algoritmo di ricerca.

Ritornando all'esempio di partenza, considerando quindi necessari 10 ms per individuare le occorrenze di un termine di un dizionario in un documento di 5.000 parole, risulta che l'identificazione di tutti i cognomi contenuti nel testo richieda circa 3.500 secondi, (quasi un'ora!), mentre l'individuazione dei nomi "solo" 90 secondi.
I tempi di attesa che l'utente dovrebbe aspettare sono estremamente elevati e irragionevoli, specialmente se calati nel contesto nelle ''web application''. Come primo espediente per ovviare al problema si decide di abbandonare completamente l'idea di impiegare un dizionario di cognomi, in quanto, seppur si individuassero delle soluzioni in grado di effettuare il riconoscimento di tutte le occorrenze di un termine in un documento indipendentemente dalla lunghezza in solo 1 ms (irreale), sarebbero comunque necessari 3 minuti e 50 secondi per l'elaborazione. Non verranno quindi neppure trattate possibili soluzioni che prevedono l'applicazione di entrambi i dizionari.

I 90 secondi richiesti dal dizionario di nomi, invece, risultano anch'essi eccessivi, ma attraverso opportune valutazioni si possono individuare delle strategie che consentono la minimizzazione del tempo necessario all'elaborazione dei documenti. Tali metodi di ottimizzazione saranno trattati in un successivo capitolo, mentre ora ci si continua a concentrare sulle modalità di impiego del dizionario.

Per inciso, si osserva che i problemi di efficienza sono strettamente legati al riconoscimento automatico dei nominativi, in quanto in questo caso devono essere applicate quasi una decina di migliaia di ''regex'' diverse; nel caso in cui i nominativi da elaborare e le ''regex'' a loro associate siano noti, si ha a che fare con un numero esiguo di pattern da trattare e l'esecuzione del programma risulta infinitamente più rapida.<div></div>

Per migliorare l'efficacia del servizio sarebbe opportuno introdurre nel dizionario anche nomi stranieri, sempre più diffusi in una società sempre più globalizzata. Il tempo di esecuzione medio del riconoscimento, già critico, crescerebbe ulteriormente: si decide allora di introdurre nel dizionario i soli nomi inglesi, in totale quasi 5500 ([0037]). Considerando sempre un tempo medio di esecuzione di 10 ms per nome, con un dizionario di circa 14.500 termini si avrebbe un tempo di esecuzione medio complessivo di 145 secondi, ossia pari a 2 minuti e 25 secondi, e risulta ancora possibile effettuare alcune ottimizzazioni che lo riducono ad un livello accettabile.

Una volta individuati i nomi contenuti nel documento occorre stabilire se essi fanno parte di un nominativo, progettando un'opportuna ''regular expression''. È importante notare che per conseguire questo scopo bisogna individuare la soluzione più efficiente possibile.

Un nominativo, come già ripetuto più volte, è composto da uno o più nomi e da un cognome. Individuato un nome, la priorità che si ha è verificare se accanto ad esso sia presente un cognome. Finora i cognomi sono stati supposti non regolamentati da alcun pattern specifico, ma è necessario formularne almeno uno per consentirne il riconoscimento automatico. È ragionevole supporre che un cognome sia formato da massimo due parole, separate da spazio o apostrofo, sempre inizianti entrambe con una maiuscola, fatta eccezione per la prima parola laddove essa sia una preposizione semplice o articolata oppure un articolo, tenendo conto dei possibili troncamenti, come <i>d'</i> e <i>dell'</i>. Inoltre per verificare se un termine adiacente al nome trovato rappresenti un nome si evita di impiegare nuovamente il dizionario per non gravare ulteriormente sul tempo di esecuzione. Inoltre, si nota che avendo supposto un cognome composto da massimo due parole inizianti con una lettera maiuscola, un altro nome, oltre quello trovato dal dizionario, viene già automaticamente riconosciuto qualora il cognome sia composto da una sola parola. Rinunciando ad individuare nominativi composti da tre nomi o più, si formula una ''regular expression'' per il riconoscimento automatico in seguito al identificazione di un nome, qui indicato con il tag <span style="font-family: monospace;"><nome></span>, supponendo il cognome come precedentemente indicato e ipotizzando la presenza di un ulteriore nominativo.
<div></div>
<div style="font-family: monospace;">
<prep> := d((a|e)(l(l[aeo]?)?|i|gli?)?|i)?|(ne|a|su)(l(l[aeo]?)?|i|gli)?|l[aeo]?|co[iln]?|i[ln]?|gli|per

<cognome> := (([A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]*|<prep>)('|\s))?[A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]+

<second_name> := [A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]+

<regex> := (<second_name>\s)?(<nome>)\s<cognome>|<cognome>\s(<nome>)(\s<second_name>)?
</div>
<div></div>
Nella scrittura della ''regex'' si è prestata particolare attenzione all'utilizzo della simbologia per rendere l'espressione il più performante possibile, attraverso il massimo sfruttamento dei cortocircuiti logici e l'opportuno ordinamento dei caratteri (sono stati anteposti i caratteri comuni a più preposizioni od articoli). Inoltre, per alleggerire la ''regex'' si è rinunciato all'utilizzo dei caratteri dell'alfabeto latino non appartenenti ai primi due blocchi Unicode.
<div></div>
È mostrata in figura la corretta elaborazione di 57 possibili casi di cognomi diversi
<div></div>(QUI IMG [0F04])<div></div>
Si osserva tuttavia che in alcune circostanze, come nella frase "''di Amorosa Lorenzo non si hanno notizie''", accade che un parola ("''di''" in questo caso), non sia parte del cognome ma il programma non è in grado di riconoscerlo. Questa ambiguità è fortemente dipendente dal contesto e non è possibile trattarla senza significativi degradi delle performance; quindi è necessario rinunciare a trattarla, accettando riconoscimenti erronei. In altre situazioni, invece, dove magari si sta elaborando la stringa contenente il nominativo ''Mario Lorenzo'', risulta impossibile determinare quale tra i due termini sia il nome e quale il cognome; cioè significa che l'unico trattamento di "minimizzazione" automatico che risulta ragionevole applicare è la sostituzione del nominativo con uno pseudonimo, non il troncamento o l'alterazione dei nomi.
In conclusione, con il riconoscimento automatico dei nominativi si migliora complessivamente l'usabilità del servizio, in quanto l'utente non deve digitare i nominativi, ma la latenza introdotta è notevole, si è soggetti a rischi di ambiguità e non è in alcun modo esprimibile la preferenza su quali nominativi si desidera "minimizzare" o meno. La soluzione così ideata non risulta quindi adeguata.

====Soluzione ibrida adottata====
Entrambe le tipologie di riconoscimento prima individuate hanno significativi problemi, si cerca quindi di sintetizzare una soluzione in grado di trarre i vantaggi dell'una e dell'altra. Risulta efficace, in particolare, che il documento venga inizialmente trattato tramite dizionari, evitando all'utente l'onere di specificare i nominativi, e che in seguito venga lasciata all'utente la possibilità di intervenire.
Infatti, esso potrebbe voler esprimere delle preferenze su quali nominativi debbano essere trattati tra quelli individuati e gestire gli eventuali errori di riconoscimento dovuti a richieste di trattamento di nominativi aventi un nome non presente nel dizionario o anche dovuti a casi di ambiguità lessicale già presentati.

Una volta inserito il documento e terminata l'elaborazione tramite il dizionario, l'utente può sia richiedere l'immediato download del file ed effettuare le operazioni prima definite, attraverso un'opportuna interfaccia. Per fornire il supporto alle esigenze più disparate, si prevede la possibilità di:
# eseguire download del file trattato unicamente con il dizionario
# ripetere la "minimizzazione" del documento, specificando:
## nuovi nominativi
## quali nominativi tra quelli precedentemente individuati ''non'' si vogliono trattare
## quale parola/e dei nominativi individuati rappresenta il cognome (in tal caso, si possono utilizzare altri metodi, oltre alla sostituzione con pseudonimo, per il trattamento)
## quale parola/e dei nominativi individuati non compone il nominativo (situazione che si verifica quando ci si imbatte in una ambiguità).

Senza soffermarsi in questo momento sull'intera sequenza concreta di interazioni tra utente e servizio, si osserva che l'unico vincolo non funzionale da valutare resta il tempo medio di attesa dell'utente. L'usabilità complessiva è molto buona ed i vincoli funzionali sono soddisfatti.

===Scelta dei formati da trattare===

Una considerazione intuitiva, ed una buona prassi, è che un documento contenente dati personali sia pseudonimizzato o anonimizzato quanto prima possibile e cioè quando è ancora solo nelle mani del suo autore: questo approccio scongiura che informazioni sensibili e dati personali in chiaro ''sfuggano'' in rete.
Si può per questo ragionevolmente ipotizzare che i naturali destinatari del servizio siano gli stessi autori (creatori) che redigono il documento. Nello scenario tipico di utilizzo, infatti, il fruitore del servizio procederà al trattamento dei dati non appena avrà finito di scrivere il documento del quale, essendone autore, potrà scegliere il formato. Si osserva che potrebbe accadere che il documento sia redatto da terzi: in tal caso l'utente che richiede il trattamento può scegliere il formato in maniera indiretta concordandolo con il redattore. Avendo quindi l'utente la possibilità di stabilire il formato del proprio documento, risulta ragionevole progettare un servizio che lavori su un solo formato.
A questo punto occorre individuare quale sia il formato che maggiormente si presta alle finalità del servizio.<div></div>
Una possibilità è quella di richiedere all'utente di inserire come documento da trattare un semplice file di testo in formato ''txt'': in questo modo ci sarebbe il grande vantaggio di trattare file molto semplici, riducendo così al minimo la complessità realizzativa, e inoltre si avrebbe l'indipendenza dagli editor di testo utilizzati, in quanto tutti supportano i file in formato ''txt''.
Risulta tuttavia sconveniente utilizzare questo formato, poiché non ha alcuna capacità espressiva per gestire elementi complessi come tabelle, modifiche allo stile del testo e così via.
Bisogna quindi optare per un formato in grado di gestire questi elementi, al costo di aumentare la complessità della progettazione, ricordando sempre che è necessario allo stesso tempo che tale formato sia supportato da tutti i principali editor di testo.<div></div>
Con facilità è possibile individuare quali sono i formati di testo più comuni oltre al ''txt'': ''doc'', ''docx'', ''odt'', ''pdf'', ''pages'', ''rtf'', ''tex''. Si passa ora dunque a valutare quale tra questi formati potrebbe meglio soddisfare i requisiti prima enunciati.
Facendo una cernita iniziale sulla base delle finalità per le quali un formato è utilizzato, si può immediatamente escludere ''tex'', che trova impiego principalmente in ambito scientifico e matematico. In questo settore, infatti, non è richiesta generalmente l'applicazione delle procedura di trattamento dei dati. <div></div>
Si può inoltre abbandonare l'idea di trattare documenti con estensione ''pages'', formato proprietario di Apple, poiché utilizzati esclusivamente dall'omonimo editor di testo anch'esso proprietario, e i documenti con estensione ''rtf'', acronimo di ''Rich Text Format'', formato proprietario di Microsoft che supporta una formattazione avanzata, poiché, pur gestito da vari editor, è un formato decisamente datato (ultima versione 1.9.1 risalente a marzo 2008 ([0009])). <div></div>
Si esclude inoltre il formato ''pdf'' per motivi di usabilità: molti editor, infatti, consentono di esportare un documento in questo formato ma non permettono di importarlo. Un utente dopo aver effettuato l'anonimizzazione di un documento non può quindi proseguire modificandolo ulteriormente. Il ''Portable Document Format'', infatti, è ideato per realizzare dei documenti destinati alla sola lettura.
L'ultima esclusione, piuttosto immediata da effettuare, riguarda il formato ''doc'', binario e proprietario di Microsoft. Esso infatti risulta, a partire dal 2006, soppiantato dal formato ''docx'', sempre proprietario di Microsoft.

Si giunge infine a valutare quale tra gli ultimi due possibili formati rimanenti, ossia ''docx'' e ''odt'', si presta meglio alle finalità del servizio. In via preliminare si osserva che entrambi i formati possiedono ottime capacità espressive, hanno una struttura interna di simile complessità e sono entrambi supportati dai principali editor di testo. È necessario quindi effettuare delle analisi più approfondite per poter sceglierne uno tra i due.
La struttura del formato ''docx'', sviluppato da Microsoft e formalmente denominato ''Office Open XML Document (OOXML Document)'', è costituita da un file compresso .zip contenente un insieme di file ''XML''. Il formato ''OOXML'' permette la rappresentazione, oltre che di documenti testuali, anche di fogli elettronici (formato ''OOXML 'Workbook'', noto anche come ''xslx'') e di presentazioni (formato ''OOXML Presentation'', noto anche come ''pptx'') ([0008], [0013]).
Il formato inoltre è stato inizialmente standardizzato nel 2006 dall'<i>ECMA</i> (come ''ECMA-376'') e successivamente nel 2008 dall'<i>ISO</i> e dall'<i>IEC</i> (come ''ISO/IEC 29500'') in una versione ''transitional'', retrocompatibile con alcune versioni precedenti del formato contenenti elementi deprecati, e in una versione ''strict'', dove tali elementi non sono ammessi. I due standard sono stati poi successivamente aggiornati e sono tutt'ora oggetto di revisioni ([0002]).

Anche la struttura del formato open source ''odt'', sviluppato dall'<i>OASIS</i> e formalmente denominato ''OpenDocument Text'', è basata su uno zip contenente un insieme di file ''XML''. Inoltre, il formato ''OpenDocument Format (ODF)'' permette di trattare fogli elettronici (formato ''OpenDocument Spreadsheet'', noto anche come ''ods'') e presentazioni (formato ''OpenDocument Presentation'', noto anche come ''odp'') ([0007]). Anche ''OpenDocument Text'' è stato standardizzato, in particolare dall'<i>OASIS</i> stesso nel 2005 e dall'<i>ISO/IEC</i> nel 2006, ed è soggetto a revisioni e aggiornamenti ([0003]).

In sintesi, basandosi sulla struttura dei documenti e sulla standardizzazione dei formati, non è ancora possibile individuare quale sia il formato migliore. L'unico elemento che potrebbe portare punti a favore del formato ''odt'' è che esso, a differenza del formato ''docx'', è aperto, tuttavia, essendo le specifiche di entrambi i formati pubbliche, ciò non rappresenta un fattore determinante nell'elezione del formato.
Entrambi i formati, inoltre, sono largamente supportati dai word processors.

Le seguenti tabelle riepilogano il supporto all'uno ed all'altro formato dei ''word-processors'' più usati, ossia ''Microsoft Office Word'', ''LibreOffice Writer'', ''OpenOffice Writer'' e ''Pages''.
Le tabelle sono tratte da wikipedia ([0000], [0001], [0006]). <div></div>

<center><i>Supporto fornito dagli editor di testo al formato docx</i></center>
{| class="wikitable"
|-
! !! Microsoft Office Word !! LibreOffice Writer !! OpenOffice Writer !! Pages
|-
! Version
|| 2013, 2011 for Mac || All versions || 3.0 || '08
|-
! Operating systems
|| Windows, Mac OS X || Windows, OS X, Linux, Unix, Android || Windows, Linux, Unix, Mac OS X || Mac OS X
|-
! Office suite
|| Microsoft Office || || OpenOffice.org || iWork
|-
! Developer
|| Microsoft || The Document Foundation || Apache OpenOffice || Apple Inc.
|-
! License
|| proprietary || MPL || LGPL || proprietary
|-
! ECMA-376
|| yes || yes || yes || yes
|-
! ISO/IEC 29500:2008
|| yes || yes || ||
|-
! Notes
|| || || Import only ||
|}

<div></div>
<center><i>Supporto fornito dagli editor di testo al formato odt</i></center>
{| class="wikitable"
|-
! !! Microsoft Office Word !! LibreOffice Writer !! OpenOffice Writer
|-
! Version
|| 2007 SP2 || 4.0.3 || 3.0.0
|-
! Operating systems
|| Windows || Unix-based systems, Mac OS X, Solaris || Windows, Linux, Unix-based systems, Mac OS X, Solaris
|-
! Office suite
|| Microsoft Office || || OpenOffice.org
|-
! Developer
|| Microsoft || The Document Foundation || Apache OpenOffice
|-
! License
|| Proprietary || MPL || LGPL
|-
! ISO/IEC 26300:2006
|| yes || yes || yes
|-
! Notes
|| some limitations || Multiple ODF versions supported (ISO/ODF 1.0/1.1/1.2/1.2 Extended) || adjustable ODF version (ISO/ODF 1.2)
|}
<div></div>

Si possono effettuare le seguenti osservazioni:
* ''Microsoft Office Word'' è, in ambiente Microsoft, il word processor maggiormente usato; è molto usato anche in ambiente Apple Mac. Esso offre il pieno supporto al formato ''OOXML Document''; solo parzialmente invece gestisce il formato ''OpenDocument Text'': il processamento di file con estensione ''odt'' con questo editor comporta la perdita di alcune informazioni secondarie.
* ''LibreOffice Writer'', l'editor open source maggiormente utilizzato, supporta pienamente entrambi formati. Nato con lo scopo di gestire i file con formato ''OpenDocument Text'', attualmente supporta completamente anche il formato ''OOXML Document''.
* ''OpenOffice Writer'', un altro degli editor di testo tra i più utilizzati, supporta pienamente ''odt'', mentre è solo in grado di importare i file con estensione ''docx''.
* ''Pages'', il word process installato a default sui Mac della Apple e, di conseguenza anche maggiormente usato su questi dispositivi, non offre supporto al formato ''odt'', ma elabora correttamente i documenti con estensione ''docx'' ([0005],[0004]). <div></div>
Queste osservazioni evidenziano che quindi è impossibile adottare un formato supportato da tutti gli editor; la scelta va allora indirizzata verso quello maggiormente supportato dai word processor più popolari.
Per avere un'indicazione di ''popolarità'', e quindi per poter comprendere meglio quali tra gli editor prima citati siano i più usati, si può fare un'analisi, tramite motori di ricerca, di quanti file con una certa estensione siano presenti in rete.
È possibile, ad esempio, ricercare su Google i file che contengono nel proprio nome una determinata sequenza di caratteri o aventi una certa estensione (''filetype''). Sono qui presentati i risultati delle interrogazioni riguardo ai file aventi formato ''docx'', ''doc'' e ''odt'' ed il cui nome contiene uno dei caratteri, fra i più frequenti, "1" o "a" o "e". L'investigazione è stata effettuata inserendo nella barra di ricerca di Google le stringhe ''1 filetype:docx'', ''a filetype:docx'' e così via.

{| class="wikitable"
|-
! Formato cercato !! Documenti con "1" nel nome !! Documenti con "a" nel nome !! Documenti con "e" nel nome
|-
| docx || 16.900.000 || 12.800.000 || 8.730.000
|-
| odt || 736.000 || 667.000 || 507.000
|-
| doc || 32.300.000 || 26.300.000 || 21.500.000
|}

Effettivamente il formato più diffuso è il ''doc''; tuttavia esso è supportato per retro-compatibilità anche dagli editor che supportano formati ''OOXML'', con i quali non si ha difficoltà nel convertire i documenti dal formato ''doc'' al ''docx''. In conclusione, quale che sia l'editor più diffuso, è ragionevole adottare il formato ''OOXML Document'' per le finalità del servizio, in quanto molto diffuso, ben supportato dagli editor e avente ottime capacità espressive. Di conseguenza i documenti che saranno elaborati dovranno essere forniti dall'utente in tale formato. In successive sezioni verrà approfondita la struttura dei documenti ''OOXML''.

===Privacy by design===

L'Art. 25 del ''GDPR'', con i Considerando 75 e 78, ha per titolo e per oggetto la "protezione dei dati fin dalla progettazione e protezione per impostazione predefinita" ([0035]), perfettamente in linea con i concetti di "minimizzazione", già richiamati.<div></div>
Il senso dell'Art. 25 viene spesso sintetizzato con l'espressione "''PbD - privacy by design, privacy by default''" ([0035]). Il principio fissato nell'Art. 25 dovrà sempre più essere tenuto ben presente nell'ambito dell'ingegneria del software, in quanto impone di adottare nuove cautele nella realizzazione delle applicazioni software.<div></div>
Del principio ''PbD'' si è ben tenuto conto nella progettazione descritta in questa tesi. In particolare, relativamente alla ''privacy by design'', si è fatto in modo che nessun dato personale permanga registrato sul sistema di esecuzione, o altrove, al termine dell'applicazione. Anche laddove l'applicazione termini in modo anomale non vi sono strutture dati superstiti, che restano memorizzate sul sistema.<div></div>
Marginale in questa tesi è la nozione di ''privacy by default'', giacché l'applicazione non offre all'utente alcuna opzione che possa indurlo in errore ed acconsentire a trattamenti dei dati personali, oltre quello realizzato dall'applicazione.<div></div>
È utile osservare quanto sia importante esprimere queste impostazioni di progettazione fra le condizioni d'uso presentate all'utente: esse costituiscono uno dei presupposti affinché l'utente abbia piena fiducia (''trust'') nel servizio, lo utilizzi, lo divulghi, lo renda un servizio di successo.

==Architettura del servizio==

===I componenti software nell'architettura LAMP===

Il servizio è realizzato in forma di ''web-based application'' poiché, come già illustrato nell'introduzione, si intende renderlo disponibile per il massimo numero di utenti possibili. Nella progettazione e realizzazione dell'architettura web si adotta la piattaforma ''LAMP'', il cui nome deriva dall'acronimo dei componenti open source che la realizzano (il sistema operativo Linux, il server HTTP Apache, il sistema per la gestione di database relazionali MySQL ed il linguaggio di programmazione PHP). Poichè il modello è composto da quattro livelli, spesso si parla anche di ''stack LAMP''. Uno degli elementi di forza del modello ''LAMP'' è che i componenti dei vari ''layer'' sono sostituibili, a seconda delle esigenze, con dei componenti più adatti, tipicamente open source ([0015], [0018], [0019]). Basando la piattaforma su un sistema operativo della famiglia di Microsoft Windows, ad esempio, si ottiene uno ''stack WAMP'', mentre se si usa un sistema operativo Mac OS si realizza uno ''stack MAMP''. Un'architettura web basata sul modello ''LAMP'' può, inoltre, essere integrata con software open source che offre utili funzionalità, come, ad esempio, il monitoraggio (''Nagios''), il load balancing (''Linux Virtual Server''), la rilevazione di accessi illeciti (''Snort'') e il security testing (''netsniff-ng''). <div></div>
Si valutano ora brevemente la diffusione dei componenti tradizionali dello ''stack LAMP'' e le alternative maggiormente usate per i vari ''layer''.
Le distribuzioni Linux risultano essere la scelta più comune per l'ultimo ''layer'' dello ''stack''. Secondo W3Techs, infatti, nell'ottobre del 2013, il 58.5% dei web server a livello globale avevano come sistema operativo la distribuzione Debian o Ubuntu, mentre il 37.3% una tra RHEL, Fedora e CentOS([0016]). <div></div>
Tra i web server, Apache risulta essere maggiormente usato. Secondo le stime fatte da Netcraft, a giugno del 2014 circa il 51.9% del milione di siti web più trafficati al mondo usavano un web server Apache, il 19.2% nginx ed il 12.4% Microsoft ([0017]). <div></div>
I principali ''DBMS'' relazionali, oltre a MySQL, che possono essere presenti nello ''stack LAMP'' sono MariaDB e PostgreSQL, mentre tra i ''DBMS NoSQL'' MongoDB risulta essere il più comune. <div></div>
Nello stack, infine, il ruolo di linguaggio di programmazione, solitamente svolto dal linguaggio PHP, spesso è ricoperto dai linguaggi Perl o Python. <div></div>
Si osserva, ad ogni modo, che le informazioni sulla diffusione delle tecnologie non rappresentano un fattore vincolante nella scelta delle stesse, in quanto la piattaforma ''LAMP'' è anche aperta verso molti altri componenti oltre quelli citati; di conseguenza la scelta delle tecnologie da impiegare può essere effettuata basandosi principalmente sui requisiti e sulle specifiche del servizio. <div></div>

===Principi di progettazione per l'architettura===

====Single Responsibility Principle====

Per rendere il servizio maggiormente manutenibile ed estensibile, si presta particolare attenzione al rispetto del ''Single Responsibility Principle'' (''SRP'') ([0020]). Si cerca, quindi, di fattorizzare il software in più moduli, suddividendo tra questi le elaborazioni da svolgere. Un altro importante beneficio che si ottiene dalla fattorizzazione del codice è la riusabilità dei componenti. Ogni singolo modulo, infatti, svolge il proprio compito in maniera indipendente dal resto della applicazione ed è, quindi, riutilizzabile in altri scenari simili senza dover essere re-implementato. Inquadrando meglio questa metodologia di progettazione con i requisiti del servizio e la piattaforma web ''LAMP'', si individuano i due principali compiti a carico dell'applicazione:
* La gestione dell'interazione web con l'utente per la trasmissione del documento e dei nominativi da trattare
* Il processamento del documento per effettuare la "minimizzazione" dei dati.
Questi due differenti ''task'' saranno, quindi, portate a termine da componenti diversi.<div></div>
Progettando la struttura dell'applicazione in questo modo, si disaccoppia completamente la logica di business del servizio dalle interfacce web di comunicazione con l'utente. In un futuro sviluppo sarà possibile, quindi, realizzare nuove interfacce utilizzando altre tecnologie senza dover modificare la logica applicativa.

====Dependency Inversion Principle====

Un altro principio di design architetturale che risulta importante nella progettazione è il ''Dependency Inversion Principle'' (''DIP'') ([0038]). Esso si traduce nella realizzazione di componenti che non dipendono dalle specifiche implementazioni degli altri moduli del sistema, bensì dalle loro ''astrazioni''.
In relazione all'estensibilità e manutenibilità del prodotto software, infatti, l'impiego di moduli dipendenti direttamente dalla definizione dei metodi presenti in altri componenti risulta problematica: il modulo dipendente deve essere re-implementato ad ogni variazione del modulo da cui dipende.
Nella programmazione orientata agli oggetti, per rispettare questo principio, si su può fare uso di classi astratte o interfacce, costrutti che definiscono i moduli senza implementarli completamente o senza implementarli affatto.

===Stile architetturale REST===

Il modello architetturale del servizio che si sta definendo presenta una serie di caratteristiche, come ad esempio l'indipendenza dei moduli, che permettono di realizzarlo secondo il paradigma delle ''RESTful API''. L'espressione "Representational State Transfer" e il suo acronimo "REST" furono introdotti nel 2000 nella tesi di dottorato di Roy Fielding ([0021]), uno dei principali autori delle specifiche dell'Hypertext Transfer Protocol (HTTP). Roy Fielding descrive il ''Representational State Transfer'' come uno stile architetturale ("''architectural style''"), ovvero un'astrazione degli elementi di un'architettura all'interno di un sistema hypermedia distribuito. ''REST'' non specifica i dettagli dell'implementazione dei componenti e della sintassi del protocollo, ma definisce i ruoli dei componenti, i vincoli sulla loro modalità di interazione e la loro interpretazione.
Riassumiamo quindi i principi che deve rispettare una architettura ''REST'':
# Architettura Client-Server <br/>In una architettura ''REST'' viene data particolare importanza ai principi ''SRP'' e ''DIP'' prima citati, più generale si può affermare che l'architettura sposi il paradigma noto con il termine di "''Separation of Concerns''". Una ''Restful API'' applica questi principi in un architettura Client-Server, capace di supportare l'evoluzione indipendente della logica lato client e della logica lato server.
# Stateless <br/>La comunicazione tra utente e fornitore del servizio deve essere senza stato, quindi ogni richiesta del client deve contenere tutte le informazioni di cui il fornitore necessita per l'erogazione del servizio offerto. Questa ipotesi viene fatta per rendere una ''Restful API'' facilmente scalabile orizzontalmente.
# Uso della cache <br/>In un Architettura ''REST'' i messaggi di risposta inviati dal server devono esplicitamente indicare se possono essere memorizzati nella cache del client o di componenti middleware per il riutilizzo nelle richieste successive.
# Interfaccia uniforme <br/>I componenti devono essere in grado di comunicare attraverso un'interfaccia uniforme e le risorse devono essere trasferite in un formato standard. Inoltre l'utente deve poter effettuare la navigazione tra le risorse di suo interesse tramite collegamenti ipertestuali. Per inciso, si osserva che il protocollo HTTP usato correttamente rispetta i requisiti di un architettura ''REST'' e che nelle implementazioni delle ''RESTful API'' il formato più usato per la modellazione dei dati è JSON.
# Layered System <br/>In un sistema a livelli, componenti intermedi (come i proxy) possono essere collocati tra client e server per intercettare il traffico per scopi specifici; ad esempio il caching o la sicurezza. Una soluzione basata su ''REST'' può essere composta da più livelli architettonici, indipendenti l'uno dall'altro.
# Code on Demand <br/>Questo vincolo facoltativo è inteso principalmente a consentire aggiornamenti alla logica all'interno dei client (come i browser Web) indipendentemente dalla logica lato server. Una ''single page application'', ad esempio, rispetta in pieno questo punto.

Un'applicazione progettata sul modello dell'architettura ''REST'' ha quindi gli indiscutibili vantaggi di:
* consentire l'evoluzione indipendente delle diverse componenti
* avere un'interfaccia utente portabile con altri tipi di piattaforme
* permettere agevolmente la replicazione delle macchine server
* non vincolare moduli server e client a linguaggi e tecnologie specifiche.

L'architettura del servizio oggetto di questa tesi si trova già perfettamente in linea con alcuni dei vincoli discussi, ma sono necessarie alcune considerazioni. Il punto 1 ("architettura Client-Server") è chiaramente soddisfatto.
Il punto 2 ("Stateless"), direttamente collegato con i punti 3 e 5 ("Uso della cache", "Layered System"), può essere rispettato con facilità; a ogni richiesta di "minimizzazione" del client corrisponde la restituzione del documento trattato dal server, non c'è quindi necessita di avere uno stato nell'interazione.

Analizzando le caratteristiche di una applicazione stateless in relazione al principio ''privacy by design'' illustrato in precedenza, si osserva che l'assenza di stato determina la semplificazione delle problematiche critiche relative al principio. Non vengono conservate, infatti, informazioni contenenti dati sensibili, poiché dopo aver effettuato l'invio della risposta, sarà subito eliminato sul server il file elaborato.

Nei capitoli precedenti tuttavia si è detto che l'utente può ripetere più volte il trattamento di uno stesso documento nella stessa sessione di interazione; essendo il vincolo dell'efficienza già difficile da rispettare per via dell'elaborazione onerosa del documento, si può progettare una modalità alternativa del funzionamento con stato del servizio, applicabile in assenza di replicazione delle macchine server e sfruttando le ripetute richieste di trattamento per uno stesso documento.
Si può infatti memorizzare lato server il documento inviato dal client inizialmente e, alle successive richieste di trattamento del medesimo documento, evitarne la ritrasmissione da client a server. Per rispettare il ''PbD'', al termine della sessione di interazione il documento verrà rimosso dal server. Si nota, inoltre, che per predisporre il servizio alla gestione delle due diverse modalità di funzionamento si può utilizzare un parametro di configurazione a livello applicativo.
I punti 4 e 6 infine ("Interfaccia uniforme", "Code on Demand") si possono rispettare utilizzando il formato JSON per la trasmissione dei documenti e dei nominativi, e usando localmente sul client Javascript per offrire tutte le funzionalità del servizio in un'unica pagina html.

===Moduli software del servizio===

====Scelta dei componenti software====

Si opera ora la scelta delle tecnologie da utilizzare per i componenti dei 4 layer dello ''stack LAMP''. Per i due layer inferiori risulta piuttosto immediato decidere di usare le tecnologie presenti per default. Un sistema operativo Linux ed un web server Apache sono adatti all'architettura del servizio.
Inoltre anche il linguaggio di programmazione PHP può essere usato senza significativi problemi, anche se verranno fatte in seguito, in una sezione di questo capitolo, alcune considerazioni sulle problematiche di esecuzioni concorrenti di script PHP. Il linguaggio sarà impiegato in particolare per la realizzazione della logica necessaria a gestire l'interazione web con il cliente, mentre l'elaborazione del documento OOXML lato server sarà effettuata da un programma Java.

I due ''task'' principali del servizio sono delegati, quindi, a due programmi distinti realizzati con tecnologie diverse. Si concretizza in questo modo il principio ''SRP'' e, sfruttando l'<i>openness</i> della piattaforma LAMP, le funzionalità necessarie vengono realizzate attraverso i linguaggi più adatti.
La scelta del linguaggio Java per l'implementazione del ''main core'' della logica di business è dovuta alla libreria open source in ambiente java Docx4j ([40],[41]). Questa libreria è realizzata per il processamento delle tre tipologie di formati OOXML (''docx'', ''xslx'', ''pptx'') e permette tutte le possibili operazioni di creazione, lettura e modifica su questo tipo di documenti. Anche questa libreria sarà approfondita in sezioni successive. Si osserva, per inciso, che esistono altre librerie equivalenti in ambiente .NET.

Nella scelta del linguaggio di programmazione usato per elaborare i documenti ed effettuare i confronti tramite ''regular expressions'', un dato non di poco conto da considerare è l'encoding delle stringhe. In Java, in particolare, una stringa è rappresentata internamente come un array di char, ognuno codificato da 2 byte in formato UTF-16 ([0042]); la codifica esprime in 16 bit tutti i caratteri definiti dallo standard Unicode, quindi è possibile scegliere Java.

Per il ''layer'' della persistenza, infine, l'impiego di un database MySql risulta una buona scelta. Si osserva che questo livello non verrà utilizzato nella tradizionale maniera prevista dallo ''stack LAMP''. Infatti, generalmente, la base di dati viene interrogata direttamente dal componente che si occupa dell'interazione con l'utente (PHP) per il reperimento delle informazioni utili da restituire al client; nel servizio, invece, la base di dati sarà a supporto unicamente del programma Java, poiché gli unici dati persistenti da gestire sono i nomi del dizionario (si ricordi sempre il ''PbD'') e solo i moduli dell'eseguibile Java devono utilizzarli. Se il dizionario contenessero unicamente i nomi (senza informazioni accessorie correlate) e fossero usati in sola lettura, un semplice file di testo poteva essere sufficiente per la rappresentazione. Tuttavia, poiché saranno individuate tecniche di ottimizzazione nell'impiego dei dizionari che richiedono operazioni di scrittura e ordinamento dei dati, risulta opportuno usare un database relazionale.

====Logica di business e dinamiche di interazione====

Vengono presentati in questa sezione gli aspetti principali dei funzionamenti dei moduli del servizio. Per mettere bene a fuoco quali siano le meccaniche di interazione e i flussi di esecuzione dei programmi, si propone il diagramma di sequenza del tipico scenario di utilizzo. In questo schema UML si descrive il caso d'uso dove un utente, dopo aver inserito un documento ed averlo ricevuto "minimizzato", esprime delle preferenze e richiede poi un secondo trattamento.<div></div>
<div></div>(QUI IMG [0F00])<div></div>
Si descrivono quindi ora le principali operazioni che vengono eseguite.
All'avvio dell'interazione viene presentata una pagina PHP di benvenuto contenente le informazioni su come i dati personali vengano elaborati ed un ''file-picker'' per consentire l'upload di un documento ''OOXML''; nel momento in cui l'utente confermerà il caricamento del documento, esso verrà trasferito sul server.
Bisogna prestare particolare attenzione al comportamento del sistema nel caso in cui più utenti richiedano contemporaneamente l'esecuzione del servizio, e cioè alle problematiche di esecuzioni concorrenti di script PHP; è necessario, in particolare, evitare situazioni in cui i nomi dei file inviati dagli utenti siano in conflitto. Analizzando più in dettaglio il problema, ogniqualvolta un web server Apache riceve una richiesta HTTP per una pagina PHP, si ha la generazione di un nuovo processo che esegue il codice presentato nella pagina PHP richiesta. Supponendo quindi che N utenti eseguano l'invio del file contemporaneamente, si avrebbe che sul server N processi diversi dovrebbero procedere con la scrittura di un file. Ovviamente se due o più file condividono il nome almeno uno di essi sarà sovrascritto. Per risolvere questo problema, supponendo di voler salvare tutti i documenti in una cartella temporanea, occorre modificare il filename dei documenti inviati dagli utenti per esser certi di non incorrere in sovrascritture o altri tipi di errori correlati.
Una valida possibilità è l'inserimento di un ''prefisso'' univoco nel filename. Per la generazione di una stringa univoca da anteporre al filename, che permetta di distinguere file caricati da utenti diversi, si può direttamente usare il ''session id'' dell'utente. In PHP esso è determinato casualmente combinando ([0043]): l'IP del cliente, orario di attribuzione dell'id, un numero pseudo-casuale (con il ''PHP Linear Congruence Generator'') e, se presente un "''random source''" sul sistema operativo del Client (spesso chiamato impropriamente "''seme''"), un ulteriore numero pseudo-casuale.
Per introdurre ulteriore alea, necessaria se, ad esempio, un utente tenti l'upload di file omonimi (con contenuto interno diverso) e mantenga il medesimo ''session id'', si utilizza un ulteriore generatore pseudo-casuale per produrre un altro numero con cui comporre il prefisso.
Concatenando i due numeri generati si ha praticamente certezza di aver individuato un numero univoco nel sistema per il tempo in cui il servizio sarà erogato al cliente.

Una volta memorizzato il file, lo script PHP dovrà ricorrere all'invocazione del modulo Java, delegato al vero e proprio processamento del documento. Occorre quindi individuare un set di opzioni che consenta al modulo che gestisce l'interazione con il cliente di sfruttare al meglio il componente delegato all'elaborazione del documento, in qualunque circostanza; la totale indipendenza dei moduli, la loro sostituibilità e la replicazione possibile di macchine server sono solo alcuni dei fattori che rendono mutevole la configurazione del sistema. Va definito un protocollo di comunicazione, quindi, che astragga completamente dall'implementazione dei moduli o dalla locazione dei file.

Valutando i possibili flussi logici, anche con l'ausilio del diagramma di sequenza, si ha che i tipi di esecuzione sono due:
* "minimizzazione" con dizionario
* "minimizzazione" di specifici nominativi
Il protocollo di comunicazione tra i due moduli è costituito in entrambi i casi di una singola richiesta a cui segue una singola risposta. Più in particolare, lo script PHP invoca il comando Java esprimendo obbligatoriamente il path del file da trattare e opzionalmente l'elenco dei nominativi. A suo volta, il modulo Java restituisce i nominativi trovati, qualora non espressamente richiesti dallo script, e segnala la corretta terminazione dell'elaborazione.
Si definiscono come canali di comunicazione standard del protocollo gli argomenti presi in input dal modulo di processamento del documento e lo standard output del processo che esegue tale programma. Inoltre è importante definire un formato standard per la comunicazione dei nominativi tra moduli; è necessario quindi scegliere un pattern che permetta di determinare univocamente la composizione dei nominativi. Un possibile formato, espresso tramite ''regex'', è il seguente:
<div></div>
<span style="font-family: monospace;"> <nominativo> = ^(<nome>:)*<nome>;<cognome>$</span>
<div></div>
<span style="font-family: monospace;"> <nominativi> = ^(<nominativo>\s+)+$</span>
<div></div>
Dove nome e cognome sono una sequenza di caratteri Unicode come già discusso. Ulteriori opzioni importanti da definire nel protocollo per l'invocazione del programma che si occupa delle funzionalità di elaborazione sono le seguenti:
* path file da elaborare (opzione "-i <file_path>", obbligatoria)
* path con cui salvare il file elaborato (opzione "-o <file_path>", opzionale: per default viene creato un nuovo file automaticamente)
* abilitazione stampe verbose, da usare solo in fase di debug (opzione "-d", opzionale)
<div></div>
Una volta terminato il processamento, il modulo di gestione dell'interazione con l'utente dovrà accertarsi che l'<i>exit status</i> sia 0 e leggere dallo standard output del processo appena terminato, qualora si sia stata eseguita la "minimizzazione" con dizionario, l'elenco dei nominativi trovati. Se invece la "minimimizzazione" ha avuto luogo con i nominativi già specificati non sarà scritto nulla sullo standard output.
A margine si osserva che l'impiego dell'opzione "-d" deve sempre consentire una semplice individuazione dei nominativi trovati; in particolare, se tale opzione è specificata, nello standard output i nominativi compariranno con un ''header'' riconoscibile ("''NOMINATIVO=''").
Ritornando alla descrizione del flusso di esecuzione tipo, una volta che il modulo Java ha completato il trattamento del documento, lo script PHP ne effettuerà l'upload sul client e presenterà all'utente le opzioni già descritte nel capitolo sull'usabilità.
A questo punto l'interazione con client potrebbe concludersi, qualora si eseguisse il download e si chiudesse il browser, o continuare elaborando i ''suggerimenti'' dell'utente espressi dopo il primo trattamento. Le modalità di comunicazione dei moduli varierebbero leggermente come appena illustrato, mentre, a seconda della configurazione stateful o stateless del servizio, verrebbe eseguito o meno un nuovo upload del file dal client al server.<div></div>

Si osserva infine che, per predisporre a successivi studi di ottimizzazione il servizio e per agevolare tutti i possibili sviluppi futuri, si applica largamente nella progettazione del modulo di elaborazione Java il ''Dependency Inversion Principle'', in quanto si desidera realizzare classi estendibili ed intercambiabili.
In particolare, si introducono delle classi astratte per rappresentare in maniera generica il concetto di "''persona''" e "''minimizzatore''". È possibile infatti realizzare successivi studi per trattare ulteriori dati personali oltre che ai nomi e cognomi; inoltre, in base ai tipi di documenti trattati o eventuali altri fattori utili, è possibile studiare differenti tecniche di "minimizzazione" realizzate da differenti algoritmi "''minimizzatori''".
In particolare una "''persona''" dovrà sempre esporre un metodo "''minimizza''" che prende in input una stringa, la "minimizza" e la restituisce; il pattern con il quale si effettua la "minimizzazione" sarà fornito in implementazione a seconda dei dati sensibili di interesse.
Un "''minimizzatore''" esporrà sempre un metodo "''work''" che, presa in input una lista di persone ed un documento ''OXML'', con l'ausilio della libreria Docx4j, fornirà in output un documento del tutto "minimizzato"; la definizione delle modalità con cui si estrapolano le informazioni dal documento e con cui si invoca il metodo "''minimizza''" della classe persona sono confinate nell'implementazione.
Definendo delle classi astratte risulta, quindi, più veloce la realizzazione dei futuri componenti e si svincola il processo di "minimizzazione" dal tipo di dati che si "minimizzano" e viceversa.

====Le classi principali del progetto====
Le classi principali del progetto vengono quindi presentate in appendice. Esse sono:
* App.java, contenente il main
* Elaborator.java, che presenta il metodo "''work''"
* Persona.java, che presenta il metodo "''minimizza''"
* Testing.java, contenente alcune funzioni usate in fase di debug.

Gli script in PHP sono stati forniti dall'azienda come implementazione minimale e provvisoria, da perfezionare a seguito della eventuale definizione sulle modalità di presentazione del servizio su Internet.

Una considerazione di implementazione comune a tutte le classi deriva del principio ''Privacy by Design'', indifferentemente dalla modalità di configurazione stateful o stateless del servizio: è di fondamentale importanza che nel sistema non siano memorizzati permanentemente in alcun caso i documenti inviati dagli utenti del servizio.
Per realizzare un sistema robusto, per fronteggiare crash improvvisi del client o congestioni della rete, è opportuno impostare dei timeout lato server che procedano automaticamente alla eliminazione dei documenti degli utenti dopo un periodo di inattività troppo prolungato. Qualora invece si dovesse verificare un interruzione critica del servizio a causa di un errore logico del server o semplicemente per via di un'interruzione dell'alimentazione della macchina server, bisogna considerare altri metodi; essendo il servizio realizzato con un sistema operativo Linux, si può configurare il demone ''crond'' per eseguire a ogni reboot e, per sicurezza, una volta al giorno l'eliminazione dei file usati dall'applicazione tutti contenuti all'interno della cartella temporanea.

==Approfondimenti tecnologici==

===Analisi della struttura del formato OOXML===

Come argomentato, il formato dei documenti elaborati dal servizio progettato dovrà essere ''Office Open XML'', o ''OOXML''; si tratta di un formato ''XML-based'' per documenti di testo, fogli elettronici e presentazioni, in grado di rappresentare grafici, diagrammi, immagini e altro materiale grafico. La specifica fu sviluppata da Microsoft e adottata dall'<i>ECMA International</i> come standard ''ECMA-376'' nel 2006. Una seconda versione fu rilasciata nel 2008, una terza nel 2011, una quarta nel 2012 ed una quinta tra il 2015 ed il 2016 ([0010]). La specifica è stata adottata, inoltre dall'<i>ISO</i> e dall'<i>IEC</i> come standard ''ISO/IEC 29500'' a partire dal 2008 ([0011], [0012]).

====Linguaggi di markup====

Lo standard ''ECMA-376'' ([0010]) include tre differenti specifiche di linguaggio per ognuna delle tre principali categorie di documenti:
* ''WordprocessingML'' per i documenti testuali
* ''SpreadsheetML'' per i fogli elettronici
* ''PresentationML'' per le presentazioni elettroniche
* ''DrawingML'' ed altri linguaggi di markup di supporto per la rappresentazione di disegni, forme e diagrammi.
<div></div>
La specifica include sia gli schemi ''XML'' sia i vincoli espressi per iscritto. Ogni documento conforme al formato dovrà, quindi, rispettare gli schemi ''XML'' e dovrà essere codificato in ''UTF-8'' o ''UTF-16''. La specifica, inoltre, permette l'aggiunta di ''custom tag XML'' a supporto dei linguaggi di markup dati, per default nel formato ''OOXML'', consentendo quindi la libera personalizzazione dei documenti.

====File packaging====

Oltre alla specifiche relative ai linguaggi di markup, la seconda parte dell'<i>ECMA-376</i> ([0010]) definisce la struttura gerarchica dei file del formato adottando le ''Open Packaging Conventions'' (''OPC''). ''OPC'', una tecnologia ''file-container'' basata sul comune formato compresso ''zip'', che stabilisce che tutti i file che riguardano una stessa entità devono essere raggruppati in un unico package ([0014]). Un documento ''OOXML'' è, infatti, un archivio ''zip'' contenente alcuni files ''XML'' (detti anche ''parti'') organizzati in un singolo package. Questa frammentazione dei dati in più files rende più semplice e veloce l'accesso ai dati stessi e riduce le possibilità di una loro corruzione. Le ''parti'' possono contenere qualsiasi tipo di dato; per tenere traccia della relazione tra una ''parte'' e la sua tipologia di contenuto, senza basarsi sull'estensione del file, è presente nel package, nella cartella radice della gerarchia, il file denominato ''[Content_Types].xml'', il quale mappa appunto queste associazioni. È mostrata qui ad esempio l'associazione tra la ''parte'' rappresentante il documento principale e il suo ''ContentType''.
<div style="font-family: monospace;">
<Override PartName="/word/document.xml" ContentType="application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml"/>
</div>
Le informazioni relative alle relazioni che ogni ''parte'' ha con le altre ''parti'', con risorse esterne e con il package in sé sono mantenute separatamente dal contenuto della ''parte'' stessa. Tali informazioni sono presenti, infatti, all'interno delle cartelle denominate ''_rels'': ne esiste una per il package nel suo complesso e una per ogni sotto-cartella del package contenente delle ''parti'' coinvolte in delle relazioni. In questo modo i riferimenti che una ''parte'' ha verso altre ''parti'' o risorse sono salvati una sola volta e possono essere aggiornati con semplicità se necessario, senza dover modificare il contenuto stesso delle ''parti'' coinvolte. È mostrato qui un esempio di relazione contenuta in ''_rels/.rels'' relativa al documento principale e al suo schema.
<div style="font-family: monospace;">
<Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument" Target="word/document.xml"/>
</div>
Il documento principale, ossia il file ''word/document.xml'', ha inoltre numerose relazioni con altre ''parti'', come ad esempio ''word/styles.xml'' e ''word/footer.xml'', e risorse esterne collegate con degli URI. Per descrivere queste relazioni si usa la cartella ''word/_rels''.

====Parti di un Documento OOXML====

Vengono qui presentate le ''parti'' che sono caratteristiche esclusive di un ''WordprocessingML package'', non presenti quindi negli altri due formati ''OOXML''. È importante osservare che alcune di esse sono facoltative e sono presenti nel package solo se necessario.

Le ''parti'' relative al vero e proprio contenuto testuale sono:
* ''Main Document'', contiene le informazioni principali ed è salvata come ''word/document.xml''
* ''Header'', contiene i dati relativi alle intestazioni ed è salvata in ''word/header.xml''. Ogni sezione del documento può avere intestazioni diverse per la prima pagina, per le pagine pari e per le dispari, quindi possono esserci molteplici ''parti header''
* ''Footer'', contiene le informazione relative al piè pagina ed è salvata in ''word/footer.xml''. Può essere presente più volte, per motivi analoghi alla ''parte header''
* ''Footnotes'', contiene le eventuali note a piè pagina del documento ed è salvata come ''word/footnotes.xml''
* ''Endnotes'', contiene le note di chiusura del documento ed è salvata in ''word/endnotes.xml''.

Sono presenti poi delle ''parti'' relative allo stile e alle impostazioni del documento:
* ''Style Definitions'', contiene la definizione di un insieme di stili usati dal documento, salvata in ''word/styles.xml''
* ''Font Table'', contiene informazioni riguardo i font usati, salvata in ''word/fontTable.xml''
* ''Numbering Definitions'', contiene le definizioni sulla struttura delle liste contenute nel documento, salvata in ''word/numbering.xml''
* ''Document Settings'', specifica come il word processor debba trattare il documento (spell checking, gestione delle revisioni, etc.), contenuta in ''word/settings.xml''
* ''Web Settings'', contiene informazioni su come il documento debba essere convertito in ''HTML'' se richiesto, contenuta in ''word/webSettings.xml''.

Sono presenti anche delle ''parti'' che rappresentano testo secondario:
* ''Comments'', contiene i commenti sul documento inseriti attraverso un word processor
* ''Glossary'', contiene dati testuali aggiuntivi secondari, ne è permessa una sola. Tutte le ''parti'' prima elencate, tranne il ''Main Document'', possono comparire una seconda volta in relazione alla ''parte glossary''.

====Analisi del Main Document====

Il file ''document.xml'', elemento principale di un documento ''WordprocessingML'', è costituito da due tipi di informazioni:
* ''properties'', che definiscono lo stile e la formattazione del testo
* ''stories'', che rappresentano il contenuto testuale delle varie parti del documento.

Le ''properties'' verranno trattate in misura minore. Queste informazioni sono espresse attraverso una struttura XML gerarchica che ha come elemento radice il nodo ''document''. Esso ha due nodi figli:
* ''background'', che contiene alcune ''properties'' che descrivono lo sfondo del documento
* ''body'', che contiene tutti i rimanenti contenuti ed è potenzialmente molto complesso.

Si osserva che per le finalità del trattamento dei dati risultano di primario interesse le ''stories'' e che è opportuno effettuare un'analisi ''bottom-up'' del problema: anziché considerare la gerarchia a partire dal ''body'' (nodo padre) partiremo dalla rappresentazione più semplice del testo contenuta nel documento (nodi figli).

Facendo direttamente riferimento allo standard ''ECMA-376'' ([0010]), si evince che l'unico nodo che contiene puro testo ha il nome ''t'' (''Text''). Questo elemento contiene una stringa rappresentante gli esatti caratteri che vengono poi mostrati negli editor a video. Il nodo ''Text'' non presenta figli e l'unico nodo padre che può avere è ''r'' (''Run''). Quest'altro nodo definisce una regione di testo con comuni proprietà (ad esempio l'uso del grassetto). Attraverso l'uso di tag ''t'' ed ''r'' quindi si rappresenta una regione di testo formattata con differenti elementi stilistici.
Occorre però evidenziare che un nodo ''r'' può presentare molti altri figli oltre a ''t'', come ad esempio immagini, in quanto rappresenta un'area generica del documento.
Si supponga quindi di avere due nodi ''Text'' fratelli, ossia figli dello stesso nodo ''r'': essi rappresenteranno semanticamente un unico blocco logico se e solo se compariranno a video come una sequenza di parole continua. Questo fenomeno è facilmente identificabile anche nel file ''XML'' descrittivo: due sequenze di parole mostrate a video adiacenti compaiono infatti nel file ''XML'' in due righe consecutive; se invece due parti di testo dovessero essere intervallate ad es. da un'immagine nel documento ''XML'' ci sarebbe un tag ''drawing'' a dividere i due tag ''t''. Dalla consecutività dei nodi ''Text'' nel file ''document.xml'' si può determinare quali siano i blocchi logici da trattare.
Un insieme di ''Run'' infine può essere figlio di diversi nodi, ma ciò non è di rilevante importanza, in quanto ogni area di testo individuata dal nodo ''Run'' rappresenta già un blocco logico a sé e, di conseguenza, contiene sufficienti informazioni per la "minimizzazione".
L'unico caso di rilievo nel quale bisogna valutare quale sia la gerarchia a monte di un nodo ''Run'' è nell'elaborazione di una tabella. In tal caso, in realtà, occorre verificare opportunamente la strutturazione della gerarchia processata. Per chiarezza espositiva viene mostrata la rappresentazione in formato ''OOXML'' di una tabella con una riga e due colonne (senza l'uso di ''properties'' per la formattazione stilistica).
<br/>
<div style="font-family: monospace;">
<w:tbl>
<w:tr>
<w:tc>
<w:p>
<w:r>
<w:t>Cella A</w:t>
</w:r>
</w:p>
</w:tc>
<w:tc>
<w:p>
<w:r>
<w:t>Cella B</w:t>
</w:r>
</w:p>
</w:tc>
</w:tr>
</w:tbl>
</div>

Come si osserva in figura, in una tabella il nodo ''r'' sarà figlio del nodo ''p'' (''Paragraph''), il quale a sua volta sarà contenuto in un noto ''tc'' (''Table Cell''). Celle di una tabella appartenenti ad una stessa riga saranno presenti all'interno dello stesso ''tr'' (''Table Row'') ed infine tutte le righe della tabella saranno inserite del tag ''tbl'' (''Table'').

Per determinare quindi se due nodi ''Text'' sono scritti in due colonne adiacenti di una stessa riga (e quindi costituiscono un unico blocco logico) è necessario verificare che per i due nodi ''Text'':
# il nodo "padre" '''non sia''' in comune
# il nodo "padre di 2° livello" sia ''Paragraph'' e '''non sia''' in comune
# il nodo "padre di 3° livello" sia ''Table Cell'' e '''non sia''' in comune
# il nodo "padre di 4° livello" sia ''Table Row'' e '''sia''' in comune
# i nodi "padre di 3° livello" '''siano''' consecutivi.
Se tutte queste ipotesi sono soddisfatte, le due celle vanno "minimizzate" come unico blocco logico.

Si valutano infine gli ultimi vincoli emersi nell'analisi sull'interpretazione della formattazione di un documento.
In particolare, descrivendo le parti che compongo un documento ''OOXML'', era già emerso che alcune sezioni di testo, ossia note a piè pagina ed intestazioni, compaiono in altri file ''XML'' e non in ''document.xml''. Questi file (''header.xml'', ''footer.xml'', ''endnotes.xml'', etc.) sono tutti raccolti in un package ("''word''") e la grammatica ''XML'' è la stessa usata per il Main Document.
Si conclude osservando che il problema della divisione in sillabe delle parole non si pone, in quanto la divisione sillabica mostrata a video dai word-processors è calcolata dinamicamente; in particolare, su una porzione di testo viene applicata la sillabazione (ove necessario) se è presente tra le ''properties'' di quella regione di documento il tag ''hyphenationZone''.

====La libreria in ambiente java open source Docx4j====

La libreria Docx4j offre completo supporto alla manipolazione di documenti ''docx'' (compressione e decompressione archivio zip, generazione file ''XML'' necessari, etc.). Offre inoltre un'utile mappatura in specifici oggetti Java della gerarchia ''XML'' presente nei vari file del formato.
Uno tra gli elementi più interessanti è la tecnica con cui vengono recuperati i nodi dai file ''XML'', in quanto si fa impiego del linguaggio standard W3C ''XPath'' ([0044], [0045]). Con ''XPath'' è possibile esprimere con una stringa un sottoinsieme di nodi presenti in una gerarchia ''XML'' non solo in base al loro nome o valore, ma anche in relazione alla posizione reciproca rispetto agli altri nodi. Riferendoci alle problematiche del servizio risulta, ad esempio, significativamente agevolato il trattamento di dati personali in forma tabellare.
Si osserva infine che la libreria attribuisce un id univoco ad ogni nodo del documento, di conseguenza se ne può trarre vantaggio nei confronti tra i nodi.

===Ottimizzazioni del processo di minimizzazione===

Durante l'analisi dei requisiti è emerso che l'efficienza costituisce un aspetto problematico del servizio. Si ricorda di aver stimato la durata di una prestazione media di circa 145 secondi, considerando dati:
* un documento di medie dimensioni (10 pagine ~ 5000 parole)
* tempo medio di 10 ms per individuare le occorrenze di un nome
* un dizionario di circa 14.500 parole

In linea di massima si individuano due generi di strategie che consentirebbero la riduzione del tempo medio di esecuzione: uno mirato a ridurre il più possibile il testo da sottoporre a "minimizzazione" automatica, l'altro a ottimizzare l'impiego del dizionario e dell'algoritmo di ricerca.

Come già spiegato, l'approccio di ricerca ''pattern-based'' è poco sensibile all'aumentare della lunghezza del documento, ma da questo valore ha una dipendenza non trascurabile.

Nel documento è altamente probabile che ci siano interi periodi, se non pagine, dove non sia presente alcun nominativo. Anche all'interno di una frase che necessita di ''minimizzazione'' è plausibile che siano sono poche le coppie (al più le terne) di parole riconducibili ad una sequenza nome-cognome. È inessenziale che sezioni di testo che non necessitano di "minimizzazione" vengano processate. Si osserva per inciso che, ovviamente, questo ragionamento è corretto per via dell'indipendenza dal contesto di un approccio ''pattern-based''.

Il pattern definito per la ricerca di un nominativo è molto restrittivo, in quanto accetta solo sequenze di parole costituenti un nominativo contenente un nome specifico; d'altronde la progettazione del pattern è stata effettuata mirando ad identificare il più accuratamente possibile le sequenze da anonimizzare.

Analizzando attentamente il problema, si può fare il seguente ragionamento: per ridurre il più possibile il numero di parole da processare a ogni iterazione di ricerca del pattern di un nome, è possibile individuare preliminarmente tutte le sequenze di parole del documento che ''potrebbero essere'' dei nominativi e ''potrebbero'' fare match.

L'operazione di "pre-filtraggio" si applica processando il documento con un ''pattern'' che presenta un'espressione più generale e permissiva delle ''regex'' definite per i nomi del dizionario. Si osserva che una qualunque successione di caratteri ''alfabetici'' iniziante con un carattere maiuscolo ''potrebbe'' rappresentare un nome. Per realizzare un espressione adatta si parte dalla definizione della ''regular expression'' già data ai nomi del dizionario:

<div style="font-family: monospace;">
<regex> := (<second_name>\s)?(<nome>)\s<cognome>|<cognome>\s(<nome>)(\s<second_name>)?
</div>

Nell'uso fatto finora di questa espressione, al tag <span style="font-family: monospace;"><nome></span> viene attributo, ciclio dopo ciclio, una parola del dizionario diversa. È possibile definire una variante più generale dell'espressione appena presentata:

<div style="font-family: monospace;">
<nome_pre> := [A-Z][a-zA-ZÀ-ÖØ-öø-ÿ<extra>]+

<regex_pre> := (<second_name>\s)?(<nome_pre>)\s<cognome>|<cognome>\s(<nome_pre>)(\s<second_name>)?
</div>

Con questa ''regex'' si identifica una qualunque sequenza che rappresenta un nominativo, ma allo stesso tempo anche, ad esempio, tutte le parole consecutive inizianti con una maiuscola. È importante sottolineare che questo pattern presenta tutte le caratteristiche già ampiamente discusse sul formato delle ''regex'' per riconoscimenti automatici (gestione dei delimitatori, posizione relativa tra i nomi ed il cognome, etc.).
Il processamento di una ''regex'' generale inoltre sarà inevitabilmente più lento di quello di ''regex'' aventi i nomi specificati, in quanto molte più sequenze faranno match essendo l'espressione più permissiva. La mancanza di accuratezza va rapportata all'impiego della ''regular expression'': fornendo essa un semplice "pre-filtraggio" del documento non risulta necessario nè che individui esclusivamente nominativi nè che sia in grado di distinguerli gli uni dagli altri. Il leggero ritardo introdotto viene valutato sperimentalmente, applicando lo stesso l'algoritmo già usato in precedenza ed elaborando gli stessi documenti, sempre a parità di piattaforma.

Partendo dall'elaborazione di un documento contenente 10 nominativi ed in totale 5.000 parole, si misura che tempo il processamento medio della ''regex'' di "pre-filtraggio" è di circa 36 ms; si ricorda che per lo stesso documento il tempo di esecuzione medio per il processamento di un nominativo non presente è di circa 9 ms, se le occorrenze salgono a 10, il tempo è in media di circa 10 ms.
Sebbene l'elaborazione di questa ''regex'' sia circa 4 volte più lenta dell'elaborazione di ''regex'' più specifiche, un ritardo introdotto dell'ordine dei millisecondi è trascurabile rispetto al tempo di processamento complessivo (stimato di circa 145 second).
Si osserva, per inciso, che nell'elaborazione di questo particolare documento sono stati individuati altre 21 sequenze che rispettavano il pattern che non costituivano dei nominativi.

Terminata l'esecuzione dell'operazione di prefiltraggio, occorre sfruttare opportunamente le informazioni ottenute: in particolare, si possono elaborare con le ''regex'' dei nomi le sole sotto-stringhe che hanno fatto match con la ''regular expression'' nell'operazione preliminare. In altri termini, con questo metodo si effettua una sola elaborazione del testo completo e molteplici processamenti delle sotto-stringhe che ''potrebbero'' contenere nominativi.
Si osserva inoltre che, conoscendo con certezza gli indici di inizio e fine delle sotto-stringhe che ''potenzialmente'' contengono nominativi, è possibile "alleggerire" la ''regex'' associata ai nomi del dizionario: si possono rimuovere i costrutti ''lookahead'' e ''lookbehind'' in quanto la sotto-stringa è stata già rimossa dal contesto e quindi rappresenta esclusivamente i caratteri individuati dalla ''regular expression'' di "pre-filtraggio".

A questo punto occorre valutare sperimentalmente l'ottimizzazione ottenuta. Si misura che sono sufficienti 2 ms di elaborazione in media per nome, mentre, nel caso raro in cui tutti i 10 nominativi presenti si riconducano ad un unico nome, il tempo medio di esecuzione tende verso i 3 ms. Si osserva che questo è possibile perchè le parole nelle sotto-stringhe sono poco meno di 50, ossia si è ridotta di oltre il 99% la dimensione complessiva di dati da processare!
Valutando l'ottimizzazione complessiva in termini di tempo si ha che, processando un dizionario di circa 14.500 termini, sono necessari in media 29 secondi.

Ovviamente questo dato è fortemente dipendente dal contenuto del documento. Vanno effettuate opportune misurazioni nel caso in cui la percentuale di nominativi presenti rispetto alle parole complessive nel documento sia maggiore. Si considera un documento di 5.000 parole contenente 200 sequenze riconosciute dall'algoritmo di "pre-filtraggio" delle quali 100 costituiscono dei nominativi.
Si misura che il tempo di esecuzione medio è di 6 ms nel caso generale del processamento di un nome con poche occorenze e tenderà verso i 10 ms nel caso sporadico in cui le occorrenze del nome saranno proprio 100 o poco meno. Il tempo di esecuzione del "pre-filtraggio" è di circa 48 ms.
Per inciso, si osserva che la ragione per cui il tempo necessario al "pre-filtraggio" non aumenta esageratamente è dovuta al pattern della ''regex''. La ''regular expression'' impiegata infatti, facendo principalmente uso di caratteri espressi in un range unitamente al quantificatore "+", risulta particolarmente efficiente da elaborare.
Nel caso di documenti più "ricchi" di nomi si stima l'elaborazione media complessiva di circa 1 minuto e 27 secondi.

Facendo il punto della situazione, si è ridotto di circa 5 volte il tempo di esecuzione complessivo nel caso di documenti "scarsamente popolati" da nominativi e quasi dimezzato il tempo necessario nell'elaborazione di documenti contenenti molte coppie nome-cognome. Occorre proseguire nello studio per migliorare l'ottimizzazione, considerando dove l'algoritmo di ricerca e l'impiego del dizionario possono essere migliorati.

Viene posta una semplice domanda sulle modalità di ricerca dei nominativi nell'insieme delle sotto-stringhe del documento: è computazionalmente equivalente prendere una ad una le sotto-stringhe e confrontarle con le ''regex'' dei nomi rispetto che prendere una ad una le ''regex'' dei nomi e confrontarle con le sotto-stringhe?

Si fornisce una spiegazione formale alla domanda.

Si definiscono due insiemi:
* A = {a_1, a_2, ... a_n}
* B = {b_1, b_2, ... b_m}

Gli elementi dell'insieme A rappresentano le sotto-stringhe (cardinalità N), mentre gli elementi dell'insieme di B indicano le ''regex'' dei nomi (cardinalità M). È importante considerare che per il secondo insieme è definita una relazione di unicità che lega il valore degli elementi: per ogni ''b_i'' appartenente a B non esiste un indice ''j'', ''j'' compreso tra 1 ed M, tale che il testo del nodo ''i'' sia uguale al testo del nodo ''j'' (tranne se ''i'' = ''j''); in altre parole gli elementi rappresentanti le ''regex'' (''b_i'') per definizione sono posti univoci in B.

Si presti attenzione al fatto che l'insieme delle sotto-stringhe presenta N elementi distinti tra loro in identità ("id nodo"), ma il cui contenuto testuale può essere equivalente a quello di altre sotto-stringhe. L'equivalenza tra due sotto-stringhe sussiste, in questo particolare contesto, qualora i contenuti testuali di entrambe facciano match con una stessa ''regex'' presente nell'insieme B. L'insieme delle ''regex'', invece, presentano elementi i cui valori testuali sono sempre univoci, in quanto ottenuti da nomi sempre diversi.

Definiti gli insiemi si procede alla formulazione della risposta alla domanda precedente. Per chiarezza espositiva indicheremo con "A->B" la procedura con cui si opera il confronto prendendo una ad una le sotto-stringhe per poi confrontarle con le ''regex'', mentre indicheremo con "B->A" la procedura con cui si opera il confronto prendendo una ad una le ''regex'' dei nomi per poi confrontarle con le sotto-stringhe.

Nel caso in cui l'insieme delle sotto-stringhe non contenga alcun nominativo, si ha una complessità computazionale equivalente per "A->B" e per "B->A". Viene mostrato nei calcoli in figura che il numero di confronti necessari ''C_1'' è dato dal prodotto delle cardinalità degli insiemi, ossia ''C_1 = N · M''.

(QUI FIG[0F07])

Si suppone ora che il testo della sotto-stringa di posizione ''r'' faccia match con la ''regex'' in posizione ''k''; si applica "A->B". Come si mostra attraverso i calcoli in figura, il numero totale di confronti ''C_2'' sarà inferiore a ''C_1'' poichè, quando la sotta-stringa in posizione ''r'' risulta equivalente alla ''regex'' in posizione ''k'' si può direttamente passare alla valutazione della stringa in posizione ''r + 1'' e non svolgere i rimanenti ''m - k" confronti per la stringa in posizione ''r''. Si calcola che ''C_2 = k + m · (n -1)''.

(QUI FIG[0F08])

Supponendo sempre che il testo della sotto-stringa di posizione ''r'' faccia match con la ''regex'' in posizione ''k'', si applica "B->A". Similmente al caso precedente, quando la sotta-stringa in posizione ''r'' risulta equivalente alla ''regex'' in posizione ''k'' si può direttamente passare alla valutazione della ''regex'' in posizione ''k + 1'' e non svolgere i rimanenti ''n - r" confronti per la ''regex'' in posizione ''k''. Si osserva inoltre che è inutile confrontare le rimanenti ''m - k'' ''regex'' con la sottostringa di posizione ''r'': essa è risultata già equivalente ad una ''regex'' e, essendo le ''regex'' poste per definizione diverse tra loro, è di conseguenza impossibile che soddisfi un'altra uguaglianza.
Per inciso si osserva che nel calcolo di ''C_2'' un ragionamento di questo genere non è applicabile: ogni sotto-stringa può potenzialmente fare match con una qualsiasi ''regex''.
Il numero totale di confronti ''C_3'' viene calcolato come mostrato, si ottiene ''C_3 = k + m · (n -1) - n + r''.

(QUI FIG[0F09])

Si osserva che ''C_3 = C_2 - n + r'' e, essendo ''r'' la posizione della sotto-stringa coinvolta nel match, si ha che ''C_3'' è sempre minore di ''C_2'' qualunque sia la posizione della sotto-stringa. L'unico caso in cui ''C_3 = C_2'' si verifica quando la ''r = n'', ossia se la sotto-stringa è l'ultima dell'insieme.

Per estendere il ragionamento, si prende la ''regex'' di posizione ''k'' e si indica con ''T'' il numero di sotto-stringhe che sono già risultate equivalenti ad una ''regex'' nelle elaborazioni precedenti. Risulta che, per il ragionamento spiegato nel calcolo di ''C_3'', potranno essere risparmiati almeno ''N - T'' confronti per la ''regex'' ''k'' e per ogni ''regex'' in posizioni successive. In generale, maggiore è il numero di nominativi nel documento, maggiore sarebbe l'ottimizzazione della procedura.

Le conclusioni che si traggono sono due:
* indipendentemente dal numero o dalla posizione dei nominativi nelle sotto-stringhe, nell'algoritmo di minimizzazione è più efficiente prendere una ad una le ''regex'' dei nomi e con ognuna trattare l'insieme delle sotto-stringhe
* un efficace ordine di elaborazione delle ''regex'' può introdurre ottimizzazioni

Va eseguita ora una valutazione sperimentale dei tempi di esecuzione del processo di "minimizzazione" tenendo conto di questi elementi. Le ''regex'' che fanno match con i nominativi presenti nel testo, quindi, vengono trattate tra le prime. Risulta di interesse principalmente valutare i miglioramenti ottenibili nel caso di documenti ''molto popolati'' da nominativi, poichè è questo il caso in cui l'ottimizzazione entra in gioco.
Si esegue il test sullo stesso documento trattato precedentemente con la sola tecnica di "pre-filtraggio". Esso è composto da 5.000 parole, dal "pre-filtraggio" sono individuate 200 sotto-stringhe delle quali 100 costituiscono dei nominativi.
Nel test si è fatto riferimento a dati Istat ([0046]) per stabilire, quanto più realisticamente possibile, il miglior ordine di elaborazione delle ''regex'' associate ai nomi; risulta che circa il 25% dei nominativi è individuato entro i primi 15 cicli di esecuzione; circa il 35% entro i primi 50 ed il 100% entro circa i primi 3000. Per inciso, si osserva che un altro documento può dare origine a tempi significativamente peggiori qualora presenti molti nominativi con nomi desueti e presenti in fondo al dizionario.
Si misura che, dopo il "transitorio iniziale" (ossia dalla 51° ''regex'' in poi), il tempo medio è di 5 ms per l'elaborazione di una ''regex''. Si osserva che, una volta che sono state elaborate circa le prime 3000 ''regex'', il tempo medio di elaborazione di una ''regex'' scende a 4 ms. Per completezza, si riporta anche il tempo medio per la fase di "transitorio iniziale", che si misura di circa 8 ms; il tempo di "pre-filtraggio", già precedentemente calcolato, risulta di 48 ms.
Calcolando complessivamente la durata del processamento si ottiene che l'elaborazione media complessiva è di circa 61 secondi, si ottiene quindi una riduzione significativa rispetto al tempo di 1 minuto e 27 prima individuato.

Si considerano, in relazione alle conclusioni della discussione teorica prima formalizzata, le implicazioni realizzative: in primis che l'imposizione del verso con cui eseguire la "minimizzazione" non determina particolari problemi implementativi, in secundis che l'ordinamento efficiente dei nomi del dizionario può essere trattato attraverso una tecnica di ''machine learning''.

La tecnica di apprendimento che si realizza si basa sull'estrapolazione di informazioni utili nei documenti inviati dagli utenti. Si tiene traccia, infatti, della ''frequenza'' con cui un nome appare in diversi processamenti. Alla fine di ogni "minimizzazione", dopo aver concluso il salvataggio del nuovo file ''OOXML'', il programma Java eseguira l'update sul database MySql delle frequenze dei nomi trovate, incrementandole.
Nell'interrogazione al database per l'ottenimento dell'insieme dei nomi, di conseguenza, si richiederà l'ordinamento per frequenza delle tuple restituite. In questo modo, più volte un nome compare nei documenti, più incrementi riceverà il suo campo frequenza, più avrà la probabilità di comparire in cima al dizionario.
Si progetta inoltre l'inserimento di un campo "ultimo utilizzo", associato ai nomi sul database, che permette di avere un secondo criterio di ordinamento utile. Tale campo viene impiegato anche per evitare una crescita esagerata del valore della frequenza; periodicamente, con ''crond'' ad esempio, si decrementano i valori del campo "frequenza" dei nomi il cui "ultimo utilizzo" è troppo vecchio. Si osserva che i valori di configurazione per la gestione di queste elementi dipendono dal carico medio del sistema, noto solo dopo la progettazione, andranno valutati con precisione in fasi future. Ovviamente l'aggiornamento del campo "ultimo utilizzo" sarà contestuale all'aggiornamento della ''frequenza''.
Si osserva, per inciso, che l'impiego di un dizionario di cognomi sarebbe stato problematico per l'aggiornamento delle frequenze. Per via del principio ''Privacy by Design'', infatti, aggiornando la frequenza per la entry del cognome di una persona, indirettamente si sarebbe tenuto traccia di un dato sensibile, specialmente nel caso in cui il cognome risulti "raro".
Una valutazione rilevante da fare è sulle implicazioni relative agli accessi concorrenti al dizionario, dovute all'introduzione dell'algoritmo appena spiegato, che esegue scrittura di "frequenza" e ''ultimo utilizzo'' sul database. Si osserva che non sono problematiche le "letture sporche", poichè, se si verificano, al più risulta alterato l'ordine di qualche nome; inoltre nemmeno un "lost update" risulta eccessivamente problematico, poichè l'ultimo utilizzo risulta sempre aggiornato e la perdita di un incremento delle frequenza di un nome non rappresenta in linea di massima un problema. Questi scenari presentati vanno valutati complessivamente, però, una volta che si realizza il reale carico del sistema: perdere molti update risulta critico per l'ottimizzazione del processamento. Conviene in linea precauzionale prevedere una semantica transazionale per l'interazione tra modulo Java e database. Per inciso, eseguire l'update finale con una transazione non influenza il tempo di attesa dell'utente, poichè il documento è stato già elaborato per intero.

Si fa infine un'ultima osservazione che consente di abbattere i tempi di attesa enormemente, a costo di perdere dell'accuratezza nel processamento automatico: ridurre il numero di nomi del dizionario processato, elaborando solo quelli in cima.
Si osserva che questa soluzione è ancor più efficace se i nomi contenuti nel documento sono pochi. In questo caso, infatti, il processamento dei nomi durante la fase di "transitorio iniziale" richiede lo stesso tempo del processamento di nomi "a regime", ossia dopo l'avvenuta riduzione del numero di sotto-stringhe da elaborare. Nei documenti "ricchi" di nominativi, come già spiegato, ciò non avviene.
Per concludere, si usano i risultati dei test sperimentali precedentemente misurati per stimare il tempo di processamento complessivo, supponendo di:
* applicare la tecnica di "pre-filtraggio"
* usare i primi 1.500 nomi di un dizionario ordinato per frequenza

Caso A:
* documento contenente 10 nominativi ed un totale di 5.000 parole
* processamento medio della ''regex'' di "pre-filtraggio" di circa 36 ms
* individuazione di 31 sotto-stringhe totali
* durata elaborazione in media per nome di circa 2 ms

Durata esecuzione senza troncamento: 29 secondi circa
Durata esecuzione con troncamento: 3 secondi circa

Caso B:
* documento contenente 100 nominativi ed un totale di 5.000 parole
* processamento medio della ''regex'' di "pre-filtraggio" di circa 48 ms
* individuazione di 200 sotto-stringhe totali
* durata elaborazione in media per nome di circa 8 ms per prime 50 iterazioni
* durata elaborazione in media per nome di circa 5 ms per successive

Durata esecuzione con solo "pre-filtraggio" : 1 minuto e 27 secondi
Durata esecuzione senza troncamento: 61 secondi circa
Durata esecuzione con troncamento: 7.7 secondi circa

I tempi a cui si giunge risultano soddisfacenti in entrambi i casi. Si prevede di lasciare all'utente la possibilità di scegliere di ricevere un servizio o più veloce o più accurato, in base alle sue esigenze.

===Tecnologie complementari===

La redazione di questa tesi è avvenuta su Mediawiki, la più importante fra le piattaforme wiki essendo il motore di Wikipedia.

Le piattaforme wiki sono riconosciute come elemento caratterizzante dell’evoluzione Internet al Web 2.0, cioè al web nel quale gli utenti-navigatori, fino ad allora "''consumatori"'' ("''consumers"'') di contenuti si sono trasformati essi stessi in "''produttori"'' ("''producers"''), e cioè in "''prosumers"''.

Un ''wiki'' è fondamentalmente un sito web che contiene informazioni e che consente agli utenti di editare facilmente il suo contenuto.

Nel redigere una pagina wiki si utilizza ciò che è chiamato ''wikitext" per definire capitoli, paragrafi, hyperlinks, elementi di formattazione della pagina, etc.; sebbene il ''wikitext" risulti non difficile da apprendere, quasi ogni piattaforma wiki è corredata da editor di tipo visuale, che non richiede alcuna conoscenza della sintassi del ''wikitext"; tuttavia è esperienza comune che utilizzare direttamente il ''wikitext" induce a concentrarsi maggiormente sui contenuti e non sulla formattazione. Il linguaggio ''wikitext'' è strettamente correlato con il linguaggio HTML, infatti nella scrittura è possibile utilizzare tag come h1, span, div e così via, oltre che la sintassi esclusiva di ''wikitext''; simmetricamente una pagina prodotta da media wiki è costituita da HTML ben formato e direttamente importabile in ogni word processor.

I wiki presentano una funzionalità di grande utilità nella redazione di documenti articolati: la tracciatura delle successive revisioni ("''Cronologia"''). La possibilità di ripercorrere l’evoluzione del testo è davvero d’aiuto quando si fissano idee originali in uno scritto, cercando di definirle, precisarle, chiarirle, come è avvenuto in effetti, anche nella redazione di questa tesi. Per curiosità, si segnala che, pur avendo redatto la maggior parte del testo off-line, la pagina wiki di questa tesi conta oltre 50 revisioni.

Per inciso, si osserva che è stata molto utile la funzionalità di "ricerca nel codice" offerta dalla piattaforma di revisione online GitHub nella corretta comprensione della libreria Docx4j, il cui codice sorgente è ivi rilasciato.

Si conclude infine dicendo che per ottimizzare le procedure di debug del codice sono stati realizzati utili tool a riga di comando per Linux per la rapida estrazione-modifica-ricompattazione di documenti ''OOXML''. Si propone in appendice un comando bash per questi scopi.

==Sviluppi futuri==

In questa sezione si fa cenno, senza poterle approfondire, ad alcune interessanti questioni emerse nello svolgimento della tesi.

===Accesso al servizio web===

In fase iniziale, il servizio web potrà essere reso accessibile in forma completamente aperta, senza richiedere cioè la registrazione dell’utente o l’autenticazione dell’utente già registrato. In questo modo, in effetti, si premia la facilità d’uso, ma si incorre nella nota problematica di un uso malevolo, costituito da accessi a raffica, finalizzati a saturare il server e generare una condizione di ''DoS – Denial of Service''. Diverse sono le tecniche che possono essere adottate per contrastare questo tipo di accessi malevoli, come richiedere di superare "''captcha''" e/o introdurre ritardi crescenti ed eventualmente blocchi in risposta ad accessi prevenienti con alta frequenza dallo stesso indirizzo IP.
È possibile anche pensare ad un accesso previa registrazione ed autenticazione dell’utente, penalizzando l’immediatezza di utilizzo del servizio, ma eventualmente ottenendo l’indirizzo email degli utenti che acconsentono a lasciarlo per successive finalità marketing.
È possibile, infine, un utilizzo misto, contando in un cookie il numero di accessi eseguiti e richiedendo all’utente di registrarsi per continuare ad utilizzare il servizio, dopo qualche accesso.

===Ampliamento dinamico del dizionario===

Nel restituire il documento elaborato all'utente, gli si da la possibilità di richiedere una nuova elaborazione, dopo aver indicato i nominativi che fossero sfuggiti; pare inesauribile, infatti, la "fantasia" dei genitori nel dare nome ai propri figlioli!
I nominativi indicati dall'utente sono sfuggiti al servizio perché non presenti nel dizionario: facilmente viene in mente l’idea di arricchire il dizionario con i nominativi indicati dall’utente. Va però considerato il caso che l’utente in malafede indichi nominativi fasulli al fine di inquinare il dizionario.
Il caso malevolo può essere affrontato attraverso una strategia che preveda non direttamente l'inserimento del nuovo nominativo nel dizionario, ma invece l'utilizzo di un concetto di "candidatura": il nuovo nominativo viene registrato, ma si attende di avere un certo numero di utenti che lo propongono prima di approvarne l'inserimento nel dizionario.
Può anche essere utilizzato un concetto di "attendibilità" della candidatura di un nuovo nominativo, verificando ad esempio l'utente che lo propone scarichi effettivamente il file rielaborato.
Nel caso l'accesso avvenga con autenticazione, e cioè identificando gli utenti, si apre la possibilità di individuare e bannare gli utenti malevoli.

===Natura del documento e ricorrenza del nominativo===

Si coglie facilmente la differenza di formato fra un documento in forma di elenco (es. una graduatoria) da un documento in forma di relazione (es. una sentenza giudiziaria). Differenze di questo tipo potrebbero essere utilizzate per escludere o ammettere la ripetizione dei nominativi.
Per meglio dire: in un elenco la ripetizione di un nominativo è di fatto da escludersi o va trattata come omonimia. In una relazione, l’individuazione di un nominativo può essere utilizzata per ricercarlo direttamente in altri punti del documento stesso.

===Altri dati personali===

Altri dati personali sono trattabili con le stesse tecniche analizzate in questa tesi: date e luoghi di nascita, codici fiscali, indirizzi, email, numeri di telefono, sesso etc. In qualche caso, come per i codici fiscali, l’individuazione del pattern da trattare è persino più semplice.
Diversi studi ([0039]) hanno dimostrato che, utilizzando set di dati personali parziali, è possibile la re-identificazione dei soggetti, pur in documenti pseudonimizzati. È questo un altro motivo per estendere i trattamenti descritti anche agli altri dati personali richiamati.

===Altri alfabeti===

È possibile estendere il sotto-insieme di caratteri Unicode utilizzati nelle ''regex'' per elaborare documenti scritti in altri alfabeti non latini.

==Conclusioni==

Questa tesi è partita da un problema basilare, quasi scolastico, dell'informatica: la ricerca di un testo in un documento, al fine della sua cancellazione o modifica.

Il problema si è subito discostato dalla sua formulazione basilare, principalmente perché, nei casi d'uso, il documento da ricercare non è un semplice testo ("''plain text''") ma invece è il prodotto di un ''word-processor'': quindi è costituito da una struttura XML più o meno complessa, rappresentante formattazioni, riferimenti interni o esterni, note, etc. La ricerca deve avvenire nei soli nodi di puro testo, individuando ed escludendo dall'analisi lessicale gli elementi testuali di mark-up che non costituiscono contenuto informativo. Nell'approfondire le strutture ed i concetti XML ho potuto notare quanto essi siano ricorrenti in molti ambiti dell'informatica.

Nell'analisi delle specifiche, un'altra complicazione si è presto aggiunta: l'usabilità del servizio cresce drasticamente se si evita di chiedere all'utente, come si era pensato in un primo tempo di fare, quali siano le stringhe (i nominativi) da ricercare e trattare; è nata allora l'idea di reperire queste stringhe in un dizionario di nomi ed in un dizionario di cognomi, considerando anche le permutazioni dei lemmi reperiti. Ho così dovuto approfondire alcuni problemi tipici dei dizionari, come il loro ampliamento automatico con tecniche oggi comprese nel ''machine-learning''. Non ho potuto "resistere" alla tentazione di ''formalizzare la matematica'' in base alla quale ho costruito le strategie di ricerca.

Spunto per la tesi è stata la recente legislazione in materia di dati personali, il GDPR. Esaminandone gli articoli pertinenti, ho maturato una riflessione generale: sempre più il software dovrà essere progettato e realizzato anche alla luce di altre discipline, non solo di quelle informatiche, come le discipline giuridiche ed il diritto.

Durante la fase iniziale della collaborazione con l'azienda mi sono dedicato alla messa a punto delle specifiche; ciò mi ha permesso di comprendere quanto questa fase sia importante e come completezza e precisione delle specifiche siano alla base di un progetto efficace.

Molto importanti sono state la analisi relative al tipo e formato dei documenti da assumere come input ed alla presentazione ottimale del servizio rispetto all'usabilità.

Centrale nel lavoro ed avvincente è stata la definizione della strategia per il riconoscimento dei lessemi attraverso la costruzione dinamica di ''regex'' idonee. In questo fase del lavoro, anche per passione personale, ho approfondito le questioni del riconoscimento "di testi nei testi" che legano, fin dalle origini, l'informatica e la linguistica.

La fase di definizione dell'architettura del servizio mi ha permesso di ripercorrere molte le materie studiate nei tre anni del Corso di Ingegneria Informatica, affrontando argomenti come il Single Responsibility Principle, il Dependency Inversion Principle, lo "stile" architetturale REST. Molto istruttiva è stata anche la riflessione sulla scomposizione del servizio in moduli software.

Come sempre accade nell'affrontare un progetto nuovo, sono nate molte nuove idee; ho così immaginato numerosi sviluppi futuri, sia a perfezionamento funzionale dell'accesso web al servizio, sia ad estensione delle specifiche per coprire casi applicativi contigui (es. quando il dato che si vuole trattare è un codice fiscale). Dovendo necessariamente tener presente che questo lavoro è una tesi, verificherò con il supporto del mio relatore come poterne proseguire lo sviluppo.

==Bibliografia==

<div></div>[0000]https://en.wikipedia.org/wiki/Comparison_of_Office_Open_XML_software
<div></div>[0001]https://en.wikipedia.org/wiki/Comparison_of_OpenDocument_software
<div></div>[0002]https://en.wikipedia.org/wiki/Standardization_of_Office_Open_XML
<div></div>[0003]https://en.wikipedia.org/wiki/OpenDocument_standardization
<div></div>[0004]https://support.apple.com/en-us/HT202227
<div></div>[0005]https://en.wikipedia.org/wiki/Pages_(word_processor)
<div></div>[0006]https://en.wikipedia.org/wiki/Comparison_of_word_processors
<div></div>[0007]https://en.wikipedia.org/wiki/OpenDocument
<div></div>[0008]https://en.wikipedia.org/wiki/Office_Open_XML_file_formats
<div></div>[0009]https://en.wikipedia.org/wiki/Rich_Text_Format
<div></div>[0010]https://www.ecma-international.org/publications/standards/Ecma-376.htm
<div></div>[0011]https://www.iso.org/standard/51463.html
<div></div>[0012]https://www.iso.org/standard/71691.html
<div></div>[0013]https://en.wikipedia.org/wiki/Office_Open_XML
<div></div>[0014]https://en.wikipedia.org/wiki/Open_Packaging_Conventions
<div></div>[0015]https://en.wikipedia.org/wiki/LAMP_(software_bundle)
<div></div>[0016]https://w3techs.com/blog/entry/debian_ubuntu_extend_the_dominance_in_the_linux_web_server_market_at_the_expense_of_red_hat_centos
<div></div>[0017]https://news.netcraft.com/archives/2014/06/06/june-2014-web-server-survey.html
<div></div>[0018]https://whatis.techtarget.com/definition/LAMP-Linux-Apache-MySQL-PHP
<div></div>[0019]https://www.ibm.com/cloud/learn/lamp-stack-explained
<div></div>[0020]https://en.wikipedia.org/wiki/Single_responsibility_principle
<div></div>[0021]https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
<div></div>[0022]https://en.wikipedia.org/wiki/Latin_script_in_Unicode
<div></div>[0023]https://it.wikipedia.org/wiki/ISO/IEC_8859-1
<div></div>[0024]http://www.treccani.it/enciclopedia/uso-delle-maiuscole_%28La-grammatica-italiana%29/
<div></div>[0025]https://en.wikipedia.org/wiki/Ambiguity#Linguistic_forms
<div></div>[0026]Steven L. Small; Garrison W Cottrell; Michael K Tanenhaus (22 October 2013). Lexical Ambiguity Resolution: Perspective from Psycholinguistics, Neuropsychology and Artificial Intelligence. Elsevier Science. ISBN 978-0-08-051013-2.
<div></div>[0027]http://www.treccani.it/vocabolario/disambiguazione/
<div></div>[0028]R. Navigli, K. Litkowski, O. Hargraves. 2007. SemEval-2007 Task 07: Coarse-Grained English All-Words Task. Proc. of Semeval-2007 Workshop (SemEval), in the 45th Annual Meeting of the Association for Computational Linguistics (ACL 2007), Prague, Czech Republic, pp. 30–35 http://www.aclweb.org/anthology/S/S07/S07-1006.pdf
<div></div>[0029]https://wordnet.princeton.edu/
<div></div>[0030]R. Navigli, S. P. Ponzetto. BabelNet: Building a Very Large Multilingual Semantic Network. Proc. of the 48th Annual Meeting of the Association for Computational Linguistics (ACL 2010), Uppsala, Sweden, July 11-16, 2010, pp. 216-225. http://aclweb.org/anthology/P/P10/P10-1023.pdf
<div></div>[0031]Roventini A., Alonge A., Calzolari N., Magnini B., Bertagna F. (2000), "ItalWordNet: a Large Semantic Database for Italian", Proc. of the 2nd International Conference on Language Resources and Evaluation (LREC 2000), Athens, Greece, 2000, pp. 783-790.
<div></div>[0032]E. Pianta, L. Bentivogli, C. Girardi. MultiWordNet: developing an aligned multilingual database, Proc. of the First International Conference on Global WordNet, Mysore, India, January 21-25, 2002. http://multiwordnet.fbk.eu/paper/MWN-India-published.pdf
<div></div>[0033]https://www.iso.org/standard/28245.html
<div></div>[0034]https://www.gpdp.it/web/guest/regolamentoue
<div></div>[0035]https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=uriserv:OJ.L_.2016.119.01.0001.01.ITA&toc=OJ:L:2016:119:TOC
<div></div>[0036]https://www.corriere.it/Primo_Piano/Cronache/2006/09_Settembre/15/cognomi.shtml
<div></div>[0037]https://data.world/axtscz/italian-first-names
<div></div>[0038]https://en.wikipedia.org/wiki/Dependency_inversion_principle
<div></div>[0039]https://imperialcollegelondon.app.box.com/s/lqqcugie51pllz26uixjvx0uio8qxgo5/file/493461282808
<div></div>[0040https://www.docx4java.org/trac/docx4j]
<div></div>[0041]https://github.com/plutext/docx4j
<div></div>[0042]https://docs.oracle.com/javase/9/docs/api/java/lang/String.html
<div></div>[0043]https://github.com/php/php-src/blob/master/ext/session/session.c
<div></div>[0044]https://github.com/plutext/docx4j/search?q=getJAXBNodesViaXPath+in%3Afile&type=Code
<div></div>[0045]https://www.w3.org/TR/xpath-30/
<div></div>[0046]https://www.istat.it/it/dati-analisi-e-prodotti/contenuti-interattivi/contanomi
<div></div>[0047]
<div></div>[0048]

==Indice delle figure==

[0F00]https://en.wikipedia.org/wiki/Latin_script


[0F01]Diagramma di Venn 1

[0F02]Diagramma di Venn 2

[0F03]Diagramma di Venn 3

[0F04]Esito unit test regex (cartella immagini)

[0F05]Inforgrafica GDPR

[0F06]Diagramma di sequenza UML

[0F07]Primo calcolo valutazione algoritmo

[0F08]Secondo calcolo valutazione algoritmo

[0F09]Terzo calcolo valutazione algoritmo

Servizio web per il trattamento dei dati personali contenuti in documenti OOXML complessi

2019-09-30T01:11:21Z

Lorenzo.amorosa: /* Bibliografia */

==Introduzione==

Il recente Regolamento Generale europeo sulla Protezione dei Dati (UE) 2016/679 ([0034], [0035]) o ''GDPR'' (''General Data Protection Regulation'', come nel seguito sarà chiamato) ha modernizzato significativamente la normativa in materia di protezione dei dati personali, rendendola omogenea fra tutti gli stati membri. È bene notare che, fin dal titolo, il ''GDPR'' non riduce gli spazi per i trattamenti di dati personali, ma anzi ne protegge la "libera circolazione", dettando, però, regole definite e certe. Rinunciando ad una presentazione più completa del ''GDPR'', saranno riportati nei successivi capitoli i concetti necessari alla discussione dell'argomento.<div></div>
Enti ed organizzazioni, aventi a che fare con documenti contenenti dati sensibili, devono operare in maniera conforme al ''GDPR''; potrebbero, di conseguenza, trarre beneficio da servizi specifici in grado di supportarli in queste esigenze.<div></div>
L'oggetto principale della tesi sarà dunque, come riportato dal titolo, la progettazione e la realizzazione di un servizio per la gestione di dati personali.
<div></div>(QUI IMG [0F05])<div></div>

La larga maggioranza dei documenti testuali viene generata con strumenti cosiddetti di "produttività individuale", cioè da ''word-processors''. L'osservazione, ovvia nella sua evidenza, consente di introdurre una riflessione: quando un documento è generato da un'elaborazione automatica, magari per composizione di ''template'' con dati estratti da un database, l'individuazione dei "dati personali" nel documento prodotto può avvenire in modo rigoroso e senza incertezze, sulla base degli elementi di composizione del documento; ad es.: i campi del documento estratti da una anagrafica di soggetti sono certamente dati personali e come tali possono essere opportunamente trattati nel processo di elaborazione automatica (ad es. cancellati).

Ma, in quella larga maggioranza di documenti testuali generata con ''word-processors'' l'individuazione ed il trattamento dei dati personali vanno affrontati con altri approcci, discussi in questa tesi.

==Scenario di lavoro==

===Minimizzazione dei dati personali===

Un concetto espresso in modo pervasivo dal ''GDPR'' è quello della "''minimizzazione''" dei dati personali trattati ed a maggior ragione dei dati personali pubblicati. In particolare l'Art. 5 ed il Considerando 39 prescrivono che i dati personali trattati siano "''adeguati, pertinenti e limitati a quanto necessario rispetto alle finalità per le quali sono trattati («minimizzazione dei dati»)''" ([0035]).<div></div>
Con questo fine, il GDPR delinea due possibilità organizzative e tecniche di "''minimizzazione''": l'anonimizzazione e la psedonimizzazione.

====Anonimizzazione====

Sono anonimizzati i dati personali non (più) riferibili alle persone a cui sono appartenuti; si tratta di serie di dati, spesso ingenti, che sono stati definitivamente ed irreversibilmente separati da ogni riferimento alle persone che caratterizzavano. Sono le serie di dati utilizzate per fini statistici, scientifici, etc. E' importante notare che, come fissato dal Considerando 26 del ''GDPR'', il Regolamento non si applica al "''trattamento di tali informazioni anonime''" ([0035]). Per questo, sottoporre database e documenti ad un procedimento, cioè un trattamento, di anonimizzazione consente di non doversi più preoccupare del ''GDPR''.

====Pseudonimizzazione====

Fra le definizioni dell'Art. 4 del ''GDPR'', la "pseudonimizzazione" viene indicata come "''il trattamento tale che i dati personali non possano più essere attribuiti a un interessato specifico senza l’utilizzo di informazioni aggiuntive, a condizione che tali informazioni aggiuntive siano conservate separatamente''" ([0035]).<div></div>
Traducendo in termini "operativi", si tratta del procedimento che, dal "record" dei dati di un interessato, separa i campi che caratterizzano l'interessato stesso da quelli che lo identificano, trasferendo questi ultimi in una nuova distinta tabella; nelle due tabelle vengono aggiunti i riferimenti che permettono la ricostruzione del record originario; il procedimento è completo quando la nuova tabella con gli identificativi viene archiviata separatamente ed eventualmente cifrata. In margine si annota che in molti casi, come molti studi dimostrano, è possibile identificare, quindi "riconoscere", gli interessati utilizzando la sola tabella con i dati pseudonimizzati.

====Altri trattamenti di "minimizzazione" ====

Un problema pratico che si incontra di frequente è quello di dover pubblicare documenti più o meno ampi che contengono dati personali. Spesso la pubblicazione è obbligatoria per legge: si pensi alle graduatorie relative a concorsi pubblici, alle sentenze dei tribunali, etc.<div></div>
In questi frequenti casi, analizzando meglio le finalità per le quali sono pubblicati quei dati personali, si osserva che sono possibili e legittimi almeno due approcci per "minimizzare" il dato nel "trattamento di pubblicazione" e, dunque, per minimizzarne la propagazione, ad esempio attraverso motori di ricerca, ben oltre ogni ragionevole finalità. I contesti ed i corrispondenti approcci sono:
# Situazioni in cui è necessario che l'interessato possa riconoscersi nel documento ed essere riconosciuto dagli altri soggetti menzionati nel contesto, ma non è plausibile la necessità di identificazione dell'interessato al di fuori di quel contesto specifico. A questo caso si riconducono le graduatorie di concorsi, gli elenchi per la formazione di classi, gli elenchi per convocazioni, etc. In tutti questi casi, nel processo di redazione del documento è più pratico trattare internamente i dati personali in forma completa; ma praticamente mai è necessario pubblicarli per intero, esponendo al pubblico accesso codici fiscali, indirizzi, recapiti telefonici etc. Per di più, nella maggior parte delle volte, è sufficiente pubblicare il solo cognome perché l'interessato conosca la sua posizione in graduatoria; ciò è spesso sufficiente anche a trasmettere l'informazione necessaria ai colleghi dell'interessato nella medesima graduatoria, o nella medesima classe, etc. Notare che, pubblicando il solo cognome, viene di fatto oscurato anche il sesso. Dunque, in questi casi è auspicabile cancellare una larga parte dei dati personali presenti nel documento.
# Situazioni in cui il documento deve essere pubblicato affinché siano rese note le motivazioni che lo hanno originato, senza che sia necessaria la precisa identificazione dei soggetti che vi compaiono. Questo è il caso della pubblicazione di sentenze giudiziarie di ogni grado. Le sentenze vengono notificate direttamente agli "aventi causa"; ma anche, come la legge prescrive, pubblicate al fine di costituire giurisprudenza. In questo secondo caso, risulta del tutto eccedente la pubblicazione dei reali nominativi degli interessati, che troverebbero verosimilmente la propria vicenda inutilmente indicizzata dai motori di ricerca negli anni a venire. Nella pubblicazione delle sentenze appare un approccio ottimale quello di sostituire con pseudonimi o con iniziali alterate i veri nominativi degli interessati presenti: il senso e le argomentazioni della sentenza restano pienamente comprensibili, come è necessario; il dato personale, del tutto superfluo ai fini della giurisprudenza, viene protetto.
In questi casi appare opportuno sostituire i dati identificativi dell'interessato, ed in particolare il nome e cognome, con pseudonimi o, ancora, con iniziali alterate, cioè non coincidenti con le iniziali reali. <div></div>
Proprio questi tipi di trattamenti di "minimizzazione" sono l'oggetto di questa tesi.

===Punti di partenza per la progettazione del servizio===

La tesi è stata svolta in collaborazione con l'azienda AFA Systems (www.afasystems.it/gdpr) con la quale si sono discusse le problematiche di progettazione e realizzazione di un servizio generalizzato di minimizzazione dei dati personali presenti in un documento.
Con l'intenzione di fornire il servizio ad un bacino d'utenza il più vasto e variegato possibile, si è pensato ad un'applicazione ''web-based'', indipendente così dai singoli devices sui quali poi sarà utilizzata.
L'attenzione è stata concentrata sul trattamento dei nomi e dei cognomi (che da qui chiameremo nominativi), poiché sono quelli sempre presenti nei documenti (ad es. gli indirizzi sono presenti solo a volte), rappresentano gli elementi tramite i quali è immediato il riconoscimento della persone, non hanno formato predefinito (come ad es. i codici fiscali); altri dati personali (indirizzi, codici fiscali, etc.), potranno essere considerati in successive evoluzioni del progetto.
È utile notare che la parte iniziale della collaborazione con l'azienda è stata dedicata alla discussione delle specifiche, la cui più precisa definizione è parte rilevante di questa tesi.<div></div>
Tra i requisiti che necessitano di un opportuno studio troviamo ad esempio:
* L'individuazione di metodi efficaci per il riconoscimento dei nominativi nei documenti
* L'identificazione delle migliori procedure di interazione con l'utente
* La scelta dei formati da trattare
* I vincoli non funzionali legati al rispetto del ''GDPR''.

==Definizione delle specifiche==

===Riconoscimento dei nominativi===

====Scelta della strategia di riconoscimento====

Le difficoltà principali con cui ci si imbatte nel processo di riconoscimento dei nominativi riguardano la complessità strutturale dei documenti di testo, ma soprattutto l'intrinseca ambiguità del linguaggio naturale. <div></div>
Le variabili ed impredicibili strutture e formattazioni dei documenti introducono alcuni problemi significativi. Rendendo fortemente eterogeneo il contenuto dei documenti, infatti, esse non consentono di ricondurre il problema del riconoscimento dei nominativi ad uno o a pochi singoli casi, ma comportano lo studio di tutte le strutture e formattazioni possibili, rendendo quindi l'analisi molto generale. L'altra rilevante difficoltà presente sta nella complessità di effettuare il riconoscimento di una stringa testuale immersa in un insieme di elementi non tutti testuali. Ogni elemento di formattazione, che sia una tabella o una barra orizzontale, introduce infatti un proprio significato logico e semantico nel documento di cui bisogna tenere conto.<div></div>
Il linguaggio naturale introduce anch'esso complessità: si pensi alle molteplici tipologie di proposizioni con cui possono essere articolati i periodi; ma i problemi principali derivano dalle sue ambiguità. Esse vengono classificate in diverse tipologie ([0025]); le principali sono le ambiguità sintattiche e lessicali.<div></div>
Si ha ambiguità sintattica quando la sintassi di una frase può essere interpretata in diversi modi e, di conseguenza, la frase stessa assume significati diversi. Essa è presente, ad esempio, nelle seguenti frasi:<div></div>
* "''Rapina in banca con rivoltella da centomila euro''"
* "''Luigi ha visto un uomo nel parco con il binocolo''"
<div></div>
L'esasperazione massima della problematica delle ambiguità sintattiche si presenta con l'<i>antinomia</i>, ossia un particolare tipo di paradosso che indica la compresenza di due affermazioni contraddittorie che possono essere entrambe dimostrate o giustificate.
L'antinomia di Epimenide o ''Paradosso del mentitore'', nota fin dal VI secolo, è probabilmente uno dei più noti esempi: "''il cretese Epimenide afferma che tutti i cretesi mentono''". Se la proposizione è vera (i cretesi mentono) allora il suo significato implica che sia falsa (Epimenide mente e quindi i cretesi dicono la verità), ma se è falsa (i cretesi dicono la verità) ciò significa che è vera (Epimenide dice la verità e quindi i cretesi mentono). La proposizione appare contemporaneamente vera e falsa. A partire dagli anni venti del '900, sono state elaborate varie teorie per la risoluzione delle contraddizioni provocate dalle antinomie, soprattutto attraverso l'elaborazione di linguaggi multilivello o attraverso l'elaborazione di logiche polivalenti (quindi non-booleane).<div></div>
Si ha ambiguità lessicale, invece, quando una parola possiede più di un significato nella lingua a cui appartiene ([0026]), in tal caso la parola è definita ''polisemica''. In italiano, alcuni termini soggetti a questo tipo di ambiguità sono, ad esempio "''acuto''" o "''venti''". È questo genere di ambiguità che risulta critico per il riconoscimento dei nominativi. La difficoltà determinata dalle ambiguità sintattiche, infatti, riguarda l'individuazione corretta di soggetti, predicati e complementi di un periodo, mentre le ambiguità lessicali ostacolano la comprensione del significato del singolo lessema. Nel processo di riconoscimento è irrilevante determinare la funzione logica che il nominativo svolge nella frase, mentre è necessario essere certi che i termini che compongono il nominativo siano effettivamente dei nomi propri di persona o dei cognomi, non altri vocaboli del lessico comune. <div></div>
In linguistica, l'intervento con cui si toglie ambiguità a una parola o a una frase prende il nome di "disambiguazione" ([0027]). Il problema della disambiguazione automatica (in inglese ''Word Sense Disambiguation'' o, abbreviato, ''WSD'') riveste particolare importanza nelle ricerche sull'intelligenza artificiale e, in particolare, nell'elaborazione del linguaggio naturale. Si prevedono benefici della disambiguazione, ad esempio, in programmi di traduzione automatica, recupero dell'informazione o estrazione automatica di informazioni. Nell'analisi delle soluzioni esistenti in letteratura per la risoluzione delle ambiguità, ci si sofferma specialmente sulle ricerche incentrate sul trattamento dell'ambiguità lessicale, essendo essa la più rilevante per i nostri interessi.<div></div>
La ''WSD'' richiede due input necessariamente: un dizionario per specificare i sensi che devono essere disambiguati e un corpus di dati linguistici da disambiguare. Nello scenario più realistico, si trattano testi le cui parole non sono note a priori e risulta molto onerosa la produzione del corpus, essendo infatti necessaria la valutazione di un operatore umano per verificare la correttezza delle disambiguazioni effettuate dagli algoritmi (''supervised learning'').<div></div>
Uno tra i principali dizionari semantici-lessicali utilizzati della lingua inglese è ''WordNet'' ([0029]), mentre alcuni dei database equivalenti che trattano l'italiano sono ''BabelNet'' ([0030]), ''ItalWordNet'' ([0031]) e ''MultiWordNet'' ([0032]).
Un elemento importante da considerare è che le prestazioni di disambiguazione per la lingua inglese, impiegando ''WordNet'', risultano corrette tra l'80% e il 90% delle volte ([0028]), percentuali discrete ma non sufficienti per avere la totale garanzia.<div></div>
I fattori che ostacolano la realizzazione di algoritmi di intelligenza artificiale per la disambiguazione sono molteplici:
# Differenze tra dizionari impiegati: i database prima citati si basano su varie fonti che raggruppano semanticamente in maniera diversa i vocaboli, quindi programmi sviluppati con dizionari diversi generalmente hanno performance differenti.
# Complessità della codifica di parte del discorso: per poter disambiguare correttamente un termine è importante riuscire a comprendere correttamente il contesto in cui è inserito, operazione non banale.
# Varianza tra giudici: i supervisori dell'apprendimento degli algoritmi possono avere opinioni diverse, o semplicemente sbagliare, nella valutazione delle disambiguazioni, ciò porta ad algoritmi che hanno comportamenti diversi.
# Impossibilità di applicare la disciplina della ''pragmatica'', ossia la logica del ''buon senso'': per identificare correttamente il senso di alcune parole, ad esempio nella comprensioni di anafore e catafore, è necessario applicare il buon senso.
# Dipendenza del senso delle parole dai contesti: ogni scenario richiede la propria divisione del significato delle parole in sensi rilevanti. In un contesto informatico, ad esempio, il termine "''mouse''" deve essere ricondotto al dispositivo di puntamento, non al cognome del celebre personaggio Disney ''Mickey Mouse''; viceversa dovrà invece avvenire in un contesto di letteratura a fumetti.<div></div>
Laddove la ''WSD'' è una tecnica molto generale e che mira a risolvere un'ambiguità riguardante una qualunque parola, per le finalità del servizio oggetto di questa tesi è sufficiente risolvere le ambiguità dei nomi e dei cognomi.
Uno dei difetti che il servizio presenterebbe adottando un approccio ''WDS'' è legato alla impredicibile formattazione dei documenti, che aggiunge informazione semantica al testo ma introduce complessità nella individuazione automatica delle parti che formano il contesto; un altro difetto dipende dalla vastità del lessico da elaborare, essendo i documenti da trattare forniti dai più disparati utenti, su qualunque genere di argomento e relativi ai più vari ambiti.<div></div>

La strategia che sarà adottata per risolvere la problematica del riconoscimento dei nominativi sarà impostata attraverso un modello ''pattern-based'', impiegando le ''regular expressions'' (''regex''). Esse risultano comunemente usate per effettuare operazioni di ricerca o sostituzione in un testo, di conseguenza se si riesce ad individuare un pattern associato ad un nominativo dato, allora sarà possibile processare il documento ricercando le occorrenze del nominativo e "minimizzarlo" opportunamente.<div></div>

Le ''regular expressions'' risultano particolarmente efficaci poiché, se opportunamente progettate, possono identificare un nominativo indipendentemente dal significato linguistico del contesto in cui è calato, basandosi piuttosto sui singoli caratteri che compongono i lessemi analizzati; permettono, di conseguenza, di effettuare una valutazione estremamente minuziosa, riducendo al minimo le possibilità di errori.<div></div>
Un algoritmo di risoluzione ''pattern-based'' risulta, inoltre, più efficiente nell'esecuzione, in generale, di un algoritmo di intelligenza artificiale; per fornire la risposta il più velocemente possibile ad un utente, fruitore del servizio via web, l'approccio di riconoscimento tramite pattern è il più indicato.<div></div>

====Definizione dei pattern====
Nella progettazione del servizio si adotta, come detto, un approccio ''pattern-based'' per il riconoscimento dei nominativi. In linea di massima è opportuno che vengano riconosciuti più nominativi possibili e allo stesso tempo che la correttezza dell'identificazione di un nominativo sia garantita, quindi bisogna individuare dei pattern non troppo stringenti ma neppure troppo laschi. Per analizzare come i pattern devono essere strutturati si prende come caso di studio un generico nominativo, ad esempio ''Lorenzo Mario Amorosa''. Nel documento esso può comparire esattamente come appena indicato, ma anche in altre plausibili varianti, in cui l'ordine dei termini viene alterato, si pensi ad esempio ad "Amorosa Lorenzo Mario" o "Mario Lorenzo Amorosa", o in altre varianti ancora in cui alcuni nomi non compaiono, come in "Lorenzo Amorosa". Bisogna tuttavia supporre un limite alla variabilità: si osserva infatti che il cognome deve sempre comparire (il solo nome ''Lorenzo'' non è riconducibile a ''Lorenzo Mario Amorosa'') e che esso inoltre deve essere necessariamente anteposto o posposto, ma non interposto, ai nomi (è poco ragionevole ricondurre "Lorenzo Amorosa Mario" a "Lorenzo Mario Amorosa'').<div></div>
Questa prima specifica permette di ricondursi a una soluzione generale, sufficiente nella maggior parte dei casi, ma che non risolve alcune criticità. Un nominativo può, in alcuni documenti, comparire manifestandosi unicamente attraverso il cognome (riferendoci all'esempio precedente, ''Lorenzo Mario Amorosa'' apparirebbe nella forma ''Amorosa''). Sorge qui il problema che molti dei cognomi italiani hanno un significato proprio nel linguaggio comune; ad es., nella frase ''una relazione amorosa è bella'' è errato considerare la parola ''amorosa'' come cognome di un nominativo. Per risolvere questo genere di ambiguità si potrebbe pensare che per stabilire che il termine ''Amorosa'' sia un cognome sia sufficiente verificare che esso inizi con una lettera maiuscola, ma ciò può verificarsi anche perché la parola si trova ad inizio di frase. Inoltre, vari cognomi italiani possono iniziare con una lettera minuscola (''de Angelis'', ''d'Onofrio'', etc.), quindi basare l'identificazione di un cognome sul fatto che la sua prima lettera sia in maiuscolo non è in generale un metodo valido. Volendo in maniera prioritaria garantire il corretto funzionamento del servizio, e quindi attuare le procedure di anonimizzazione solo sui nominativi senza applicarle erroneamente ad altri termini, risulta necessario evitare il trattamento dei nominativi che si manifestano con i soli cognomi. Per via del contesto e dei significati che i cognomi possono assumere, infatti, risulta spesso impossibile distinguerli da parole del linguaggio comune.

Ci si concentra, quindi, nello studio di nominativi composti da un cognome seguito o preceduto da uno o più nomi.<div></div>
Si rappresenta dunque in formato di ''regular expression'' il pattern attualmente ideato. Per semplicità espositiva, si definisce il tag <span style="font-family: monospace;"><nomi></span> come l'insieme delle permutazioni di tutti i nomi del nominativo più l'insieme delle permutazioni di tutti i possibili sottoinsiemi di nomi del nominativo. Considerando il nominativo preso precedentemente come caso di studio, ad esempio, si avrebbe:
<div></div>
<span style="font-family: monospace;"> <nomi> = Lorenzo Mario|Mario Lorenzo|Lorenzo|Mario</span>
<div></div>
Posto inoltre il tag <span style="font-family: monospace;"><cognome></span> ad indicare il cognome contenuto nel nominativo e il tag <span style="font-family: monospace;"><regex></span> ad indicare la ''regular expression'' associata al nominativo, si ottiene:
<div></div>
<span style="font-family: monospace;"> <regex> := <cognome> (<nomi>)|(<nomi>) <cognome></span>
<div></div>
Una osservazione sottile ma di fondamentale importanza per la corretta progettazione delle ''regular expressions'' sta nella piena comprensione della semantica dell'operatore di scelta, espresso con il carattere ''pipe'' ("|"). Un qualunque ''engine'' di elaborazione delle ''regex'', infatti, interrompe la valutazione di una stringa non appena può stabilire se tale stringa fa match o meno con il pattern dato, senza quindi necessariamente valutarlo nella sua interezza, come parimenti avviene nelle valutazioni ''a corto circuito'' delle espressioni logiche nei linguaggi di programmazione. Ogni nominativo avrà a sè associato un pattern che lo rappresenta in più possibili sequenze di caratteri; per effettuare una corretta "minimizzazione" dei dati è necessario che le sequenze contenenti tutti i nomi sia poste per prime, mentre quelle contenenti un singolo nome per ultime.<div></div>
In questa prima formulazione della ''regex'', inoltre, si è posto come separatore unicamente lo spazio bianco, ma alcuni documenti potrebbero contenere dei nominativi i cui termini sono separati da altri caratteri, come ad esempio una virgola nel caso di "Amorosa, Lorenzo Mario". Per poter quindi identificare un nominativo anche in questi casi, si potrebbe considerare un qualunque carattere di interpunzione come possibile separatore dei termini del nominativo.
Adottando questa soluzione si ha però come effetto collaterale che risultano critici i casi in cui nel testo sono presenti dei nominativi soggetti ad omonimia. Si consideri una generica frase contenente una sequenza di nominativi, ad esempio ''Amorosa Lorenzo, Mario Giacomo e Fabio Rossi'', e si supponga che i nominativi da trattare siano ''Amorosa Lorenzo Mario'', ''Mario Giacomo'' (in cui la parola ''Mario'' è il cognome) e ''Fabio Rossi''. Gli ultimi due nominativi compaiono nella frase nella loro forma estesa, mentre il primo compare con il solo nome ''Lorenzo'' (eventualità possibile considerando la definizione del pattern precedentemente data). Considerando la virgola come carattere separatore dei termini del nominativo, la sequenza di parole ''Amorosa Lorenzo, Mario'' sarebbe ricondotta, venendo elaborata per prima, ad ''Amorosa Lorenzo Mario'', mentre rimarrebbe non trattata la parola ''Giacomo'', in quanto il cognome ''Mario'' che gli era associato è stato già identificato come un nome del nominativo ''Amorosa Lorenzo Mario'' ed il termine ''Giacomo'' preso singolarmente non rappresenta un nominativo.<div></div>
Prima di valutare ulteriormente le problematiche relative alle omonimie, si possono scegliere due approcci per risolvere questo specifico caso:
# Si riconduce una sequenza di parole ad un nominativo se e solo se tutti i suoi nomi sono contenuti nella sequenza
# Si considerano come separatori dei termini contenuti nei nominativi solo spazi bianchi, tabulazioni e a capo, non gli altri segni di punteggiatura.
<div></div>
Entrambe le strategie sono valide, in quanto risolvono il problema garantendo la corretta identificazione dei nominativi, ma allo stesso tempo entrambe presentano lo svantaggio di ridurre le sequenze di parole riconducibili a dei nominativi, aumentando le possibilità che alcuni di essi non vengano trattati.
Si consideri nuovamente il nominativo preso come caso di studio ''Amorosa Lorenzo Mario'': applicando la prima strategia, non sarebbe possibile ricondurgli la sequenza ''Amorosa Lorenzo'', mentre applicando il secondo metodo non sarebbe riconducibile la sequenza ''Amorosa, Lorenzo Mario''.
Si decide di attuare la seconda strategia, in quanto è opportuno non imporre vincoli troppo stringenti sui nomi e poiché nella gran parte dei casi i termini dei nominativi nei documenti sono separati tra loro da caratteri quali spazi bianchi, tabulazioni ed a capo.<div></div>
Un altro elemento su cui porre l'attenzione è la possibilità che i documenti da trattare contengano dei nominativi scritti interamente in maiuscolo o minuscolo, di conseguenza è conveniente che le ''regular expressions'' siano progettate ''case-insensitive''.<div></div>
Un ulteriore punto su cui bisogna soffermarsi è la posizione all'interno di un periodo in cui un nominativo può comparire, in particolare si vogliono evitare quei casi critici in cui uno dei termini del nominativo è una sotto-stringa di un'altra parola del testo (si pensi ad ''amorosa'' in ''clamorosa''). Come regola generale si può stabilire che è sempre necessario che un nominativo sia preceduto e seguito da un ''carattere non alfabetico''. Un caso particolare si presenta quando il nominativo è posto ad inizio o a fine documento, situazione in cui quindi esso non è preceduto o non è seguito da alcun carattere: entrambe le posizioni sono da considerare corrette.<div></div>
È opportuno ora definire il concetto di ''carattere non alfabetico'', e ciò si può fare più facilmente ragionando sul problema in logica positiva; infatti risulta più semplice individuare quei caratteri che rappresentano lettere piuttosto che quelli che rappresentano segni di interpunzione ed individuare ogni altro carattere che non può mai comporre una parola.

Inquadrando lo scenario di applicazione del servizio, molto probabilmente l'utente vorrà trattare un documento scritto nella lingua di uno dei paesi dell'Unione Europea, poiché il ''GDPR'' vige nei soli paesi membri dell'Unione.
Si può, quindi, ipotizzare che i documenti trattati possono sì contenere parole e nominativi stranieri, ma che i caratteri contenuti siano appartenenti all'alfabeto latino (''Latin script''), usato in molti stati nel mondo e da tutti i principali stati europei (fatta eccezione per la Grecia ed alcuni stati che scrivono in caratteri cirillici).
Inoltre, testi scritti in altri alfabeti, come esempio il cinese, l'arabo o il cirillico, vengono generalmente traslitterati. Considerare, quindi, ''caratteri non alfabetici'' tutti i caratteri diversi dalle lettere contenute nell'alfabeto latino sarebbe di conseguenza estremamente riduttivo ed inoltre in questo modo non si terrebbe conto delle lettere accentate, molto utilizzate anche nella lingua italiana.
<div></div>(XXXX QUI IMG [0F00])<div></div>
Per risolvere il problema facciamo riferimento alla codifica standard Unicode dell'alfabeto latino ([0022]); in essa è possibile individuare, oltre ai caratteri rappresentanti le lettere nella codifica ''ASCII'' classica, i caratteri rappresentanti le lettere nella codifica standard ''ISO/IEC 8859-1'' ([0023]), encoding orientato principalmente alla rappresentazione delle lingue dell'Europa occidentale.

<div></div>
<center><i>Caratteri latini nei primi due blocchi dello standard Unicode</i></center>
{| class="nounderlines" border="1" cellpadding="2" cellspacing="0" style="border-collapse:collapse"
|----- align="center"
!style="background:#ccf; text-align:center; font-weight: bold;"|U+
!style="text-align:center; font-weight: bold;"|0||style="text-align: center; font-weight: bold;"|1||style="text-align: center; font-weight: bold;"|2||style="text-align: center; font-weight: bold;"|3||style="text-align: center; font-weight: bold;"|4||style="text-align: center; font-weight: bold;"|5||style="text-align: center; font-weight: bold;"|6||style="text-align: center; font-weight: bold;"|7||style="text-align: center; font-weight: bold;"|8||style="text-align: center; font-weight: bold;"|9||style="text-align: center; font-weight: bold;"|A||style="text-align: center; font-weight: bold;"|B||style="text-align: center; font-weight: bold;"|C||style="text-align: center; font-weight: bold;"|D||style="text-align: center; font-weight: bold;"|E||style="text-align: center; font-weight: bold;"|F||style="text-align: center; font-weight: bold;"|Block||style="text-align: center; font-weight: bold;"|#
|-
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0040
|style="background:#fff"|@||A||B||C||D||E||F||G||H||I||J||K||L||M||N||O
|rowspan="4" style="background:#fff" align:"center"|C0 Controls and Basic Latin<br>0000–007F<br>(identical to ASCII)
|rowspan="4" style="background:#fff"|52
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0050
|P||Q||R||S||T||U||V||W||X||Y||Z||style="background:#fff"|[||style="background:#fff"|\||style="background:#fff"|]||style="background:#fff"|^||style="background:#fff"|_
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0060
|style="background:#fff"|`||a||b||c||d||e||f||g||h||i||j||k||l||m||n||o
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0070
|p||q||r||s||t||u||v||w||x||y||z||style="background:#fff"|{||style="background:#fff"||||style="background:#fff"|}||style="background:#fff"|~||style="background:#fff; font-size:75%"|DEL
|-
!colspan="19"|
|----- align="center" style="background:#fff"
!style="background:#fff; text-align:center; font-weight: bold;"|00A0
| ||¡||¢||£||¤||¥||¦||§||¨||©||ª||«||¬||||®||¯
|rowspan="6" style="background:#fff" align="center"|C1 Controls and Latin-1 Supplement<br>0080–00FF<br>(identical to ISO/IEC 8859-1)
|rowspan="6" style="background:#fff"|62
|----- align="center" style="background:#fff"
!style="background:#fff; text-align:center; font-weight: bold;"|00B0
|°||±||²||³||´||µ||¶||·||¸||¹||º||»||¼||½||¾||¿
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00C0
|À||Á||Â||Ã||Ä||Å||Æ||Ç||È||É||Ê||Ë||Ì||Í||Î||Ï
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00D0
|Ð||Ñ||Ò||Ó||Ô||Õ||Ö||style="background:#fff"|×||Ø||Ù||Ú||Û||Ü||Ý||Þ||ß
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00E0
|à||á||â||ã||ä||å||æ||ç||è||é||ê||ë||ì||í||î||ï
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00F0
|ð||ñ||ò||ó||ô||õ||ö||style="background:#fff"|÷||ø||ù||ú||û||ü||ý||þ||ÿ
|---- align="center" style="background:#f66"
|}
<div></div>

I caratteri indicati in rosso nella tabella sono tutti i possibili ''caratteri alfabetici'' che compaiono nei documenti scritti in 29 lingue diverse ([0023]), tra le quali sono presenti l'italiano, l'inglese, lo spagnolo, il tedesco e il portoghese.
Aggiungendo pochi altri caratteri all'insieme dei ''caratteri alfabetici'' appena mostrati, si riesce a rappresentare ogni parola di altre 12 lingue ([0023]), tra cui il francese, l'olandese, il ceco e il turco.<div></div>
I caratteri mostrati in tabella corrispondono ad una parte dei primi due blocchi dello standard Unicode che codificano l'alfabeto latino e, come già accennato in precedenza, essi sono presenti negli standard ''ASCII'' e ''ISO/IEC 8859-1''. I rimanenti ''caratteri alfabetici'', invece, sono presenti in estensioni dello standard Unicode per il ''Latin script''. Queste estensioni sono state realizzate per fornire il massimo supporto a tutte le lingue e contenenti molti simboli ad uso speciale, come ad esempio per la rappresentazione dei fonemi. Si osserva, inoltre, che i ''caratteri alfabetici'' definiti nelle estensioni dello standard Unicode sono presenti anche nella codifica ''ISO/IEC 8859-2'' o nelle versioni successive ([0023]).<div></div>
Definiti i ''caratteri non alfabetici'' come elementi di separazione tra un nominativo ed il testo in cui esso è inserito, occorre definire opportunamente la ''regex'' che al nominativo è associata.

Utili strumenti messi a disposizione dalle ''regular expressions'' sono i gruppi speciali ''lookahead'' e ''lookbehind''. Un pattern di un nominativo deve essere preceduto o seguito da una prestabilita sequenza di caratteri, la quale però non è parte del nominativo. Utilizzando i due costrutti citati, è possibile far sì che nell'elaborazione di una stringa facciano match solamente le parole effettivamente appartenenti al nominativo, non i caratteri che lo delimitano dal resto del testo, e allo stesso tempo che un nominativo faccia match se e solo se preceduto o seguito da una certa sequenza di caratteri. <div></div>
Per esprimere nella sintassi delle ''regex'' un carattere letterale in un qualunque alfabeto si può utilizzare il costrutto ''\p{L}'', che però risulta molto generale e troppo lasco per i requisiti considerati. Si può piuttosto valutare l'impiego del costrutto ''\p{Latin}'', il quale identifica un qualunque carattere alfabetico presente nell'alfabeto latino. Tra i caratteri corrispondenti al costrutto, però, ve ne sono alcuni che per le specifiche del servizio devono essere considerati ''caratteri non alfabetici'', come ad esempio i caratteri dei fonemi, i segni diacritici e gli indicatori ordinali; di conseguenza è necessario individuare una strategia ad hoc per risolvere questa problematica.<div></div>
Per chiarezza espositiva, si definisce il tag <span style="font-family: monospace;"><start></span>, per indicare un qualunque carattere non alfabetico o l'inizio stringa, il tag <span style="font-family: monospace;"><end></span>, per indicare un qualunque carattere non alfabetico o il fine stringa, ed il tag <extra>, per indicare i ''caratteri alfabetici'' non presenti negli standard ''ASCII'' o ''ISO/IEC 8859-1'':<div></div>
<span style="font-family: monospace;">
<extra> := ĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ
<br/>
<start> := (?<=[^A-Za-zÀ-ÖØ-öø-ÿ<extra>]|^)
<br/>
<end> := (?=[^A-Za-zÀ-ÖØ-öø-ÿ<extra>]|$)
</span>
<div></div>
Si osserva che si sono utilizzati i gruppi speciali prima descritti e che si sono inseriti i caratteri dello standard Unicode presentati in precedenza. Si definisce nuovamente la ''regular expression'' associata ad un generico nominativo. Applicando i tag appena definiti, il costrutto ''(?i)'' che rende il pattern ''case-insensitive'' ed il costrutto ''\s'' che rappresenta un carattere qualunque tra i separatori non visibili, ossia ''\r \n \t \f \v'' e lo spazio bianco, si ottiene:<div></div>
<span style="font-family: monospace;">
<regex> := (?i)(<start><cognome>\s+(<nomi>)|(<nomi>)\s+<cognome><end>)
</span>
<div></div>
Si osserva, inoltre, che in questa nuova formulazione della ''regular expression'' i nomi sono da intendersi separati tra loro da ''\s+''.<div></div>
A questo punto si è quasi giunti alla formulazione finale del pattern da associare ad un nominativo, rimangono solo da trattare alcuni casi critici non ancora risolti.<div></div>
Si è già presentato in precedenza il problema legato al fatto che alcuni cognomi possono avere un significato proprio nel lessico comune e che ciò costringeva, quindi, ad abbandonare l'idea di trattare nominativi formati dal solo cognome. Questa problematica di ambiguità si presenta anche con alcuni nomi (si pensi, ad esempio, al nome ''Gioia''). Ciò non rappresenta generalmente un problema, in quanto la coppia nome-cognome che forma il nominativo, presa complessivamente, non è soggetta ad ambiguità. Esistono, però, dei casi in cui questo non è vero. Si prenda in analisi il nominativo ''Gioia Grande'': risulta evidentemente soggetto a rischio di ambiguità. Una soluzione che si può adottare, per risolvere questo caso critico, si basa sull'associazione di un pattern più stringente ai nominativi. In particolare, si osserva che i nomi propri di persona compaiono sempre ed obbligatoriamente, in un documento grammaticalmente corretto, con la prima lettera maiuscola ([0024]). I cognomi, invece, non sono soggetti ad una regola così stringente: un cognome iniziante con una lettera minuscola (come ''de Rosa'') in alcuni casi, ad esempio se posto dopo un punto fermo, può comparire scritto con la prima lettera sia maiuscola che minuscola; naturalmente, in nessuna occorrenza un cognome che inizi con una lettera maiuscola potrà comparire con una minuscola. <div></div>
Occorre quindi ridefinire, alla luce di queste osservazioni, la ''regex'' associata ad un nominativo, poiché precedentemente era stata posta interamente ''case-insensitive''. Nel pattern, in particolare, i nomi dovranno sempre iniziare con una maiuscola, mentre i cognomi avranno questo vincolo solo se nel nominativo compaiono con la prima lettera maiuscola. Si mostra quindi quali sono i tag <span style="font-family: monospace;"><nomi></span> e <span style="font-family: monospace;"><cognome></span> associati a due nominativi, ad esempio ''Gioia Grande'' e ''Antonio de Rosa''. <div></div>
Per ''Gioia Grande'' si ha:<div></div>
<span style="font-family: monospace;"><nomi> = G((?i)ioia)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = G((?i)rande)</span>
<div></div>
Per ''Antonio de Rosa'' si ha:<div></div>
<span style="font-family: monospace;"><nomi> = A((?i)ntonio)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = (?i)de Rosa</span>
<div></div>
Si presenta dunque la definizione finale del tag <span style="font-family: monospace;"><regex></span>. Nella definizione il tag <span style="font-family: monospace;"><nomi></span> è definito il base al numero di nomi del nominativo ed il tag <span style="font-family: monospace;"><cognome></span> è definito in base al carattere iniziale del cognome.<div></div>
<span style="font-family: monospace;">
<regex> := <start><cognome>\s+(<nomi>)|(<nomi>)\s+<cognome><end>
</span>
<div></div>
Vengono inoltre mostrati i valori dei due tag <span style="font-family: monospace;"><nomi></span> e <span style="font-family: monospace;"><cognome></span> per il nominativo preso come caso di studio in fase iniziale, ossia ''Amorosa Lorenzo Mario''. Si ottiene:<div></div>
<span style="font-family: monospace;"><nomi> = L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = A((?i)morosa)</span>
<div></div>
Infine, per completezza, viene mostrata la ''regular expression'', associata a quest'ultimo nominativo, risolvendo tutti i tag che la compongono:
<div></div>
<span style="font-family: monospace;">
<regex> = (?<=[^A-Za-zÀ-ÖØ-öø-ÿĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ]|^)(A((?i)morosa)\s+(L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario))|(L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario))\s+A((?i)morosa))(?=[^A-Za-zÀ-ÖØ-öø-ÿĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ]|$)
</span>
<div></div>

====Gestione delle omonimie====

Nei ragionamenti che hanno portato alla formulazione della ''regular expression'' associata ai nominativi, si è tenuto conto di possibili ambiguità con termini appartenenti al linguaggio comune, risolte con l'introduzione nel pattern di stringhe ''case-sensitive'', e di possibili nominativi posti in sequenza parzialmente omonimi (ossia aventi un nome o il cognome in comune tra loro), gestite con l'imposizione dei soli caratteri separatori non visibili come delimitatori delle parole componenti un nominativo. Per rendere l'analisi completa occorre valutare come ci si debba comportare in altri possibili casi di omonimia. Si osserva, per inciso, che nel pattern individuato nella sezione precedente il tag <span style="font-family: monospace;"><nomi></span> è stato l'unico non definito formalmente. La definizione di tale tag infatti dipende, oltre che dai nomi del nominativo, anche dall'insieme complessivo dei nominativi da trattare presenti nel documento.<div></div>
Il caso più semplice di omonimia, che si verifica quando un solo nome o il solo cognome di un nominativo coincide con un nome o il cognome di un altro (come nel caso di ''Lorenzo Mario Amorosa'' e ''Stefano Amorosa''), risulta già ben gestito dall'attuale formulazione del pattern. Infatti, un riconoscimento è determinato quando almeno un nome e il cognome del nominativo appaiono in sequenza.<div></div>
Il problema si complica quando un nominativo ha due o più componenti in comune con un altro. Si osserva che se l'omonimia riguarda solo i nomi dei nominativi, ciò non risulta problematico, in quanto il cognome, supposto sempre presente nel pattern, funge da elemento di disambiguazione. Si considera da ora, quindi, che i nominativi abbiano il medesimo cognome e si analizzano i casi in cui anche uno o più nomi risultano in comune, attraverso degli esempi:
* Nomi_A = {"Lorenzo", "Mario", "Luca"}; Nomi_B = {"Stefano", "Mario"}
<div></div>(QUI IMG [0F01])<div></div>
In questo caso sono elementi di disambiguazione i nomi ''Lorenzo'' e ''Luca'' per il primo nominativo e ''Stefano'' per il secondo, bisognerà quindi far sì che almeno uno tra tali nomi compaia sempre nelle ''regex'' associate ai nominativi in questione. L'occorrenza ''Mario <cognome>'' rimane ambigua e non può essere trattata.
* Nomi_A = {"Lorenzo", "Mario", "Luca"}; Nomi_B = {"Mario", "Luca"}
<div></div>(QUI IMG [0F02])<div></div>
L'insieme Nomi_B risulta un sottoinsieme di Nomi_A, di conseguenza solo il primo nominativo presenta degli elementi utili per risolvere l'ambiguità. Nel pattern relativo al primo nominativo dovrà essere presente almeno un tra i nomi non in comune, mentre il pattern del secondo nominativo rappresenterà inevitabilmente espressioni ambigue poiché riconducibili all'altro. Le soluzioni possibili sono due: rifiutarsi di effettuare il trattamento del secondo nominativo oppure decretare che esso è riconosciuto se e solo se appare nella sua forma estesa, presentando quindi tutti i nomi. Quest'ultima soluzione è ragionevole e la si sceglie, poiché così si aumentano, per quanto possibile, le sequenze "minimizzabili", e viene inoltre messo in conto di informare l'utente opportunamente sulla gestione di questo genere di omonimia per rendere le operazioni trasparenti.
* Nomi_A = Nomi_B = {"Lorenzo", "Mario", "Luca"}
<div></div>(QUI IMG [0F03])<div></div>
Qualora l'insieme dei nomi dei due nominativi sia identico risulta impossibile distinguerli e non possono in alcun modo essere trattati, poiché l'ordine con cui compaiono i nomi di un nominativo non rappresenta un elemento di disambiguità. I dati appartenenti a persone completamente omonime contenuti in uno stesso documento, quindi, non sono "minimizzabili" distintamente.<div></div>
Si osserva che è di fondamentale importanza che i documenti che gli utenti forniscono siano grammaticalmente corretti, in quanto un errato uso dei segni di interpunzione può rendere impossibile l'applicazione delle ''regular expression''. Si prenda ad esempio una sequenza anomala di caratteri in cui non è corretto l'uso delle virgole, come "''Amorosa Mario Rossi Giacomo''": supponendo che nel documento si vogliano trattare i nominativi ''Amorosa Mario'', ''Rossi Mario'' e ''Rossi Giacomo'', risulta impossibile identificare quali tra questi siano rappresentatati nella sequenza.<div></div>
In conclusione, risultano quindi individuate le strategie che permettono di formulare ''regular expressions'' anche per i nominativi soggetti ad omonimia.

====Formattazione dei documenti====

I documenti prodotti in enti ed organizzazioni presentano generalmente formattazioni e non sono puramente testuali. Si vuole qui considerare quale debbano essere le interpretazioni più adatte da dare agli elementi grafici per rendere sempre efficace il riconoscimento dei nominativi. In particolare, quindi, non si tratteranno gli elementi di punteggiatura, come parentesi o virgolette, poiché già compresi nelle ''regex'', bensì tutti gli elementi che in un pattern composto da caratteri non sono espressi. Si inizia dunque la rassegna:
* Elementi di formattazione del testo
I font, la dimensione dei caratteri, il grassetto, il corsivo, l'evidenziazione e tutti i possibili elementi di modifica della apparizione grafica del testo non alterano il significato dei lessemi coinvolti. Se il cognome di un nominativo è posto in grassetto ed il nome no, ad esempio, la coppia nome-cognome rappresenta sempre il nominativo iniziale; lo stesso vale per gli altri elementi citati.
* Aree di comparizione del testo
In genere ogni documento è formato da più sezioni, ha un corpo principale ed eventuali titoli, note a piè pagina, intestazioni ed altre possibili aree. Il trattamento di "minimizzazione", secondo il ''GDPR'', deve essere effettuato al documento in ogni sua parte, ma ogni sezione deve essere elaborata in maniera indipendente dalle altre sezioni in quanto rappresenta un blocco logico a sé. Ciò significa che, ad esempio, bisogna individuare eventuali nominativi presenti nel titolo, ma non bisogna considerare nominativo una sequenza di parole che è posta in parte nel titolo e in parte nel primo paragrafo del testo.
* Elementi blocco
Gli elementi blocco, come ad esempio le immagini, possono causare un'interruzione netta in un paragrafo, suddividendolo quindi in più blocchi logici, che devono essere analizzati separatamente; tuttavia nel caso in cui questi elementi siano posti ''fluttuanti'', ossia ancorati ai bordi della pagina, il testo scorre in un unico flusso e forma quindi un unico blocco logico.
* Divisione in sillabe
Un problema rilevante nella formattazione del documento è che spesso, per esigenze estetiche, contiene delle parole divise in sillabe poste su righe diverse e separate da un trattino. Ovviamente se un nome va a capo a fine linea non perde il suo significato semantico, bisognerà quindi continuare a riconoscerlo.
* Tabelle
Molti documenti, specialmente quelli contenenti ingenti quantità di nominativi, possono essere strutturati in forma tabellare. Trascurando una trattazione per esteso delle modalità con cui i nominativi potrebbero comparire nelle tabelle, si considera esclusivamente il caso di gran lunga più ricorrente. In genere, infatti, in una tabella contenente dei nominativi, essi sono presenti nella stessa colonna o in colonne contigue: l'una contenente i nomi, l'altra il cognome, o viceversa. Senza basarsi sull'intestazione delle colonne, si può valutare se il contenuto di due celle adiacenti poste su di una stessa riga faccia match con il pattern di un nominativo, ed in caso ciò accada si può affermare la coppia di celle individuata rappresenta un nominativo.<div></div>
Si osserva che si sono fornite solamente le interpretazioni più plausibili e comuni a questi elementi grafici e non si è ideato alcun particolare algoritmo per la loro elaborazione. L'espressione di tali strutture, infatti, è fortemente determinata dal formato in cui il documento è redatto. Si rimanda, quindi, ai capitoli successivi per specificazioni ulteriori della soluzione. Occorre notare, infine, che gli elementi di formattazione non sono descritti da stringhe nel formato delle ''regular expressions'': bisognerà quindi integrare gli elementi presentati in questa sezione con l'approccio ''pattern-based'' adottato.

===Analisi dell'usabilità===

====Elenco dei nominativi da trattare esplicitamente espressi come dati in input====

In questo caso, per usufruire del servizio, l'utente deve fornire un documento contenente una serie di nominativi da trattare. Una garanzia della corretta elaborazione del documento si ha richiedendo all'utente stesso quali siano i nominativi da trattare: in questo modo potranno essere "minimizzati" i dati (cioè i nominativi) di tutte e sole le persone espressamente richieste. In molti plausibili scenari, infatti, è necessario anonimizzare solo alcuni dei nominativi presenti nel documento; ad esempio in un atto giudiziario serve anonimizzare le parti in causa ma non i magistrati.

Questa configurazione del servizio permette quindi all'utente di avere il massimo controllo possibile del risultato. Tuttavia questo approccio è poco pratico nel caso in cui i documenti da trattare contengano grandi quantità di nominativi diversi e, magari, l'utente che ne richiede il trattamento non li conosce; si pensi ad esempio a lunghe graduatorie di concorsi o altro. Si osserva inoltre che anche per pochi nominativi l'usabilità può degradare, se l'inserimento viene fatto con estemporanea digitazione, esposta anche al rischio di possibili errori di battitura, con conseguenti noiose ripetizioni delle operazioni.

Si osserva, infine, che il sistema progettato è sufficientemente robusto nel trattare i nominativi in input espressi da un utente che ha digitato caratteri maiuscoli o minuscoli violando le convenzioni grammaticali. Supposto che il documento trattato debba essere grammaticalmente corretto, infatti, si ha la garanzia che i nomi ivi presenti comincino con una maiuscola; è sufficiente, quindi, forzare una conversione ''to-upper-case'' dei nomi inseriti dall'utente e le ''regex'' progettate funzionano correttamente. Un discorso a parte va fatto per i cognomi inseriti dall'utente, in quanto essi possono comparire con la prima lettera sia maiuscola che minuscola. L'inserimento di un cognome iniziante con una minuscola non crea grossi problemi, in quanto in tal caso la ''regex'' risultante sarebbe totalmente ''case-insensitive'' per il cognome, mentre l'aggiunta di un cognome cominciante con una maiuscola determina una ''regex'' ''case-insensitive'' per la prima lettera del cognome; qualora quindi un utente inserisse un nominativo tutto in maiuscolo, le occorrenze del cognome, presenti nel documento, inizianti con una lettera minuscola non verrebbero riconosciute.
Per le altre lettere dopo la prima, sia per i nomi che per i cognomi, il pattern è stato progettato ''case-insensitive'', quindi non emergono problemi. <div></div>
In sintesi, il rischio che vengano introdotte delle ambiguità lessicali, incaricando l'utente dell'inserimento dei nominativi, è piuttosto basso ed il controllo che si ha sui nominativi è il massimo desiderabile, mentre i requisiti di usabilità risultano penalizzati.

====Elenco dei nominativi da trattare dedotti automaticamente da un dizionario====

Se si desidera privilegiare la tematica dell'usabilità nella progettazione del servizio, risulta necessario individuare delle strategie che semplifichino il più possibile i compiti che devono essere svolti dall'utente. L'unica operazione che inevitabilmente resta a suo carico è l'upload del documento da trattare; non è infatti necessario richiedergli l'elencazione dei nominativi dei nominativi da trattare, in quanto questi possono essere dedotti automaticamente impiegando dei dizionari, dei quali va quindi valutato il contenuto e le modalità di utilizzo. <div></div>

Si scarta subito l'ipotesi di dedurre automaticamente i nominativi basandosi unicamente sul fatto che le iniziali di nomi e cognomi siano maiuscole; come già argomentato infatti l'uso delle lettere maiuscole non è limitato solo a questi usi e, inoltre, non si può avere la certezza che un cognome inizi con una maiuscola.

Sono disponibili fortunatamente alcuni dizionari di nomi ed altri di cognomi, in diverse lingue; si fa qui riferimento a quelli di "Data World" (un'azienda focalizzata sulla raccolta, produzione e pubblicazione di dataset: https://data.world) ([0037]).

Si inizia l'analisi inquadrando le dimensioni che un dizionario contenente nomi o cognomi avrebbe. Risalta subito all'occhio la differenza tra il numero di termini contenuti nei due casi: facendo riferimento ai soli nomi e cognomi italiani, risultano esistenti circa 350.000 cognomi ([0036]) e circa 9.000 nomi, dei quale circa 5.000 maschili e circa 4.000 femminili ([0037]); il numero dei cognomi è quindi quasi 40 volte più grande del numero dei nomi.<div></div>
Si ipotizza, per chiarire le idee, di applicare questi dizionari in uno scenario reale, in cui, ad esempio, si vuole trattare un documento di 10 pagine contenente 5.000 parole. Si trascurano inoltre i meccanismi che permettono di ricondurre un nome od un cognome ad un nominativo per concentrarsi unicamente sul numero di confronti necessari da effettuare nell'elaborazione. Nel peggiore dei casi possibili, ossia quando nessuna parola del documento compare tra i termini del dizionari, e dove occorre quindi confrontare ogni singola parola del documento con tutti i termini del dizionario, per semplice moltiplicazione si ottiene che l'impiego di un dizionario di nomi darebbe luogo a 45.000.000 confronti, mentre un dizionario di cognomi ben a 1.750.000.000 confronti. Se invece le parole nel documento fossero 50.000 si avrebbero 450.000.000 di confronti nel primo caso e 10.750.000.000 nel secondo. In sintesi, sebbene il rapporto tra il numero di confronti nei due casi rimanga sempre costante (circa 1:40) indipendentemente dalla lunghezza del documento, la differenza tra il numero di confronti cresce proporzionalmente al numero di parole che vengono sottoposte all'elaborazione. Per quantificare, infine, attraverso un unità di tempo, la differenza esistente tra l'impiego delle due diverse tipologie di dizionario, si realizza un semplice programma java, di cui si riporta qui sotto il contenuto del metodo principale, che realizza i confronti necessari attraverso l'uso di ''regular expression'':
<div></div>
<div style="font-family: monospace;">
final String regex = "\bLorenzo\b";<br/>
final String string = ... //testo di prova<br/>
<br/>
final Pattern pattern = Pattern.compile(regex, Pattern.MULTILINE);<br/>
final Matcher matcher = pattern.matcher(string);<br/>
int start, total;
<br/>
start = System.currentTimeMillis();
while (matcher.find()) {
System.out.println("Full match: " + matcher.group(0));
for (int i = 1; i <= matcher.groupCount(); i++) {
System.out.println("Group " + i + ": " + matcher.group(i));
}
} <br/>
total = System.currentTimeMillis() - start;
System.out.println("Total: " + total + " ms");
</div>
<div></div>
Eseguendo il test più volte, inserendo fino a 10 occorrenze della parola "Lorenzo" nel testo, si ha un tempo di elaborazione medio di circa 3 ms, con prestazioni di picco di 2 ms, ottenibili con poche occorrenze del nome presenti, e tempo di attesa massimo di 6 ms, dovuto alla presenza invece a una presenza più frequente del nome nel testo.
Questo fenomeno si comprende meglio ricordando che, come spiegato nel capitolo precedente, le ''regular expressions'' ottimizzano la ricerca, considerano le stringhe del testo trattato solo finché necessario, ossia fino a quando non vi è certezza che esse corrispondano o non corrispondano ad un match. Ogni volta che nel testo si presenta una parola che inizia con una lettera diversa dalla 'L' di "Lorenzo", la ricerca procede direttamente con la valutazione della parola successiva, ignorando i rimanenti caratteri della parola.

Risulta, invece, più onerosa la verifica della corrispondenza tra una stringa ed il pattern desiderato, poiché in questo caso vanno elaborati tutti i caratteri della parola. Come caso limite, si è posta come stringa da elaborare la sequenza di caratteri "Lorenzo " ripetuta 500 volte: il tempo di esecuzione medio del programma risultante, a parità di piattaforma, è stato di circa 25 ms.

Un'altra diretta conseguenza di questo meccanismo di confronto è che all'aumentare del numero di parole nel documento non corrisponde un eccessivo aumento del tempo di esecuzione: considerando un documento di 5000 parole, con 0 occorrenze del nome "Lorenzo" il tempo di esecuzione medio risulta di 9 ms, con 10 occorrenze di 10 ms, con 100 occorrenze di 15 ms.

Occorre precisare, prima di formulare ulteriori ragionamenti, che in documento di 5.000 parole potranno essere presenti al più 2500 coppie nome-cognome; in un dizionario con più di 2.500 termini almeno uno di questi non contribuirà nell'individuazione di un nominativo. Se poi sono presenti altre parole oltre ai nominativi nel documento, la percentuale di nomi che presenterà 0 occorrenze crescerà di conseguenza. Ad ogni modo, si sceglie di sviluppare i ragionamenti considerando necessario il tempo medio di 10 ms per individuare le occorrenze di un termine di un dizionario in un documento di 5.000 parole; questo tempo è sicuramente maggiore rispetto al caso reale, ma valutando per eccesso questo valore è possibile trascurare il tempo impiegato nelle altre operazioni di routine a supporto dell'algoritmo di ricerca.

Ritornando all'esempio di partenza, considerando quindi necessari 10 ms per individuare le occorrenze di un termine di un dizionario in un documento di 5.000 parole, risulta che l'identificazione di tutti i cognomi contenuti nel testo richieda circa 3.500 secondi, (quasi un'ora!), mentre l'individuazione dei nomi "solo" 90 secondi.
I tempi di attesa che l'utente dovrebbe aspettare sono estremamente elevati e irragionevoli, specialmente se calati nel contesto nelle ''web application''. Come primo espediente per ovviare al problema si decide di abbandonare completamente l'idea di impiegare un dizionario di cognomi, in quanto, seppur si individuassero delle soluzioni in grado di effettuare il riconoscimento di tutte le occorrenze di un termine in un documento indipendentemente dalla lunghezza in solo 1 ms (irreale), sarebbero comunque necessari 3 minuti e 50 secondi per l'elaborazione. Non verranno quindi neppure trattate possibili soluzioni che prevedono l'applicazione di entrambi i dizionari.

I 90 secondi richiesti dal dizionario di nomi, invece, risultano anch'essi eccessivi, ma attraverso opportune valutazioni si possono individuare delle strategie che consentono la minimizzazione del tempo necessario all'elaborazione dei documenti. Tali metodi di ottimizzazione saranno trattati in un successivo capitolo, mentre ora ci si continua a concentrare sulle modalità di impiego del dizionario.

Per inciso, si osserva che i problemi di efficienza sono strettamente legati al riconoscimento automatico dei nominativi, in quanto in questo caso devono essere applicate quasi una decina di migliaia di ''regex'' diverse; nel caso in cui i nominativi da elaborare e le ''regex'' a loro associate siano noti, si ha a che fare con un numero esiguo di pattern da trattare e l'esecuzione del programma risulta infinitamente più rapida.<div></div>

Per migliorare l'efficacia del servizio sarebbe opportuno introdurre nel dizionario anche nomi stranieri, sempre più diffusi in una società sempre più globalizzata. Il tempo di esecuzione medio del riconoscimento, già critico, crescerebbe ulteriormente: si decide allora di introdurre nel dizionario i soli nomi inglesi, in totale quasi 5500 ([0037]). Considerando sempre un tempo medio di esecuzione di 10 ms per nome, con un dizionario di circa 14.500 termini si avrebbe un tempo di esecuzione medio complessivo di 145 secondi, ossia pari a 2 minuti e 25 secondi, e risulta ancora possibile effettuare alcune ottimizzazioni che lo riducono ad un livello accettabile.

Una volta individuati i nomi contenuti nel documento occorre stabilire se essi fanno parte di un nominativo, progettando un'opportuna ''regular expression''. È importante notare che per conseguire questo scopo bisogna individuare la soluzione più efficiente possibile.

Un nominativo, come già ripetuto più volte, è composto da uno o più nomi e da un cognome. Individuato un nome, la priorità che si ha è verificare se accanto ad esso sia presente un cognome. Finora i cognomi sono stati supposti non regolamentati da alcun pattern specifico, ma è necessario formularne almeno uno per consentirne il riconoscimento automatico. È ragionevole supporre che un cognome sia formato da massimo due parole, separate da spazio o apostrofo, sempre inizianti entrambe con una maiuscola, fatta eccezione per la prima parola laddove essa sia una preposizione semplice o articolata oppure un articolo, tenendo conto dei possibili troncamenti, come <i>d'</i> e <i>dell'</i>. Inoltre per verificare se un termine adiacente al nome trovato rappresenti un nome si evita di impiegare nuovamente il dizionario per non gravare ulteriormente sul tempo di esecuzione. Inoltre, si nota che avendo supposto un cognome composto da massimo due parole inizianti con una lettera maiuscola, un altro nome, oltre quello trovato dal dizionario, viene già automaticamente riconosciuto qualora il cognome sia composto da una sola parola. Rinunciando ad individuare nominativi composti da tre nomi o più, si formula una ''regular expression'' per il riconoscimento automatico in seguito al identificazione di un nome, qui indicato con il tag <span style="font-family: monospace;"><nome></span>, supponendo il cognome come precedentemente indicato e ipotizzando la presenza di un ulteriore nominativo.
<div></div>
<div style="font-family: monospace;">
<prep> := d((a|e)(l(l[aeo]?)?|i|gli?)?|i)?|(ne|a|su)(l(l[aeo]?)?|i|gli)?|l[aeo]?|co[iln]?|i[ln]?|gli|per

<cognome> := (([A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]*|<prep>)('|\s))?[A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]+

<second_name> := [A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]+

<regex> := (<second_name>\s)?(<nome>)\s<cognome>|<cognome>\s(<nome>)(\s<second_name>)?
</div>
<div></div>
Nella scrittura della ''regex'' si è prestata particolare attenzione all'utilizzo della simbologia per rendere l'espressione il più performante possibile, attraverso il massimo sfruttamento dei cortocircuiti logici e l'opportuno ordinamento dei caratteri (sono stati anteposti i caratteri comuni a più preposizioni od articoli). Inoltre, per alleggerire la ''regex'' si è rinunciato all'utilizzo dei caratteri dell'alfabeto latino non appartenenti ai primi due blocchi Unicode.
<div></div>
È mostrata in figura la corretta elaborazione di 57 possibili casi di cognomi diversi
<div></div>(QUI IMG [0F04])<div></div>
Si osserva tuttavia che in alcune circostanze, come nella frase "''di Amorosa Lorenzo non si hanno notizie''", accade che un parola ("''di''" in questo caso), non sia parte del cognome ma il programma non è in grado di riconoscerlo. Questa ambiguità è fortemente dipendente dal contesto e non è possibile trattarla senza significativi degradi delle performance; quindi è necessario rinunciare a trattarla, accettando riconoscimenti erronei. In altre situazioni, invece, dove magari si sta elaborando la stringa contenente il nominativo ''Mario Lorenzo'', risulta impossibile determinare quale tra i due termini sia il nome e quale il cognome; cioè significa che l'unico trattamento di "minimizzazione" automatico che risulta ragionevole applicare è la sostituzione del nominativo con uno pseudonimo, non il troncamento o l'alterazione dei nomi.
In conclusione, con il riconoscimento automatico dei nominativi si migliora complessivamente l'usabilità del servizio, in quanto l'utente non deve digitare i nominativi, ma la latenza introdotta è notevole, si è soggetti a rischi di ambiguità e non è in alcun modo esprimibile la preferenza su quali nominativi si desidera "minimizzare" o meno. La soluzione così ideata non risulta quindi adeguata.

====Soluzione ibrida adottata====
Entrambe le tipologie di riconoscimento prima individuate hanno significativi problemi, si cerca quindi di sintetizzare una soluzione in grado di trarre i vantaggi dell'una e dell'altra. Risulta efficace, in particolare, che il documento venga inizialmente trattato tramite dizionari, evitando all'utente l'onere di specificare i nominativi, e che in seguito venga lasciata all'utente la possibilità di intervenire.
Infatti, esso potrebbe voler esprimere delle preferenze su quali nominativi debbano essere trattati tra quelli individuati e gestire gli eventuali errori di riconoscimento dovuti a richieste di trattamento di nominativi aventi un nome non presente nel dizionario o anche dovuti a casi di ambiguità lessicale già presentati.

Una volta inserito il documento e terminata l'elaborazione tramite il dizionario, l'utente può sia richiedere l'immediato download del file ed effettuare le operazioni prima definite, attraverso un'opportuna interfaccia. Per fornire il supporto alle esigenze più disparate, si prevede la possibilità di:
# eseguire download del file trattato unicamente con il dizionario
# ripetere la "minimizzazione" del documento, specificando:
## nuovi nominativi
## quali nominativi tra quelli precedentemente individuati ''non'' si vogliono trattare
## quale parola/e dei nominativi individuati rappresenta il cognome (in tal caso, si possono utilizzare altri metodi, oltre alla sostituzione con pseudonimo, per il trattamento)
## quale parola/e dei nominativi individuati non compone il nominativo (situazione che si verifica quando ci si imbatte in una ambiguità).

Senza soffermarsi in questo momento sull'intera sequenza concreta di interazioni tra utente e servizio, si osserva che l'unico vincolo non funzionale da valutare resta il tempo medio di attesa dell'utente. L'usabilità complessiva è molto buona ed i vincoli funzionali sono soddisfatti.

===Scelta dei formati da trattare===

Una considerazione intuitiva, ed una buona prassi, è che un documento contenente dati personali sia pseudonimizzato o anonimizzato quanto prima possibile e cioè quando è ancora solo nelle mani del suo autore: questo approccio scongiura che informazioni sensibili e dati personali in chiaro ''sfuggano'' in rete.
Si può per questo ragionevolmente ipotizzare che i naturali destinatari del servizio siano gli stessi autori (creatori) che redigono il documento. Nello scenario tipico di utilizzo, infatti, il fruitore del servizio procederà al trattamento dei dati non appena avrà finito di scrivere il documento del quale, essendone autore, potrà scegliere il formato. Si osserva che potrebbe accadere che il documento sia redatto da terzi: in tal caso l'utente che richiede il trattamento può scegliere il formato in maniera indiretta concordandolo con il redattore. Avendo quindi l'utente la possibilità di stabilire il formato del proprio documento, risulta ragionevole progettare un servizio che lavori su un solo formato.
A questo punto occorre individuare quale sia il formato che maggiormente si presta alle finalità del servizio.<div></div>
Una possibilità è quella di richiedere all'utente di inserire come documento da trattare un semplice file di testo in formato ''txt'': in questo modo ci sarebbe il grande vantaggio di trattare file molto semplici, riducendo così al minimo la complessità realizzativa, e inoltre si avrebbe l'indipendenza dagli editor di testo utilizzati, in quanto tutti supportano i file in formato ''txt''.
Risulta tuttavia sconveniente utilizzare questo formato, poiché non ha alcuna capacità espressiva per gestire elementi complessi come tabelle, modifiche allo stile del testo e così via.
Bisogna quindi optare per un formato in grado di gestire questi elementi, al costo di aumentare la complessità della progettazione, ricordando sempre che è necessario allo stesso tempo che tale formato sia supportato da tutti i principali editor di testo.<div></div>
Con facilità è possibile individuare quali sono i formati di testo più comuni oltre al ''txt'': ''doc'', ''docx'', ''odt'', ''pdf'', ''pages'', ''rtf'', ''tex''. Si passa ora dunque a valutare quale tra questi formati potrebbe meglio soddisfare i requisiti prima enunciati.
Facendo una cernita iniziale sulla base delle finalità per le quali un formato è utilizzato, si può immediatamente escludere ''tex'', che trova impiego principalmente in ambito scientifico e matematico. In questo settore, infatti, non è richiesta generalmente l'applicazione delle procedura di trattamento dei dati. <div></div>
Si può inoltre abbandonare l'idea di trattare documenti con estensione ''pages'', formato proprietario di Apple, poiché utilizzati esclusivamente dall'omonimo editor di testo anch'esso proprietario, e i documenti con estensione ''rtf'', acronimo di ''Rich Text Format'', formato proprietario di Microsoft che supporta una formattazione avanzata, poiché, pur gestito da vari editor, è un formato decisamente datato (ultima versione 1.9.1 risalente a marzo 2008 ([0009])). <div></div>
Si esclude inoltre il formato ''pdf'' per motivi di usabilità: molti editor, infatti, consentono di esportare un documento in questo formato ma non permettono di importarlo. Un utente dopo aver effettuato l'anonimizzazione di un documento non può quindi proseguire modificandolo ulteriormente. Il ''Portable Document Format'', infatti, è ideato per realizzare dei documenti destinati alla sola lettura.
L'ultima esclusione, piuttosto immediata da effettuare, riguarda il formato ''doc'', binario e proprietario di Microsoft. Esso infatti risulta, a partire dal 2006, soppiantato dal formato ''docx'', sempre proprietario di Microsoft.

Si giunge infine a valutare quale tra gli ultimi due possibili formati rimanenti, ossia ''docx'' e ''odt'', si presta meglio alle finalità del servizio. In via preliminare si osserva che entrambi i formati possiedono ottime capacità espressive, hanno una struttura interna di simile complessità e sono entrambi supportati dai principali editor di testo. È necessario quindi effettuare delle analisi più approfondite per poter sceglierne uno tra i due.
La struttura del formato ''docx'', sviluppato da Microsoft e formalmente denominato ''Office Open XML Document (OOXML Document)'', è costituita da un file compresso .zip contenente un insieme di file ''XML''. Il formato ''OOXML'' permette la rappresentazione, oltre che di documenti testuali, anche di fogli elettronici (formato ''OOXML 'Workbook'', noto anche come ''xslx'') e di presentazioni (formato ''OOXML Presentation'', noto anche come ''pptx'') ([0008], [0013]).
Il formato inoltre è stato inizialmente standardizzato nel 2006 dall'<i>ECMA</i> (come ''ECMA-376'') e successivamente nel 2008 dall'<i>ISO</i> e dall'<i>IEC</i> (come ''ISO/IEC 29500'') in una versione ''transitional'', retrocompatibile con alcune versioni precedenti del formato contenenti elementi deprecati, e in una versione ''strict'', dove tali elementi non sono ammessi. I due standard sono stati poi successivamente aggiornati e sono tutt'ora oggetto di revisioni ([0002]).

Anche la struttura del formato open source ''odt'', sviluppato dall'<i>OASIS</i> e formalmente denominato ''OpenDocument Text'', è basata su uno zip contenente un insieme di file ''XML''. Inoltre, il formato ''OpenDocument Format (ODF)'' permette di trattare fogli elettronici (formato ''OpenDocument Spreadsheet'', noto anche come ''ods'') e presentazioni (formato ''OpenDocument Presentation'', noto anche come ''odp'') ([0007]). Anche ''OpenDocument Text'' è stato standardizzato, in particolare dall'<i>OASIS</i> stesso nel 2005 e dall'<i>ISO/IEC</i> nel 2006, ed è soggetto a revisioni e aggiornamenti ([0003]).

In sintesi, basandosi sulla struttura dei documenti e sulla standardizzazione dei formati, non è ancora possibile individuare quale sia il formato migliore. L'unico elemento che potrebbe portare punti a favore del formato ''odt'' è che esso, a differenza del formato ''docx'', è aperto, tuttavia, essendo le specifiche di entrambi i formati pubbliche, ciò non rappresenta un fattore determinante nell'elezione del formato.
Entrambi i formati, inoltre, sono largamente supportati dai word processors.

Le seguenti tabelle riepilogano il supporto all'uno ed all'altro formato dei ''word-processors'' più usati, ossia ''Microsoft Office Word'', ''LibreOffice Writer'', ''OpenOffice Writer'' e ''Pages''.
Le tabelle sono tratte da wikipedia ([0000], [0001], [0006]). <div></div>

<center><i>Supporto fornito dagli editor di testo al formato docx</i></center>
{| class="wikitable"
|-
! !! Microsoft Office Word !! LibreOffice Writer !! OpenOffice Writer !! Pages
|-
! Version
|| 2013, 2011 for Mac || All versions || 3.0 || '08
|-
! Operating systems
|| Windows, Mac OS X || Windows, OS X, Linux, Unix, Android || Windows, Linux, Unix, Mac OS X || Mac OS X
|-
! Office suite
|| Microsoft Office || || OpenOffice.org || iWork
|-
! Developer
|| Microsoft || The Document Foundation || Apache OpenOffice || Apple Inc.
|-
! License
|| proprietary || MPL || LGPL || proprietary
|-
! ECMA-376
|| yes || yes || yes || yes
|-
! ISO/IEC 29500:2008
|| yes || yes || ||
|-
! Notes
|| || || Import only ||
|}

<div></div>
<center><i>Supporto fornito dagli editor di testo al formato odt</i></center>
{| class="wikitable"
|-
! !! Microsoft Office Word !! LibreOffice Writer !! OpenOffice Writer
|-
! Version
|| 2007 SP2 || 4.0.3 || 3.0.0
|-
! Operating systems
|| Windows || Unix-based systems, Mac OS X, Solaris || Windows, Linux, Unix-based systems, Mac OS X, Solaris
|-
! Office suite
|| Microsoft Office || || OpenOffice.org
|-
! Developer
|| Microsoft || The Document Foundation || Apache OpenOffice
|-
! License
|| Proprietary || MPL || LGPL
|-
! ISO/IEC 26300:2006
|| yes || yes || yes
|-
! Notes
|| some limitations || Multiple ODF versions supported (ISO/ODF 1.0/1.1/1.2/1.2 Extended) || adjustable ODF version (ISO/ODF 1.2)
|}
<div></div>

Si possono effettuare le seguenti osservazioni:
* ''Microsoft Office Word'' è, in ambiente Microsoft, il word processor maggiormente usato; è molto usato anche in ambiente Apple Mac. Esso offre il pieno supporto al formato ''OOXML Document''; solo parzialmente invece gestisce il formato ''OpenDocument Text'': il processamento di file con estensione ''odt'' con questo editor comporta la perdita di alcune informazioni secondarie.
* ''LibreOffice Writer'', l'editor open source maggiormente utilizzato, supporta pienamente entrambi formati. Nato con lo scopo di gestire i file con formato ''OpenDocument Text'', attualmente supporta completamente anche il formato ''OOXML Document''.
* ''OpenOffice Writer'', un altro degli editor di testo tra i più utilizzati, supporta pienamente ''odt'', mentre è solo in grado di importare i file con estensione ''docx''.
* ''Pages'', il word process installato a default sui Mac della Apple e, di conseguenza anche maggiormente usato su questi dispositivi, non offre supporto al formato ''odt'', ma elabora correttamente i documenti con estensione ''docx'' ([0005],[0004]). <div></div>
Queste osservazioni evidenziano che quindi è impossibile adottare un formato supportato da tutti gli editor; la scelta va allora indirizzata verso quello maggiormente supportato dai word processor più popolari.
Per avere un'indicazione di ''popolarità'', e quindi per poter comprendere meglio quali tra gli editor prima citati siano i più usati, si può fare un'analisi, tramite motori di ricerca, di quanti file con una certa estensione siano presenti in rete.
È possibile, ad esempio, ricercare su Google i file che contengono nel proprio nome una determinata sequenza di caratteri o aventi una certa estensione (''filetype''). Sono qui presentati i risultati delle interrogazioni riguardo ai file aventi formato ''docx'', ''doc'' e ''odt'' ed il cui nome contiene uno dei caratteri, fra i più frequenti, "1" o "a" o "e". L'investigazione è stata effettuata inserendo nella barra di ricerca di Google le stringhe ''1 filetype:docx'', ''a filetype:docx'' e così via.

{| class="wikitable"
|-
! Formato cercato !! Documenti con "1" nel nome !! Documenti con "a" nel nome !! Documenti con "e" nel nome
|-
| docx || 16.900.000 || 12.800.000 || 8.730.000
|-
| odt || 736.000 || 667.000 || 507.000
|-
| doc || 32.300.000 || 26.300.000 || 21.500.000
|}

Effettivamente il formato più diffuso è il ''doc''; tuttavia esso è supportato per retro-compatibilità anche dagli editor che supportano formati ''OOXML'', con i quali non si ha difficoltà nel convertire i documenti dal formato ''doc'' al ''docx''. In conclusione, quale che sia l'editor più diffuso, è ragionevole adottare il formato ''OOXML Document'' per le finalità del servizio, in quanto molto diffuso, ben supportato dagli editor e avente ottime capacità espressive. Di conseguenza i documenti che saranno elaborati dovranno essere forniti dall'utente in tale formato. In successive sezioni verrà approfondita la struttura dei documenti ''OOXML''.

===Privacy by design===

L'Art. 25 del ''GDPR'', con i Considerando 75 e 78, ha per titolo e per oggetto la "protezione dei dati fin dalla progettazione e protezione per impostazione predefinita" ([0035]), perfettamente in linea con i concetti di "minimizzazione", già richiamati.<div></div>
Il senso dell'Art. 25 viene spesso sintetizzato con l'espressione "''PbD - privacy by design, privacy by default''" ([0035]). Il principio fissato nell'Art. 25 dovrà sempre più essere tenuto ben presente nell'ambito dell'ingegneria del software, in quanto impone di adottare nuove cautele nella realizzazione delle applicazioni software.<div></div>
Del principio ''PbD'' si è ben tenuto conto nella progettazione descritta in questa tesi. In particolare, relativamente alla ''privacy by design'', si è fatto in modo che nessun dato personale permanga registrato sul sistema di esecuzione, o altrove, al termine dell'applicazione. Anche laddove l'applicazione termini in modo anomale non vi sono strutture dati superstiti, che restano memorizzate sul sistema.<div></div>
Marginale in questa tesi è la nozione di ''privacy by default'', giacché l'applicazione non offre all'utente alcuna opzione che possa indurlo in errore ed acconsentire a trattamenti dei dati personali, oltre quello realizzato dall'applicazione.<div></div>
È utile osservare quanto sia importante esprimere queste impostazioni di progettazione fra le condizioni d'uso presentate all'utente: esse costituiscono uno dei presupposti affinché l'utente abbia piena fiducia (''trust'') nel servizio, lo utilizzi, lo divulghi, lo renda un servizio di successo.

==Architettura del servizio==

===I componenti software nell'architettura LAMP===

Il servizio è realizzato in forma di ''web-based application'' poiché, come già illustrato nell'introduzione, si intende renderlo disponibile per il massimo numero di utenti possibili. Nella progettazione e realizzazione dell'architettura web si adotta la piattaforma ''LAMP'', il cui nome deriva dall'acronimo dei componenti open source che la realizzano (il sistema operativo Linux, il server HTTP Apache, il sistema per la gestione di database relazionali MySQL ed il linguaggio di programmazione PHP). Poichè il modello è composto da quattro livelli, spesso si parla anche di ''stack LAMP''. Uno degli elementi di forza del modello ''LAMP'' è che i componenti dei vari ''layer'' sono sostituibili, a seconda delle esigenze, con dei componenti più adatti, tipicamente open source ([0015], [0018], [0019]). Basando la piattaforma su un sistema operativo della famiglia di Microsoft Windows, ad esempio, si ottiene uno ''stack WAMP'', mentre se si usa un sistema operativo Mac OS si realizza uno ''stack MAMP''. Un'architettura web basata sul modello ''LAMP'' può, inoltre, essere integrata con software open source che offre utili funzionalità, come, ad esempio, il monitoraggio (''Nagios''), il load balancing (''Linux Virtual Server''), la rilevazione di accessi illeciti (''Snort'') e il security testing (''netsniff-ng''). <div></div>
Si valutano ora brevemente la diffusione dei componenti tradizionali dello ''stack LAMP'' e le alternative maggiormente usate per i vari ''layer''.
Le distribuzioni Linux risultano essere la scelta più comune per l'ultimo ''layer'' dello ''stack''. Secondo W3Techs, infatti, nell'ottobre del 2013, il 58.5% dei web server a livello globale avevano come sistema operativo la distribuzione Debian o Ubuntu, mentre il 37.3% una tra RHEL, Fedora e CentOS([0016]). <div></div>
Tra i web server, Apache risulta essere maggiormente usato. Secondo le stime fatte da Netcraft, a giugno del 2014 circa il 51.9% del milione di siti web più trafficati al mondo usavano un web server Apache, il 19.2% nginx ed il 12.4% Microsoft ([0017]). <div></div>
I principali ''DBMS'' relazionali, oltre a MySQL, che possono essere presenti nello ''stack LAMP'' sono MariaDB e PostgreSQL, mentre tra i ''DBMS NoSQL'' MongoDB risulta essere il più comune. <div></div>
Nello stack, infine, il ruolo di linguaggio di programmazione, solitamente svolto dal linguaggio PHP, spesso è ricoperto dai linguaggi Perl o Python. <div></div>
Si osserva, ad ogni modo, che le informazioni sulla diffusione delle tecnologie non rappresentano un fattore vincolante nella scelta delle stesse, in quanto la piattaforma ''LAMP'' è anche aperta verso molti altri componenti oltre quelli citati; di conseguenza la scelta delle tecnologie da impiegare può essere effettuata basandosi principalmente sui requisiti e sulle specifiche del servizio. <div></div>

===Principi di progettazione per l'architettura===

====Single Responsibility Principle====

Per rendere il servizio maggiormente manutenibile ed estensibile, si presta particolare attenzione al rispetto del ''Single Responsibility Principle'' (''SRP'') ([0020]). Si cerca, quindi, di fattorizzare il software in più moduli, suddividendo tra questi le elaborazioni da svolgere. Un altro importante beneficio che si ottiene dalla fattorizzazione del codice è la riusabilità dei componenti. Ogni singolo modulo, infatti, svolge il proprio compito in maniera indipendente dal resto della applicazione ed è, quindi, riutilizzabile in altri scenari simili senza dover essere re-implementato. Inquadrando meglio questa metodologia di progettazione con i requisiti del servizio e la piattaforma web ''LAMP'', si individuano i due principali compiti a carico dell'applicazione:
* La gestione dell'interazione web con l'utente per la trasmissione del documento e dei nominativi da trattare
* Il processamento del documento per effettuare la "minimizzazione" dei dati.
Questi due differenti ''task'' saranno, quindi, portate a termine da componenti diversi.<div></div>
Progettando la struttura dell'applicazione in questo modo, si disaccoppia completamente la logica di business del servizio dalle interfacce web di comunicazione con l'utente. In un futuro sviluppo sarà possibile, quindi, realizzare nuove interfacce utilizzando altre tecnologie senza dover modificare la logica applicativa.

====Dependency Inversion Principle====

Un altro principio di design architetturale che risulta importante nella progettazione è il ''Dependency Inversion Principle'' (''DIP'') ([0038]). Esso si traduce nella realizzazione di componenti che non dipendono dalle specifiche implementazioni degli altri moduli del sistema, bensì dalle loro ''astrazioni''.
In relazione all'estensibilità e manutenibilità del prodotto software, infatti, l'impiego di moduli dipendenti direttamente dalla definizione dei metodi presenti in altri componenti risulta problematica: il modulo dipendente deve essere re-implementato ad ogni variazione del modulo da cui dipende.
Nella programmazione orientata agli oggetti, per rispettare questo principio, si su può fare uso di classi astratte o interfacce, costrutti che definiscono i moduli senza implementarli completamente o senza implementarli affatto.

===Stile architetturale REST===

Il modello architetturale del servizio che si sta definendo presenta una serie di caratteristiche, come ad esempio l'indipendenza dei moduli, che permettono di realizzarlo secondo il paradigma delle ''RESTful API''. L'espressione "Representational State Transfer" e il suo acronimo "REST" furono introdotti nel 2000 nella tesi di dottorato di Roy Fielding ([0021]), uno dei principali autori delle specifiche dell'Hypertext Transfer Protocol (HTTP). Roy Fielding descrive il ''Representational State Transfer'' come uno stile architetturale ("''architectural style''"), ovvero un'astrazione degli elementi di un'architettura all'interno di un sistema hypermedia distribuito. ''REST'' non specifica i dettagli dell'implementazione dei componenti e della sintassi del protocollo, ma definisce i ruoli dei componenti, i vincoli sulla loro modalità di interazione e la loro interpretazione.
Riassumiamo quindi i principi che deve rispettare una architettura ''REST'':
# Architettura Client-Server <br/>In una architettura ''REST'' viene data particolare importanza ai principi ''SRP'' e ''DIP'' prima citati, più generale si può affermare che l'architettura sposi il paradigma noto con il termine di "''Separation of Concerns''". Una ''Restful API'' applica questi principi in un architettura Client-Server, capace di supportare l'evoluzione indipendente della logica lato client e della logica lato server.
# Stateless <br/>La comunicazione tra utente e fornitore del servizio deve essere senza stato, quindi ogni richiesta del client deve contenere tutte le informazioni di cui il fornitore necessita per l'erogazione del servizio offerto. Questa ipotesi viene fatta per rendere una ''Restful API'' facilmente scalabile orizzontalmente.
# Uso della cache <br/>In un Architettura ''REST'' i messaggi di risposta inviati dal server devono esplicitamente indicare se possono essere memorizzati nella cache del client o di componenti middleware per il riutilizzo nelle richieste successive.
# Interfaccia uniforme <br/>I componenti devono essere in grado di comunicare attraverso un'interfaccia uniforme e le risorse devono essere trasferite in un formato standard. Inoltre l'utente deve poter effettuare la navigazione tra le risorse di suo interesse tramite collegamenti ipertestuali. Per inciso, si osserva che il protocollo HTTP usato correttamente rispetta i requisiti di un architettura ''REST'' e che nelle implementazioni delle ''RESTful API'' il formato più usato per la modellazione dei dati è JSON.
# Layered System <br/>In un sistema a livelli, componenti intermedi (come i proxy) possono essere collocati tra client e server per intercettare il traffico per scopi specifici; ad esempio il caching o la sicurezza. Una soluzione basata su ''REST'' può essere composta da più livelli architettonici, indipendenti l'uno dall'altro.
# Code on Demand <br/>Questo vincolo facoltativo è inteso principalmente a consentire aggiornamenti alla logica all'interno dei client (come i browser Web) indipendentemente dalla logica lato server. Una ''single page application'', ad esempio, rispetta in pieno questo punto.

Un'applicazione progettata sul modello dell'architettura ''REST'' ha quindi gli indiscutibili vantaggi di:
* consentire l'evoluzione indipendente delle diverse componenti
* avere un'interfaccia utente portabile con altri tipi di piattaforme
* permettere agevolmente la replicazione delle macchine server
* non vincolare moduli server e client a linguaggi e tecnologie specifiche.

L'architettura del servizio oggetto di questa tesi si trova già perfettamente in linea con alcuni dei vincoli discussi, ma sono necessarie alcune considerazioni. Il punto 1 ("architettura Client-Server") è chiaramente soddisfatto.
Il punto 2 ("Stateless"), direttamente collegato con i punti 3 e 5 ("Uso della cache", "Layered System"), può essere rispettato con facilità; a ogni richiesta di "minimizzazione" del client corrisponde la restituzione del documento trattato dal server, non c'è quindi necessita di avere uno stato nell'interazione.

Analizzando le caratteristiche di una applicazione stateless in relazione al principio ''privacy by design'' illustrato in precedenza, si osserva che l'assenza di stato determina la semplificazione delle problematiche critiche relative al principio. Non vengono conservate, infatti, informazioni contenenti dati sensibili, poiché dopo aver effettuato l'invio della risposta, sarà subito eliminato sul server il file elaborato.

Nei capitoli precedenti tuttavia si è detto che l'utente può ripetere più volte il trattamento di uno stesso documento nella stessa sessione di interazione; essendo il vincolo dell'efficienza già difficile da rispettare per via dell'elaborazione onerosa del documento, si può progettare una modalità alternativa del funzionamento con stato del servizio, applicabile in assenza di replicazione delle macchine server e sfruttando le ripetute richieste di trattamento per uno stesso documento.
Si può infatti memorizzare lato server il documento inviato dal client inizialmente e, alle successive richieste di trattamento del medesimo documento, evitarne la ritrasmissione da client a server. Per rispettare il ''PbD'', al termine della sessione di interazione il documento verrà rimosso dal server. Si nota, inoltre, che per predisporre il servizio alla gestione delle due diverse modalità di funzionamento si può utilizzare un parametro di configurazione a livello applicativo.
I punti 4 e 6 infine ("Interfaccia uniforme", "Code on Demand") si possono rispettare utilizzando il formato JSON per la trasmissione dei documenti e dei nominativi, e usando localmente sul client Javascript per offrire tutte le funzionalità del servizio in un'unica pagina html.

===Moduli software del servizio===

====Scelta dei componenti software====

Si opera ora la scelta delle tecnologie da utilizzare per i componenti dei 4 layer dello ''stack LAMP''. Per i due layer inferiori risulta piuttosto immediato decidere di usare le tecnologie presenti per default. Un sistema operativo Linux ed un web server Apache sono adatti all'architettura del servizio.
Inoltre anche il linguaggio di programmazione PHP può essere usato senza significativi problemi, anche se verranno fatte in seguito, in una sezione di questo capitolo, alcune considerazioni sulle problematiche di esecuzioni concorrenti di script PHP. Il linguaggio sarà impiegato in particolare per la realizzazione della logica necessaria a gestire l'interazione web con il cliente, mentre l'elaborazione del documento OOXML lato server sarà effettuata da un programma Java.

I due ''task'' principali del servizio sono delegati, quindi, a due programmi distinti realizzati con tecnologie diverse. Si concretizza in questo modo il principio ''SRP'' e, sfruttando l'<i>openness</i> della piattaforma LAMP, le funzionalità necessarie vengono realizzate attraverso i linguaggi più adatti.
La scelta del linguaggio Java per l'implementazione del ''main core'' della logica di business è dovuta alla libreria open source in ambiente java Docx4j ([40],[41]). Questa libreria è realizzata per il processamento delle tre tipologie di formati OOXML (''docx'', ''xslx'', ''pptx'') e permette tutte le possibili operazioni di creazione, lettura e modifica su questo tipo di documenti. Anche questa libreria sarà approfondita in sezioni successive. Si osserva, per inciso, che esistono altre librerie equivalenti in ambiente .NET.

Nella scelta del linguaggio di programmazione usato per elaborare i documenti ed effettuare i confronti tramite ''regular expressions'', un dato non di poco conto da considerare è l'encoding delle stringhe. In Java, in particolare, una stringa è rappresentata internamente come un array di char, ognuno codificato da 2 byte in formato UTF-16 ([0042]); la codifica esprime in 16 bit tutti i caratteri definiti dallo standard Unicode, quindi è possibile scegliere Java.

Per il ''layer'' della persistenza, infine, l'impiego di un database MySql risulta una buona scelta. Si osserva che questo livello non verrà utilizzato nella tradizionale maniera prevista dallo ''stack LAMP''. Infatti, generalmente, la base di dati viene interrogata direttamente dal componente che si occupa dell'interazione con l'utente (PHP) per il reperimento delle informazioni utili da restituire al client; nel servizio, invece, la base di dati sarà a supporto unicamente del programma Java, poiché gli unici dati persistenti da gestire sono i nomi del dizionario (si ricordi sempre il ''PbD'') e solo i moduli dell'eseguibile Java devono utilizzarli. Se il dizionario contenessero unicamente i nomi (senza informazioni accessorie correlate) e fossero usati in sola lettura, un semplice file di testo poteva essere sufficiente per la rappresentazione. Tuttavia, poiché saranno individuate tecniche di ottimizzazione nell'impiego dei dizionari che richiedono operazioni di scrittura e ordinamento dei dati, risulta opportuno usare un database relazionale.

====Logica di business e dinamiche di interazione====

Vengono presentati in questa sezione gli aspetti principali dei funzionamenti dei moduli del servizio. Per mettere bene a fuoco quali siano le meccaniche di interazione e i flussi di esecuzione dei programmi, si propone il diagramma di sequenza del tipico scenario di utilizzo. In questo schema UML si descrive il caso d'uso dove un utente, dopo aver inserito un documento ed averlo ricevuto "minimizzato", esprime delle preferenze e richiede poi un secondo trattamento.<div></div>
<div></div>(QUI IMG [0F00])<div></div>
Si descrivono quindi ora le principali operazioni che vengono eseguite.
All'avvio dell'interazione viene presentata una pagina PHP di benvenuto contenente le informazioni su come i dati personali vengano elaborati ed un ''file-picker'' per consentire l'upload di un documento ''OOXML''; nel momento in cui l'utente confermerà il caricamento del documento, esso verrà trasferito sul server.
Bisogna prestare particolare attenzione al comportamento del sistema nel caso in cui più utenti richiedano contemporaneamente l'esecuzione del servizio, e cioè alle problematiche di esecuzioni concorrenti di script PHP; è necessario, in particolare, evitare situazioni in cui i nomi dei file inviati dagli utenti siano in conflitto. Analizzando più in dettaglio il problema, ogniqualvolta un web server Apache riceve una richiesta HTTP per una pagina PHP, si ha la generazione di un nuovo processo che esegue il codice presentato nella pagina PHP richiesta. Supponendo quindi che N utenti eseguano l'invio del file contemporaneamente, si avrebbe che sul server N processi diversi dovrebbero procedere con la scrittura di un file. Ovviamente se due o più file condividono il nome almeno uno di essi sarà sovrascritto. Per risolvere questo problema, supponendo di voler salvare tutti i documenti in una cartella temporanea, occorre modificare il filename dei documenti inviati dagli utenti per esser certi di non incorrere in sovrascritture o altri tipi di errori correlati.
Una valida possibilità è l'inserimento di un ''prefisso'' univoco nel filename. Per la generazione di una stringa univoca da anteporre al filename, che permetta di distinguere file caricati da utenti diversi, si può direttamente usare il ''session id'' dell'utente. In PHP esso è determinato casualmente combinando ([0043]): l'IP del cliente, orario di attribuzione dell'id, un numero pseudo-casuale (con il ''PHP Linear Congruence Generator'') e, se presente un "''random source''" sul sistema operativo del Client (spesso chiamato impropriamente "''seme''"), un ulteriore numero pseudo-casuale.
Per introdurre ulteriore alea, necessaria se, ad esempio, un utente tenti l'upload di file omonimi (con contenuto interno diverso) e mantenga il medesimo ''session id'', si utilizza un ulteriore generatore pseudo-casuale per produrre un altro numero con cui comporre il prefisso.
Concatenando i due numeri generati si ha praticamente certezza di aver individuato un numero univoco nel sistema per il tempo in cui il servizio sarà erogato al cliente.

Una volta memorizzato il file, lo script PHP dovrà ricorrere all'invocazione del modulo Java, delegato al vero e proprio processamento del documento. Occorre quindi individuare un set di opzioni che consenta al modulo che gestisce l'interazione con il cliente di sfruttare al meglio il componente delegato all'elaborazione del documento, in qualunque circostanza; la totale indipendenza dei moduli, la loro sostituibilità e la replicazione possibile di macchine server sono solo alcuni dei fattori che rendono mutevole la configurazione del sistema. Va definito un protocollo di comunicazione, quindi, che astragga completamente dall'implementazione dei moduli o dalla locazione dei file.

Valutando i possibili flussi logici, anche con l'ausilio del diagramma di sequenza, si ha che i tipi di esecuzione sono due:
* "minimizzazione" con dizionario
* "minimizzazione" di specifici nominativi
Il protocollo di comunicazione tra i due moduli è costituito in entrambi i casi di una singola richiesta a cui segue una singola risposta. Più in particolare, lo script PHP invoca il comando Java esprimendo obbligatoriamente il path del file da trattare e opzionalmente l'elenco dei nominativi. A suo volta, il modulo Java restituisce i nominativi trovati, qualora non espressamente richiesti dallo script, e segnala la corretta terminazione dell'elaborazione.
Si definiscono come canali di comunicazione standard del protocollo gli argomenti presi in input dal modulo di processamento del documento e lo standard output del processo che esegue tale programma. Inoltre è importante definire un formato standard per la comunicazione dei nominativi tra moduli; è necessario quindi scegliere un pattern che permetta di determinare univocamente la composizione dei nominativi. Un possibile formato, espresso tramite ''regex'', è il seguente:
<div></div>
<span style="font-family: monospace;"> <nominativo> = ^(<nome>:)*<nome>;<cognome>$</span>
<div></div>
<span style="font-family: monospace;"> <nominativi> = ^(<nominativo>\s+)+$</span>
<div></div>
Dove nome e cognome sono una sequenza di caratteri Unicode come già discusso. Ulteriori opzioni importanti da definire nel protocollo per l'invocazione del programma che si occupa delle funzionalità di elaborazione sono le seguenti:
* path file da elaborare (opzione "-i <file_path>", obbligatoria)
* path con cui salvare il file elaborato (opzione "-o <file_path>", opzionale: per default viene creato un nuovo file automaticamente)
* abilitazione stampe verbose, da usare solo in fase di debug (opzione "-d", opzionale)
<div></div>
Una volta terminato il processamento, il modulo di gestione dell'interazione con l'utente dovrà accertarsi che l'<i>exit status</i> sia 0 e leggere dallo standard output del processo appena terminato, qualora si sia stata eseguita la "minimizzazione" con dizionario, l'elenco dei nominativi trovati. Se invece la "minimimizzazione" ha avuto luogo con i nominativi già specificati non sarà scritto nulla sullo standard output.
A margine si osserva che l'impiego dell'opzione "-d" deve sempre consentire una semplice individuazione dei nominativi trovati; in particolare, se tale opzione è specificata, nello standard output i nominativi compariranno con un ''header'' riconoscibile ("''NOMINATIVO=''").
Ritornando alla descrizione del flusso di esecuzione tipo, una volta che il modulo Java ha completato il trattamento del documento, lo script PHP ne effettuerà l'upload sul client e presenterà all'utente le opzioni già descritte nel capitolo sull'usabilità.
A questo punto l'interazione con client potrebbe concludersi, qualora si eseguisse il download e si chiudesse il browser, o continuare elaborando i ''suggerimenti'' dell'utente espressi dopo il primo trattamento. Le modalità di comunicazione dei moduli varierebbero leggermente come appena illustrato, mentre, a seconda della configurazione stateful o stateless del servizio, verrebbe eseguito o meno un nuovo upload del file dal client al server.<div></div>

Si osserva infine che, per predisporre a successivi studi di ottimizzazione il servizio e per agevolare tutti i possibili sviluppi futuri, si applica largamente nella progettazione del modulo di elaborazione Java il ''Dependency Inversion Principle'', in quanto si desidera realizzare classi estendibili ed intercambiabili.
In particolare, si introducono delle classi astratte per rappresentare in maniera generica il concetto di "''persona''" e "''minimizzatore''". È possibile infatti realizzare successivi studi per trattare ulteriori dati personali oltre che ai nomi e cognomi; inoltre, in base ai tipi di documenti trattati o eventuali altri fattori utili, è possibile studiare differenti tecniche di "minimizzazione" realizzate da differenti algoritmi "''minimizzatori''".
In particolare una "''persona''" dovrà sempre esporre un metodo "''minimizza''" che prende in input una stringa, la "minimizza" e la restituisce; il pattern con il quale si effettua la "minimizzazione" sarà fornito in implementazione a seconda dei dati sensibili di interesse.
Un "''minimizzatore''" esporrà sempre un metodo "''work''" che, presa in input una lista di persone ed un documento ''OXML'', con l'ausilio della libreria Docx4j, fornirà in output un documento del tutto "minimizzato"; la definizione delle modalità con cui si estrapolano le informazioni dal documento e con cui si invoca il metodo "''minimizza''" della classe persona sono confinate nell'implementazione.
Definendo delle classi astratte risulta, quindi, più veloce la realizzazione dei futuri componenti e si svincola il processo di "minimizzazione" dal tipo di dati che si "minimizzano" e viceversa.

====Le classi principali del progetto====
Le classi principali del progetto vengono quindi presentate in appendice. Esse sono:
* App.java, contenente il main
* Elaborator.java, che presenta il metodo "''work''"
* Persona.java, che presenta il metodo "''minimizza''"
* Testing.java, contenente alcune funzioni usate in fase di debug.

Gli script in PHP sono stati forniti dall'azienda come implementazione minimale e provvisoria, da perfezionare a seguito della eventuale definizione sulle modalità di presentazione del servizio su Internet.

Una considerazione di implementazione comune a tutte le classi deriva del principio ''Privacy by Design'', indifferentemente dalla modalità di configurazione stateful o stateless del servizio: è di fondamentale importanza che nel sistema non siano memorizzati permanentemente in alcun caso i documenti inviati dagli utenti del servizio.
Per realizzare un sistema robusto, per fronteggiare crash improvvisi del client o congestioni della rete, è opportuno impostare dei timeout lato server che procedano automaticamente alla eliminazione dei documenti degli utenti dopo un periodo di inattività troppo prolungato. Qualora invece si dovesse verificare un interruzione critica del servizio a causa di un errore logico del server o semplicemente per via di un'interruzione dell'alimentazione della macchina server, bisogna considerare altri metodi; essendo il servizio realizzato con un sistema operativo Linux, si può configurare il demone ''crond'' per eseguire a ogni reboot e, per sicurezza, una volta al giorno l'eliminazione dei file usati dall'applicazione tutti contenuti all'interno della cartella temporanea.

==Approfondimenti tecnologici==

===Analisi della struttura del formato OOXML===

Come argomentato, il formato dei documenti elaborati dal servizio progettato dovrà essere ''Office Open XML'', o ''OOXML''; si tratta di un formato ''XML-based'' per documenti di testo, fogli elettronici e presentazioni, in grado di rappresentare grafici, diagrammi, immagini e altro materiale grafico. La specifica fu sviluppata da Microsoft e adottata dall'<i>ECMA International</i> come standard ''ECMA-376'' nel 2006. Una seconda versione fu rilasciata nel 2008, una terza nel 2011, una quarta nel 2012 ed una quinta tra il 2015 ed il 2016 ([0010]). La specifica è stata adottata, inoltre dall'<i>ISO</i> e dall'<i>IEC</i> come standard ''ISO/IEC 29500'' a partire dal 2008 ([0011], [0012]).

====Linguaggi di markup====

Lo standard ''ECMA-376'' ([0010]) include tre differenti specifiche di linguaggio per ognuna delle tre principali categorie di documenti:
* ''WordprocessingML'' per i documenti testuali
* ''SpreadsheetML'' per i fogli elettronici
* ''PresentationML'' per le presentazioni elettroniche
* ''DrawingML'' ed altri linguaggi di markup di supporto per la rappresentazione di disegni, forme e diagrammi.
<div></div>
La specifica include sia gli schemi ''XML'' sia i vincoli espressi per iscritto. Ogni documento conforme al formato dovrà, quindi, rispettare gli schemi ''XML'' e dovrà essere codificato in ''UTF-8'' o ''UTF-16''. La specifica, inoltre, permette l'aggiunta di ''custom tag XML'' a supporto dei linguaggi di markup dati, per default nel formato ''OOXML'', consentendo quindi la libera personalizzazione dei documenti.

====File packaging====

Oltre alla specifiche relative ai linguaggi di markup, la seconda parte dell'<i>ECMA-376</i> ([0010]) definisce la struttura gerarchica dei file del formato adottando le ''Open Packaging Conventions'' (''OPC''). ''OPC'', una tecnologia ''file-container'' basata sul comune formato compresso ''zip'', che stabilisce che tutti i file che riguardano una stessa entità devono essere raggruppati in un unico package ([0014]). Un documento ''OOXML'' è, infatti, un archivio ''zip'' contenente alcuni files ''XML'' (detti anche ''parti'') organizzati in un singolo package. Questa frammentazione dei dati in più files rende più semplice e veloce l'accesso ai dati stessi e riduce le possibilità di una loro corruzione. Le ''parti'' possono contenere qualsiasi tipo di dato; per tenere traccia della relazione tra una ''parte'' e la sua tipologia di contenuto, senza basarsi sull'estensione del file, è presente nel package, nella cartella radice della gerarchia, il file denominato ''[Content_Types].xml'', il quale mappa appunto queste associazioni. È mostrata qui ad esempio l'associazione tra la ''parte'' rappresentante il documento principale e il suo ''ContentType''.
<div style="font-family: monospace;">
<Override PartName="/word/document.xml" ContentType="application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml"/>
</div>
Le informazioni relative alle relazioni che ogni ''parte'' ha con le altre ''parti'', con risorse esterne e con il package in sé sono mantenute separatamente dal contenuto della ''parte'' stessa. Tali informazioni sono presenti, infatti, all'interno delle cartelle denominate ''_rels'': ne esiste una per il package nel suo complesso e una per ogni sotto-cartella del package contenente delle ''parti'' coinvolte in delle relazioni. In questo modo i riferimenti che una ''parte'' ha verso altre ''parti'' o risorse sono salvati una sola volta e possono essere aggiornati con semplicità se necessario, senza dover modificare il contenuto stesso delle ''parti'' coinvolte. È mostrato qui un esempio di relazione contenuta in ''_rels/.rels'' relativa al documento principale e al suo schema.
<div style="font-family: monospace;">
<Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument" Target="word/document.xml"/>
</div>
Il documento principale, ossia il file ''word/document.xml'', ha inoltre numerose relazioni con altre ''parti'', come ad esempio ''word/styles.xml'' e ''word/footer.xml'', e risorse esterne collegate con degli URI. Per descrivere queste relazioni si usa la cartella ''word/_rels''.

====Parti di un Documento OOXML====

Vengono qui presentate le ''parti'' che sono caratteristiche esclusive di un ''WordprocessingML package'', non presenti quindi negli altri due formati ''OOXML''. È importante osservare che alcune di esse sono facoltative e sono presenti nel package solo se necessario.

Le ''parti'' relative al vero e proprio contenuto testuale sono:
* ''Main Document'', contiene le informazioni principali ed è salvata come ''word/document.xml''
* ''Header'', contiene i dati relativi alle intestazioni ed è salvata in ''word/header.xml''. Ogni sezione del documento può avere intestazioni diverse per la prima pagina, per le pagine pari e per le dispari, quindi possono esserci molteplici ''parti header''
* ''Footer'', contiene le informazione relative al piè pagina ed è salvata in ''word/footer.xml''. Può essere presente più volte, per motivi analoghi alla ''parte header''
* ''Footnotes'', contiene le eventuali note a piè pagina del documento ed è salvata come ''word/footnotes.xml''
* ''Endnotes'', contiene le note di chiusura del documento ed è salvata in ''word/endnotes.xml''.

Sono presenti poi delle ''parti'' relative allo stile e alle impostazioni del documento:
* ''Style Definitions'', contiene la definizione di un insieme di stili usati dal documento, salvata in ''word/styles.xml''
* ''Font Table'', contiene informazioni riguardo i font usati, salvata in ''word/fontTable.xml''
* ''Numbering Definitions'', contiene le definizioni sulla struttura delle liste contenute nel documento, salvata in ''word/numbering.xml''
* ''Document Settings'', specifica come il word processor debba trattare il documento (spell checking, gestione delle revisioni, etc.), contenuta in ''word/settings.xml''
* ''Web Settings'', contiene informazioni su come il documento debba essere convertito in ''HTML'' se richiesto, contenuta in ''word/webSettings.xml''.

Sono presenti anche delle ''parti'' che rappresentano testo secondario:
* ''Comments'', contiene i commenti sul documento inseriti attraverso un word processor
* ''Glossary'', contiene dati testuali aggiuntivi secondari, ne è permessa una sola. Tutte le ''parti'' prima elencate, tranne il ''Main Document'', possono comparire una seconda volta in relazione alla ''parte glossary''.

====Analisi del Main Document====

Il file ''document.xml'', elemento principale di un documento ''WordprocessingML'', è costituito da due tipi di informazioni:
* ''properties'', che definiscono lo stile e la formattazione del testo
* ''stories'', che rappresentano il contenuto testuale delle varie parti del documento.

Le ''properties'' verranno trattate in misura minore. Queste informazioni sono espresse attraverso una struttura XML gerarchica che ha come elemento radice il nodo ''document''. Esso ha due nodi figli:
* ''background'', che contiene alcune ''properties'' che descrivono lo sfondo del documento
* ''body'', che contiene tutti i rimanenti contenuti ed è potenzialmente molto complesso.

Si osserva che per le finalità del trattamento dei dati risultano di primario interesse le ''stories'' e che è opportuno effettuare un'analisi ''bottom-up'' del problema: anziché considerare la gerarchia a partire dal ''body'' (nodo padre) partiremo dalla rappresentazione più semplice del testo contenuta nel documento (nodi figli).

Facendo direttamente riferimento allo standard ''ECMA-376'' ([0010]), si evince che l'unico nodo che contiene puro testo ha il nome ''t'' (''Text''). Questo elemento contiene una stringa rappresentante gli esatti caratteri che vengono poi mostrati negli editor a video. Il nodo ''Text'' non presenta figli e l'unico nodo padre che può avere è ''r'' (''Run''). Quest'altro nodo definisce una regione di testo con comuni proprietà (ad esempio l'uso del grassetto). Attraverso l'uso di tag ''t'' ed ''r'' quindi si rappresenta una regione di testo formattata con differenti elementi stilistici.
Occorre però evidenziare che un nodo ''r'' può presentare molti altri figli oltre a ''t'', come ad esempio immagini, in quanto rappresenta un'area generica del documento.
Si supponga quindi di avere due nodi ''Text'' fratelli, ossia figli dello stesso nodo ''r'': essi rappresenteranno semanticamente un unico blocco logico se e solo se compariranno a video come una sequenza di parole continua. Questo fenomeno è facilmente identificabile anche nel file ''XML'' descrittivo: due sequenze di parole mostrate a video adiacenti compaiono infatti nel file ''XML'' in due righe consecutive; se invece due parti di testo dovessero essere intervallate ad es. da un'immagine nel documento ''XML'' ci sarebbe un tag ''drawing'' a dividere i due tag ''t''. Dalla consecutività dei nodi ''Text'' nel file ''document.xml'' si può determinare quali siano i blocchi logici da trattare.
Un insieme di ''Run'' infine può essere figlio di diversi nodi, ma ciò non è di rilevante importanza, in quanto ogni area di testo individuata dal nodo ''Run'' rappresenta già un blocco logico a sé e, di conseguenza, contiene sufficienti informazioni per la "minimizzazione".
L'unico caso di rilievo nel quale bisogna valutare quale sia la gerarchia a monte di un nodo ''Run'' è nell'elaborazione di una tabella. In tal caso, in realtà, occorre verificare opportunamente la strutturazione della gerarchia processata. Per chiarezza espositiva viene mostrata la rappresentazione in formato ''OOXML'' di una tabella con una riga e due colonne (senza l'uso di ''properties'' per la formattazione stilistica).
<br/>
<div style="font-family: monospace;">
<w:tbl>
<w:tr>
<w:tc>
<w:p>
<w:r>
<w:t>Cella A</w:t>
</w:r>
</w:p>
</w:tc>
<w:tc>
<w:p>
<w:r>
<w:t>Cella B</w:t>
</w:r>
</w:p>
</w:tc>
</w:tr>
</w:tbl>
</div>

Come si osserva in figura, in una tabella il nodo ''r'' sarà figlio del nodo ''p'' (''Paragraph''), il quale a sua volta sarà contenuto in un noto ''tc'' (''Table Cell''). Celle di una tabella appartenenti ad una stessa riga saranno presenti all'interno dello stesso ''tr'' (''Table Row'') ed infine tutte le righe della tabella saranno inserite del tag ''tbl'' (''Table'').

Per determinare quindi se due nodi ''Text'' sono scritti in due colonne adiacenti di una stessa riga (e quindi costituiscono un unico blocco logico) è necessario verificare che per i due nodi ''Text'':
# il nodo "padre" '''non sia''' in comune
# il nodo "padre di 2° livello" sia ''Paragraph'' e '''non sia''' in comune
# il nodo "padre di 3° livello" sia ''Table Cell'' e '''non sia''' in comune
# il nodo "padre di 4° livello" sia ''Table Row'' e '''sia''' in comune
# i nodi "padre di 3° livello" '''siano''' consecutivi.
Se tutte queste ipotesi sono soddisfatte, le due celle vanno "minimizzate" come unico blocco logico.

Si valutano infine gli ultimi vincoli emersi nell'analisi sull'interpretazione della formattazione di un documento.
In particolare, descrivendo le parti che compongo un documento ''OOXML'', era già emerso che alcune sezioni di testo, ossia note a piè pagina ed intestazioni, compaiono in altri file ''XML'' e non in ''document.xml''. Questi file (''header.xml'', ''footer.xml'', ''endnotes.xml'', etc.) sono tutti raccolti in un package ("''word''") e la grammatica ''XML'' è la stessa usata per il Main Document.
Si conclude osservando che il problema della divisione in sillabe delle parole non si pone, in quanto la divisione sillabica mostrata a video dai word-processors è calcolata dinamicamente; in particolare, su una porzione di testo viene applicata la sillabazione (ove necessario) se è presente tra le ''properties'' di quella regione di documento il tag ''hyphenationZone''.

====La libreria in ambiente java open source Docx4j====

La libreria Docx4j offre completo supporto alla manipolazione di documenti ''docx'' (compressione e decompressione archivio zip, generazione file ''XML'' necessari, etc.). Offre inoltre un'utile mappatura in specifici oggetti Java della gerarchia ''XML'' presente nei vari file del formato.
Uno tra gli elementi più interessanti è la tecnica con cui vengono recuperati i nodi dai file ''XML'', in quanto si fa impiego del linguaggio standard W3C ''XPath'' ([0044], [0045]). Con ''XPath'' è possibile esprimere con una stringa un sottoinsieme di nodi presenti in una gerarchia ''XML'' non solo in base al loro nome o valore, ma anche in relazione alla posizione reciproca rispetto agli altri nodi. Riferendoci alle problematiche del servizio risulta, ad esempio, significativamente agevolato il trattamento di dati personali in forma tabellare.
Si osserva infine che la libreria attribuisce un id univoco ad ogni nodo del documento, di conseguenza se ne può trarre vantaggio nei confronti tra i nodi.

===Ottimizzazioni del processo di minimizzazione===

===Tecnologie complementari===

La redazione di questa tesi è avvenuta su Mediawiki, la più importante fra le piattaforme wiki essendo il motore di Wikipedia.

Le piattaforme wiki sono riconosciute come elemento caratterizzante dell’evoluzione Internet al Web 2.0, cioè al web nel quale gli utenti-navigatori, fino ad allora "''consumatori"'' ("''consumers"'') di contenuti si sono trasformati essi stessi in "''produttori"'' ("''producers"''), e cioè in "''prosumers"''.

Un ''wiki'' è fondamentalmente un sito web che contiene informazioni e che consente agli utenti di editare facilmente il suo contenuto.

Nel redigere una pagina wiki si utilizza ciò che è chiamato ''wikitext" per definire capitoli, paragrafi, hyperlinks, elementi di formattazione della pagina, etc.; sebbene il ''wikitext" risulti non difficile da apprendere, quasi ogni piattaforma wiki è corredata da editor di tipo visuale, che non richiede alcuna conoscenza della sintassi del ''wikitext"; tuttavia è esperienza comune che utilizzare direttamente il ''wikitext" induce a concentrarsi maggiormente sui contenuti e non sulla formattazione. Il linguaggio ''wikitext'' è strettamente correlato con il linguaggio HTML, infatti nella scrittura è possibile utilizzare tag come h1, span, div e così via, oltre che la sintassi esclusiva di ''wikitext''; simmetricamente una pagina prodotta da media wiki è costituita da HTML ben formato e direttamente importabile in ogni word processor.

I wiki presentano una funzionalità di grande utilità nella redazione di documenti articolati: la tracciatura delle successive revisioni ("''Cronologia"''). La possibilità di ripercorrere l’evoluzione del testo è davvero d’aiuto quando si fissano idee originali in uno scritto, cercando di definirle, precisarle, chiarirle, come è avvenuto in effetti, anche nella redazione di questa tesi. Per curiosità, si segnala che, pur avendo redatto la maggior parte del testo off-line, la pagina wiki di questa tesi conta oltre 50 revisioni.

Per inciso, si osserva che è stata molto utile la funzionalità di "ricerca nel codice" offerta dalla piattaforma di revisione online GitHub nella corretta comprensione della libreria Docx4j, il cui codice sorgente è ivi rilasciato.

Si conclude infine dicendo che per ottimizzare le procedure di debug del codice sono stati realizzati utili tool a riga di comando per Linux per la rapida estrazione-modifica-ricompattazione di documenti ''OOXML''. Si propone in appendice un comando bash per questi scopi.

==Sviluppi futuri==

In questa sezione si fa cenno, senza poterle approfondire, ad alcune interessanti questioni emerse nello svolgimento della tesi.

===Accesso al servizio web===

In fase iniziale, il servizio web potrà essere reso accessibile in forma completamente aperta, senza richiedere cioè la registrazione dell’utente o l’autenticazione dell’utente già registrato. In questo modo, in effetti, si premia la facilità d’uso, ma si incorre nella nota problematica di un uso malevolo, costituito da accessi a raffica, finalizzati a saturare il server e generare una condizione di ''DoS – Denial of Service''. Diverse sono le tecniche che possono essere adottate per contrastare questo tipo di accessi malevoli, come richiedere di superare "''captcha''" e/o introdurre ritardi crescenti ed eventualmente blocchi in risposta ad accessi prevenienti con alta frequenza dallo stesso indirizzo IP.
È possibile anche pensare ad un accesso previa registrazione ed autenticazione dell’utente, penalizzando l’immediatezza di utilizzo del servizio, ma eventualmente ottenendo l’indirizzo email degli utenti che acconsentono a lasciarlo per successive finalità marketing.
È possibile, infine, un utilizzo misto, contando in un cookie il numero di accessi eseguiti e richiedendo all’utente di registrarsi per continuare ad utilizzare il servizio, dopo qualche accesso.

===Ampliamento dinamico del dizionario===

Nel restituire il documento elaborato all'utente, gli si da la possibilità di richiedere una nuova elaborazione, dopo aver indicato i nominativi che fossero sfuggiti; pare inesauribile, infatti, la "fantasia" dei genitori nel dare nome ai propri figlioli!
I nominativi indicati dall'utente sono sfuggiti al servizio perché non presenti nel dizionario: facilmente viene in mente l’idea di arricchire il dizionario con i nominativi indicati dall’utente. Va però considerato il caso che l’utente in malafede indichi nominativi fasulli al fine di inquinare il dizionario.
Il caso malevolo può essere affrontato attraverso una strategia che preveda non direttamente l'inserimento del nuovo nominativo nel dizionario, ma invece l'utilizzo di un concetto di "candidatura": il nuovo nominativo viene registrato, ma si attende di avere un certo numero di utenti che lo propongono prima di approvarne l'inserimento nel dizionario.
Può anche essere utilizzato un concetto di "attendibilità" della candidatura di un nuovo nominativo, verificando ad esempio l'utente che lo propone scarichi effettivamente il file rielaborato.
Nel caso l'accesso avvenga con autenticazione, e cioè identificando gli utenti, si apre la possibilità di individuare e bannare gli utenti malevoli.

===Natura del documento e ricorrenza del nominativo===

Si coglie facilmente la differenza di formato fra un documento in forma di elenco (es. una graduatoria) da un documento in forma di relazione (es. una sentenza giudiziaria). Differenze di questo tipo potrebbero essere utilizzate per escludere o ammettere la ripetizione dei nominativi.
Per meglio dire: in un elenco la ripetizione di un nominativo è di fatto da escludersi o va trattata come omonimia. In una relazione, l’individuazione di un nominativo può essere utilizzata per ricercarlo direttamente in altri punti del documento stesso.

===Altri dati personali===

Altri dati personali sono trattabili con le stesse tecniche analizzate in questa tesi: date e luoghi di nascita, codici fiscali, indirizzi, email, numeri di telefono, sesso etc. In qualche caso, come per i codici fiscali, l’individuazione del pattern da trattare è persino più semplice.
Diversi studi ([0039]) hanno dimostrato che, utilizzando set di dati personali parziali, è possibile la re-identificazione dei soggetti, pur in documenti pseudonimizzati. È questo un altro motivo per estendere i trattamenti descritti anche agli altri dati personali richiamati.

===Altri alfabeti===

È possibile estendere il sotto-insieme di caratteri Unicode utilizzati nelle ''regex'' per elaborare documenti scritti in altri alfabeti non latini.

==Conclusioni==

Questa tesi è partita da un problema basilare, quasi scolastico, dell'informatica: la ricerca di un testo in un documento, al fine della sua cancellazione o modifica.

Il problema si è subito discostato dalla sua formulazione basilare, principalmente perché, nei casi d'uso, il documento da ricercare non è un semplice testo ("''plain text''") ma invece è il prodotto di un ''word-processor'': quindi è costituito da una struttura XML più o meno complessa, rappresentante formattazioni, riferimenti interni o esterni, note, etc. La ricerca deve avvenire nei soli nodi di puro testo, individuando ed escludendo dall'analisi lessicale gli elementi testuali di mark-up che non costituiscono contenuto informativo. Nell'approfondire le strutture ed i concetti XML ho potuto notare quanto essi siano ricorrenti in molti ambiti dell'informatica.

Nell'analisi delle specifiche, un'altra complicazione si è presto aggiunta: l'usabilità del servizio cresce drasticamente se si evita di chiedere all'utente, come si era pensato in un primo tempo di fare, quali siano le stringhe (i nominativi) da ricercare e trattare; è nata allora l'idea di reperire queste stringhe in un dizionario di nomi ed in un dizionario di cognomi, considerando anche le permutazioni dei lemmi reperiti. Ho così dovuto approfondire alcuni problemi tipici dei dizionari, come il loro ampliamento automatico con tecniche oggi comprese nel ''machine-learning''. Non ho potuto "resistere" alla tentazione di ''formalizzare la matematica'' in base alla quale ho costruito le strategie di ricerca.

Spunto per la tesi è stata la recente legislazione in materia di dati personali, il GDPR. Esaminandone gli articoli pertinenti, ho maturato una riflessione generale: sempre più il software dovrà essere progettato e realizzato anche alla luce di altre discipline, non solo di quelle informatiche, come le discipline giuridiche ed il diritto.

Durante la fase iniziale della collaborazione con l'azienda mi sono dedicato alla messa a punto delle specifiche; ciò mi ha permesso di comprendere quanto questa fase sia importante e come completezza e precisione delle specifiche siano alla base di un progetto efficace.

Molto importanti sono state la analisi relative al tipo e formato dei documenti da assumere come input ed alla presentazione ottimale del servizio rispetto all'usabilità.

Centrale nel lavoro ed avvincente è stata la definizione della strategia per il riconoscimento dei lessemi attraverso la costruzione dinamica di ''regex'' idonee. In questo fase del lavoro, anche per passione personale, ho approfondito le questioni del riconoscimento "di testi nei testi" che legano, fin dalle origini, l'informatica e la linguistica.

La fase di definizione dell'architettura del servizio mi ha permesso di ripercorrere molte le materie studiate nei tre anni del Corso di Ingegneria Informatica, affrontando argomenti come il Single Responsibility Principle, il Dependency Inversion Principle, lo "stile" architetturale REST. Molto istruttiva è stata anche la riflessione sulla scomposizione del servizio in moduli software.

Come sempre accade nell'affrontare un progetto nuovo, sono nate molte nuove idee; ho così immaginato numerosi sviluppi futuri, sia a perfezionamento funzionale dell'accesso web al servizio, sia ad estensione delle specifiche per coprire casi applicativi contigui (es. quando il dato che si vuole trattare è un codice fiscale). Dovendo necessariamente tener presente che questo lavoro è una tesi, verificherò con il supporto del mio relatore come poterne proseguire lo sviluppo.

==Bibliografia==

<div></div>[0000]https://en.wikipedia.org/wiki/Comparison_of_Office_Open_XML_software
<div></div>[0001]https://en.wikipedia.org/wiki/Comparison_of_OpenDocument_software
<div></div>[0002]https://en.wikipedia.org/wiki/Standardization_of_Office_Open_XML
<div></div>[0003]https://en.wikipedia.org/wiki/OpenDocument_standardization
<div></div>[0004]https://support.apple.com/en-us/HT202227
<div></div>[0005]https://en.wikipedia.org/wiki/Pages_(word_processor)
<div></div>[0006]https://en.wikipedia.org/wiki/Comparison_of_word_processors
<div></div>[0007]https://en.wikipedia.org/wiki/OpenDocument
<div></div>[0008]https://en.wikipedia.org/wiki/Office_Open_XML_file_formats
<div></div>[0009]https://en.wikipedia.org/wiki/Rich_Text_Format
<div></div>[0010]https://www.ecma-international.org/publications/standards/Ecma-376.htm
<div></div>[0011]https://www.iso.org/standard/51463.html
<div></div>[0012]https://www.iso.org/standard/71691.html
<div></div>[0013]https://en.wikipedia.org/wiki/Office_Open_XML
<div></div>[0014]https://en.wikipedia.org/wiki/Open_Packaging_Conventions
<div></div>[0015]https://en.wikipedia.org/wiki/LAMP_(software_bundle)
<div></div>[0016]https://w3techs.com/blog/entry/debian_ubuntu_extend_the_dominance_in_the_linux_web_server_market_at_the_expense_of_red_hat_centos
<div></div>[0017]https://news.netcraft.com/archives/2014/06/06/june-2014-web-server-survey.html
<div></div>[0018]https://whatis.techtarget.com/definition/LAMP-Linux-Apache-MySQL-PHP
<div></div>[0019]https://www.ibm.com/cloud/learn/lamp-stack-explained
<div></div>[0020]https://en.wikipedia.org/wiki/Single_responsibility_principle
<div></div>[0021]https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
<div></div>[0022]https://en.wikipedia.org/wiki/Latin_script_in_Unicode
<div></div>[0023]https://it.wikipedia.org/wiki/ISO/IEC_8859-1
<div></div>[0024]http://www.treccani.it/enciclopedia/uso-delle-maiuscole_%28La-grammatica-italiana%29/
<div></div>[0025]https://en.wikipedia.org/wiki/Ambiguity#Linguistic_forms
<div></div>[0026]Steven L. Small; Garrison W Cottrell; Michael K Tanenhaus (22 October 2013). Lexical Ambiguity Resolution: Perspective from Psycholinguistics, Neuropsychology and Artificial Intelligence. Elsevier Science. ISBN 978-0-08-051013-2.
<div></div>[0027]http://www.treccani.it/vocabolario/disambiguazione/
<div></div>[0028]R. Navigli, K. Litkowski, O. Hargraves. 2007. SemEval-2007 Task 07: Coarse-Grained English All-Words Task. Proc. of Semeval-2007 Workshop (SemEval), in the 45th Annual Meeting of the Association for Computational Linguistics (ACL 2007), Prague, Czech Republic, pp. 30–35 http://www.aclweb.org/anthology/S/S07/S07-1006.pdf
<div></div>[0029]https://wordnet.princeton.edu/
<div></div>[0030]R. Navigli, S. P. Ponzetto. BabelNet: Building a Very Large Multilingual Semantic Network. Proc. of the 48th Annual Meeting of the Association for Computational Linguistics (ACL 2010), Uppsala, Sweden, July 11-16, 2010, pp. 216-225. http://aclweb.org/anthology/P/P10/P10-1023.pdf
<div></div>[0031]Roventini A., Alonge A., Calzolari N., Magnini B., Bertagna F. (2000), "ItalWordNet: a Large Semantic Database for Italian", Proc. of the 2nd International Conference on Language Resources and Evaluation (LREC 2000), Athens, Greece, 2000, pp. 783-790.
<div></div>[0032]E. Pianta, L. Bentivogli, C. Girardi. MultiWordNet: developing an aligned multilingual database, Proc. of the First International Conference on Global WordNet, Mysore, India, January 21-25, 2002. http://multiwordnet.fbk.eu/paper/MWN-India-published.pdf
<div></div>[0033]https://www.iso.org/standard/28245.html
<div></div>[0034]https://www.gpdp.it/web/guest/regolamentoue
<div></div>[0035]https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=uriserv:OJ.L_.2016.119.01.0001.01.ITA&toc=OJ:L:2016:119:TOC
<div></div>[0036]https://www.corriere.it/Primo_Piano/Cronache/2006/09_Settembre/15/cognomi.shtml
<div></div>[0037]https://data.world/axtscz/italian-first-names
<div></div>[0038]https://en.wikipedia.org/wiki/Dependency_inversion_principle
<div></div>[0039]https://imperialcollegelondon.app.box.com/s/lqqcugie51pllz26uixjvx0uio8qxgo5/file/493461282808
<div></div>[0040https://www.docx4java.org/trac/docx4j]
<div></div>[0041]https://github.com/plutext/docx4j
<div></div>[0042]https://docs.oracle.com/javase/9/docs/api/java/lang/String.html
<div></div>[0043]https://github.com/php/php-src/blob/master/ext/session/session.c
<div></div>[0044]https://github.com/plutext/docx4j/search?q=getJAXBNodesViaXPath+in%3Afile&type=Code
<div></div>[0045]https://www.w3.org/TR/xpath-30/
<div></div>[0046]https://www.istat.it/it/dati-analisi-e-prodotti/contenuti-interattivi/contanomi
<div></div>[0047]
<div></div>[0048]

==Indice delle figure==

[0F00]https://en.wikipedia.org/wiki/Latin_script


[0F01]Diagramma di Venn 1

[0F02]Diagramma di Venn 2

[0F03]Diagramma di Venn 3

[0F04]Esito unit test regex (cartella immagini)

[0F05]Inforgrafica GDPR

[0F06]Diagramma di sequenza UML

[0F07]Primo calcolo valutazione algoritmo

[0F08]Secondo calcolo valutazione algoritmo

[0F09]Terzo calcolo valutazione algoritmo

Servizio web per il trattamento dei dati personali contenuti in documenti OOXML complessi

2019-09-30T00:18:44Z

Lorenzo.amorosa: /* Indice delle figure */

==Introduzione==

Il recente Regolamento Generale europeo sulla Protezione dei Dati (UE) 2016/679 ([0034], [0035]) o ''GDPR'' (''General Data Protection Regulation'', come nel seguito sarà chiamato) ha modernizzato significativamente la normativa in materia di protezione dei dati personali, rendendola omogenea fra tutti gli stati membri. È bene notare che, fin dal titolo, il ''GDPR'' non riduce gli spazi per i trattamenti di dati personali, ma anzi ne protegge la "libera circolazione", dettando, però, regole definite e certe. Rinunciando ad una presentazione più completa del ''GDPR'', saranno riportati nei successivi capitoli i concetti necessari alla discussione dell'argomento.<div></div>
Enti ed organizzazioni, aventi a che fare con documenti contenenti dati sensibili, devono operare in maniera conforme al ''GDPR''; potrebbero, di conseguenza, trarre beneficio da servizi specifici in grado di supportarli in queste esigenze.<div></div>
L'oggetto principale della tesi sarà dunque, come riportato dal titolo, la progettazione e la realizzazione di un servizio per la gestione di dati personali.
<div></div>(QUI IMG [0F05])<div></div>

La larga maggioranza dei documenti testuali viene generata con strumenti cosiddetti di "produttività individuale", cioè da ''word-processors''. L'osservazione, ovvia nella sua evidenza, consente di introdurre una riflessione: quando un documento è generato da un'elaborazione automatica, magari per composizione di ''template'' con dati estratti da un database, l'individuazione dei "dati personali" nel documento prodotto può avvenire in modo rigoroso e senza incertezze, sulla base degli elementi di composizione del documento; ad es.: i campi del documento estratti da una anagrafica di soggetti sono certamente dati personali e come tali possono essere opportunamente trattati nel processo di elaborazione automatica (ad es. cancellati).

Ma, in quella larga maggioranza di documenti testuali generata con ''word-processors'' l'individuazione ed il trattamento dei dati personali vanno affrontati con altri approcci, discussi in questa tesi.

==Scenario di lavoro==

===Minimizzazione dei dati personali===

Un concetto espresso in modo pervasivo dal ''GDPR'' è quello della "''minimizzazione''" dei dati personali trattati ed a maggior ragione dei dati personali pubblicati. In particolare l'Art. 5 ed il Considerando 39 prescrivono che i dati personali trattati siano "''adeguati, pertinenti e limitati a quanto necessario rispetto alle finalità per le quali sono trattati («minimizzazione dei dati»)''" ([0035]).<div></div>
Con questo fine, il GDPR delinea due possibilità organizzative e tecniche di "''minimizzazione''": l'anonimizzazione e la psedonimizzazione.

====Anonimizzazione====

Sono anonimizzati i dati personali non (più) riferibili alle persone a cui sono appartenuti; si tratta di serie di dati, spesso ingenti, che sono stati definitivamente ed irreversibilmente separati da ogni riferimento alle persone che caratterizzavano. Sono le serie di dati utilizzate per fini statistici, scientifici, etc. E' importante notare che, come fissato dal Considerando 26 del ''GDPR'', il Regolamento non si applica al "''trattamento di tali informazioni anonime''" ([0035]). Per questo, sottoporre database e documenti ad un procedimento, cioè un trattamento, di anonimizzazione consente di non doversi più preoccupare del ''GDPR''.

====Pseudonimizzazione====

Fra le definizioni dell'Art. 4 del ''GDPR'', la "pseudonimizzazione" viene indicata come "''il trattamento tale che i dati personali non possano più essere attribuiti a un interessato specifico senza l’utilizzo di informazioni aggiuntive, a condizione che tali informazioni aggiuntive siano conservate separatamente''" ([0035]).<div></div>
Traducendo in termini "operativi", si tratta del procedimento che, dal "record" dei dati di un interessato, separa i campi che caratterizzano l'interessato stesso da quelli che lo identificano, trasferendo questi ultimi in una nuova distinta tabella; nelle due tabelle vengono aggiunti i riferimenti che permettono la ricostruzione del record originario; il procedimento è completo quando la nuova tabella con gli identificativi viene archiviata separatamente ed eventualmente cifrata. In margine si annota che in molti casi, come molti studi dimostrano, è possibile identificare, quindi "riconoscere", gli interessati utilizzando la sola tabella con i dati pseudonimizzati.

====Altri trattamenti di "minimizzazione" ====

Un problema pratico che si incontra di frequente è quello di dover pubblicare documenti più o meno ampi che contengono dati personali. Spesso la pubblicazione è obbligatoria per legge: si pensi alle graduatorie relative a concorsi pubblici, alle sentenze dei tribunali, etc.<div></div>
In questi frequenti casi, analizzando meglio le finalità per le quali sono pubblicati quei dati personali, si osserva che sono possibili e legittimi almeno due approcci per "minimizzare" il dato nel "trattamento di pubblicazione" e, dunque, per minimizzarne la propagazione, ad esempio attraverso motori di ricerca, ben oltre ogni ragionevole finalità. I contesti ed i corrispondenti approcci sono:
# Situazioni in cui è necessario che l'interessato possa riconoscersi nel documento ed essere riconosciuto dagli altri soggetti menzionati nel contesto, ma non è plausibile la necessità di identificazione dell'interessato al di fuori di quel contesto specifico. A questo caso si riconducono le graduatorie di concorsi, gli elenchi per la formazione di classi, gli elenchi per convocazioni, etc. In tutti questi casi, nel processo di redazione del documento è più pratico trattare internamente i dati personali in forma completa; ma praticamente mai è necessario pubblicarli per intero, esponendo al pubblico accesso codici fiscali, indirizzi, recapiti telefonici etc. Per di più, nella maggior parte delle volte, è sufficiente pubblicare il solo cognome perché l'interessato conosca la sua posizione in graduatoria; ciò è spesso sufficiente anche a trasmettere l'informazione necessaria ai colleghi dell'interessato nella medesima graduatoria, o nella medesima classe, etc. Notare che, pubblicando il solo cognome, viene di fatto oscurato anche il sesso. Dunque, in questi casi è auspicabile cancellare una larga parte dei dati personali presenti nel documento.
# Situazioni in cui il documento deve essere pubblicato affinché siano rese note le motivazioni che lo hanno originato, senza che sia necessaria la precisa identificazione dei soggetti che vi compaiono. Questo è il caso della pubblicazione di sentenze giudiziarie di ogni grado. Le sentenze vengono notificate direttamente agli "aventi causa"; ma anche, come la legge prescrive, pubblicate al fine di costituire giurisprudenza. In questo secondo caso, risulta del tutto eccedente la pubblicazione dei reali nominativi degli interessati, che troverebbero verosimilmente la propria vicenda inutilmente indicizzata dai motori di ricerca negli anni a venire. Nella pubblicazione delle sentenze appare un approccio ottimale quello di sostituire con pseudonimi o con iniziali alterate i veri nominativi degli interessati presenti: il senso e le argomentazioni della sentenza restano pienamente comprensibili, come è necessario; il dato personale, del tutto superfluo ai fini della giurisprudenza, viene protetto.
In questi casi appare opportuno sostituire i dati identificativi dell'interessato, ed in particolare il nome e cognome, con pseudonimi o, ancora, con iniziali alterate, cioè non coincidenti con le iniziali reali. <div></div>
Proprio questi tipi di trattamenti di "minimizzazione" sono l'oggetto di questa tesi.

===Punti di partenza per la progettazione del servizio===

La tesi è stata svolta in collaborazione con l'azienda AFA Systems (www.afasystems.it/gdpr) con la quale si sono discusse le problematiche di progettazione e realizzazione di un servizio generalizzato di minimizzazione dei dati personali presenti in un documento.
Con l'intenzione di fornire il servizio ad un bacino d'utenza il più vasto e variegato possibile, si è pensato ad un'applicazione ''web-based'', indipendente così dai singoli devices sui quali poi sarà utilizzata.
L'attenzione è stata concentrata sul trattamento dei nomi e dei cognomi (che da qui chiameremo nominativi), poiché sono quelli sempre presenti nei documenti (ad es. gli indirizzi sono presenti solo a volte), rappresentano gli elementi tramite i quali è immediato il riconoscimento della persone, non hanno formato predefinito (come ad es. i codici fiscali); altri dati personali (indirizzi, codici fiscali, etc.), potranno essere considerati in successive evoluzioni del progetto.
È utile notare che la parte iniziale della collaborazione con l'azienda è stata dedicata alla discussione delle specifiche, la cui più precisa definizione è parte rilevante di questa tesi.<div></div>
Tra i requisiti che necessitano di un opportuno studio troviamo ad esempio:
* L'individuazione di metodi efficaci per il riconoscimento dei nominativi nei documenti
* L'identificazione delle migliori procedure di interazione con l'utente
* La scelta dei formati da trattare
* I vincoli non funzionali legati al rispetto del ''GDPR''.

==Definizione delle specifiche==

===Riconoscimento dei nominativi===

====Scelta della strategia di riconoscimento====

Le difficoltà principali con cui ci si imbatte nel processo di riconoscimento dei nominativi riguardano la complessità strutturale dei documenti di testo, ma soprattutto l'intrinseca ambiguità del linguaggio naturale. <div></div>
Le variabili ed impredicibili strutture e formattazioni dei documenti introducono alcuni problemi significativi. Rendendo fortemente eterogeneo il contenuto dei documenti, infatti, esse non consentono di ricondurre il problema del riconoscimento dei nominativi ad uno o a pochi singoli casi, ma comportano lo studio di tutte le strutture e formattazioni possibili, rendendo quindi l'analisi molto generale. L'altra rilevante difficoltà presente sta nella complessità di effettuare il riconoscimento di una stringa testuale immersa in un insieme di elementi non tutti testuali. Ogni elemento di formattazione, che sia una tabella o una barra orizzontale, introduce infatti un proprio significato logico e semantico nel documento di cui bisogna tenere conto.<div></div>
Il linguaggio naturale introduce anch'esso complessità: si pensi alle molteplici tipologie di proposizioni con cui possono essere articolati i periodi; ma i problemi principali derivano dalle sue ambiguità. Esse vengono classificate in diverse tipologie ([0025]); le principali sono le ambiguità sintattiche e lessicali.<div></div>
Si ha ambiguità sintattica quando la sintassi di una frase può essere interpretata in diversi modi e, di conseguenza, la frase stessa assume significati diversi. Essa è presente, ad esempio, nelle seguenti frasi:<div></div>
* "''Rapina in banca con rivoltella da centomila euro''"
* "''Luigi ha visto un uomo nel parco con il binocolo''"
<div></div>
L'esasperazione massima della problematica delle ambiguità sintattiche si presenta con l'<i>antinomia</i>, ossia un particolare tipo di paradosso che indica la compresenza di due affermazioni contraddittorie che possono essere entrambe dimostrate o giustificate.
L'antinomia di Epimenide o ''Paradosso del mentitore'', nota fin dal VI secolo, è probabilmente uno dei più noti esempi: "''il cretese Epimenide afferma che tutti i cretesi mentono''". Se la proposizione è vera (i cretesi mentono) allora il suo significato implica che sia falsa (Epimenide mente e quindi i cretesi dicono la verità), ma se è falsa (i cretesi dicono la verità) ciò significa che è vera (Epimenide dice la verità e quindi i cretesi mentono). La proposizione appare contemporaneamente vera e falsa. A partire dagli anni venti del '900, sono state elaborate varie teorie per la risoluzione delle contraddizioni provocate dalle antinomie, soprattutto attraverso l'elaborazione di linguaggi multilivello o attraverso l'elaborazione di logiche polivalenti (quindi non-booleane).<div></div>
Si ha ambiguità lessicale, invece, quando una parola possiede più di un significato nella lingua a cui appartiene ([0026]), in tal caso la parola è definita ''polisemica''. In italiano, alcuni termini soggetti a questo tipo di ambiguità sono, ad esempio "''acuto''" o "''venti''". È questo genere di ambiguità che risulta critico per il riconoscimento dei nominativi. La difficoltà determinata dalle ambiguità sintattiche, infatti, riguarda l'individuazione corretta di soggetti, predicati e complementi di un periodo, mentre le ambiguità lessicali ostacolano la comprensione del significato del singolo lessema. Nel processo di riconoscimento è irrilevante determinare la funzione logica che il nominativo svolge nella frase, mentre è necessario essere certi che i termini che compongono il nominativo siano effettivamente dei nomi propri di persona o dei cognomi, non altri vocaboli del lessico comune. <div></div>
In linguistica, l'intervento con cui si toglie ambiguità a una parola o a una frase prende il nome di "disambiguazione" ([0027]). Il problema della disambiguazione automatica (in inglese ''Word Sense Disambiguation'' o, abbreviato, ''WSD'') riveste particolare importanza nelle ricerche sull'intelligenza artificiale e, in particolare, nell'elaborazione del linguaggio naturale. Si prevedono benefici della disambiguazione, ad esempio, in programmi di traduzione automatica, recupero dell'informazione o estrazione automatica di informazioni. Nell'analisi delle soluzioni esistenti in letteratura per la risoluzione delle ambiguità, ci si sofferma specialmente sulle ricerche incentrate sul trattamento dell'ambiguità lessicale, essendo essa la più rilevante per i nostri interessi.<div></div>
La ''WSD'' richiede due input necessariamente: un dizionario per specificare i sensi che devono essere disambiguati e un corpus di dati linguistici da disambiguare. Nello scenario più realistico, si trattano testi le cui parole non sono note a priori e risulta molto onerosa la produzione del corpus, essendo infatti necessaria la valutazione di un operatore umano per verificare la correttezza delle disambiguazioni effettuate dagli algoritmi (''supervised learning'').<div></div>
Uno tra i principali dizionari semantici-lessicali utilizzati della lingua inglese è ''WordNet'' ([0029]), mentre alcuni dei database equivalenti che trattano l'italiano sono ''BabelNet'' ([0030]), ''ItalWordNet'' ([0031]) e ''MultiWordNet'' ([0032]).
Un elemento importante da considerare è che le prestazioni di disambiguazione per la lingua inglese, impiegando ''WordNet'', risultano corrette tra l'80% e il 90% delle volte ([0028]), percentuali discrete ma non sufficienti per avere la totale garanzia.<div></div>
I fattori che ostacolano la realizzazione di algoritmi di intelligenza artificiale per la disambiguazione sono molteplici:
# Differenze tra dizionari impiegati: i database prima citati si basano su varie fonti che raggruppano semanticamente in maniera diversa i vocaboli, quindi programmi sviluppati con dizionari diversi generalmente hanno performance differenti.
# Complessità della codifica di parte del discorso: per poter disambiguare correttamente un termine è importante riuscire a comprendere correttamente il contesto in cui è inserito, operazione non banale.
# Varianza tra giudici: i supervisori dell'apprendimento degli algoritmi possono avere opinioni diverse, o semplicemente sbagliare, nella valutazione delle disambiguazioni, ciò porta ad algoritmi che hanno comportamenti diversi.
# Impossibilità di applicare la disciplina della ''pragmatica'', ossia la logica del ''buon senso'': per identificare correttamente il senso di alcune parole, ad esempio nella comprensioni di anafore e catafore, è necessario applicare il buon senso.
# Dipendenza del senso delle parole dai contesti: ogni scenario richiede la propria divisione del significato delle parole in sensi rilevanti. In un contesto informatico, ad esempio, il termine "''mouse''" deve essere ricondotto al dispositivo di puntamento, non al cognome del celebre personaggio Disney ''Mickey Mouse''; viceversa dovrà invece avvenire in un contesto di letteratura a fumetti.<div></div>
Laddove la ''WSD'' è una tecnica molto generale e che mira a risolvere un'ambiguità riguardante una qualunque parola, per le finalità del servizio oggetto di questa tesi è sufficiente risolvere le ambiguità dei nomi e dei cognomi.
Uno dei difetti che il servizio presenterebbe adottando un approccio ''WDS'' è legato alla impredicibile formattazione dei documenti, che aggiunge informazione semantica al testo ma introduce complessità nella individuazione automatica delle parti che formano il contesto; un altro difetto dipende dalla vastità del lessico da elaborare, essendo i documenti da trattare forniti dai più disparati utenti, su qualunque genere di argomento e relativi ai più vari ambiti.<div></div>

La strategia che sarà adottata per risolvere la problematica del riconoscimento dei nominativi sarà impostata attraverso un modello ''pattern-based'', impiegando le ''regular expressions'' (''regex''). Esse risultano comunemente usate per effettuare operazioni di ricerca o sostituzione in un testo, di conseguenza se si riesce ad individuare un pattern associato ad un nominativo dato, allora sarà possibile processare il documento ricercando le occorrenze del nominativo e "minimizzarlo" opportunamente.<div></div>

Le ''regular expressions'' risultano particolarmente efficaci poiché, se opportunamente progettate, possono identificare un nominativo indipendentemente dal significato linguistico del contesto in cui è calato, basandosi piuttosto sui singoli caratteri che compongono i lessemi analizzati; permettono, di conseguenza, di effettuare una valutazione estremamente minuziosa, riducendo al minimo le possibilità di errori.<div></div>
Un algoritmo di risoluzione ''pattern-based'' risulta, inoltre, più efficiente nell'esecuzione, in generale, di un algoritmo di intelligenza artificiale; per fornire la risposta il più velocemente possibile ad un utente, fruitore del servizio via web, l'approccio di riconoscimento tramite pattern è il più indicato.<div></div>

====Definizione dei pattern====
Nella progettazione del servizio si adotta, come detto, un approccio ''pattern-based'' per il riconoscimento dei nominativi. In linea di massima è opportuno che vengano riconosciuti più nominativi possibili e allo stesso tempo che la correttezza dell'identificazione di un nominativo sia garantita, quindi bisogna individuare dei pattern non troppo stringenti ma neppure troppo laschi. Per analizzare come i pattern devono essere strutturati si prende come caso di studio un generico nominativo, ad esempio ''Lorenzo Mario Amorosa''. Nel documento esso può comparire esattamente come appena indicato, ma anche in altre plausibili varianti, in cui l'ordine dei termini viene alterato, si pensi ad esempio ad "Amorosa Lorenzo Mario" o "Mario Lorenzo Amorosa", o in altre varianti ancora in cui alcuni nomi non compaiono, come in "Lorenzo Amorosa". Bisogna tuttavia supporre un limite alla variabilità: si osserva infatti che il cognome deve sempre comparire (il solo nome ''Lorenzo'' non è riconducibile a ''Lorenzo Mario Amorosa'') e che esso inoltre deve essere necessariamente anteposto o posposto, ma non interposto, ai nomi (è poco ragionevole ricondurre "Lorenzo Amorosa Mario" a "Lorenzo Mario Amorosa'').<div></div>
Questa prima specifica permette di ricondursi a una soluzione generale, sufficiente nella maggior parte dei casi, ma che non risolve alcune criticità. Un nominativo può, in alcuni documenti, comparire manifestandosi unicamente attraverso il cognome (riferendoci all'esempio precedente, ''Lorenzo Mario Amorosa'' apparirebbe nella forma ''Amorosa''). Sorge qui il problema che molti dei cognomi italiani hanno un significato proprio nel linguaggio comune; ad es., nella frase ''una relazione amorosa è bella'' è errato considerare la parola ''amorosa'' come cognome di un nominativo. Per risolvere questo genere di ambiguità si potrebbe pensare che per stabilire che il termine ''Amorosa'' sia un cognome sia sufficiente verificare che esso inizi con una lettera maiuscola, ma ciò può verificarsi anche perché la parola si trova ad inizio di frase. Inoltre, vari cognomi italiani possono iniziare con una lettera minuscola (''de Angelis'', ''d'Onofrio'', etc.), quindi basare l'identificazione di un cognome sul fatto che la sua prima lettera sia in maiuscolo non è in generale un metodo valido. Volendo in maniera prioritaria garantire il corretto funzionamento del servizio, e quindi attuare le procedure di anonimizzazione solo sui nominativi senza applicarle erroneamente ad altri termini, risulta necessario evitare il trattamento dei nominativi che si manifestano con i soli cognomi. Per via del contesto e dei significati che i cognomi possono assumere, infatti, risulta spesso impossibile distinguerli da parole del linguaggio comune.

Ci si concentra, quindi, nello studio di nominativi composti da un cognome seguito o preceduto da uno o più nomi.<div></div>
Si rappresenta dunque in formato di ''regular expression'' il pattern attualmente ideato. Per semplicità espositiva, si definisce il tag <span style="font-family: monospace;"><nomi></span> come l'insieme delle permutazioni di tutti i nomi del nominativo più l'insieme delle permutazioni di tutti i possibili sottoinsiemi di nomi del nominativo. Considerando il nominativo preso precedentemente come caso di studio, ad esempio, si avrebbe:
<div></div>
<span style="font-family: monospace;"> <nomi> = Lorenzo Mario|Mario Lorenzo|Lorenzo|Mario</span>
<div></div>
Posto inoltre il tag <span style="font-family: monospace;"><cognome></span> ad indicare il cognome contenuto nel nominativo e il tag <span style="font-family: monospace;"><regex></span> ad indicare la ''regular expression'' associata al nominativo, si ottiene:
<div></div>
<span style="font-family: monospace;"> <regex> := <cognome> (<nomi>)|(<nomi>) <cognome></span>
<div></div>
Una osservazione sottile ma di fondamentale importanza per la corretta progettazione delle ''regular expressions'' sta nella piena comprensione della semantica dell'operatore di scelta, espresso con il carattere ''pipe'' ("|"). Un qualunque ''engine'' di elaborazione delle ''regex'', infatti, interrompe la valutazione di una stringa non appena può stabilire se tale stringa fa match o meno con il pattern dato, senza quindi necessariamente valutarlo nella sua interezza, come parimenti avviene nelle valutazioni ''a corto circuito'' delle espressioni logiche nei linguaggi di programmazione. Ogni nominativo avrà a sè associato un pattern che lo rappresenta in più possibili sequenze di caratteri; per effettuare una corretta "minimizzazione" dei dati è necessario che le sequenze contenenti tutti i nomi sia poste per prime, mentre quelle contenenti un singolo nome per ultime.<div></div>
In questa prima formulazione della ''regex'', inoltre, si è posto come separatore unicamente lo spazio bianco, ma alcuni documenti potrebbero contenere dei nominativi i cui termini sono separati da altri caratteri, come ad esempio una virgola nel caso di "Amorosa, Lorenzo Mario". Per poter quindi identificare un nominativo anche in questi casi, si potrebbe considerare un qualunque carattere di interpunzione come possibile separatore dei termini del nominativo.
Adottando questa soluzione si ha però come effetto collaterale che risultano critici i casi in cui nel testo sono presenti dei nominativi soggetti ad omonimia. Si consideri una generica frase contenente una sequenza di nominativi, ad esempio ''Amorosa Lorenzo, Mario Giacomo e Fabio Rossi'', e si supponga che i nominativi da trattare siano ''Amorosa Lorenzo Mario'', ''Mario Giacomo'' (in cui la parola ''Mario'' è il cognome) e ''Fabio Rossi''. Gli ultimi due nominativi compaiono nella frase nella loro forma estesa, mentre il primo compare con il solo nome ''Lorenzo'' (eventualità possibile considerando la definizione del pattern precedentemente data). Considerando la virgola come carattere separatore dei termini del nominativo, la sequenza di parole ''Amorosa Lorenzo, Mario'' sarebbe ricondotta, venendo elaborata per prima, ad ''Amorosa Lorenzo Mario'', mentre rimarrebbe non trattata la parola ''Giacomo'', in quanto il cognome ''Mario'' che gli era associato è stato già identificato come un nome del nominativo ''Amorosa Lorenzo Mario'' ed il termine ''Giacomo'' preso singolarmente non rappresenta un nominativo.<div></div>
Prima di valutare ulteriormente le problematiche relative alle omonimie, si possono scegliere due approcci per risolvere questo specifico caso:
# Si riconduce una sequenza di parole ad un nominativo se e solo se tutti i suoi nomi sono contenuti nella sequenza
# Si considerano come separatori dei termini contenuti nei nominativi solo spazi bianchi, tabulazioni e a capo, non gli altri segni di punteggiatura.
<div></div>
Entrambe le strategie sono valide, in quanto risolvono il problema garantendo la corretta identificazione dei nominativi, ma allo stesso tempo entrambe presentano lo svantaggio di ridurre le sequenze di parole riconducibili a dei nominativi, aumentando le possibilità che alcuni di essi non vengano trattati.
Si consideri nuovamente il nominativo preso come caso di studio ''Amorosa Lorenzo Mario'': applicando la prima strategia, non sarebbe possibile ricondurgli la sequenza ''Amorosa Lorenzo'', mentre applicando il secondo metodo non sarebbe riconducibile la sequenza ''Amorosa, Lorenzo Mario''.
Si decide di attuare la seconda strategia, in quanto è opportuno non imporre vincoli troppo stringenti sui nomi e poiché nella gran parte dei casi i termini dei nominativi nei documenti sono separati tra loro da caratteri quali spazi bianchi, tabulazioni ed a capo.<div></div>
Un altro elemento su cui porre l'attenzione è la possibilità che i documenti da trattare contengano dei nominativi scritti interamente in maiuscolo o minuscolo, di conseguenza è conveniente che le ''regular expressions'' siano progettate ''case-insensitive''.<div></div>
Un ulteriore punto su cui bisogna soffermarsi è la posizione all'interno di un periodo in cui un nominativo può comparire, in particolare si vogliono evitare quei casi critici in cui uno dei termini del nominativo è una sotto-stringa di un'altra parola del testo (si pensi ad ''amorosa'' in ''clamorosa''). Come regola generale si può stabilire che è sempre necessario che un nominativo sia preceduto e seguito da un ''carattere non alfabetico''. Un caso particolare si presenta quando il nominativo è posto ad inizio o a fine documento, situazione in cui quindi esso non è preceduto o non è seguito da alcun carattere: entrambe le posizioni sono da considerare corrette.<div></div>
È opportuno ora definire il concetto di ''carattere non alfabetico'', e ciò si può fare più facilmente ragionando sul problema in logica positiva; infatti risulta più semplice individuare quei caratteri che rappresentano lettere piuttosto che quelli che rappresentano segni di interpunzione ed individuare ogni altro carattere che non può mai comporre una parola.

Inquadrando lo scenario di applicazione del servizio, molto probabilmente l'utente vorrà trattare un documento scritto nella lingua di uno dei paesi dell'Unione Europea, poiché il ''GDPR'' vige nei soli paesi membri dell'Unione.
Si può, quindi, ipotizzare che i documenti trattati possono sì contenere parole e nominativi stranieri, ma che i caratteri contenuti siano appartenenti all'alfabeto latino (''Latin script''), usato in molti stati nel mondo e da tutti i principali stati europei (fatta eccezione per la Grecia ed alcuni stati che scrivono in caratteri cirillici).
Inoltre, testi scritti in altri alfabeti, come esempio il cinese, l'arabo o il cirillico, vengono generalmente traslitterati. Considerare, quindi, ''caratteri non alfabetici'' tutti i caratteri diversi dalle lettere contenute nell'alfabeto latino sarebbe di conseguenza estremamente riduttivo ed inoltre in questo modo non si terrebbe conto delle lettere accentate, molto utilizzate anche nella lingua italiana.
<div></div>(XXXX QUI IMG [0F00])<div></div>
Per risolvere il problema facciamo riferimento alla codifica standard Unicode dell'alfabeto latino ([0022]); in essa è possibile individuare, oltre ai caratteri rappresentanti le lettere nella codifica ''ASCII'' classica, i caratteri rappresentanti le lettere nella codifica standard ''ISO/IEC 8859-1'' ([0023]), encoding orientato principalmente alla rappresentazione delle lingue dell'Europa occidentale.

<div></div>
<center><i>Caratteri latini nei primi due blocchi dello standard Unicode</i></center>
{| class="nounderlines" border="1" cellpadding="2" cellspacing="0" style="border-collapse:collapse"
|----- align="center"
!style="background:#ccf; text-align:center; font-weight: bold;"|U+
!style="text-align:center; font-weight: bold;"|0||style="text-align: center; font-weight: bold;"|1||style="text-align: center; font-weight: bold;"|2||style="text-align: center; font-weight: bold;"|3||style="text-align: center; font-weight: bold;"|4||style="text-align: center; font-weight: bold;"|5||style="text-align: center; font-weight: bold;"|6||style="text-align: center; font-weight: bold;"|7||style="text-align: center; font-weight: bold;"|8||style="text-align: center; font-weight: bold;"|9||style="text-align: center; font-weight: bold;"|A||style="text-align: center; font-weight: bold;"|B||style="text-align: center; font-weight: bold;"|C||style="text-align: center; font-weight: bold;"|D||style="text-align: center; font-weight: bold;"|E||style="text-align: center; font-weight: bold;"|F||style="text-align: center; font-weight: bold;"|Block||style="text-align: center; font-weight: bold;"|#
|-
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0040
|style="background:#fff"|@||A||B||C||D||E||F||G||H||I||J||K||L||M||N||O
|rowspan="4" style="background:#fff" align:"center"|C0 Controls and Basic Latin<br>0000–007F<br>(identical to ASCII)
|rowspan="4" style="background:#fff"|52
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0050
|P||Q||R||S||T||U||V||W||X||Y||Z||style="background:#fff"|[||style="background:#fff"|\||style="background:#fff"|]||style="background:#fff"|^||style="background:#fff"|_
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0060
|style="background:#fff"|`||a||b||c||d||e||f||g||h||i||j||k||l||m||n||o
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0070
|p||q||r||s||t||u||v||w||x||y||z||style="background:#fff"|{||style="background:#fff"||||style="background:#fff"|}||style="background:#fff"|~||style="background:#fff; font-size:75%"|DEL
|-
!colspan="19"|
|----- align="center" style="background:#fff"
!style="background:#fff; text-align:center; font-weight: bold;"|00A0
| ||¡||¢||£||¤||¥||¦||§||¨||©||ª||«||¬||||®||¯
|rowspan="6" style="background:#fff" align="center"|C1 Controls and Latin-1 Supplement<br>0080–00FF<br>(identical to ISO/IEC 8859-1)
|rowspan="6" style="background:#fff"|62
|----- align="center" style="background:#fff"
!style="background:#fff; text-align:center; font-weight: bold;"|00B0
|°||±||²||³||´||µ||¶||·||¸||¹||º||»||¼||½||¾||¿
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00C0
|À||Á||Â||Ã||Ä||Å||Æ||Ç||È||É||Ê||Ë||Ì||Í||Î||Ï
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00D0
|Ð||Ñ||Ò||Ó||Ô||Õ||Ö||style="background:#fff"|×||Ø||Ù||Ú||Û||Ü||Ý||Þ||ß
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00E0
|à||á||â||ã||ä||å||æ||ç||è||é||ê||ë||ì||í||î||ï
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00F0
|ð||ñ||ò||ó||ô||õ||ö||style="background:#fff"|÷||ø||ù||ú||û||ü||ý||þ||ÿ
|---- align="center" style="background:#f66"
|}
<div></div>

I caratteri indicati in rosso nella tabella sono tutti i possibili ''caratteri alfabetici'' che compaiono nei documenti scritti in 29 lingue diverse ([0023]), tra le quali sono presenti l'italiano, l'inglese, lo spagnolo, il tedesco e il portoghese.
Aggiungendo pochi altri caratteri all'insieme dei ''caratteri alfabetici'' appena mostrati, si riesce a rappresentare ogni parola di altre 12 lingue ([0023]), tra cui il francese, l'olandese, il ceco e il turco.<div></div>
I caratteri mostrati in tabella corrispondono ad una parte dei primi due blocchi dello standard Unicode che codificano l'alfabeto latino e, come già accennato in precedenza, essi sono presenti negli standard ''ASCII'' e ''ISO/IEC 8859-1''. I rimanenti ''caratteri alfabetici'', invece, sono presenti in estensioni dello standard Unicode per il ''Latin script''. Queste estensioni sono state realizzate per fornire il massimo supporto a tutte le lingue e contenenti molti simboli ad uso speciale, come ad esempio per la rappresentazione dei fonemi. Si osserva, inoltre, che i ''caratteri alfabetici'' definiti nelle estensioni dello standard Unicode sono presenti anche nella codifica ''ISO/IEC 8859-2'' o nelle versioni successive ([0023]).<div></div>
Definiti i ''caratteri non alfabetici'' come elementi di separazione tra un nominativo ed il testo in cui esso è inserito, occorre definire opportunamente la ''regex'' che al nominativo è associata.

Utili strumenti messi a disposizione dalle ''regular expressions'' sono i gruppi speciali ''lookahead'' e ''lookbehind''. Un pattern di un nominativo deve essere preceduto o seguito da una prestabilita sequenza di caratteri, la quale però non è parte del nominativo. Utilizzando i due costrutti citati, è possibile far sì che nell'elaborazione di una stringa facciano match solamente le parole effettivamente appartenenti al nominativo, non i caratteri che lo delimitano dal resto del testo, e allo stesso tempo che un nominativo faccia match se e solo se preceduto o seguito da una certa sequenza di caratteri. <div></div>
Per esprimere nella sintassi delle ''regex'' un carattere letterale in un qualunque alfabeto si può utilizzare il costrutto ''\p{L}'', che però risulta molto generale e troppo lasco per i requisiti considerati. Si può piuttosto valutare l'impiego del costrutto ''\p{Latin}'', il quale identifica un qualunque carattere alfabetico presente nell'alfabeto latino. Tra i caratteri corrispondenti al costrutto, però, ve ne sono alcuni che per le specifiche del servizio devono essere considerati ''caratteri non alfabetici'', come ad esempio i caratteri dei fonemi, i segni diacritici e gli indicatori ordinali; di conseguenza è necessario individuare una strategia ad hoc per risolvere questa problematica.<div></div>
Per chiarezza espositiva, si definisce il tag <span style="font-family: monospace;"><start></span>, per indicare un qualunque carattere non alfabetico o l'inizio stringa, il tag <span style="font-family: monospace;"><end></span>, per indicare un qualunque carattere non alfabetico o il fine stringa, ed il tag <extra>, per indicare i ''caratteri alfabetici'' non presenti negli standard ''ASCII'' o ''ISO/IEC 8859-1'':<div></div>
<span style="font-family: monospace;">
<extra> := ĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ
<br/>
<start> := (?<=[^A-Za-zÀ-ÖØ-öø-ÿ<extra>]|^)
<br/>
<end> := (?=[^A-Za-zÀ-ÖØ-öø-ÿ<extra>]|$)
</span>
<div></div>
Si osserva che si sono utilizzati i gruppi speciali prima descritti e che si sono inseriti i caratteri dello standard Unicode presentati in precedenza. Si definisce nuovamente la ''regular expression'' associata ad un generico nominativo. Applicando i tag appena definiti, il costrutto ''(?i)'' che rende il pattern ''case-insensitive'' ed il costrutto ''\s'' che rappresenta un carattere qualunque tra i separatori non visibili, ossia ''\r \n \t \f \v'' e lo spazio bianco, si ottiene:<div></div>
<span style="font-family: monospace;">
<regex> := (?i)(<start><cognome>\s+(<nomi>)|(<nomi>)\s+<cognome><end>)
</span>
<div></div>
Si osserva, inoltre, che in questa nuova formulazione della ''regular expression'' i nomi sono da intendersi separati tra loro da ''\s+''.<div></div>
A questo punto si è quasi giunti alla formulazione finale del pattern da associare ad un nominativo, rimangono solo da trattare alcuni casi critici non ancora risolti.<div></div>
Si è già presentato in precedenza il problema legato al fatto che alcuni cognomi possono avere un significato proprio nel lessico comune e che ciò costringeva, quindi, ad abbandonare l'idea di trattare nominativi formati dal solo cognome. Questa problematica di ambiguità si presenta anche con alcuni nomi (si pensi, ad esempio, al nome ''Gioia''). Ciò non rappresenta generalmente un problema, in quanto la coppia nome-cognome che forma il nominativo, presa complessivamente, non è soggetta ad ambiguità. Esistono, però, dei casi in cui questo non è vero. Si prenda in analisi il nominativo ''Gioia Grande'': risulta evidentemente soggetto a rischio di ambiguità. Una soluzione che si può adottare, per risolvere questo caso critico, si basa sull'associazione di un pattern più stringente ai nominativi. In particolare, si osserva che i nomi propri di persona compaiono sempre ed obbligatoriamente, in un documento grammaticalmente corretto, con la prima lettera maiuscola ([0024]). I cognomi, invece, non sono soggetti ad una regola così stringente: un cognome iniziante con una lettera minuscola (come ''de Rosa'') in alcuni casi, ad esempio se posto dopo un punto fermo, può comparire scritto con la prima lettera sia maiuscola che minuscola; naturalmente, in nessuna occorrenza un cognome che inizi con una lettera maiuscola potrà comparire con una minuscola. <div></div>
Occorre quindi ridefinire, alla luce di queste osservazioni, la ''regex'' associata ad un nominativo, poiché precedentemente era stata posta interamente ''case-insensitive''. Nel pattern, in particolare, i nomi dovranno sempre iniziare con una maiuscola, mentre i cognomi avranno questo vincolo solo se nel nominativo compaiono con la prima lettera maiuscola. Si mostra quindi quali sono i tag <span style="font-family: monospace;"><nomi></span> e <span style="font-family: monospace;"><cognome></span> associati a due nominativi, ad esempio ''Gioia Grande'' e ''Antonio de Rosa''. <div></div>
Per ''Gioia Grande'' si ha:<div></div>
<span style="font-family: monospace;"><nomi> = G((?i)ioia)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = G((?i)rande)</span>
<div></div>
Per ''Antonio de Rosa'' si ha:<div></div>
<span style="font-family: monospace;"><nomi> = A((?i)ntonio)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = (?i)de Rosa</span>
<div></div>
Si presenta dunque la definizione finale del tag <span style="font-family: monospace;"><regex></span>. Nella definizione il tag <span style="font-family: monospace;"><nomi></span> è definito il base al numero di nomi del nominativo ed il tag <span style="font-family: monospace;"><cognome></span> è definito in base al carattere iniziale del cognome.<div></div>
<span style="font-family: monospace;">
<regex> := <start><cognome>\s+(<nomi>)|(<nomi>)\s+<cognome><end>
</span>
<div></div>
Vengono inoltre mostrati i valori dei due tag <span style="font-family: monospace;"><nomi></span> e <span style="font-family: monospace;"><cognome></span> per il nominativo preso come caso di studio in fase iniziale, ossia ''Amorosa Lorenzo Mario''. Si ottiene:<div></div>
<span style="font-family: monospace;"><nomi> = L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = A((?i)morosa)</span>
<div></div>
Infine, per completezza, viene mostrata la ''regular expression'', associata a quest'ultimo nominativo, risolvendo tutti i tag che la compongono:
<div></div>
<span style="font-family: monospace;">
<regex> = (?<=[^A-Za-zÀ-ÖØ-öø-ÿĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ]|^)(A((?i)morosa)\s+(L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario))|(L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario))\s+A((?i)morosa))(?=[^A-Za-zÀ-ÖØ-öø-ÿĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ]|$)
</span>
<div></div>

====Gestione delle omonimie====

Nei ragionamenti che hanno portato alla formulazione della ''regular expression'' associata ai nominativi, si è tenuto conto di possibili ambiguità con termini appartenenti al linguaggio comune, risolte con l'introduzione nel pattern di stringhe ''case-sensitive'', e di possibili nominativi posti in sequenza parzialmente omonimi (ossia aventi un nome o il cognome in comune tra loro), gestite con l'imposizione dei soli caratteri separatori non visibili come delimitatori delle parole componenti un nominativo. Per rendere l'analisi completa occorre valutare come ci si debba comportare in altri possibili casi di omonimia. Si osserva, per inciso, che nel pattern individuato nella sezione precedente il tag <span style="font-family: monospace;"><nomi></span> è stato l'unico non definito formalmente. La definizione di tale tag infatti dipende, oltre che dai nomi del nominativo, anche dall'insieme complessivo dei nominativi da trattare presenti nel documento.<div></div>
Il caso più semplice di omonimia, che si verifica quando un solo nome o il solo cognome di un nominativo coincide con un nome o il cognome di un altro (come nel caso di ''Lorenzo Mario Amorosa'' e ''Stefano Amorosa''), risulta già ben gestito dall'attuale formulazione del pattern. Infatti, un riconoscimento è determinato quando almeno un nome e il cognome del nominativo appaiono in sequenza.<div></div>
Il problema si complica quando un nominativo ha due o più componenti in comune con un altro. Si osserva che se l'omonimia riguarda solo i nomi dei nominativi, ciò non risulta problematico, in quanto il cognome, supposto sempre presente nel pattern, funge da elemento di disambiguazione. Si considera da ora, quindi, che i nominativi abbiano il medesimo cognome e si analizzano i casi in cui anche uno o più nomi risultano in comune, attraverso degli esempi:
* Nomi_A = {"Lorenzo", "Mario", "Luca"}; Nomi_B = {"Stefano", "Mario"}
<div></div>(QUI IMG [0F01])<div></div>
In questo caso sono elementi di disambiguazione i nomi ''Lorenzo'' e ''Luca'' per il primo nominativo e ''Stefano'' per il secondo, bisognerà quindi far sì che almeno uno tra tali nomi compaia sempre nelle ''regex'' associate ai nominativi in questione. L'occorrenza ''Mario <cognome>'' rimane ambigua e non può essere trattata.
* Nomi_A = {"Lorenzo", "Mario", "Luca"}; Nomi_B = {"Mario", "Luca"}
<div></div>(QUI IMG [0F02])<div></div>
L'insieme Nomi_B risulta un sottoinsieme di Nomi_A, di conseguenza solo il primo nominativo presenta degli elementi utili per risolvere l'ambiguità. Nel pattern relativo al primo nominativo dovrà essere presente almeno un tra i nomi non in comune, mentre il pattern del secondo nominativo rappresenterà inevitabilmente espressioni ambigue poiché riconducibili all'altro. Le soluzioni possibili sono due: rifiutarsi di effettuare il trattamento del secondo nominativo oppure decretare che esso è riconosciuto se e solo se appare nella sua forma estesa, presentando quindi tutti i nomi. Quest'ultima soluzione è ragionevole e la si sceglie, poiché così si aumentano, per quanto possibile, le sequenze "minimizzabili", e viene inoltre messo in conto di informare l'utente opportunamente sulla gestione di questo genere di omonimia per rendere le operazioni trasparenti.
* Nomi_A = Nomi_B = {"Lorenzo", "Mario", "Luca"}
<div></div>(QUI IMG [0F03])<div></div>
Qualora l'insieme dei nomi dei due nominativi sia identico risulta impossibile distinguerli e non possono in alcun modo essere trattati, poiché l'ordine con cui compaiono i nomi di un nominativo non rappresenta un elemento di disambiguità. I dati appartenenti a persone completamente omonime contenuti in uno stesso documento, quindi, non sono "minimizzabili" distintamente.<div></div>
Si osserva che è di fondamentale importanza che i documenti che gli utenti forniscono siano grammaticalmente corretti, in quanto un errato uso dei segni di interpunzione può rendere impossibile l'applicazione delle ''regular expression''. Si prenda ad esempio una sequenza anomala di caratteri in cui non è corretto l'uso delle virgole, come "''Amorosa Mario Rossi Giacomo''": supponendo che nel documento si vogliano trattare i nominativi ''Amorosa Mario'', ''Rossi Mario'' e ''Rossi Giacomo'', risulta impossibile identificare quali tra questi siano rappresentatati nella sequenza.<div></div>
In conclusione, risultano quindi individuate le strategie che permettono di formulare ''regular expressions'' anche per i nominativi soggetti ad omonimia.

====Formattazione dei documenti====

I documenti prodotti in enti ed organizzazioni presentano generalmente formattazioni e non sono puramente testuali. Si vuole qui considerare quale debbano essere le interpretazioni più adatte da dare agli elementi grafici per rendere sempre efficace il riconoscimento dei nominativi. In particolare, quindi, non si tratteranno gli elementi di punteggiatura, come parentesi o virgolette, poiché già compresi nelle ''regex'', bensì tutti gli elementi che in un pattern composto da caratteri non sono espressi. Si inizia dunque la rassegna:
* Elementi di formattazione del testo
I font, la dimensione dei caratteri, il grassetto, il corsivo, l'evidenziazione e tutti i possibili elementi di modifica della apparizione grafica del testo non alterano il significato dei lessemi coinvolti. Se il cognome di un nominativo è posto in grassetto ed il nome no, ad esempio, la coppia nome-cognome rappresenta sempre il nominativo iniziale; lo stesso vale per gli altri elementi citati.
* Aree di comparizione del testo
In genere ogni documento è formato da più sezioni, ha un corpo principale ed eventuali titoli, note a piè pagina, intestazioni ed altre possibili aree. Il trattamento di "minimizzazione", secondo il ''GDPR'', deve essere effettuato al documento in ogni sua parte, ma ogni sezione deve essere elaborata in maniera indipendente dalle altre sezioni in quanto rappresenta un blocco logico a sé. Ciò significa che, ad esempio, bisogna individuare eventuali nominativi presenti nel titolo, ma non bisogna considerare nominativo una sequenza di parole che è posta in parte nel titolo e in parte nel primo paragrafo del testo.
* Elementi blocco
Gli elementi blocco, come ad esempio le immagini, possono causare un'interruzione netta in un paragrafo, suddividendolo quindi in più blocchi logici, che devono essere analizzati separatamente; tuttavia nel caso in cui questi elementi siano posti ''fluttuanti'', ossia ancorati ai bordi della pagina, il testo scorre in un unico flusso e forma quindi un unico blocco logico.
* Divisione in sillabe
Un problema rilevante nella formattazione del documento è che spesso, per esigenze estetiche, contiene delle parole divise in sillabe poste su righe diverse e separate da un trattino. Ovviamente se un nome va a capo a fine linea non perde il suo significato semantico, bisognerà quindi continuare a riconoscerlo.
* Tabelle
Molti documenti, specialmente quelli contenenti ingenti quantità di nominativi, possono essere strutturati in forma tabellare. Trascurando una trattazione per esteso delle modalità con cui i nominativi potrebbero comparire nelle tabelle, si considera esclusivamente il caso di gran lunga più ricorrente. In genere, infatti, in una tabella contenente dei nominativi, essi sono presenti nella stessa colonna o in colonne contigue: l'una contenente i nomi, l'altra il cognome, o viceversa. Senza basarsi sull'intestazione delle colonne, si può valutare se il contenuto di due celle adiacenti poste su di una stessa riga faccia match con il pattern di un nominativo, ed in caso ciò accada si può affermare la coppia di celle individuata rappresenta un nominativo.<div></div>
Si osserva che si sono fornite solamente le interpretazioni più plausibili e comuni a questi elementi grafici e non si è ideato alcun particolare algoritmo per la loro elaborazione. L'espressione di tali strutture, infatti, è fortemente determinata dal formato in cui il documento è redatto. Si rimanda, quindi, ai capitoli successivi per specificazioni ulteriori della soluzione. Occorre notare, infine, che gli elementi di formattazione non sono descritti da stringhe nel formato delle ''regular expressions'': bisognerà quindi integrare gli elementi presentati in questa sezione con l'approccio ''pattern-based'' adottato.

===Analisi dell'usabilità===

====Elenco dei nominativi da trattare esplicitamente espressi come dati in input====

In questo caso, per usufruire del servizio, l'utente deve fornire un documento contenente una serie di nominativi da trattare. Una garanzia della corretta elaborazione del documento si ha richiedendo all'utente stesso quali siano i nominativi da trattare: in questo modo potranno essere "minimizzati" i dati (cioè i nominativi) di tutte e sole le persone espressamente richieste. In molti plausibili scenari, infatti, è necessario anonimizzare solo alcuni dei nominativi presenti nel documento; ad esempio in un atto giudiziario serve anonimizzare le parti in causa ma non i magistrati.

Questa configurazione del servizio permette quindi all'utente di avere il massimo controllo possibile del risultato. Tuttavia questo approccio è poco pratico nel caso in cui i documenti da trattare contengano grandi quantità di nominativi diversi e, magari, l'utente che ne richiede il trattamento non li conosce; si pensi ad esempio a lunghe graduatorie di concorsi o altro. Si osserva inoltre che anche per pochi nominativi l'usabilità può degradare, se l'inserimento viene fatto con estemporanea digitazione, esposta anche al rischio di possibili errori di battitura, con conseguenti noiose ripetizioni delle operazioni.

Si osserva, infine, che il sistema progettato è sufficientemente robusto nel trattare i nominativi in input espressi da un utente che ha digitato caratteri maiuscoli o minuscoli violando le convenzioni grammaticali. Supposto che il documento trattato debba essere grammaticalmente corretto, infatti, si ha la garanzia che i nomi ivi presenti comincino con una maiuscola; è sufficiente, quindi, forzare una conversione ''to-upper-case'' dei nomi inseriti dall'utente e le ''regex'' progettate funzionano correttamente. Un discorso a parte va fatto per i cognomi inseriti dall'utente, in quanto essi possono comparire con la prima lettera sia maiuscola che minuscola. L'inserimento di un cognome iniziante con una minuscola non crea grossi problemi, in quanto in tal caso la ''regex'' risultante sarebbe totalmente ''case-insensitive'' per il cognome, mentre l'aggiunta di un cognome cominciante con una maiuscola determina una ''regex'' ''case-insensitive'' per la prima lettera del cognome; qualora quindi un utente inserisse un nominativo tutto in maiuscolo, le occorrenze del cognome, presenti nel documento, inizianti con una lettera minuscola non verrebbero riconosciute.
Per le altre lettere dopo la prima, sia per i nomi che per i cognomi, il pattern è stato progettato ''case-insensitive'', quindi non emergono problemi. <div></div>
In sintesi, il rischio che vengano introdotte delle ambiguità lessicali, incaricando l'utente dell'inserimento dei nominativi, è piuttosto basso ed il controllo che si ha sui nominativi è il massimo desiderabile, mentre i requisiti di usabilità risultano penalizzati.

====Elenco dei nominativi da trattare dedotti automaticamente da un dizionario====

Se si desidera privilegiare la tematica dell'usabilità nella progettazione del servizio, risulta necessario individuare delle strategie che semplifichino il più possibile i compiti che devono essere svolti dall'utente. L'unica operazione che inevitabilmente resta a suo carico è l'upload del documento da trattare; non è infatti necessario richiedergli l'elencazione dei nominativi dei nominativi da trattare, in quanto questi possono essere dedotti automaticamente impiegando dei dizionari, dei quali va quindi valutato il contenuto e le modalità di utilizzo. <div></div>

Si scarta subito l'ipotesi di dedurre automaticamente i nominativi basandosi unicamente sul fatto che le iniziali di nomi e cognomi siano maiuscole; come già argomentato infatti l'uso delle lettere maiuscole non è limitato solo a questi usi e, inoltre, non si può avere la certezza che un cognome inizi con una maiuscola.

Sono disponibili fortunatamente alcuni dizionari di nomi ed altri di cognomi, in diverse lingue; si fa qui riferimento a quelli di "Data World" (un'azienda focalizzata sulla raccolta, produzione e pubblicazione di dataset: https://data.world) ([0037]).

Si inizia l'analisi inquadrando le dimensioni che un dizionario contenente nomi o cognomi avrebbe. Risalta subito all'occhio la differenza tra il numero di termini contenuti nei due casi: facendo riferimento ai soli nomi e cognomi italiani, risultano esistenti circa 350.000 cognomi ([0036]) e circa 9.000 nomi, dei quale circa 5.000 maschili e circa 4.000 femminili ([0037]); il numero dei cognomi è quindi quasi 40 volte più grande del numero dei nomi.<div></div>
Si ipotizza, per chiarire le idee, di applicare questi dizionari in uno scenario reale, in cui, ad esempio, si vuole trattare un documento di 10 pagine contenente 5.000 parole. Si trascurano inoltre i meccanismi che permettono di ricondurre un nome od un cognome ad un nominativo per concentrarsi unicamente sul numero di confronti necessari da effettuare nell'elaborazione. Nel peggiore dei casi possibili, ossia quando nessuna parola del documento compare tra i termini del dizionari, e dove occorre quindi confrontare ogni singola parola del documento con tutti i termini del dizionario, per semplice moltiplicazione si ottiene che l'impiego di un dizionario di nomi darebbe luogo a 45.000.000 confronti, mentre un dizionario di cognomi ben a 1.750.000.000 confronti. Se invece le parole nel documento fossero 50.000 si avrebbero 450.000.000 di confronti nel primo caso e 10.750.000.000 nel secondo. In sintesi, sebbene il rapporto tra il numero di confronti nei due casi rimanga sempre costante (circa 1:40) indipendentemente dalla lunghezza del documento, la differenza tra il numero di confronti cresce proporzionalmente al numero di parole che vengono sottoposte all'elaborazione. Per quantificare, infine, attraverso un unità di tempo, la differenza esistente tra l'impiego delle due diverse tipologie di dizionario, si realizza un semplice programma java, di cui si riporta qui sotto il contenuto del metodo principale, che realizza i confronti necessari attraverso l'uso di ''regular expression'':
<div></div>
<div style="font-family: monospace;">
final String regex = "\bLorenzo\b";<br/>
final String string = ... //testo di prova<br/>
<br/>
final Pattern pattern = Pattern.compile(regex, Pattern.MULTILINE);<br/>
final Matcher matcher = pattern.matcher(string);<br/>
int start, total;
<br/>
start = System.currentTimeMillis();
while (matcher.find()) {
System.out.println("Full match: " + matcher.group(0));
for (int i = 1; i <= matcher.groupCount(); i++) {
System.out.println("Group " + i + ": " + matcher.group(i));
}
} <br/>
total = System.currentTimeMillis() - start;
System.out.println("Total: " + total + " ms");
</div>
<div></div>
Eseguendo il test più volte, inserendo fino a 10 occorrenze della parola "Lorenzo" nel testo, si ha un tempo di elaborazione medio di circa 3 ms, con prestazioni di picco di 2 ms, ottenibili con poche occorrenze del nome presenti, e tempo di attesa massimo di 6 ms, dovuto alla presenza invece a una presenza più frequente del nome nel testo.
Questo fenomeno si comprende meglio ricordando che, come spiegato nel capitolo precedente, le ''regular expressions'' ottimizzano la ricerca, considerano le stringhe del testo trattato solo finché necessario, ossia fino a quando non vi è certezza che esse corrispondano o non corrispondano ad un match. Ogni volta che nel testo si presenta una parola che inizia con una lettera diversa dalla 'L' di "Lorenzo", la ricerca procede direttamente con la valutazione della parola successiva, ignorando i rimanenti caratteri della parola.

Risulta, invece, più onerosa la verifica della corrispondenza tra una stringa ed il pattern desiderato, poiché in questo caso vanno elaborati tutti i caratteri della parola. Come caso limite, si è posta come stringa da elaborare la sequenza di caratteri "Lorenzo " ripetuta 500 volte: il tempo di esecuzione medio del programma risultante, a parità di piattaforma, è stato di circa 25 ms.

Un'altra diretta conseguenza di questo meccanismo di confronto è che all'aumentare del numero di parole nel documento non corrisponde un eccessivo aumento del tempo di esecuzione: considerando un documento di 5000 parole, con 0 occorrenze del nome "Lorenzo" il tempo di esecuzione medio risulta di 9 ms, con 10 occorrenze di 10 ms, con 100 occorrenze di 15 ms.

Occorre precisare, prima di formulare ulteriori ragionamenti, che in documento di 5.000 parole potranno essere presenti al più 2500 coppie nome-cognome; in un dizionario con più di 2.500 termini almeno uno di questi non contribuirà nell'individuazione di un nominativo. Se poi sono presenti altre parole oltre ai nominativi nel documento, la percentuale di nomi che presenterà 0 occorrenze crescerà di conseguenza. Ad ogni modo, si sceglie di sviluppare i ragionamenti considerando necessario il tempo medio di 10 ms per individuare le occorrenze di un termine di un dizionario in un documento di 5.000 parole; questo tempo è sicuramente maggiore rispetto al caso reale, ma valutando per eccesso questo valore è possibile trascurare il tempo impiegato nelle altre operazioni di routine a supporto dell'algoritmo di ricerca.

Ritornando all'esempio di partenza, considerando quindi necessari 10 ms per individuare le occorrenze di un termine di un dizionario in un documento di 5.000 parole, risulta che l'identificazione di tutti i cognomi contenuti nel testo richieda circa 3.500 secondi, (quasi un'ora!), mentre l'individuazione dei nomi "solo" 90 secondi.
I tempi di attesa che l'utente dovrebbe aspettare sono estremamente elevati e irragionevoli, specialmente se calati nel contesto nelle ''web application''. Come primo espediente per ovviare al problema si decide di abbandonare completamente l'idea di impiegare un dizionario di cognomi, in quanto, seppur si individuassero delle soluzioni in grado di effettuare il riconoscimento di tutte le occorrenze di un termine in un documento indipendentemente dalla lunghezza in solo 1 ms (irreale), sarebbero comunque necessari 3 minuti e 50 secondi per l'elaborazione. Non verranno quindi neppure trattate possibili soluzioni che prevedono l'applicazione di entrambi i dizionari.

I 90 secondi richiesti dal dizionario di nomi, invece, risultano anch'essi eccessivi, ma attraverso opportune valutazioni si possono individuare delle strategie che consentono la minimizzazione del tempo necessario all'elaborazione dei documenti. Tali metodi di ottimizzazione saranno trattati in un successivo capitolo, mentre ora ci si continua a concentrare sulle modalità di impiego del dizionario.

Per inciso, si osserva che i problemi di efficienza sono strettamente legati al riconoscimento automatico dei nominativi, in quanto in questo caso devono essere applicate quasi una decina di migliaia di ''regex'' diverse; nel caso in cui i nominativi da elaborare e le ''regex'' a loro associate siano noti, si ha a che fare con un numero esiguo di pattern da trattare e l'esecuzione del programma risulta infinitamente più rapida.<div></div>

Per migliorare l'efficacia del servizio sarebbe opportuno introdurre nel dizionario anche nomi stranieri, sempre più diffusi in una società sempre più globalizzata. Il tempo di esecuzione medio del riconoscimento, già critico, crescerebbe ulteriormente: si decide allora di introdurre nel dizionario i soli nomi inglesi, in totale quasi 5500 ([0037]). Considerando sempre un tempo medio di esecuzione di 10 ms per nome, con un dizionario di circa 14.500 termini si avrebbe un tempo di esecuzione medio complessivo di 145 secondi, ossia pari a 2 minuti e 25 secondi, e risulta ancora possibile effettuare alcune ottimizzazioni che lo riducono ad un livello accettabile.

Una volta individuati i nomi contenuti nel documento occorre stabilire se essi fanno parte di un nominativo, progettando un'opportuna ''regular expression''. È importante notare che per conseguire questo scopo bisogna individuare la soluzione più efficiente possibile.

Un nominativo, come già ripetuto più volte, è composto da uno o più nomi e da un cognome. Individuato un nome, la priorità che si ha è verificare se accanto ad esso sia presente un cognome. Finora i cognomi sono stati supposti non regolamentati da alcun pattern specifico, ma è necessario formularne almeno uno per consentirne il riconoscimento automatico. È ragionevole supporre che un cognome sia formato da massimo due parole, separate da spazio o apostrofo, sempre inizianti entrambe con una maiuscola, fatta eccezione per la prima parola laddove essa sia una preposizione semplice o articolata oppure un articolo, tenendo conto dei possibili troncamenti, come <i>d'</i> e <i>dell'</i>. Inoltre per verificare se un termine adiacente al nome trovato rappresenti un nome si evita di impiegare nuovamente il dizionario per non gravare ulteriormente sul tempo di esecuzione. Inoltre, si nota che avendo supposto un cognome composto da massimo due parole inizianti con una lettera maiuscola, un altro nome, oltre quello trovato dal dizionario, viene già automaticamente riconosciuto qualora il cognome sia composto da una sola parola. Rinunciando ad individuare nominativi composti da tre nomi o più, si formula una ''regular expression'' per il riconoscimento automatico in seguito al identificazione di un nome, qui indicato con il tag <span style="font-family: monospace;"><nome></span>, supponendo il cognome come precedentemente indicato e ipotizzando la presenza di un ulteriore nominativo.
<div></div>
<div style="font-family: monospace;">
<prep> := d((a|e)(l(l[aeo]?)?|i|gli?)?|i)?|(ne|a|su)(l(l[aeo]?)?|i|gli)?|l[aeo]?|co[iln]?|i[ln]?|gli|per

<cognome> := (([A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]*|<prep>)('|\s))?[A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]+

<second_name> := [A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]+

<regex> := (<second_name>\s)?(<nome>)\s<cognome>|<cognome>\s(<nome>)(\s<second_name>)?
</div>
<div></div>
Nella scrittura della ''regex'' si è prestata particolare attenzione all'utilizzo della simbologia per rendere l'espressione il più performante possibile, attraverso il massimo sfruttamento dei cortocircuiti logici e l'opportuno ordinamento dei caratteri (sono stati anteposti i caratteri comuni a più preposizioni od articoli). Inoltre, per alleggerire la ''regex'' si è rinunciato all'utilizzo dei caratteri dell'alfabeto latino non appartenenti ai primi due blocchi Unicode.
<div></div>
È mostrata in figura la corretta elaborazione di 57 possibili casi di cognomi diversi
<div></div>(QUI IMG [0F04])<div></div>
Si osserva tuttavia che in alcune circostanze, come nella frase "''di Amorosa Lorenzo non si hanno notizie''", accade che un parola ("''di''" in questo caso), non sia parte del cognome ma il programma non è in grado di riconoscerlo. Questa ambiguità è fortemente dipendente dal contesto e non è possibile trattarla senza significativi degradi delle performance; quindi è necessario rinunciare a trattarla, accettando riconoscimenti erronei. In altre situazioni, invece, dove magari si sta elaborando la stringa contenente il nominativo ''Mario Lorenzo'', risulta impossibile determinare quale tra i due termini sia il nome e quale il cognome; cioè significa che l'unico trattamento di "minimizzazione" automatico che risulta ragionevole applicare è la sostituzione del nominativo con uno pseudonimo, non il troncamento o l'alterazione dei nomi.
In conclusione, con il riconoscimento automatico dei nominativi si migliora complessivamente l'usabilità del servizio, in quanto l'utente non deve digitare i nominativi, ma la latenza introdotta è notevole, si è soggetti a rischi di ambiguità e non è in alcun modo esprimibile la preferenza su quali nominativi si desidera "minimizzare" o meno. La soluzione così ideata non risulta quindi adeguata.

====Soluzione ibrida adottata====
Entrambe le tipologie di riconoscimento prima individuate hanno significativi problemi, si cerca quindi di sintetizzare una soluzione in grado di trarre i vantaggi dell'una e dell'altra. Risulta efficace, in particolare, che il documento venga inizialmente trattato tramite dizionari, evitando all'utente l'onere di specificare i nominativi, e che in seguito venga lasciata all'utente la possibilità di intervenire.
Infatti, esso potrebbe voler esprimere delle preferenze su quali nominativi debbano essere trattati tra quelli individuati e gestire gli eventuali errori di riconoscimento dovuti a richieste di trattamento di nominativi aventi un nome non presente nel dizionario o anche dovuti a casi di ambiguità lessicale già presentati.

Una volta inserito il documento e terminata l'elaborazione tramite il dizionario, l'utente può sia richiedere l'immediato download del file ed effettuare le operazioni prima definite, attraverso un'opportuna interfaccia. Per fornire il supporto alle esigenze più disparate, si prevede la possibilità di:
# eseguire download del file trattato unicamente con il dizionario
# ripetere la "minimizzazione" del documento, specificando:
## nuovi nominativi
## quali nominativi tra quelli precedentemente individuati ''non'' si vogliono trattare
## quale parola/e dei nominativi individuati rappresenta il cognome (in tal caso, si possono utilizzare altri metodi, oltre alla sostituzione con pseudonimo, per il trattamento)
## quale parola/e dei nominativi individuati non compone il nominativo (situazione che si verifica quando ci si imbatte in una ambiguità).

Senza soffermarsi in questo momento sull'intera sequenza concreta di interazioni tra utente e servizio, si osserva che l'unico vincolo non funzionale da valutare resta il tempo medio di attesa dell'utente. L'usabilità complessiva è molto buona ed i vincoli funzionali sono soddisfatti.

===Scelta dei formati da trattare===

Una considerazione intuitiva, ed una buona prassi, è che un documento contenente dati personali sia pseudonimizzato o anonimizzato quanto prima possibile e cioè quando è ancora solo nelle mani del suo autore: questo approccio scongiura che informazioni sensibili e dati personali in chiaro ''sfuggano'' in rete.
Si può per questo ragionevolmente ipotizzare che i naturali destinatari del servizio siano gli stessi autori (creatori) che redigono il documento. Nello scenario tipico di utilizzo, infatti, il fruitore del servizio procederà al trattamento dei dati non appena avrà finito di scrivere il documento del quale, essendone autore, potrà scegliere il formato. Si osserva che potrebbe accadere che il documento sia redatto da terzi: in tal caso l'utente che richiede il trattamento può scegliere il formato in maniera indiretta concordandolo con il redattore. Avendo quindi l'utente la possibilità di stabilire il formato del proprio documento, risulta ragionevole progettare un servizio che lavori su un solo formato.
A questo punto occorre individuare quale sia il formato che maggiormente si presta alle finalità del servizio.<div></div>
Una possibilità è quella di richiedere all'utente di inserire come documento da trattare un semplice file di testo in formato ''txt'': in questo modo ci sarebbe il grande vantaggio di trattare file molto semplici, riducendo così al minimo la complessità realizzativa, e inoltre si avrebbe l'indipendenza dagli editor di testo utilizzati, in quanto tutti supportano i file in formato ''txt''.
Risulta tuttavia sconveniente utilizzare questo formato, poiché non ha alcuna capacità espressiva per gestire elementi complessi come tabelle, modifiche allo stile del testo e così via.
Bisogna quindi optare per un formato in grado di gestire questi elementi, al costo di aumentare la complessità della progettazione, ricordando sempre che è necessario allo stesso tempo che tale formato sia supportato da tutti i principali editor di testo.<div></div>
Con facilità è possibile individuare quali sono i formati di testo più comuni oltre al ''txt'': ''doc'', ''docx'', ''odt'', ''pdf'', ''pages'', ''rtf'', ''tex''. Si passa ora dunque a valutare quale tra questi formati potrebbe meglio soddisfare i requisiti prima enunciati.
Facendo una cernita iniziale sulla base delle finalità per le quali un formato è utilizzato, si può immediatamente escludere ''tex'', che trova impiego principalmente in ambito scientifico e matematico. In questo settore, infatti, non è richiesta generalmente l'applicazione delle procedura di trattamento dei dati. <div></div>
Si può inoltre abbandonare l'idea di trattare documenti con estensione ''pages'', formato proprietario di Apple, poiché utilizzati esclusivamente dall'omonimo editor di testo anch'esso proprietario, e i documenti con estensione ''rtf'', acronimo di ''Rich Text Format'', formato proprietario di Microsoft che supporta una formattazione avanzata, poiché, pur gestito da vari editor, è un formato decisamente datato (ultima versione 1.9.1 risalente a marzo 2008 ([0009])). <div></div>
Si esclude inoltre il formato ''pdf'' per motivi di usabilità: molti editor, infatti, consentono di esportare un documento in questo formato ma non permettono di importarlo. Un utente dopo aver effettuato l'anonimizzazione di un documento non può quindi proseguire modificandolo ulteriormente. Il ''Portable Document Format'', infatti, è ideato per realizzare dei documenti destinati alla sola lettura.
L'ultima esclusione, piuttosto immediata da effettuare, riguarda il formato ''doc'', binario e proprietario di Microsoft. Esso infatti risulta, a partire dal 2006, soppiantato dal formato ''docx'', sempre proprietario di Microsoft.

Si giunge infine a valutare quale tra gli ultimi due possibili formati rimanenti, ossia ''docx'' e ''odt'', si presta meglio alle finalità del servizio. In via preliminare si osserva che entrambi i formati possiedono ottime capacità espressive, hanno una struttura interna di simile complessità e sono entrambi supportati dai principali editor di testo. È necessario quindi effettuare delle analisi più approfondite per poter sceglierne uno tra i due.
La struttura del formato ''docx'', sviluppato da Microsoft e formalmente denominato ''Office Open XML Document (OOXML Document)'', è costituita da un file compresso .zip contenente un insieme di file ''XML''. Il formato ''OOXML'' permette la rappresentazione, oltre che di documenti testuali, anche di fogli elettronici (formato ''OOXML 'Workbook'', noto anche come ''xslx'') e di presentazioni (formato ''OOXML Presentation'', noto anche come ''pptx'') ([0008], [0013]).
Il formato inoltre è stato inizialmente standardizzato nel 2006 dall'<i>ECMA</i> (come ''ECMA-376'') e successivamente nel 2008 dall'<i>ISO</i> e dall'<i>IEC</i> (come ''ISO/IEC 29500'') in una versione ''transitional'', retrocompatibile con alcune versioni precedenti del formato contenenti elementi deprecati, e in una versione ''strict'', dove tali elementi non sono ammessi. I due standard sono stati poi successivamente aggiornati e sono tutt'ora oggetto di revisioni ([0002]).

Anche la struttura del formato open source ''odt'', sviluppato dall'<i>OASIS</i> e formalmente denominato ''OpenDocument Text'', è basata su uno zip contenente un insieme di file ''XML''. Inoltre, il formato ''OpenDocument Format (ODF)'' permette di trattare fogli elettronici (formato ''OpenDocument Spreadsheet'', noto anche come ''ods'') e presentazioni (formato ''OpenDocument Presentation'', noto anche come ''odp'') ([0007]). Anche ''OpenDocument Text'' è stato standardizzato, in particolare dall'<i>OASIS</i> stesso nel 2005 e dall'<i>ISO/IEC</i> nel 2006, ed è soggetto a revisioni e aggiornamenti ([0003]).

In sintesi, basandosi sulla struttura dei documenti e sulla standardizzazione dei formati, non è ancora possibile individuare quale sia il formato migliore. L'unico elemento che potrebbe portare punti a favore del formato ''odt'' è che esso, a differenza del formato ''docx'', è aperto, tuttavia, essendo le specifiche di entrambi i formati pubbliche, ciò non rappresenta un fattore determinante nell'elezione del formato.
Entrambi i formati, inoltre, sono largamente supportati dai word processors.

Le seguenti tabelle riepilogano il supporto all'uno ed all'altro formato dei ''word-processors'' più usati, ossia ''Microsoft Office Word'', ''LibreOffice Writer'', ''OpenOffice Writer'' e ''Pages''.
Le tabelle sono tratte da wikipedia ([0000], [0001], [0006]). <div></div>

<center><i>Supporto fornito dagli editor di testo al formato docx</i></center>
{| class="wikitable"
|-
! !! Microsoft Office Word !! LibreOffice Writer !! OpenOffice Writer !! Pages
|-
! Version
|| 2013, 2011 for Mac || All versions || 3.0 || '08
|-
! Operating systems
|| Windows, Mac OS X || Windows, OS X, Linux, Unix, Android || Windows, Linux, Unix, Mac OS X || Mac OS X
|-
! Office suite
|| Microsoft Office || || OpenOffice.org || iWork
|-
! Developer
|| Microsoft || The Document Foundation || Apache OpenOffice || Apple Inc.
|-
! License
|| proprietary || MPL || LGPL || proprietary
|-
! ECMA-376
|| yes || yes || yes || yes
|-
! ISO/IEC 29500:2008
|| yes || yes || ||
|-
! Notes
|| || || Import only ||
|}

<div></div>
<center><i>Supporto fornito dagli editor di testo al formato odt</i></center>
{| class="wikitable"
|-
! !! Microsoft Office Word !! LibreOffice Writer !! OpenOffice Writer
|-
! Version
|| 2007 SP2 || 4.0.3 || 3.0.0
|-
! Operating systems
|| Windows || Unix-based systems, Mac OS X, Solaris || Windows, Linux, Unix-based systems, Mac OS X, Solaris
|-
! Office suite
|| Microsoft Office || || OpenOffice.org
|-
! Developer
|| Microsoft || The Document Foundation || Apache OpenOffice
|-
! License
|| Proprietary || MPL || LGPL
|-
! ISO/IEC 26300:2006
|| yes || yes || yes
|-
! Notes
|| some limitations || Multiple ODF versions supported (ISO/ODF 1.0/1.1/1.2/1.2 Extended) || adjustable ODF version (ISO/ODF 1.2)
|}
<div></div>

Si possono effettuare le seguenti osservazioni:
* ''Microsoft Office Word'' è, in ambiente Microsoft, il word processor maggiormente usato; è molto usato anche in ambiente Apple Mac. Esso offre il pieno supporto al formato ''OOXML Document''; solo parzialmente invece gestisce il formato ''OpenDocument Text'': il processamento di file con estensione ''odt'' con questo editor comporta la perdita di alcune informazioni secondarie.
* ''LibreOffice Writer'', l'editor open source maggiormente utilizzato, supporta pienamente entrambi formati. Nato con lo scopo di gestire i file con formato ''OpenDocument Text'', attualmente supporta completamente anche il formato ''OOXML Document''.
* ''OpenOffice Writer'', un altro degli editor di testo tra i più utilizzati, supporta pienamente ''odt'', mentre è solo in grado di importare i file con estensione ''docx''.
* ''Pages'', il word process installato a default sui Mac della Apple e, di conseguenza anche maggiormente usato su questi dispositivi, non offre supporto al formato ''odt'', ma elabora correttamente i documenti con estensione ''docx'' ([0005],[0004]). <div></div>
Queste osservazioni evidenziano che quindi è impossibile adottare un formato supportato da tutti gli editor; la scelta va allora indirizzata verso quello maggiormente supportato dai word processor più popolari.
Per avere un'indicazione di ''popolarità'', e quindi per poter comprendere meglio quali tra gli editor prima citati siano i più usati, si può fare un'analisi, tramite motori di ricerca, di quanti file con una certa estensione siano presenti in rete.
È possibile, ad esempio, ricercare su Google i file che contengono nel proprio nome una determinata sequenza di caratteri o aventi una certa estensione (''filetype''). Sono qui presentati i risultati delle interrogazioni riguardo ai file aventi formato ''docx'', ''doc'' e ''odt'' ed il cui nome contiene uno dei caratteri, fra i più frequenti, "1" o "a" o "e". L'investigazione è stata effettuata inserendo nella barra di ricerca di Google le stringhe ''1 filetype:docx'', ''a filetype:docx'' e così via.

{| class="wikitable"
|-
! Formato cercato !! Documenti con "1" nel nome !! Documenti con "a" nel nome !! Documenti con "e" nel nome
|-
| docx || 16.900.000 || 12.800.000 || 8.730.000
|-
| odt || 736.000 || 667.000 || 507.000
|-
| doc || 32.300.000 || 26.300.000 || 21.500.000
|}

Effettivamente il formato più diffuso è il ''doc''; tuttavia esso è supportato per retro-compatibilità anche dagli editor che supportano formati ''OOXML'', con i quali non si ha difficoltà nel convertire i documenti dal formato ''doc'' al ''docx''. In conclusione, quale che sia l'editor più diffuso, è ragionevole adottare il formato ''OOXML Document'' per le finalità del servizio, in quanto molto diffuso, ben supportato dagli editor e avente ottime capacità espressive. Di conseguenza i documenti che saranno elaborati dovranno essere forniti dall'utente in tale formato. In successive sezioni verrà approfondita la struttura dei documenti ''OOXML''.

===Privacy by design===

L'Art. 25 del ''GDPR'', con i Considerando 75 e 78, ha per titolo e per oggetto la "protezione dei dati fin dalla progettazione e protezione per impostazione predefinita" ([0035]), perfettamente in linea con i concetti di "minimizzazione", già richiamati.<div></div>
Il senso dell'Art. 25 viene spesso sintetizzato con l'espressione "''PbD - privacy by design, privacy by default''" ([0035]). Il principio fissato nell'Art. 25 dovrà sempre più essere tenuto ben presente nell'ambito dell'ingegneria del software, in quanto impone di adottare nuove cautele nella realizzazione delle applicazioni software.<div></div>
Del principio ''PbD'' si è ben tenuto conto nella progettazione descritta in questa tesi. In particolare, relativamente alla ''privacy by design'', si è fatto in modo che nessun dato personale permanga registrato sul sistema di esecuzione, o altrove, al termine dell'applicazione. Anche laddove l'applicazione termini in modo anomale non vi sono strutture dati superstiti, che restano memorizzate sul sistema.<div></div>
Marginale in questa tesi è la nozione di ''privacy by default'', giacché l'applicazione non offre all'utente alcuna opzione che possa indurlo in errore ed acconsentire a trattamenti dei dati personali, oltre quello realizzato dall'applicazione.<div></div>
È utile osservare quanto sia importante esprimere queste impostazioni di progettazione fra le condizioni d'uso presentate all'utente: esse costituiscono uno dei presupposti affinché l'utente abbia piena fiducia (''trust'') nel servizio, lo utilizzi, lo divulghi, lo renda un servizio di successo.

==Architettura del servizio==

===I componenti software nell'architettura LAMP===

Il servizio è realizzato in forma di ''web-based application'' poiché, come già illustrato nell'introduzione, si intende renderlo disponibile per il massimo numero di utenti possibili. Nella progettazione e realizzazione dell'architettura web si adotta la piattaforma ''LAMP'', il cui nome deriva dall'acronimo dei componenti open source che la realizzano (il sistema operativo Linux, il server HTTP Apache, il sistema per la gestione di database relazionali MySQL ed il linguaggio di programmazione PHP). Poichè il modello è composto da quattro livelli, spesso si parla anche di ''stack LAMP''. Uno degli elementi di forza del modello ''LAMP'' è che i componenti dei vari ''layer'' sono sostituibili, a seconda delle esigenze, con dei componenti più adatti, tipicamente open source ([0015], [0018], [0019]). Basando la piattaforma su un sistema operativo della famiglia di Microsoft Windows, ad esempio, si ottiene uno ''stack WAMP'', mentre se si usa un sistema operativo Mac OS si realizza uno ''stack MAMP''. Un'architettura web basata sul modello ''LAMP'' può, inoltre, essere integrata con software open source che offre utili funzionalità, come, ad esempio, il monitoraggio (''Nagios''), il load balancing (''Linux Virtual Server''), la rilevazione di accessi illeciti (''Snort'') e il security testing (''netsniff-ng''). <div></div>
Si valutano ora brevemente la diffusione dei componenti tradizionali dello ''stack LAMP'' e le alternative maggiormente usate per i vari ''layer''.
Le distribuzioni Linux risultano essere la scelta più comune per l'ultimo ''layer'' dello ''stack''. Secondo W3Techs, infatti, nell'ottobre del 2013, il 58.5% dei web server a livello globale avevano come sistema operativo la distribuzione Debian o Ubuntu, mentre il 37.3% una tra RHEL, Fedora e CentOS([0016]). <div></div>
Tra i web server, Apache risulta essere maggiormente usato. Secondo le stime fatte da Netcraft, a giugno del 2014 circa il 51.9% del milione di siti web più trafficati al mondo usavano un web server Apache, il 19.2% nginx ed il 12.4% Microsoft ([0017]). <div></div>
I principali ''DBMS'' relazionali, oltre a MySQL, che possono essere presenti nello ''stack LAMP'' sono MariaDB e PostgreSQL, mentre tra i ''DBMS NoSQL'' MongoDB risulta essere il più comune. <div></div>
Nello stack, infine, il ruolo di linguaggio di programmazione, solitamente svolto dal linguaggio PHP, spesso è ricoperto dai linguaggi Perl o Python. <div></div>
Si osserva, ad ogni modo, che le informazioni sulla diffusione delle tecnologie non rappresentano un fattore vincolante nella scelta delle stesse, in quanto la piattaforma ''LAMP'' è anche aperta verso molti altri componenti oltre quelli citati; di conseguenza la scelta delle tecnologie da impiegare può essere effettuata basandosi principalmente sui requisiti e sulle specifiche del servizio. <div></div>

===Principi di progettazione per l'architettura===

====Single Responsibility Principle====

Per rendere il servizio maggiormente manutenibile ed estensibile, si presta particolare attenzione al rispetto del ''Single Responsibility Principle'' (''SRP'') ([0020]). Si cerca, quindi, di fattorizzare il software in più moduli, suddividendo tra questi le elaborazioni da svolgere. Un altro importante beneficio che si ottiene dalla fattorizzazione del codice è la riusabilità dei componenti. Ogni singolo modulo, infatti, svolge il proprio compito in maniera indipendente dal resto della applicazione ed è, quindi, riutilizzabile in altri scenari simili senza dover essere re-implementato. Inquadrando meglio questa metodologia di progettazione con i requisiti del servizio e la piattaforma web ''LAMP'', si individuano i due principali compiti a carico dell'applicazione:
* La gestione dell'interazione web con l'utente per la trasmissione del documento e dei nominativi da trattare
* Il processamento del documento per effettuare la "minimizzazione" dei dati.
Questi due differenti ''task'' saranno, quindi, portate a termine da componenti diversi.<div></div>
Progettando la struttura dell'applicazione in questo modo, si disaccoppia completamente la logica di business del servizio dalle interfacce web di comunicazione con l'utente. In un futuro sviluppo sarà possibile, quindi, realizzare nuove interfacce utilizzando altre tecnologie senza dover modificare la logica applicativa.

====Dependency Inversion Principle====

Un altro principio di design architetturale che risulta importante nella progettazione è il ''Dependency Inversion Principle'' (''DIP'') ([0038]). Esso si traduce nella realizzazione di componenti che non dipendono dalle specifiche implementazioni degli altri moduli del sistema, bensì dalle loro ''astrazioni''.
In relazione all'estensibilità e manutenibilità del prodotto software, infatti, l'impiego di moduli dipendenti direttamente dalla definizione dei metodi presenti in altri componenti risulta problematica: il modulo dipendente deve essere re-implementato ad ogni variazione del modulo da cui dipende.
Nella programmazione orientata agli oggetti, per rispettare questo principio, si su può fare uso di classi astratte o interfacce, costrutti che definiscono i moduli senza implementarli completamente o senza implementarli affatto.

===Stile architetturale REST===

Il modello architetturale del servizio che si sta definendo presenta una serie di caratteristiche, come ad esempio l'indipendenza dei moduli, che permettono di realizzarlo secondo il paradigma delle ''RESTful API''. L'espressione "Representational State Transfer" e il suo acronimo "REST" furono introdotti nel 2000 nella tesi di dottorato di Roy Fielding ([0021]), uno dei principali autori delle specifiche dell'Hypertext Transfer Protocol (HTTP). Roy Fielding descrive il ''Representational State Transfer'' come uno stile architetturale ("''architectural style''"), ovvero un'astrazione degli elementi di un'architettura all'interno di un sistema hypermedia distribuito. ''REST'' non specifica i dettagli dell'implementazione dei componenti e della sintassi del protocollo, ma definisce i ruoli dei componenti, i vincoli sulla loro modalità di interazione e la loro interpretazione.
Riassumiamo quindi i principi che deve rispettare una architettura ''REST'':
# Architettura Client-Server <br/>In una architettura ''REST'' viene data particolare importanza ai principi ''SRP'' e ''DIP'' prima citati, più generale si può affermare che l'architettura sposi il paradigma noto con il termine di "''Separation of Concerns''". Una ''Restful API'' applica questi principi in un architettura Client-Server, capace di supportare l'evoluzione indipendente della logica lato client e della logica lato server.
# Stateless <br/>La comunicazione tra utente e fornitore del servizio deve essere senza stato, quindi ogni richiesta del client deve contenere tutte le informazioni di cui il fornitore necessita per l'erogazione del servizio offerto. Questa ipotesi viene fatta per rendere una ''Restful API'' facilmente scalabile orizzontalmente.
# Uso della cache <br/>In un Architettura ''REST'' i messaggi di risposta inviati dal server devono esplicitamente indicare se possono essere memorizzati nella cache del client o di componenti middleware per il riutilizzo nelle richieste successive.
# Interfaccia uniforme <br/>I componenti devono essere in grado di comunicare attraverso un'interfaccia uniforme e le risorse devono essere trasferite in un formato standard. Inoltre l'utente deve poter effettuare la navigazione tra le risorse di suo interesse tramite collegamenti ipertestuali. Per inciso, si osserva che il protocollo HTTP usato correttamente rispetta i requisiti di un architettura ''REST'' e che nelle implementazioni delle ''RESTful API'' il formato più usato per la modellazione dei dati è JSON.
# Layered System <br/>In un sistema a livelli, componenti intermedi (come i proxy) possono essere collocati tra client e server per intercettare il traffico per scopi specifici; ad esempio il caching o la sicurezza. Una soluzione basata su ''REST'' può essere composta da più livelli architettonici, indipendenti l'uno dall'altro.
# Code on Demand <br/>Questo vincolo facoltativo è inteso principalmente a consentire aggiornamenti alla logica all'interno dei client (come i browser Web) indipendentemente dalla logica lato server. Una ''single page application'', ad esempio, rispetta in pieno questo punto.

Un'applicazione progettata sul modello dell'architettura ''REST'' ha quindi gli indiscutibili vantaggi di:
* consentire l'evoluzione indipendente delle diverse componenti
* avere un'interfaccia utente portabile con altri tipi di piattaforme
* permettere agevolmente la replicazione delle macchine server
* non vincolare moduli server e client a linguaggi e tecnologie specifiche.

L'architettura del servizio oggetto di questa tesi si trova già perfettamente in linea con alcuni dei vincoli discussi, ma sono necessarie alcune considerazioni. Il punto 1 ("architettura Client-Server") è chiaramente soddisfatto.
Il punto 2 ("Stateless"), direttamente collegato con i punti 3 e 5 ("Uso della cache", "Layered System"), può essere rispettato con facilità; a ogni richiesta di "minimizzazione" del client corrisponde la restituzione del documento trattato dal server, non c'è quindi necessita di avere uno stato nell'interazione.

Analizzando le caratteristiche di una applicazione stateless in relazione al principio ''privacy by design'' illustrato in precedenza, si osserva che l'assenza di stato determina la semplificazione delle problematiche critiche relative al principio. Non vengono conservate, infatti, informazioni contenenti dati sensibili, poiché dopo aver effettuato l'invio della risposta, sarà subito eliminato sul server il file elaborato.

Nei capitoli precedenti tuttavia si è detto che l'utente può ripetere più volte il trattamento di uno stesso documento nella stessa sessione di interazione; essendo il vincolo dell'efficienza già difficile da rispettare per via dell'elaborazione onerosa del documento, si può progettare una modalità alternativa del funzionamento con stato del servizio, applicabile in assenza di replicazione delle macchine server e sfruttando le ripetute richieste di trattamento per uno stesso documento.
Si può infatti memorizzare lato server il documento inviato dal client inizialmente e, alle successive richieste di trattamento del medesimo documento, evitarne la ritrasmissione da client a server. Per rispettare il ''PbD'', al termine della sessione di interazione il documento verrà rimosso dal server. Si nota, inoltre, che per predisporre il servizio alla gestione delle due diverse modalità di funzionamento si può utilizzare un parametro di configurazione a livello applicativo.
I punti 4 e 6 infine ("Interfaccia uniforme", "Code on Demand") si possono rispettare utilizzando il formato JSON per la trasmissione dei documenti e dei nominativi, e usando localmente sul client Javascript per offrire tutte le funzionalità del servizio in un'unica pagina html.

===Moduli software del servizio===

====Scelta dei componenti software====

Si opera ora la scelta delle tecnologie da utilizzare per i componenti dei 4 layer dello ''stack LAMP''. Per i due layer inferiori risulta piuttosto immediato decidere di usare le tecnologie presenti per default. Un sistema operativo Linux ed un web server Apache sono adatti all'architettura del servizio.
Inoltre anche il linguaggio di programmazione PHP può essere usato senza significativi problemi, anche se verranno fatte in seguito, in una sezione di questo capitolo, alcune considerazioni sulle problematiche di esecuzioni concorrenti di script PHP. Il linguaggio sarà impiegato in particolare per la realizzazione della logica necessaria a gestire l'interazione web con il cliente, mentre l'elaborazione del documento OOXML lato server sarà effettuata da un programma Java.

I due ''task'' principali del servizio sono delegati, quindi, a due programmi distinti realizzati con tecnologie diverse. Si concretizza in questo modo il principio ''SRP'' e, sfruttando l'<i>openness</i> della piattaforma LAMP, le funzionalità necessarie vengono realizzate attraverso i linguaggi più adatti.
La scelta del linguaggio Java per l'implementazione del ''main core'' della logica di business è dovuta alla libreria open source in ambiente java Docx4j ([40],[41]). Questa libreria è realizzata per il processamento delle tre tipologie di formati OOXML (''docx'', ''xslx'', ''pptx'') e permette tutte le possibili operazioni di creazione, lettura e modifica su questo tipo di documenti. Anche questa libreria sarà approfondita in sezioni successive. Si osserva, per inciso, che esistono altre librerie equivalenti in ambiente .NET.

Nella scelta del linguaggio di programmazione usato per elaborare i documenti ed effettuare i confronti tramite ''regular expressions'', un dato non di poco conto da considerare è l'encoding delle stringhe. In Java, in particolare, una stringa è rappresentata internamente come un array di char, ognuno codificato da 2 byte in formato UTF-16 ([0042]); la codifica esprime in 16 bit tutti i caratteri definiti dallo standard Unicode, quindi è possibile scegliere Java.

Per il ''layer'' della persistenza, infine, l'impiego di un database MySql risulta una buona scelta. Si osserva che questo livello non verrà utilizzato nella tradizionale maniera prevista dallo ''stack LAMP''. Infatti, generalmente, la base di dati viene interrogata direttamente dal componente che si occupa dell'interazione con l'utente (PHP) per il reperimento delle informazioni utili da restituire al client; nel servizio, invece, la base di dati sarà a supporto unicamente del programma Java, poiché gli unici dati persistenti da gestire sono i nomi del dizionario (si ricordi sempre il ''PbD'') e solo i moduli dell'eseguibile Java devono utilizzarli. Se il dizionario contenessero unicamente i nomi (senza informazioni accessorie correlate) e fossero usati in sola lettura, un semplice file di testo poteva essere sufficiente per la rappresentazione. Tuttavia, poiché saranno individuate tecniche di ottimizzazione nell'impiego dei dizionari che richiedono operazioni di scrittura e ordinamento dei dati, risulta opportuno usare un database relazionale.

====Logica di business e dinamiche di interazione====

Vengono presentati in questa sezione gli aspetti principali dei funzionamenti dei moduli del servizio. Per mettere bene a fuoco quali siano le meccaniche di interazione e i flussi di esecuzione dei programmi, si propone il diagramma di sequenza del tipico scenario di utilizzo. In questo schema UML si descrive il caso d'uso dove un utente, dopo aver inserito un documento ed averlo ricevuto "minimizzato", esprime delle preferenze e richiede poi un secondo trattamento.<div></div>
<div></div>(QUI IMG [0F00])<div></div>
Si descrivono quindi ora le principali operazioni che vengono eseguite.
All'avvio dell'interazione viene presentata una pagina PHP di benvenuto contenente le informazioni su come i dati personali vengano elaborati ed un ''file-picker'' per consentire l'upload di un documento ''OOXML''; nel momento in cui l'utente confermerà il caricamento del documento, esso verrà trasferito sul server.
Bisogna prestare particolare attenzione al comportamento del sistema nel caso in cui più utenti richiedano contemporaneamente l'esecuzione del servizio, e cioè alle problematiche di esecuzioni concorrenti di script PHP; è necessario, in particolare, evitare situazioni in cui i nomi dei file inviati dagli utenti siano in conflitto. Analizzando più in dettaglio il problema, ogniqualvolta un web server Apache riceve una richiesta HTTP per una pagina PHP, si ha la generazione di un nuovo processo che esegue il codice presentato nella pagina PHP richiesta. Supponendo quindi che N utenti eseguano l'invio del file contemporaneamente, si avrebbe che sul server N processi diversi dovrebbero procedere con la scrittura di un file. Ovviamente se due o più file condividono il nome almeno uno di essi sarà sovrascritto. Per risolvere questo problema, supponendo di voler salvare tutti i documenti in una cartella temporanea, occorre modificare il filename dei documenti inviati dagli utenti per esser certi di non incorrere in sovrascritture o altri tipi di errori correlati.
Una valida possibilità è l'inserimento di un ''prefisso'' univoco nel filename. Per la generazione di una stringa univoca da anteporre al filename, che permetta di distinguere file caricati da utenti diversi, si può direttamente usare il ''session id'' dell'utente. In PHP esso è determinato casualmente combinando ([0043]): l'IP del cliente, orario di attribuzione dell'id, un numero pseudo-casuale (con il ''PHP Linear Congruence Generator'') e, se presente un "''random source''" sul sistema operativo del Client (spesso chiamato impropriamente "''seme''"), un ulteriore numero pseudo-casuale.
Per introdurre ulteriore alea, necessaria se, ad esempio, un utente tenti l'upload di file omonimi (con contenuto interno diverso) e mantenga il medesimo ''session id'', si utilizza un ulteriore generatore pseudo-casuale per produrre un altro numero con cui comporre il prefisso.
Concatenando i due numeri generati si ha praticamente certezza di aver individuato un numero univoco nel sistema per il tempo in cui il servizio sarà erogato al cliente.

Una volta memorizzato il file, lo script PHP dovrà ricorrere all'invocazione del modulo Java, delegato al vero e proprio processamento del documento. Occorre quindi individuare un set di opzioni che consenta al modulo che gestisce l'interazione con il cliente di sfruttare al meglio il componente delegato all'elaborazione del documento, in qualunque circostanza; la totale indipendenza dei moduli, la loro sostituibilità e la replicazione possibile di macchine server sono solo alcuni dei fattori che rendono mutevole la configurazione del sistema. Va definito un protocollo di comunicazione, quindi, che astragga completamente dall'implementazione dei moduli o dalla locazione dei file.

Valutando i possibili flussi logici, anche con l'ausilio del diagramma di sequenza, si ha che i tipi di esecuzione sono due:
* "minimizzazione" con dizionario
* "minimizzazione" di specifici nominativi
Il protocollo di comunicazione tra i due moduli è costituito in entrambi i casi di una singola richiesta a cui segue una singola risposta. Più in particolare, lo script PHP invoca il comando Java esprimendo obbligatoriamente il path del file da trattare e opzionalmente l'elenco dei nominativi. A suo volta, il modulo Java restituisce i nominativi trovati, qualora non espressamente richiesti dallo script, e segnala la corretta terminazione dell'elaborazione.
Si definiscono come canali di comunicazione standard del protocollo gli argomenti presi in input dal modulo di processamento del documento e lo standard output del processo che esegue tale programma. Inoltre è importante definire un formato standard per la comunicazione dei nominativi tra moduli; è necessario quindi scegliere un pattern che permetta di determinare univocamente la composizione dei nominativi. Un possibile formato, espresso tramite ''regex'', è il seguente:
<div></div>
<span style="font-family: monospace;"> <nominativo> = ^(<nome>:)*<nome>;<cognome>$</span>
<div></div>
<span style="font-family: monospace;"> <nominativi> = ^(<nominativo>\s+)+$</span>
<div></div>
Dove nome e cognome sono una sequenza di caratteri Unicode come già discusso. Ulteriori opzioni importanti da definire nel protocollo per l'invocazione del programma che si occupa delle funzionalità di elaborazione sono le seguenti:
* path file da elaborare (opzione "-i <file_path>", obbligatoria)
* path con cui salvare il file elaborato (opzione "-o <file_path>", opzionale: per default viene creato un nuovo file automaticamente)
* abilitazione stampe verbose, da usare solo in fase di debug (opzione "-d", opzionale)
<div></div>
Una volta terminato il processamento, il modulo di gestione dell'interazione con l'utente dovrà accertarsi che l'<i>exit status</i> sia 0 e leggere dallo standard output del processo appena terminato, qualora si sia stata eseguita la "minimizzazione" con dizionario, l'elenco dei nominativi trovati. Se invece la "minimimizzazione" ha avuto luogo con i nominativi già specificati non sarà scritto nulla sullo standard output.
A margine si osserva che l'impiego dell'opzione "-d" deve sempre consentire una semplice individuazione dei nominativi trovati; in particolare, se tale opzione è specificata, nello standard output i nominativi compariranno con un ''header'' riconoscibile ("''NOMINATIVO=''").
Ritornando alla descrizione del flusso di esecuzione tipo, una volta che il modulo Java ha completato il trattamento del documento, lo script PHP ne effettuerà l'upload sul client e presenterà all'utente le opzioni già descritte nel capitolo sull'usabilità.
A questo punto l'interazione con client potrebbe concludersi, qualora si eseguisse il download e si chiudesse il browser, o continuare elaborando i ''suggerimenti'' dell'utente espressi dopo il primo trattamento. Le modalità di comunicazione dei moduli varierebbero leggermente come appena illustrato, mentre, a seconda della configurazione stateful o stateless del servizio, verrebbe eseguito o meno un nuovo upload del file dal client al server.<div></div>

Si osserva infine che, per predisporre a successivi studi di ottimizzazione il servizio e per agevolare tutti i possibili sviluppi futuri, si applica largamente nella progettazione del modulo di elaborazione Java il ''Dependency Inversion Principle'', in quanto si desidera realizzare classi estendibili ed intercambiabili.
In particolare, si introducono delle classi astratte per rappresentare in maniera generica il concetto di "''persona''" e "''minimizzatore''". È possibile infatti realizzare successivi studi per trattare ulteriori dati personali oltre che ai nomi e cognomi; inoltre, in base ai tipi di documenti trattati o eventuali altri fattori utili, è possibile studiare differenti tecniche di "minimizzazione" realizzate da differenti algoritmi "''minimizzatori''".
In particolare una "''persona''" dovrà sempre esporre un metodo "''minimizza''" che prende in input una stringa, la "minimizza" e la restituisce; il pattern con il quale si effettua la "minimizzazione" sarà fornito in implementazione a seconda dei dati sensibili di interesse.
Un "''minimizzatore''" esporrà sempre un metodo "''work''" che, presa in input una lista di persone ed un documento ''OXML'', con l'ausilio della libreria Docx4j, fornirà in output un documento del tutto "minimizzato"; la definizione delle modalità con cui si estrapolano le informazioni dal documento e con cui si invoca il metodo "''minimizza''" della classe persona sono confinate nell'implementazione.
Definendo delle classi astratte risulta, quindi, più veloce la realizzazione dei futuri componenti e si svincola il processo di "minimizzazione" dal tipo di dati che si "minimizzano" e viceversa.

====Le classi principali del progetto====
Le classi principali del progetto vengono quindi presentate in appendice. Esse sono:
* App.java, contenente il main
* Elaborator.java, che presenta il metodo "''work''"
* Persona.java, che presenta il metodo "''minimizza''"
* Testing.java, contenente alcune funzioni usate in fase di debug.

Gli script in PHP sono stati forniti dall'azienda come implementazione minimale e provvisoria, da perfezionare a seguito della eventuale definizione sulle modalità di presentazione del servizio su Internet.

Una considerazione di implementazione comune a tutte le classi deriva del principio ''Privacy by Design'', indifferentemente dalla modalità di configurazione stateful o stateless del servizio: è di fondamentale importanza che nel sistema non siano memorizzati permanentemente in alcun caso i documenti inviati dagli utenti del servizio.
Per realizzare un sistema robusto, per fronteggiare crash improvvisi del client o congestioni della rete, è opportuno impostare dei timeout lato server che procedano automaticamente alla eliminazione dei documenti degli utenti dopo un periodo di inattività troppo prolungato. Qualora invece si dovesse verificare un interruzione critica del servizio a causa di un errore logico del server o semplicemente per via di un'interruzione dell'alimentazione della macchina server, bisogna considerare altri metodi; essendo il servizio realizzato con un sistema operativo Linux, si può configurare il demone ''crond'' per eseguire a ogni reboot e, per sicurezza, una volta al giorno l'eliminazione dei file usati dall'applicazione tutti contenuti all'interno della cartella temporanea.

==Approfondimenti tecnologici==

===Analisi della struttura del formato OOXML===

Come argomentato, il formato dei documenti elaborati dal servizio progettato dovrà essere ''Office Open XML'', o ''OOXML''; si tratta di un formato ''XML-based'' per documenti di testo, fogli elettronici e presentazioni, in grado di rappresentare grafici, diagrammi, immagini e altro materiale grafico. La specifica fu sviluppata da Microsoft e adottata dall'<i>ECMA International</i> come standard ''ECMA-376'' nel 2006. Una seconda versione fu rilasciata nel 2008, una terza nel 2011, una quarta nel 2012 ed una quinta tra il 2015 ed il 2016 ([0010]). La specifica è stata adottata, inoltre dall'<i>ISO</i> e dall'<i>IEC</i> come standard ''ISO/IEC 29500'' a partire dal 2008 ([0011], [0012]).

====Linguaggi di markup====

Lo standard ''ECMA-376'' ([0010]) include tre differenti specifiche di linguaggio per ognuna delle tre principali categorie di documenti:
* ''WordprocessingML'' per i documenti testuali
* ''SpreadsheetML'' per i fogli elettronici
* ''PresentationML'' per le presentazioni elettroniche
* ''DrawingML'' ed altri linguaggi di markup di supporto per la rappresentazione di disegni, forme e diagrammi.
<div></div>
La specifica include sia gli schemi ''XML'' sia i vincoli espressi per iscritto. Ogni documento conforme al formato dovrà, quindi, rispettare gli schemi ''XML'' e dovrà essere codificato in ''UTF-8'' o ''UTF-16''. La specifica, inoltre, permette l'aggiunta di ''custom tag XML'' a supporto dei linguaggi di markup dati, per default nel formato ''OOXML'', consentendo quindi la libera personalizzazione dei documenti.

====File packaging====

Oltre alla specifiche relative ai linguaggi di markup, la seconda parte dell'<i>ECMA-376</i> ([0010]) definisce la struttura gerarchica dei file del formato adottando le ''Open Packaging Conventions'' (''OPC''). ''OPC'', una tecnologia ''file-container'' basata sul comune formato compresso ''zip'', che stabilisce che tutti i file che riguardano una stessa entità devono essere raggruppati in un unico package ([0014]). Un documento ''OOXML'' è, infatti, un archivio ''zip'' contenente alcuni files ''XML'' (detti anche ''parti'') organizzati in un singolo package. Questa frammentazione dei dati in più files rende più semplice e veloce l'accesso ai dati stessi e riduce le possibilità di una loro corruzione. Le ''parti'' possono contenere qualsiasi tipo di dato; per tenere traccia della relazione tra una ''parte'' e la sua tipologia di contenuto, senza basarsi sull'estensione del file, è presente nel package, nella cartella radice della gerarchia, il file denominato ''[Content_Types].xml'', il quale mappa appunto queste associazioni. È mostrata qui ad esempio l'associazione tra la ''parte'' rappresentante il documento principale e il suo ''ContentType''.
<div style="font-family: monospace;">
<Override PartName="/word/document.xml" ContentType="application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml"/>
</div>
Le informazioni relative alle relazioni che ogni ''parte'' ha con le altre ''parti'', con risorse esterne e con il package in sé sono mantenute separatamente dal contenuto della ''parte'' stessa. Tali informazioni sono presenti, infatti, all'interno delle cartelle denominate ''_rels'': ne esiste una per il package nel suo complesso e una per ogni sotto-cartella del package contenente delle ''parti'' coinvolte in delle relazioni. In questo modo i riferimenti che una ''parte'' ha verso altre ''parti'' o risorse sono salvati una sola volta e possono essere aggiornati con semplicità se necessario, senza dover modificare il contenuto stesso delle ''parti'' coinvolte. È mostrato qui un esempio di relazione contenuta in ''_rels/.rels'' relativa al documento principale e al suo schema.
<div style="font-family: monospace;">
<Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument" Target="word/document.xml"/>
</div>
Il documento principale, ossia il file ''word/document.xml'', ha inoltre numerose relazioni con altre ''parti'', come ad esempio ''word/styles.xml'' e ''word/footer.xml'', e risorse esterne collegate con degli URI. Per descrivere queste relazioni si usa la cartella ''word/_rels''.

====Parti di un Documento OOXML====

Vengono qui presentate le ''parti'' che sono caratteristiche esclusive di un ''WordprocessingML package'', non presenti quindi negli altri due formati ''OOXML''. È importante osservare che alcune di esse sono facoltative e sono presenti nel package solo se necessario.

Le ''parti'' relative al vero e proprio contenuto testuale sono:
* ''Main Document'', contiene le informazioni principali ed è salvata come ''word/document.xml''
* ''Header'', contiene i dati relativi alle intestazioni ed è salvata in ''word/header.xml''. Ogni sezione del documento può avere intestazioni diverse per la prima pagina, per le pagine pari e per le dispari, quindi possono esserci molteplici ''parti header''
* ''Footer'', contiene le informazione relative al piè pagina ed è salvata in ''word/footer.xml''. Può essere presente più volte, per motivi analoghi alla ''parte header''
* ''Footnotes'', contiene le eventuali note a piè pagina del documento ed è salvata come ''word/footnotes.xml''
* ''Endnotes'', contiene le note di chiusura del documento ed è salvata in ''word/endnotes.xml''.

Sono presenti poi delle ''parti'' relative allo stile e alle impostazioni del documento:
* ''Style Definitions'', contiene la definizione di un insieme di stili usati dal documento, salvata in ''word/styles.xml''
* ''Font Table'', contiene informazioni riguardo i font usati, salvata in ''word/fontTable.xml''
* ''Numbering Definitions'', contiene le definizioni sulla struttura delle liste contenute nel documento, salvata in ''word/numbering.xml''
* ''Document Settings'', specifica come il word processor debba trattare il documento (spell checking, gestione delle revisioni, etc.), contenuta in ''word/settings.xml''
* ''Web Settings'', contiene informazioni su come il documento debba essere convertito in ''HTML'' se richiesto, contenuta in ''word/webSettings.xml''.

Sono presenti anche delle ''parti'' che rappresentano testo secondario:
* ''Comments'', contiene i commenti sul documento inseriti attraverso un word processor
* ''Glossary'', contiene dati testuali aggiuntivi secondari, ne è permessa una sola. Tutte le ''parti'' prima elencate, tranne il ''Main Document'', possono comparire una seconda volta in relazione alla ''parte glossary''.

====Analisi del Main Document====

Il file ''document.xml'', elemento principale di un documento ''WordprocessingML'', è costituito da due tipi di informazioni:
* ''properties'', che definiscono lo stile e la formattazione del testo
* ''stories'', che rappresentano il contenuto testuale delle varie parti del documento.

Le ''properties'' verranno trattate in misura minore. Queste informazioni sono espresse attraverso una struttura XML gerarchica che ha come elemento radice il nodo ''document''. Esso ha due nodi figli:
* ''background'', che contiene alcune ''properties'' che descrivono lo sfondo del documento
* ''body'', che contiene tutti i rimanenti contenuti ed è potenzialmente molto complesso.

Si osserva che per le finalità del trattamento dei dati risultano di primario interesse le ''stories'' e che è opportuno effettuare un'analisi ''bottom-up'' del problema: anziché considerare la gerarchia a partire dal ''body'' (nodo padre) partiremo dalla rappresentazione più semplice del testo contenuta nel documento (nodi figli).

Facendo direttamente riferimento allo standard ''ECMA-376'' ([0010]), si evince che l'unico nodo che contiene puro testo ha il nome ''t'' (''Text''). Questo elemento contiene una stringa rappresentante gli esatti caratteri che vengono poi mostrati negli editor a video. Il nodo ''Text'' non presenta figli e l'unico nodo padre che può avere è ''r'' (''Run''). Quest'altro nodo definisce una regione di testo con comuni proprietà (ad esempio l'uso del grassetto). Attraverso l'uso di tag ''t'' ed ''r'' quindi si rappresenta una regione di testo formattata con differenti elementi stilistici.
Occorre però evidenziare che un nodo ''r'' può presentare molti altri figli oltre a ''t'', come ad esempio immagini, in quanto rappresenta un'area generica del documento.
Si supponga quindi di avere due nodi ''Text'' fratelli, ossia figli dello stesso nodo ''r'': essi rappresenteranno semanticamente un unico blocco logico se e solo se compariranno a video come una sequenza di parole continua. Questo fenomeno è facilmente identificabile anche nel file ''XML'' descrittivo: due sequenze di parole mostrate a video adiacenti compaiono infatti nel file ''XML'' in due righe consecutive; se invece due parti di testo dovessero essere intervallate ad es. da un'immagine nel documento ''XML'' ci sarebbe un tag ''drawing'' a dividere i due tag ''t''. Dalla consecutività dei nodi ''Text'' nel file ''document.xml'' si può determinare quali siano i blocchi logici da trattare.
Un insieme di ''Run'' infine può essere figlio di diversi nodi, ma ciò non è di rilevante importanza, in quanto ogni area di testo individuata dal nodo ''Run'' rappresenta già un blocco logico a sé e, di conseguenza, contiene sufficienti informazioni per la "minimizzazione".
L'unico caso di rilievo nel quale bisogna valutare quale sia la gerarchia a monte di un nodo ''Run'' è nell'elaborazione di una tabella. In tal caso, in realtà, occorre verificare opportunamente la strutturazione della gerarchia processata. Per chiarezza espositiva viene mostrata la rappresentazione in formato ''OOXML'' di una tabella con una riga e due colonne (senza l'uso di ''properties'' per la formattazione stilistica).
<br/>
<div style="font-family: monospace;">
<w:tbl>
<w:tr>
<w:tc>
<w:p>
<w:r>
<w:t>Cella A</w:t>
</w:r>
</w:p>
</w:tc>
<w:tc>
<w:p>
<w:r>
<w:t>Cella B</w:t>
</w:r>
</w:p>
</w:tc>
</w:tr>
</w:tbl>
</div>

Come si osserva in figura, in una tabella il nodo ''r'' sarà figlio del nodo ''p'' (''Paragraph''), il quale a sua volta sarà contenuto in un noto ''tc'' (''Table Cell''). Celle di una tabella appartenenti ad una stessa riga saranno presenti all'interno dello stesso ''tr'' (''Table Row'') ed infine tutte le righe della tabella saranno inserite del tag ''tbl'' (''Table'').

Per determinare quindi se due nodi ''Text'' sono scritti in due colonne adiacenti di una stessa riga (e quindi costituiscono un unico blocco logico) è necessario verificare che per i due nodi ''Text'':
# il nodo "padre" '''non sia''' in comune
# il nodo "padre di 2° livello" sia ''Paragraph'' e '''non sia''' in comune
# il nodo "padre di 3° livello" sia ''Table Cell'' e '''non sia''' in comune
# il nodo "padre di 4° livello" sia ''Table Row'' e '''sia''' in comune
# i nodi "padre di 3° livello" '''siano''' consecutivi.
Se tutte queste ipotesi sono soddisfatte, le due celle vanno "minimizzate" come unico blocco logico.

Si valutano infine gli ultimi vincoli emersi nell'analisi sull'interpretazione della formattazione di un documento.
In particolare, descrivendo le parti che compongo un documento ''OOXML'', era già emerso che alcune sezioni di testo, ossia note a piè pagina ed intestazioni, compaiono in altri file ''XML'' e non in ''document.xml''. Questi file (''header.xml'', ''footer.xml'', ''endnotes.xml'', etc.) sono tutti raccolti in un package ("''word''") e la grammatica ''XML'' è la stessa usata per il Main Document.
Si conclude osservando che il problema della divisione in sillabe delle parole non si pone, in quanto la divisione sillabica mostrata a video dai word-processors è calcolata dinamicamente; in particolare, su una porzione di testo viene applicata la sillabazione (ove necessario) se è presente tra le ''properties'' di quella regione di documento il tag ''hyphenationZone''.

====La libreria in ambiente java open source Docx4j====

La libreria Docx4j offre completo supporto alla manipolazione di documenti ''docx'' (compressione e decompressione archivio zip, generazione file ''XML'' necessari, etc.). Offre inoltre un'utile mappatura in specifici oggetti Java della gerarchia ''XML'' presente nei vari file del formato.
Uno tra gli elementi più interessanti è la tecnica con cui vengono recuperati i nodi dai file ''XML'', in quanto si fa impiego del linguaggio standard W3C ''XPath'' ([0044], [0045]). Con ''XPath'' è possibile esprimere con una stringa un sottoinsieme di nodi presenti in una gerarchia ''XML'' non solo in base al loro nome o valore, ma anche in relazione alla posizione reciproca rispetto agli altri nodi. Riferendoci alle problematiche del servizio risulta, ad esempio, significativamente agevolato il trattamento di dati personali in forma tabellare.
Si osserva infine che la libreria attribuisce un id univoco ad ogni nodo del documento, di conseguenza se ne può trarre vantaggio nei confronti tra i nodi.

===Ottimizzazioni del processo di minimizzazione===

===Tecnologie complementari===

La redazione di questa tesi è avvenuta su Mediawiki, la più importante fra le piattaforme wiki essendo il motore di Wikipedia.

Le piattaforme wiki sono riconosciute come elemento caratterizzante dell’evoluzione Internet al Web 2.0, cioè al web nel quale gli utenti-navigatori, fino ad allora "''consumatori"'' ("''consumers"'') di contenuti si sono trasformati essi stessi in "''produttori"'' ("''producers"''), e cioè in "''prosumers"''.

Un ''wiki'' è fondamentalmente un sito web che contiene informazioni e che consente agli utenti di editare facilmente il suo contenuto.

Nel redigere una pagina wiki si utilizza ciò che è chiamato ''wikitext" per definire capitoli, paragrafi, hyperlinks, elementi di formattazione della pagina, etc.; sebbene il ''wikitext" risulti non difficile da apprendere, quasi ogni piattaforma wiki è corredata da editor di tipo visuale, che non richiede alcuna conoscenza della sintassi del ''wikitext"; tuttavia è esperienza comune che utilizzare direttamente il ''wikitext" induce a concentrarsi maggiormente sui contenuti e non sulla formattazione. Il linguaggio ''wikitext'' è strettamente correlato con il linguaggio HTML, infatti nella scrittura è possibile utilizzare tag come h1, span, div e così via, oltre che la sintassi esclusiva di ''wikitext''; simmetricamente una pagina prodotta da media wiki è costituita da HTML ben formato e direttamente importabile in ogni word processor.

I wiki presentano una funzionalità di grande utilità nella redazione di documenti articolati: la tracciatura delle successive revisioni ("''Cronologia"''). La possibilità di ripercorrere l’evoluzione del testo è davvero d’aiuto quando si fissano idee originali in uno scritto, cercando di definirle, precisarle, chiarirle, come è avvenuto in effetti, anche nella redazione di questa tesi. Per curiosità, si segnala che, pur avendo redatto la maggior parte del testo off-line, la pagina wiki di questa tesi conta oltre 50 revisioni.

Per inciso, si osserva che è stata molto utile la funzionalità di "ricerca nel codice" offerta dalla piattaforma di revisione online GitHub nella corretta comprensione della libreria Docx4j, il cui codice sorgente è ivi rilasciato.

Si conclude infine dicendo che per ottimizzare le procedure di debug del codice sono stati realizzati utili tool a riga di comando per Linux per la rapida estrazione-modifica-ricompattazione di documenti ''OOXML''. Si propone in appendice un comando bash per questi scopi.

==Sviluppi futuri==

In questa sezione si fa cenno, senza poterle approfondire, ad alcune interessanti questioni emerse nello svolgimento della tesi.

===Accesso al servizio web===

In fase iniziale, il servizio web potrà essere reso accessibile in forma completamente aperta, senza richiedere cioè la registrazione dell’utente o l’autenticazione dell’utente già registrato. In questo modo, in effetti, si premia la facilità d’uso, ma si incorre nella nota problematica di un uso malevolo, costituito da accessi a raffica, finalizzati a saturare il server e generare una condizione di ''DoS – Denial of Service''. Diverse sono le tecniche che possono essere adottate per contrastare questo tipo di accessi malevoli, come richiedere di superare "''captcha''" e/o introdurre ritardi crescenti ed eventualmente blocchi in risposta ad accessi prevenienti con alta frequenza dallo stesso indirizzo IP.
È possibile anche pensare ad un accesso previa registrazione ed autenticazione dell’utente, penalizzando l’immediatezza di utilizzo del servizio, ma eventualmente ottenendo l’indirizzo email degli utenti che acconsentono a lasciarlo per successive finalità marketing.
È possibile, infine, un utilizzo misto, contando in un cookie il numero di accessi eseguiti e richiedendo all’utente di registrarsi per continuare ad utilizzare il servizio, dopo qualche accesso.

===Ampliamento dinamico del dizionario===

Nel restituire il documento elaborato all'utente, gli si da la possibilità di richiedere una nuova elaborazione, dopo aver indicato i nominativi che fossero sfuggiti; pare inesauribile, infatti, la "fantasia" dei genitori nel dare nome ai propri figlioli!
I nominativi indicati dall'utente sono sfuggiti al servizio perché non presenti nel dizionario: facilmente viene in mente l’idea di arricchire il dizionario con i nominativi indicati dall’utente. Va però considerato il caso che l’utente in malafede indichi nominativi fasulli al fine di inquinare il dizionario.
Il caso malevolo può essere affrontato attraverso una strategia che preveda non direttamente l'inserimento del nuovo nominativo nel dizionario, ma invece l'utilizzo di un concetto di "candidatura": il nuovo nominativo viene registrato, ma si attende di avere un certo numero di utenti che lo propongono prima di approvarne l'inserimento nel dizionario.
Può anche essere utilizzato un concetto di "attendibilità" della candidatura di un nuovo nominativo, verificando ad esempio l'utente che lo propone scarichi effettivamente il file rielaborato.
Nel caso l'accesso avvenga con autenticazione, e cioè identificando gli utenti, si apre la possibilità di individuare e bannare gli utenti malevoli.

===Natura del documento e ricorrenza del nominativo===

Si coglie facilmente la differenza di formato fra un documento in forma di elenco (es. una graduatoria) da un documento in forma di relazione (es. una sentenza giudiziaria). Differenze di questo tipo potrebbero essere utilizzate per escludere o ammettere la ripetizione dei nominativi.
Per meglio dire: in un elenco la ripetizione di un nominativo è di fatto da escludersi o va trattata come omonimia. In una relazione, l’individuazione di un nominativo può essere utilizzata per ricercarlo direttamente in altri punti del documento stesso.

===Altri dati personali===

Altri dati personali sono trattabili con le stesse tecniche analizzate in questa tesi: date e luoghi di nascita, codici fiscali, indirizzi, email, numeri di telefono, sesso etc. In qualche caso, come per i codici fiscali, l’individuazione del pattern da trattare è persino più semplice.
Diversi studi ([0039]) hanno dimostrato che, utilizzando set di dati personali parziali, è possibile la re-identificazione dei soggetti, pur in documenti pseudonimizzati. È questo un altro motivo per estendere i trattamenti descritti anche agli altri dati personali richiamati.

===Altri alfabeti===

È possibile estendere il sotto-insieme di caratteri Unicode utilizzati nelle ''regex'' per elaborare documenti scritti in altri alfabeti non latini.

==Conclusioni==

Questa tesi è partita da un problema basilare, quasi scolastico, dell'informatica: la ricerca di un testo in un documento, al fine della sua cancellazione o modifica.

Il problema si è subito discostato dalla sua formulazione basilare, principalmente perché, nei casi d'uso, il documento da ricercare non è un semplice testo ("''plain text''") ma invece è il prodotto di un ''word-processor'': quindi è costituito da una struttura XML più o meno complessa, rappresentante formattazioni, riferimenti interni o esterni, note, etc. La ricerca deve avvenire nei soli nodi di puro testo, individuando ed escludendo dall'analisi lessicale gli elementi testuali di mark-up che non costituiscono contenuto informativo. Nell'approfondire le strutture ed i concetti XML ho potuto notare quanto essi siano ricorrenti in molti ambiti dell'informatica.

Nell'analisi delle specifiche, un'altra complicazione si è presto aggiunta: l'usabilità del servizio cresce drasticamente se si evita di chiedere all'utente, come si era pensato in un primo tempo di fare, quali siano le stringhe (i nominativi) da ricercare e trattare; è nata allora l'idea di reperire queste stringhe in un dizionario di nomi ed in un dizionario di cognomi, considerando anche le permutazioni dei lemmi reperiti. Ho così dovuto approfondire alcuni problemi tipici dei dizionari, come il loro ampliamento automatico con tecniche oggi comprese nel ''machine-learning''. Non ho potuto "resistere" alla tentazione di ''formalizzare la matematica'' in base alla quale ho costruito le strategie di ricerca.

Spunto per la tesi è stata la recente legislazione in materia di dati personali, il GDPR. Esaminandone gli articoli pertinenti, ho maturato una riflessione generale: sempre più il software dovrà essere progettato e realizzato anche alla luce di altre discipline, non solo di quelle informatiche, come le discipline giuridiche ed il diritto.

Durante la fase iniziale della collaborazione con l'azienda mi sono dedicato alla messa a punto delle specifiche; ciò mi ha permesso di comprendere quanto questa fase sia importante e come completezza e precisione delle specifiche siano alla base di un progetto efficace.

Molto importanti sono state la analisi relative al tipo e formato dei documenti da assumere come input ed alla presentazione ottimale del servizio rispetto all'usabilità.

Centrale nel lavoro ed avvincente è stata la definizione della strategia per il riconoscimento dei lessemi attraverso la costruzione dinamica di ''regex'' idonee. In questo fase del lavoro, anche per passione personale, ho approfondito le questioni del riconoscimento "di testi nei testi" che legano, fin dalle origini, l'informatica e la linguistica.

La fase di definizione dell'architettura del servizio mi ha permesso di ripercorrere molte le materie studiate nei tre anni del Corso di Ingegneria Informatica, affrontando argomenti come il Single Responsibility Principle, il Dependency Inversion Principle, lo "stile" architetturale REST. Molto istruttiva è stata anche la riflessione sulla scomposizione del servizio in moduli software.

Come sempre accade nell'affrontare un progetto nuovo, sono nate molte nuove idee; ho così immaginato numerosi sviluppi futuri, sia a perfezionamento funzionale dell'accesso web al servizio, sia ad estensione delle specifiche per coprire casi applicativi contigui (es. quando il dato che si vuole trattare è un codice fiscale). Dovendo necessariamente tener presente che questo lavoro è una tesi, verificherò con il supporto del mio relatore come poterne proseguire lo sviluppo.

==Bibliografia==

<div></div>[0000]https://en.wikipedia.org/wiki/Comparison_of_Office_Open_XML_software
<div></div>[0001]https://en.wikipedia.org/wiki/Comparison_of_OpenDocument_software
<div></div>[0002]https://en.wikipedia.org/wiki/Standardization_of_Office_Open_XML
<div></div>[0003]https://en.wikipedia.org/wiki/OpenDocument_standardization
<div></div>[0004]https://support.apple.com/en-us/HT202227
<div></div>[0005]https://en.wikipedia.org/wiki/Pages_(word_processor)
<div></div>[0006]https://en.wikipedia.org/wiki/Comparison_of_word_processors
<div></div>[0007]https://en.wikipedia.org/wiki/OpenDocument
<div></div>[0008]https://en.wikipedia.org/wiki/Office_Open_XML_file_formats
<div></div>[0009]https://en.wikipedia.org/wiki/Rich_Text_Format
<div></div>[0010]https://www.ecma-international.org/publications/standards/Ecma-376.htm
<div></div>[0011]https://www.iso.org/standard/51463.html
<div></div>[0012]https://www.iso.org/standard/71691.html
<div></div>[0013]https://en.wikipedia.org/wiki/Office_Open_XML
<div></div>[0014]https://en.wikipedia.org/wiki/Open_Packaging_Conventions
<div></div>[0015]https://en.wikipedia.org/wiki/LAMP_(software_bundle)
<div></div>[0016]https://w3techs.com/blog/entry/debian_ubuntu_extend_the_dominance_in_the_linux_web_server_market_at_the_expense_of_red_hat_centos
<div></div>[0017]https://news.netcraft.com/archives/2014/06/06/june-2014-web-server-survey.html
<div></div>[0018]https://whatis.techtarget.com/definition/LAMP-Linux-Apache-MySQL-PHP
<div></div>[0019]https://www.ibm.com/cloud/learn/lamp-stack-explained
<div></div>[0020]https://en.wikipedia.org/wiki/Single_responsibility_principle
<div></div>[0021]https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
<div></div>[0022]https://en.wikipedia.org/wiki/Latin_script_in_Unicode
<div></div>[0023]https://it.wikipedia.org/wiki/ISO/IEC_8859-1
<div></div>[0024]http://www.treccani.it/enciclopedia/uso-delle-maiuscole_%28La-grammatica-italiana%29/
<div></div>[0025]https://en.wikipedia.org/wiki/Ambiguity#Linguistic_forms
<div></div>[0026]Steven L. Small; Garrison W Cottrell; Michael K Tanenhaus (22 October 2013). Lexical Ambiguity Resolution: Perspective from Psycholinguistics, Neuropsychology and Artificial Intelligence. Elsevier Science. ISBN 978-0-08-051013-2.
<div></div>[0027]http://www.treccani.it/vocabolario/disambiguazione/
<div></div>[0028]R. Navigli, K. Litkowski, O. Hargraves. 2007. SemEval-2007 Task 07: Coarse-Grained English All-Words Task. Proc. of Semeval-2007 Workshop (SemEval), in the 45th Annual Meeting of the Association for Computational Linguistics (ACL 2007), Prague, Czech Republic, pp. 30–35 http://www.aclweb.org/anthology/S/S07/S07-1006.pdf
<div></div>[0029]https://wordnet.princeton.edu/
<div></div>[0030]R. Navigli, S. P. Ponzetto. BabelNet: Building a Very Large Multilingual Semantic Network. Proc. of the 48th Annual Meeting of the Association for Computational Linguistics (ACL 2010), Uppsala, Sweden, July 11-16, 2010, pp. 216-225. http://aclweb.org/anthology/P/P10/P10-1023.pdf
<div></div>[0031]Roventini A., Alonge A., Calzolari N., Magnini B., Bertagna F. (2000), "ItalWordNet: a Large Semantic Database for Italian", Proc. of the 2nd International Conference on Language Resources and Evaluation (LREC 2000), Athens, Greece, 2000, pp. 783-790.
<div></div>[0032]E. Pianta, L. Bentivogli, C. Girardi. MultiWordNet: developing an aligned multilingual database, Proc. of the First International Conference on Global WordNet, Mysore, India, January 21-25, 2002. http://multiwordnet.fbk.eu/paper/MWN-India-published.pdf
<div></div>[0033]https://www.iso.org/standard/28245.html
<div></div>[0034]https://www.gpdp.it/web/guest/regolamentoue
<div></div>[0035]https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=uriserv:OJ.L_.2016.119.01.0001.01.ITA&toc=OJ:L:2016:119:TOC
<div></div>[0036]https://www.corriere.it/Primo_Piano/Cronache/2006/09_Settembre/15/cognomi.shtml
<div></div>[0037]https://data.world/axtscz/italian-first-names
<div></div>[0038]https://en.wikipedia.org/wiki/Dependency_inversion_principle
<div></div>[0039]https://imperialcollegelondon.app.box.com/s/lqqcugie51pllz26uixjvx0uio8qxgo5/file/493461282808
<div></div>[0040https://www.docx4java.org/trac/docx4j]
<div></div>[0041]https://github.com/plutext/docx4j
<div></div>[0042]https://docs.oracle.com/javase/9/docs/api/java/lang/String.html
<div></div>[0043]https://github.com/php/php-src/blob/master/ext/session/session.c
<div></div>[0044]https://github.com/plutext/docx4j/search?q=getJAXBNodesViaXPath+in%3Afile&type=Code
<div></div>[0045]https://www.w3.org/TR/xpath-30/
<div></div>[0046]
<div></div>[0047]
<div></div>[0048]

==Indice delle figure==

[0F00]https://en.wikipedia.org/wiki/Latin_script


[0F01]Diagramma di Venn 1

[0F02]Diagramma di Venn 2

[0F03]Diagramma di Venn 3

[0F04]Esito unit test regex (cartella immagini)

[0F05]Inforgrafica GDPR

[0F06]Diagramma di sequenza UML

[0F07]Primo calcolo valutazione algoritmo

[0F08]Secondo calcolo valutazione algoritmo

[0F09]Terzo calcolo valutazione algoritmo

Servizio web per il trattamento dei dati personali contenuti in documenti OOXML complessi

2019-09-29T23:15:17Z

Lorenzo.amorosa: /* Indice delle figure */

==Introduzione==

Il recente Regolamento Generale europeo sulla Protezione dei Dati (UE) 2016/679 ([0034], [0035]) o ''GDPR'' (''General Data Protection Regulation'', come nel seguito sarà chiamato) ha modernizzato significativamente la normativa in materia di protezione dei dati personali, rendendola omogenea fra tutti gli stati membri. È bene notare che, fin dal titolo, il ''GDPR'' non riduce gli spazi per i trattamenti di dati personali, ma anzi ne protegge la "libera circolazione", dettando, però, regole definite e certe. Rinunciando ad una presentazione più completa del ''GDPR'', saranno riportati nei successivi capitoli i concetti necessari alla discussione dell'argomento.<div></div>
Enti ed organizzazioni, aventi a che fare con documenti contenenti dati sensibili, devono operare in maniera conforme al ''GDPR''; potrebbero, di conseguenza, trarre beneficio da servizi specifici in grado di supportarli in queste esigenze.<div></div>
L'oggetto principale della tesi sarà dunque, come riportato dal titolo, la progettazione e la realizzazione di un servizio per la gestione di dati personali.
<div></div>(QUI IMG [0F05])<div></div>

La larga maggioranza dei documenti testuali viene generata con strumenti cosiddetti di "produttività individuale", cioè da ''word-processors''. L'osservazione, ovvia nella sua evidenza, consente di introdurre una riflessione: quando un documento è generato da un'elaborazione automatica, magari per composizione di ''template'' con dati estratti da un database, l'individuazione dei "dati personali" nel documento prodotto può avvenire in modo rigoroso e senza incertezze, sulla base degli elementi di composizione del documento; ad es.: i campi del documento estratti da una anagrafica di soggetti sono certamente dati personali e come tali possono essere opportunamente trattati nel processo di elaborazione automatica (ad es. cancellati).

Ma, in quella larga maggioranza di documenti testuali generata con ''word-processors'' l'individuazione ed il trattamento dei dati personali vanno affrontati con altri approcci, discussi in questa tesi.

==Scenario di lavoro==

===Minimizzazione dei dati personali===

Un concetto espresso in modo pervasivo dal ''GDPR'' è quello della "''minimizzazione''" dei dati personali trattati ed a maggior ragione dei dati personali pubblicati. In particolare l'Art. 5 ed il Considerando 39 prescrivono che i dati personali trattati siano "''adeguati, pertinenti e limitati a quanto necessario rispetto alle finalità per le quali sono trattati («minimizzazione dei dati»)''" ([0035]).<div></div>
Con questo fine, il GDPR delinea due possibilità organizzative e tecniche di "''minimizzazione''": l'anonimizzazione e la psedonimizzazione.

====Anonimizzazione====

Sono anonimizzati i dati personali non (più) riferibili alle persone a cui sono appartenuti; si tratta di serie di dati, spesso ingenti, che sono stati definitivamente ed irreversibilmente separati da ogni riferimento alle persone che caratterizzavano. Sono le serie di dati utilizzate per fini statistici, scientifici, etc. E' importante notare che, come fissato dal Considerando 26 del ''GDPR'', il Regolamento non si applica al "''trattamento di tali informazioni anonime''" ([0035]). Per questo, sottoporre database e documenti ad un procedimento, cioè un trattamento, di anonimizzazione consente di non doversi più preoccupare del ''GDPR''.

====Pseudonimizzazione====

Fra le definizioni dell'Art. 4 del ''GDPR'', la "pseudonimizzazione" viene indicata come "''il trattamento tale che i dati personali non possano più essere attribuiti a un interessato specifico senza l’utilizzo di informazioni aggiuntive, a condizione che tali informazioni aggiuntive siano conservate separatamente''" ([0035]).<div></div>
Traducendo in termini "operativi", si tratta del procedimento che, dal "record" dei dati di un interessato, separa i campi che caratterizzano l'interessato stesso da quelli che lo identificano, trasferendo questi ultimi in una nuova distinta tabella; nelle due tabelle vengono aggiunti i riferimenti che permettono la ricostruzione del record originario; il procedimento è completo quando la nuova tabella con gli identificativi viene archiviata separatamente ed eventualmente cifrata. In margine si annota che in molti casi, come molti studi dimostrano, è possibile identificare, quindi "riconoscere", gli interessati utilizzando la sola tabella con i dati pseudonimizzati.

====Altri trattamenti di "minimizzazione" ====

Un problema pratico che si incontra di frequente è quello di dover pubblicare documenti più o meno ampi che contengono dati personali. Spesso la pubblicazione è obbligatoria per legge: si pensi alle graduatorie relative a concorsi pubblici, alle sentenze dei tribunali, etc.<div></div>
In questi frequenti casi, analizzando meglio le finalità per le quali sono pubblicati quei dati personali, si osserva che sono possibili e legittimi almeno due approcci per "minimizzare" il dato nel "trattamento di pubblicazione" e, dunque, per minimizzarne la propagazione, ad esempio attraverso motori di ricerca, ben oltre ogni ragionevole finalità. I contesti ed i corrispondenti approcci sono:
# Situazioni in cui è necessario che l'interessato possa riconoscersi nel documento ed essere riconosciuto dagli altri soggetti menzionati nel contesto, ma non è plausibile la necessità di identificazione dell'interessato al di fuori di quel contesto specifico. A questo caso si riconducono le graduatorie di concorsi, gli elenchi per la formazione di classi, gli elenchi per convocazioni, etc. In tutti questi casi, nel processo di redazione del documento è più pratico trattare internamente i dati personali in forma completa; ma praticamente mai è necessario pubblicarli per intero, esponendo al pubblico accesso codici fiscali, indirizzi, recapiti telefonici etc. Per di più, nella maggior parte delle volte, è sufficiente pubblicare il solo cognome perché l'interessato conosca la sua posizione in graduatoria; ciò è spesso sufficiente anche a trasmettere l'informazione necessaria ai colleghi dell'interessato nella medesima graduatoria, o nella medesima classe, etc. Notare che, pubblicando il solo cognome, viene di fatto oscurato anche il sesso. Dunque, in questi casi è auspicabile cancellare una larga parte dei dati personali presenti nel documento.
# Situazioni in cui il documento deve essere pubblicato affinché siano rese note le motivazioni che lo hanno originato, senza che sia necessaria la precisa identificazione dei soggetti che vi compaiono. Questo è il caso della pubblicazione di sentenze giudiziarie di ogni grado. Le sentenze vengono notificate direttamente agli "aventi causa"; ma anche, come la legge prescrive, pubblicate al fine di costituire giurisprudenza. In questo secondo caso, risulta del tutto eccedente la pubblicazione dei reali nominativi degli interessati, che troverebbero verosimilmente la propria vicenda inutilmente indicizzata dai motori di ricerca negli anni a venire. Nella pubblicazione delle sentenze appare un approccio ottimale quello di sostituire con pseudonimi o con iniziali alterate i veri nominativi degli interessati presenti: il senso e le argomentazioni della sentenza restano pienamente comprensibili, come è necessario; il dato personale, del tutto superfluo ai fini della giurisprudenza, viene protetto.
In questi casi appare opportuno sostituire i dati identificativi dell'interessato, ed in particolare il nome e cognome, con pseudonimi o, ancora, con iniziali alterate, cioè non coincidenti con le iniziali reali. <div></div>
Proprio questi tipi di trattamenti di "minimizzazione" sono l'oggetto di questa tesi.

===Punti di partenza per la progettazione del servizio===

La tesi è stata svolta in collaborazione con l'azienda AFA Systems (www.afasystems.it/gdpr) con la quale si sono discusse le problematiche di progettazione e realizzazione di un servizio generalizzato di minimizzazione dei dati personali presenti in un documento.
Con l'intenzione di fornire il servizio ad un bacino d'utenza il più vasto e variegato possibile, si è pensato ad un'applicazione ''web-based'', indipendente così dai singoli devices sui quali poi sarà utilizzata.
L'attenzione è stata concentrata sul trattamento dei nomi e dei cognomi (che da qui chiameremo nominativi), poiché sono quelli sempre presenti nei documenti (ad es. gli indirizzi sono presenti solo a volte), rappresentano gli elementi tramite i quali è immediato il riconoscimento della persone, non hanno formato predefinito (come ad es. i codici fiscali); altri dati personali (indirizzi, codici fiscali, etc.), potranno essere considerati in successive evoluzioni del progetto.
È utile notare che la parte iniziale della collaborazione con l'azienda è stata dedicata alla discussione delle specifiche, la cui più precisa definizione è parte rilevante di questa tesi.<div></div>
Tra i requisiti che necessitano di un opportuno studio troviamo ad esempio:
* L'individuazione di metodi efficaci per il riconoscimento dei nominativi nei documenti
* L'identificazione delle migliori procedure di interazione con l'utente
* La scelta dei formati da trattare
* I vincoli non funzionali legati al rispetto del ''GDPR''.

==Definizione delle specifiche==

===Riconoscimento dei nominativi===

====Scelta della strategia di riconoscimento====

Le difficoltà principali con cui ci si imbatte nel processo di riconoscimento dei nominativi riguardano la complessità strutturale dei documenti di testo, ma soprattutto l'intrinseca ambiguità del linguaggio naturale. <div></div>
Le variabili ed impredicibili strutture e formattazioni dei documenti introducono alcuni problemi significativi. Rendendo fortemente eterogeneo il contenuto dei documenti, infatti, esse non consentono di ricondurre il problema del riconoscimento dei nominativi ad uno o a pochi singoli casi, ma comportano lo studio di tutte le strutture e formattazioni possibili, rendendo quindi l'analisi molto generale. L'altra rilevante difficoltà presente sta nella complessità di effettuare il riconoscimento di una stringa testuale immersa in un insieme di elementi non tutti testuali. Ogni elemento di formattazione, che sia una tabella o una barra orizzontale, introduce infatti un proprio significato logico e semantico nel documento di cui bisogna tenere conto.<div></div>
Il linguaggio naturale introduce anch'esso complessità: si pensi alle molteplici tipologie di proposizioni con cui possono essere articolati i periodi; ma i problemi principali derivano dalle sue ambiguità. Esse vengono classificate in diverse tipologie ([0025]); le principali sono le ambiguità sintattiche e lessicali.<div></div>
Si ha ambiguità sintattica quando la sintassi di una frase può essere interpretata in diversi modi e, di conseguenza, la frase stessa assume significati diversi. Essa è presente, ad esempio, nelle seguenti frasi:<div></div>
* "''Rapina in banca con rivoltella da centomila euro''"
* "''Luigi ha visto un uomo nel parco con il binocolo''"
<div></div>
L'esasperazione massima della problematica delle ambiguità sintattiche si presenta con l'<i>antinomia</i>, ossia un particolare tipo di paradosso che indica la compresenza di due affermazioni contraddittorie che possono essere entrambe dimostrate o giustificate.
L'antinomia di Epimenide o ''Paradosso del mentitore'', nota fin dal VI secolo, è probabilmente uno dei più noti esempi: "''il cretese Epimenide afferma che tutti i cretesi mentono''". Se la proposizione è vera (i cretesi mentono) allora il suo significato implica che sia falsa (Epimenide mente e quindi i cretesi dicono la verità), ma se è falsa (i cretesi dicono la verità) ciò significa che è vera (Epimenide dice la verità e quindi i cretesi mentono). La proposizione appare contemporaneamente vera e falsa. A partire dagli anni venti del '900, sono state elaborate varie teorie per la risoluzione delle contraddizioni provocate dalle antinomie, soprattutto attraverso l'elaborazione di linguaggi multilivello o attraverso l'elaborazione di logiche polivalenti (quindi non-booleane).<div></div>
Si ha ambiguità lessicale, invece, quando una parola possiede più di un significato nella lingua a cui appartiene ([0026]), in tal caso la parola è definita ''polisemica''. In italiano, alcuni termini soggetti a questo tipo di ambiguità sono, ad esempio "''acuto''" o "''venti''". È questo genere di ambiguità che risulta critico per il riconoscimento dei nominativi. La difficoltà determinata dalle ambiguità sintattiche, infatti, riguarda l'individuazione corretta di soggetti, predicati e complementi di un periodo, mentre le ambiguità lessicali ostacolano la comprensione del significato del singolo lessema. Nel processo di riconoscimento è irrilevante determinare la funzione logica che il nominativo svolge nella frase, mentre è necessario essere certi che i termini che compongono il nominativo siano effettivamente dei nomi propri di persona o dei cognomi, non altri vocaboli del lessico comune. <div></div>
In linguistica, l'intervento con cui si toglie ambiguità a una parola o a una frase prende il nome di "disambiguazione" ([0027]). Il problema della disambiguazione automatica (in inglese ''Word Sense Disambiguation'' o, abbreviato, ''WSD'') riveste particolare importanza nelle ricerche sull'intelligenza artificiale e, in particolare, nell'elaborazione del linguaggio naturale. Si prevedono benefici della disambiguazione, ad esempio, in programmi di traduzione automatica, recupero dell'informazione o estrazione automatica di informazioni. Nell'analisi delle soluzioni esistenti in letteratura per la risoluzione delle ambiguità, ci si sofferma specialmente sulle ricerche incentrate sul trattamento dell'ambiguità lessicale, essendo essa la più rilevante per i nostri interessi.<div></div>
La ''WSD'' richiede due input necessariamente: un dizionario per specificare i sensi che devono essere disambiguati e un corpus di dati linguistici da disambiguare. Nello scenario più realistico, si trattano testi le cui parole non sono note a priori e risulta molto onerosa la produzione del corpus, essendo infatti necessaria la valutazione di un operatore umano per verificare la correttezza delle disambiguazioni effettuate dagli algoritmi (''supervised learning'').<div></div>
Uno tra i principali dizionari semantici-lessicali utilizzati della lingua inglese è ''WordNet'' ([0029]), mentre alcuni dei database equivalenti che trattano l'italiano sono ''BabelNet'' ([0030]), ''ItalWordNet'' ([0031]) e ''MultiWordNet'' ([0032]).
Un elemento importante da considerare è che le prestazioni di disambiguazione per la lingua inglese, impiegando ''WordNet'', risultano corrette tra l'80% e il 90% delle volte ([0028]), percentuali discrete ma non sufficienti per avere la totale garanzia.<div></div>
I fattori che ostacolano la realizzazione di algoritmi di intelligenza artificiale per la disambiguazione sono molteplici:
# Differenze tra dizionari impiegati: i database prima citati si basano su varie fonti che raggruppano semanticamente in maniera diversa i vocaboli, quindi programmi sviluppati con dizionari diversi generalmente hanno performance differenti.
# Complessità della codifica di parte del discorso: per poter disambiguare correttamente un termine è importante riuscire a comprendere correttamente il contesto in cui è inserito, operazione non banale.
# Varianza tra giudici: i supervisori dell'apprendimento degli algoritmi possono avere opinioni diverse, o semplicemente sbagliare, nella valutazione delle disambiguazioni, ciò porta ad algoritmi che hanno comportamenti diversi.
# Impossibilità di applicare la disciplina della ''pragmatica'', ossia la logica del ''buon senso'': per identificare correttamente il senso di alcune parole, ad esempio nella comprensioni di anafore e catafore, è necessario applicare il buon senso.
# Dipendenza del senso delle parole dai contesti: ogni scenario richiede la propria divisione del significato delle parole in sensi rilevanti. In un contesto informatico, ad esempio, il termine "''mouse''" deve essere ricondotto al dispositivo di puntamento, non al cognome del celebre personaggio Disney ''Mickey Mouse''; viceversa dovrà invece avvenire in un contesto di letteratura a fumetti.<div></div>
Laddove la ''WSD'' è una tecnica molto generale e che mira a risolvere un'ambiguità riguardante una qualunque parola, per le finalità del servizio oggetto di questa tesi è sufficiente risolvere le ambiguità dei nomi e dei cognomi.
Uno dei difetti che il servizio presenterebbe adottando un approccio ''WDS'' è legato alla impredicibile formattazione dei documenti, che aggiunge informazione semantica al testo ma introduce complessità nella individuazione automatica delle parti che formano il contesto; un altro difetto dipende dalla vastità del lessico da elaborare, essendo i documenti da trattare forniti dai più disparati utenti, su qualunque genere di argomento e relativi ai più vari ambiti.<div></div>

La strategia che sarà adottata per risolvere la problematica del riconoscimento dei nominativi sarà impostata attraverso un modello ''pattern-based'', impiegando le ''regular expressions'' (''regex''). Esse risultano comunemente usate per effettuare operazioni di ricerca o sostituzione in un testo, di conseguenza se si riesce ad individuare un pattern associato ad un nominativo dato, allora sarà possibile processare il documento ricercando le occorrenze del nominativo e "minimizzarlo" opportunamente.<div></div>

Le ''regular expressions'' risultano particolarmente efficaci poiché, se opportunamente progettate, possono identificare un nominativo indipendentemente dal significato linguistico del contesto in cui è calato, basandosi piuttosto sui singoli caratteri che compongono i lessemi analizzati; permettono, di conseguenza, di effettuare una valutazione estremamente minuziosa, riducendo al minimo le possibilità di errori.<div></div>
Un algoritmo di risoluzione ''pattern-based'' risulta, inoltre, più efficiente nell'esecuzione, in generale, di un algoritmo di intelligenza artificiale; per fornire la risposta il più velocemente possibile ad un utente, fruitore del servizio via web, l'approccio di riconoscimento tramite pattern è il più indicato.<div></div>

====Definizione dei pattern====
Nella progettazione del servizio si adotta, come detto, un approccio ''pattern-based'' per il riconoscimento dei nominativi. In linea di massima è opportuno che vengano riconosciuti più nominativi possibili e allo stesso tempo che la correttezza dell'identificazione di un nominativo sia garantita, quindi bisogna individuare dei pattern non troppo stringenti ma neppure troppo laschi. Per analizzare come i pattern devono essere strutturati si prende come caso di studio un generico nominativo, ad esempio ''Lorenzo Mario Amorosa''. Nel documento esso può comparire esattamente come appena indicato, ma anche in altre plausibili varianti, in cui l'ordine dei termini viene alterato, si pensi ad esempio ad "Amorosa Lorenzo Mario" o "Mario Lorenzo Amorosa", o in altre varianti ancora in cui alcuni nomi non compaiono, come in "Lorenzo Amorosa". Bisogna tuttavia supporre un limite alla variabilità: si osserva infatti che il cognome deve sempre comparire (il solo nome ''Lorenzo'' non è riconducibile a ''Lorenzo Mario Amorosa'') e che esso inoltre deve essere necessariamente anteposto o posposto, ma non interposto, ai nomi (è poco ragionevole ricondurre "Lorenzo Amorosa Mario" a "Lorenzo Mario Amorosa'').<div></div>
Questa prima specifica permette di ricondursi a una soluzione generale, sufficiente nella maggior parte dei casi, ma che non risolve alcune criticità. Un nominativo può, in alcuni documenti, comparire manifestandosi unicamente attraverso il cognome (riferendoci all'esempio precedente, ''Lorenzo Mario Amorosa'' apparirebbe nella forma ''Amorosa''). Sorge qui il problema che molti dei cognomi italiani hanno un significato proprio nel linguaggio comune; ad es., nella frase ''una relazione amorosa è bella'' è errato considerare la parola ''amorosa'' come cognome di un nominativo. Per risolvere questo genere di ambiguità si potrebbe pensare che per stabilire che il termine ''Amorosa'' sia un cognome sia sufficiente verificare che esso inizi con una lettera maiuscola, ma ciò può verificarsi anche perché la parola si trova ad inizio di frase. Inoltre, vari cognomi italiani possono iniziare con una lettera minuscola (''de Angelis'', ''d'Onofrio'', etc.), quindi basare l'identificazione di un cognome sul fatto che la sua prima lettera sia in maiuscolo non è in generale un metodo valido. Volendo in maniera prioritaria garantire il corretto funzionamento del servizio, e quindi attuare le procedure di anonimizzazione solo sui nominativi senza applicarle erroneamente ad altri termini, risulta necessario evitare il trattamento dei nominativi che si manifestano con i soli cognomi. Per via del contesto e dei significati che i cognomi possono assumere, infatti, risulta spesso impossibile distinguerli da parole del linguaggio comune.

Ci si concentra, quindi, nello studio di nominativi composti da un cognome seguito o preceduto da uno o più nomi.<div></div>
Si rappresenta dunque in formato di ''regular expression'' il pattern attualmente ideato. Per semplicità espositiva, si definisce il tag <span style="font-family: monospace;"><nomi></span> come l'insieme delle permutazioni di tutti i nomi del nominativo più l'insieme delle permutazioni di tutti i possibili sottoinsiemi di nomi del nominativo. Considerando il nominativo preso precedentemente come caso di studio, ad esempio, si avrebbe:
<div></div>
<span style="font-family: monospace;"> <nomi> = Lorenzo Mario|Mario Lorenzo|Lorenzo|Mario</span>
<div></div>
Posto inoltre il tag <span style="font-family: monospace;"><cognome></span> ad indicare il cognome contenuto nel nominativo e il tag <span style="font-family: monospace;"><regex></span> ad indicare la ''regular expression'' associata al nominativo, si ottiene:
<div></div>
<span style="font-family: monospace;"> <regex> := <cognome> (<nomi>)|(<nomi>) <cognome></span>
<div></div>
Una osservazione sottile ma di fondamentale importanza per la corretta progettazione delle ''regular expressions'' sta nella piena comprensione della semantica dell'operatore di scelta, espresso con il carattere ''pipe'' ("|"). Un qualunque ''engine'' di elaborazione delle ''regex'', infatti, interrompe la valutazione di una stringa non appena può stabilire se tale stringa fa match o meno con il pattern dato, senza quindi necessariamente valutarlo nella sua interezza, come parimenti avviene nelle valutazioni ''a corto circuito'' delle espressioni logiche nei linguaggi di programmazione. Ogni nominativo avrà a sè associato un pattern che lo rappresenta in più possibili sequenze di caratteri; per effettuare una corretta "minimizzazione" dei dati è necessario che le sequenze contenenti tutti i nomi sia poste per prime, mentre quelle contenenti un singolo nome per ultime.<div></div>
In questa prima formulazione della ''regex'', inoltre, si è posto come separatore unicamente lo spazio bianco, ma alcuni documenti potrebbero contenere dei nominativi i cui termini sono separati da altri caratteri, come ad esempio una virgola nel caso di "Amorosa, Lorenzo Mario". Per poter quindi identificare un nominativo anche in questi casi, si potrebbe considerare un qualunque carattere di interpunzione come possibile separatore dei termini del nominativo.
Adottando questa soluzione si ha però come effetto collaterale che risultano critici i casi in cui nel testo sono presenti dei nominativi soggetti ad omonimia. Si consideri una generica frase contenente una sequenza di nominativi, ad esempio ''Amorosa Lorenzo, Mario Giacomo e Fabio Rossi'', e si supponga che i nominativi da trattare siano ''Amorosa Lorenzo Mario'', ''Mario Giacomo'' (in cui la parola ''Mario'' è il cognome) e ''Fabio Rossi''. Gli ultimi due nominativi compaiono nella frase nella loro forma estesa, mentre il primo compare con il solo nome ''Lorenzo'' (eventualità possibile considerando la definizione del pattern precedentemente data). Considerando la virgola come carattere separatore dei termini del nominativo, la sequenza di parole ''Amorosa Lorenzo, Mario'' sarebbe ricondotta, venendo elaborata per prima, ad ''Amorosa Lorenzo Mario'', mentre rimarrebbe non trattata la parola ''Giacomo'', in quanto il cognome ''Mario'' che gli era associato è stato già identificato come un nome del nominativo ''Amorosa Lorenzo Mario'' ed il termine ''Giacomo'' preso singolarmente non rappresenta un nominativo.<div></div>
Prima di valutare ulteriormente le problematiche relative alle omonimie, si possono scegliere due approcci per risolvere questo specifico caso:
# Si riconduce una sequenza di parole ad un nominativo se e solo se tutti i suoi nomi sono contenuti nella sequenza
# Si considerano come separatori dei termini contenuti nei nominativi solo spazi bianchi, tabulazioni e a capo, non gli altri segni di punteggiatura.
<div></div>
Entrambe le strategie sono valide, in quanto risolvono il problema garantendo la corretta identificazione dei nominativi, ma allo stesso tempo entrambe presentano lo svantaggio di ridurre le sequenze di parole riconducibili a dei nominativi, aumentando le possibilità che alcuni di essi non vengano trattati.
Si consideri nuovamente il nominativo preso come caso di studio ''Amorosa Lorenzo Mario'': applicando la prima strategia, non sarebbe possibile ricondurgli la sequenza ''Amorosa Lorenzo'', mentre applicando il secondo metodo non sarebbe riconducibile la sequenza ''Amorosa, Lorenzo Mario''.
Si decide di attuare la seconda strategia, in quanto è opportuno non imporre vincoli troppo stringenti sui nomi e poiché nella gran parte dei casi i termini dei nominativi nei documenti sono separati tra loro da caratteri quali spazi bianchi, tabulazioni ed a capo.<div></div>
Un altro elemento su cui porre l'attenzione è la possibilità che i documenti da trattare contengano dei nominativi scritti interamente in maiuscolo o minuscolo, di conseguenza è conveniente che le ''regular expressions'' siano progettate ''case-insensitive''.<div></div>
Un ulteriore punto su cui bisogna soffermarsi è la posizione all'interno di un periodo in cui un nominativo può comparire, in particolare si vogliono evitare quei casi critici in cui uno dei termini del nominativo è una sotto-stringa di un'altra parola del testo (si pensi ad ''amorosa'' in ''clamorosa''). Come regola generale si può stabilire che è sempre necessario che un nominativo sia preceduto e seguito da un ''carattere non alfabetico''. Un caso particolare si presenta quando il nominativo è posto ad inizio o a fine documento, situazione in cui quindi esso non è preceduto o non è seguito da alcun carattere: entrambe le posizioni sono da considerare corrette.<div></div>
È opportuno ora definire il concetto di ''carattere non alfabetico'', e ciò si può fare più facilmente ragionando sul problema in logica positiva; infatti risulta più semplice individuare quei caratteri che rappresentano lettere piuttosto che quelli che rappresentano segni di interpunzione ed individuare ogni altro carattere che non può mai comporre una parola.

Inquadrando lo scenario di applicazione del servizio, molto probabilmente l'utente vorrà trattare un documento scritto nella lingua di uno dei paesi dell'Unione Europea, poiché il ''GDPR'' vige nei soli paesi membri dell'Unione.
Si può, quindi, ipotizzare che i documenti trattati possono sì contenere parole e nominativi stranieri, ma che i caratteri contenuti siano appartenenti all'alfabeto latino (''Latin script''), usato in molti stati nel mondo e da tutti i principali stati europei (fatta eccezione per la Grecia ed alcuni stati che scrivono in caratteri cirillici).
Inoltre, testi scritti in altri alfabeti, come esempio il cinese, l'arabo o il cirillico, vengono generalmente traslitterati. Considerare, quindi, ''caratteri non alfabetici'' tutti i caratteri diversi dalle lettere contenute nell'alfabeto latino sarebbe di conseguenza estremamente riduttivo ed inoltre in questo modo non si terrebbe conto delle lettere accentate, molto utilizzate anche nella lingua italiana.
<div></div>(XXXX QUI IMG [0F00])<div></div>
Per risolvere il problema facciamo riferimento alla codifica standard Unicode dell'alfabeto latino ([0022]); in essa è possibile individuare, oltre ai caratteri rappresentanti le lettere nella codifica ''ASCII'' classica, i caratteri rappresentanti le lettere nella codifica standard ''ISO/IEC 8859-1'' ([0023]), encoding orientato principalmente alla rappresentazione delle lingue dell'Europa occidentale.

<div></div>
<center><i>Caratteri latini nei primi due blocchi dello standard Unicode</i></center>
{| class="nounderlines" border="1" cellpadding="2" cellspacing="0" style="border-collapse:collapse"
|----- align="center"
!style="background:#ccf; text-align:center; font-weight: bold;"|U+
!style="text-align:center; font-weight: bold;"|0||style="text-align: center; font-weight: bold;"|1||style="text-align: center; font-weight: bold;"|2||style="text-align: center; font-weight: bold;"|3||style="text-align: center; font-weight: bold;"|4||style="text-align: center; font-weight: bold;"|5||style="text-align: center; font-weight: bold;"|6||style="text-align: center; font-weight: bold;"|7||style="text-align: center; font-weight: bold;"|8||style="text-align: center; font-weight: bold;"|9||style="text-align: center; font-weight: bold;"|A||style="text-align: center; font-weight: bold;"|B||style="text-align: center; font-weight: bold;"|C||style="text-align: center; font-weight: bold;"|D||style="text-align: center; font-weight: bold;"|E||style="text-align: center; font-weight: bold;"|F||style="text-align: center; font-weight: bold;"|Block||style="text-align: center; font-weight: bold;"|#
|-
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0040
|style="background:#fff"|@||A||B||C||D||E||F||G||H||I||J||K||L||M||N||O
|rowspan="4" style="background:#fff" align:"center"|C0 Controls and Basic Latin<br>0000–007F<br>(identical to ASCII)
|rowspan="4" style="background:#fff"|52
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0050
|P||Q||R||S||T||U||V||W||X||Y||Z||style="background:#fff"|[||style="background:#fff"|\||style="background:#fff"|]||style="background:#fff"|^||style="background:#fff"|_
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0060
|style="background:#fff"|`||a||b||c||d||e||f||g||h||i||j||k||l||m||n||o
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|0070
|p||q||r||s||t||u||v||w||x||y||z||style="background:#fff"|{||style="background:#fff"||||style="background:#fff"|}||style="background:#fff"|~||style="background:#fff; font-size:75%"|DEL
|-
!colspan="19"|
|----- align="center" style="background:#fff"
!style="background:#fff; text-align:center; font-weight: bold;"|00A0
| ||¡||¢||£||¤||¥||¦||§||¨||©||ª||«||¬||||®||¯
|rowspan="6" style="background:#fff" align="center"|C1 Controls and Latin-1 Supplement<br>0080–00FF<br>(identical to ISO/IEC 8859-1)
|rowspan="6" style="background:#fff"|62
|----- align="center" style="background:#fff"
!style="background:#fff; text-align:center; font-weight: bold;"|00B0
|°||±||²||³||´||µ||¶||·||¸||¹||º||»||¼||½||¾||¿
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00C0
|À||Á||Â||Ã||Ä||Å||Æ||Ç||È||É||Ê||Ë||Ì||Í||Î||Ï
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00D0
|Ð||Ñ||Ò||Ó||Ô||Õ||Ö||style="background:#fff"|×||Ø||Ù||Ú||Û||Ü||Ý||Þ||ß
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00E0
|à||á||â||ã||ä||å||æ||ç||è||é||ê||ë||ì||í||î||ï
|----- align="center" style="background:#f66"
!style="background:#fff; text-align:center; font-weight: bold;"|00F0
|ð||ñ||ò||ó||ô||õ||ö||style="background:#fff"|÷||ø||ù||ú||û||ü||ý||þ||ÿ
|---- align="center" style="background:#f66"
|}
<div></div>

I caratteri indicati in rosso nella tabella sono tutti i possibili ''caratteri alfabetici'' che compaiono nei documenti scritti in 29 lingue diverse ([0023]), tra le quali sono presenti l'italiano, l'inglese, lo spagnolo, il tedesco e il portoghese.
Aggiungendo pochi altri caratteri all'insieme dei ''caratteri alfabetici'' appena mostrati, si riesce a rappresentare ogni parola di altre 12 lingue ([0023]), tra cui il francese, l'olandese, il ceco e il turco.<div></div>
I caratteri mostrati in tabella corrispondono ad una parte dei primi due blocchi dello standard Unicode che codificano l'alfabeto latino e, come già accennato in precedenza, essi sono presenti negli standard ''ASCII'' e ''ISO/IEC 8859-1''. I rimanenti ''caratteri alfabetici'', invece, sono presenti in estensioni dello standard Unicode per il ''Latin script''. Queste estensioni sono state realizzate per fornire il massimo supporto a tutte le lingue e contenenti molti simboli ad uso speciale, come ad esempio per la rappresentazione dei fonemi. Si osserva, inoltre, che i ''caratteri alfabetici'' definiti nelle estensioni dello standard Unicode sono presenti anche nella codifica ''ISO/IEC 8859-2'' o nelle versioni successive ([0023]).<div></div>
Definiti i ''caratteri non alfabetici'' come elementi di separazione tra un nominativo ed il testo in cui esso è inserito, occorre definire opportunamente la ''regex'' che al nominativo è associata.

Utili strumenti messi a disposizione dalle ''regular expressions'' sono i gruppi speciali ''lookahead'' e ''lookbehind''. Un pattern di un nominativo deve essere preceduto o seguito da una prestabilita sequenza di caratteri, la quale però non è parte del nominativo. Utilizzando i due costrutti citati, è possibile far sì che nell'elaborazione di una stringa facciano match solamente le parole effettivamente appartenenti al nominativo, non i caratteri che lo delimitano dal resto del testo, e allo stesso tempo che un nominativo faccia match se e solo se preceduto o seguito da una certa sequenza di caratteri. <div></div>
Per esprimere nella sintassi delle ''regex'' un carattere letterale in un qualunque alfabeto si può utilizzare il costrutto ''\p{L}'', che però risulta molto generale e troppo lasco per i requisiti considerati. Si può piuttosto valutare l'impiego del costrutto ''\p{Latin}'', il quale identifica un qualunque carattere alfabetico presente nell'alfabeto latino. Tra i caratteri corrispondenti al costrutto, però, ve ne sono alcuni che per le specifiche del servizio devono essere considerati ''caratteri non alfabetici'', come ad esempio i caratteri dei fonemi, i segni diacritici e gli indicatori ordinali; di conseguenza è necessario individuare una strategia ad hoc per risolvere questa problematica.<div></div>
Per chiarezza espositiva, si definisce il tag <span style="font-family: monospace;"><start></span>, per indicare un qualunque carattere non alfabetico o l'inizio stringa, il tag <span style="font-family: monospace;"><end></span>, per indicare un qualunque carattere non alfabetico o il fine stringa, ed il tag <extra>, per indicare i ''caratteri alfabetici'' non presenti negli standard ''ASCII'' o ''ISO/IEC 8859-1'':<div></div>
<span style="font-family: monospace;">
<extra> := ĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ
<br/>
<start> := (?<=[^A-Za-zÀ-ÖØ-öø-ÿ<extra>]|^)
<br/>
<end> := (?=[^A-Za-zÀ-ÖØ-öø-ÿ<extra>]|$)
</span>
<div></div>
Si osserva che si sono utilizzati i gruppi speciali prima descritti e che si sono inseriti i caratteri dello standard Unicode presentati in precedenza. Si definisce nuovamente la ''regular expression'' associata ad un generico nominativo. Applicando i tag appena definiti, il costrutto ''(?i)'' che rende il pattern ''case-insensitive'' ed il costrutto ''\s'' che rappresenta un carattere qualunque tra i separatori non visibili, ossia ''\r \n \t \f \v'' e lo spazio bianco, si ottiene:<div></div>
<span style="font-family: monospace;">
<regex> := (?i)(<start><cognome>\s+(<nomi>)|(<nomi>)\s+<cognome><end>)
</span>
<div></div>
Si osserva, inoltre, che in questa nuova formulazione della ''regular expression'' i nomi sono da intendersi separati tra loro da ''\s+''.<div></div>
A questo punto si è quasi giunti alla formulazione finale del pattern da associare ad un nominativo, rimangono solo da trattare alcuni casi critici non ancora risolti.<div></div>
Si è già presentato in precedenza il problema legato al fatto che alcuni cognomi possono avere un significato proprio nel lessico comune e che ciò costringeva, quindi, ad abbandonare l'idea di trattare nominativi formati dal solo cognome. Questa problematica di ambiguità si presenta anche con alcuni nomi (si pensi, ad esempio, al nome ''Gioia''). Ciò non rappresenta generalmente un problema, in quanto la coppia nome-cognome che forma il nominativo, presa complessivamente, non è soggetta ad ambiguità. Esistono, però, dei casi in cui questo non è vero. Si prenda in analisi il nominativo ''Gioia Grande'': risulta evidentemente soggetto a rischio di ambiguità. Una soluzione che si può adottare, per risolvere questo caso critico, si basa sull'associazione di un pattern più stringente ai nominativi. In particolare, si osserva che i nomi propri di persona compaiono sempre ed obbligatoriamente, in un documento grammaticalmente corretto, con la prima lettera maiuscola ([0024]). I cognomi, invece, non sono soggetti ad una regola così stringente: un cognome iniziante con una lettera minuscola (come ''de Rosa'') in alcuni casi, ad esempio se posto dopo un punto fermo, può comparire scritto con la prima lettera sia maiuscola che minuscola; naturalmente, in nessuna occorrenza un cognome che inizi con una lettera maiuscola potrà comparire con una minuscola. <div></div>
Occorre quindi ridefinire, alla luce di queste osservazioni, la ''regex'' associata ad un nominativo, poiché precedentemente era stata posta interamente ''case-insensitive''. Nel pattern, in particolare, i nomi dovranno sempre iniziare con una maiuscola, mentre i cognomi avranno questo vincolo solo se nel nominativo compaiono con la prima lettera maiuscola. Si mostra quindi quali sono i tag <span style="font-family: monospace;"><nomi></span> e <span style="font-family: monospace;"><cognome></span> associati a due nominativi, ad esempio ''Gioia Grande'' e ''Antonio de Rosa''. <div></div>
Per ''Gioia Grande'' si ha:<div></div>
<span style="font-family: monospace;"><nomi> = G((?i)ioia)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = G((?i)rande)</span>
<div></div>
Per ''Antonio de Rosa'' si ha:<div></div>
<span style="font-family: monospace;"><nomi> = A((?i)ntonio)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = (?i)de Rosa</span>
<div></div>
Si presenta dunque la definizione finale del tag <span style="font-family: monospace;"><regex></span>. Nella definizione il tag <span style="font-family: monospace;"><nomi></span> è definito il base al numero di nomi del nominativo ed il tag <span style="font-family: monospace;"><cognome></span> è definito in base al carattere iniziale del cognome.<div></div>
<span style="font-family: monospace;">
<regex> := <start><cognome>\s+(<nomi>)|(<nomi>)\s+<cognome><end>
</span>
<div></div>
Vengono inoltre mostrati i valori dei due tag <span style="font-family: monospace;"><nomi></span> e <span style="font-family: monospace;"><cognome></span> per il nominativo preso come caso di studio in fase iniziale, ossia ''Amorosa Lorenzo Mario''. Si ottiene:<div></div>
<span style="font-family: monospace;"><nomi> = L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario)</span>
<div></div>
<span style="font-family: monospace;"><cognome> = A((?i)morosa)</span>
<div></div>
Infine, per completezza, viene mostrata la ''regular expression'', associata a quest'ultimo nominativo, risolvendo tutti i tag che la compongono:
<div></div>
<span style="font-family: monospace;">
<regex> = (?<=[^A-Za-zÀ-ÖØ-öø-ÿĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ]|^)(A((?i)morosa)\s+(L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario))|(L((?i)orenzo)\s+M((?i)ario)|M((?i)ario)\s+L((?i)orenzo)|L((?i)orenzo)|M((?i)ario))\s+A((?i)morosa))(?=[^A-Za-zÀ-ÖØ-öø-ÿĿŀČčŘřŠšŽžĲĳŒœŸŐőŰűḂḃĊċḊḋḞḟĠġṀṁṠṡṪṫĀāĒēĪīŌōŪūİıĞğŞşẀẁẂẃŴŵŶŷǾǿẞ]|$)
</span>
<div></div>

====Gestione delle omonimie====

Nei ragionamenti che hanno portato alla formulazione della ''regular expression'' associata ai nominativi, si è tenuto conto di possibili ambiguità con termini appartenenti al linguaggio comune, risolte con l'introduzione nel pattern di stringhe ''case-sensitive'', e di possibili nominativi posti in sequenza parzialmente omonimi (ossia aventi un nome o il cognome in comune tra loro), gestite con l'imposizione dei soli caratteri separatori non visibili come delimitatori delle parole componenti un nominativo. Per rendere l'analisi completa occorre valutare come ci si debba comportare in altri possibili casi di omonimia. Si osserva, per inciso, che nel pattern individuato nella sezione precedente il tag <span style="font-family: monospace;"><nomi></span> è stato l'unico non definito formalmente. La definizione di tale tag infatti dipende, oltre che dai nomi del nominativo, anche dall'insieme complessivo dei nominativi da trattare presenti nel documento.<div></div>
Il caso più semplice di omonimia, che si verifica quando un solo nome o il solo cognome di un nominativo coincide con un nome o il cognome di un altro (come nel caso di ''Lorenzo Mario Amorosa'' e ''Stefano Amorosa''), risulta già ben gestito dall'attuale formulazione del pattern. Infatti, un riconoscimento è determinato quando almeno un nome e il cognome del nominativo appaiono in sequenza.<div></div>
Il problema si complica quando un nominativo ha due o più componenti in comune con un altro. Si osserva che se l'omonimia riguarda solo i nomi dei nominativi, ciò non risulta problematico, in quanto il cognome, supposto sempre presente nel pattern, funge da elemento di disambiguazione. Si considera da ora, quindi, che i nominativi abbiano il medesimo cognome e si analizzano i casi in cui anche uno o più nomi risultano in comune, attraverso degli esempi:
* Nomi_A = {"Lorenzo", "Mario", "Luca"}; Nomi_B = {"Stefano", "Mario"}
<div></div>(QUI IMG [0F01])<div></div>
In questo caso sono elementi di disambiguazione i nomi ''Lorenzo'' e ''Luca'' per il primo nominativo e ''Stefano'' per il secondo, bisognerà quindi far sì che almeno uno tra tali nomi compaia sempre nelle ''regex'' associate ai nominativi in questione. L'occorrenza ''Mario <cognome>'' rimane ambigua e non può essere trattata.
* Nomi_A = {"Lorenzo", "Mario", "Luca"}; Nomi_B = {"Mario", "Luca"}
<div></div>(QUI IMG [0F02])<div></div>
L'insieme Nomi_B risulta un sottoinsieme di Nomi_A, di conseguenza solo il primo nominativo presenta degli elementi utili per risolvere l'ambiguità. Nel pattern relativo al primo nominativo dovrà essere presente almeno un tra i nomi non in comune, mentre il pattern del secondo nominativo rappresenterà inevitabilmente espressioni ambigue poiché riconducibili all'altro. Le soluzioni possibili sono due: rifiutarsi di effettuare il trattamento del secondo nominativo oppure decretare che esso è riconosciuto se e solo se appare nella sua forma estesa, presentando quindi tutti i nomi. Quest'ultima soluzione è ragionevole e la si sceglie, poiché così si aumentano, per quanto possibile, le sequenze "minimizzabili", e viene inoltre messo in conto di informare l'utente opportunamente sulla gestione di questo genere di omonimia per rendere le operazioni trasparenti.
* Nomi_A = Nomi_B = {"Lorenzo", "Mario", "Luca"}
<div></div>(QUI IMG [0F03])<div></div>
Qualora l'insieme dei nomi dei due nominativi sia identico risulta impossibile distinguerli e non possono in alcun modo essere trattati, poiché l'ordine con cui compaiono i nomi di un nominativo non rappresenta un elemento di disambiguità. I dati appartenenti a persone completamente omonime contenuti in uno stesso documento, quindi, non sono "minimizzabili" distintamente.<div></div>
Si osserva che è di fondamentale importanza che i documenti che gli utenti forniscono siano grammaticalmente corretti, in quanto un errato uso dei segni di interpunzione può rendere impossibile l'applicazione delle ''regular expression''. Si prenda ad esempio una sequenza anomala di caratteri in cui non è corretto l'uso delle virgole, come "''Amorosa Mario Rossi Giacomo''": supponendo che nel documento si vogliano trattare i nominativi ''Amorosa Mario'', ''Rossi Mario'' e ''Rossi Giacomo'', risulta impossibile identificare quali tra questi siano rappresentatati nella sequenza.<div></div>
In conclusione, risultano quindi individuate le strategie che permettono di formulare ''regular expressions'' anche per i nominativi soggetti ad omonimia.

====Formattazione dei documenti====

I documenti prodotti in enti ed organizzazioni presentano generalmente formattazioni e non sono puramente testuali. Si vuole qui considerare quale debbano essere le interpretazioni più adatte da dare agli elementi grafici per rendere sempre efficace il riconoscimento dei nominativi. In particolare, quindi, non si tratteranno gli elementi di punteggiatura, come parentesi o virgolette, poiché già compresi nelle ''regex'', bensì tutti gli elementi che in un pattern composto da caratteri non sono espressi. Si inizia dunque la rassegna:
* Elementi di formattazione del testo
I font, la dimensione dei caratteri, il grassetto, il corsivo, l'evidenziazione e tutti i possibili elementi di modifica della apparizione grafica del testo non alterano il significato dei lessemi coinvolti. Se il cognome di un nominativo è posto in grassetto ed il nome no, ad esempio, la coppia nome-cognome rappresenta sempre il nominativo iniziale; lo stesso vale per gli altri elementi citati.
* Aree di comparizione del testo
In genere ogni documento è formato da più sezioni, ha un corpo principale ed eventuali titoli, note a piè pagina, intestazioni ed altre possibili aree. Il trattamento di "minimizzazione", secondo il ''GDPR'', deve essere effettuato al documento in ogni sua parte, ma ogni sezione deve essere elaborata in maniera indipendente dalle altre sezioni in quanto rappresenta un blocco logico a sé. Ciò significa che, ad esempio, bisogna individuare eventuali nominativi presenti nel titolo, ma non bisogna considerare nominativo una sequenza di parole che è posta in parte nel titolo e in parte nel primo paragrafo del testo.
* Elementi blocco
Gli elementi blocco, come ad esempio le immagini, possono causare un'interruzione netta in un paragrafo, suddividendolo quindi in più blocchi logici, che devono essere analizzati separatamente; tuttavia nel caso in cui questi elementi siano posti ''fluttuanti'', ossia ancorati ai bordi della pagina, il testo scorre in un unico flusso e forma quindi un unico blocco logico.
* Divisione in sillabe
Un problema rilevante nella formattazione del documento è che spesso, per esigenze estetiche, contiene delle parole divise in sillabe poste su righe diverse e separate da un trattino. Ovviamente se un nome va a capo a fine linea non perde il suo significato semantico, bisognerà quindi continuare a riconoscerlo.
* Tabelle
Molti documenti, specialmente quelli contenenti ingenti quantità di nominativi, possono essere strutturati in forma tabellare. Trascurando una trattazione per esteso delle modalità con cui i nominativi potrebbero comparire nelle tabelle, si considera esclusivamente il caso di gran lunga più ricorrente. In genere, infatti, in una tabella contenente dei nominativi, essi sono presenti nella stessa colonna o in colonne contigue: l'una contenente i nomi, l'altra il cognome, o viceversa. Senza basarsi sull'intestazione delle colonne, si può valutare se il contenuto di due celle adiacenti poste su di una stessa riga faccia match con il pattern di un nominativo, ed in caso ciò accada si può affermare la coppia di celle individuata rappresenta un nominativo.<div></div>
Si osserva che si sono fornite solamente le interpretazioni più plausibili e comuni a questi elementi grafici e non si è ideato alcun particolare algoritmo per la loro elaborazione. L'espressione di tali strutture, infatti, è fortemente determinata dal formato in cui il documento è redatto. Si rimanda, quindi, ai capitoli successivi per specificazioni ulteriori della soluzione. Occorre notare, infine, che gli elementi di formattazione non sono descritti da stringhe nel formato delle ''regular expressions'': bisognerà quindi integrare gli elementi presentati in questa sezione con l'approccio ''pattern-based'' adottato.

===Analisi dell'usabilità===

====Elenco dei nominativi da trattare esplicitamente espressi come dati in input====

In questo caso, per usufruire del servizio, l'utente deve fornire un documento contenente una serie di nominativi da trattare. Una garanzia della corretta elaborazione del documento si ha richiedendo all'utente stesso quali siano i nominativi da trattare: in questo modo potranno essere "minimizzati" i dati (cioè i nominativi) di tutte e sole le persone espressamente richieste. In molti plausibili scenari, infatti, è necessario anonimizzare solo alcuni dei nominativi presenti nel documento; ad esempio in un atto giudiziario serve anonimizzare le parti in causa ma non i magistrati.

Questa configurazione del servizio permette quindi all'utente di avere il massimo controllo possibile del risultato. Tuttavia questo approccio è poco pratico nel caso in cui i documenti da trattare contengano grandi quantità di nominativi diversi e, magari, l'utente che ne richiede il trattamento non li conosce; si pensi ad esempio a lunghe graduatorie di concorsi o altro. Si osserva inoltre che anche per pochi nominativi l'usabilità può degradare, se l'inserimento viene fatto con estemporanea digitazione, esposta anche al rischio di possibili errori di battitura, con conseguenti noiose ripetizioni delle operazioni.

Si osserva, infine, che il sistema progettato è sufficientemente robusto nel trattare i nominativi in input espressi da un utente che ha digitato caratteri maiuscoli o minuscoli violando le convenzioni grammaticali. Supposto che il documento trattato debba essere grammaticalmente corretto, infatti, si ha la garanzia che i nomi ivi presenti comincino con una maiuscola; è sufficiente, quindi, forzare una conversione ''to-upper-case'' dei nomi inseriti dall'utente e le ''regex'' progettate funzionano correttamente. Un discorso a parte va fatto per i cognomi inseriti dall'utente, in quanto essi possono comparire con la prima lettera sia maiuscola che minuscola. L'inserimento di un cognome iniziante con una minuscola non crea grossi problemi, in quanto in tal caso la ''regex'' risultante sarebbe totalmente ''case-insensitive'' per il cognome, mentre l'aggiunta di un cognome cominciante con una maiuscola determina una ''regex'' ''case-insensitive'' per la prima lettera del cognome; qualora quindi un utente inserisse un nominativo tutto in maiuscolo, le occorrenze del cognome, presenti nel documento, inizianti con una lettera minuscola non verrebbero riconosciute.
Per le altre lettere dopo la prima, sia per i nomi che per i cognomi, il pattern è stato progettato ''case-insensitive'', quindi non emergono problemi. <div></div>
In sintesi, il rischio che vengano introdotte delle ambiguità lessicali, incaricando l'utente dell'inserimento dei nominativi, è piuttosto basso ed il controllo che si ha sui nominativi è il massimo desiderabile, mentre i requisiti di usabilità risultano penalizzati.

====Elenco dei nominativi da trattare dedotti automaticamente da un dizionario====

Se si desidera privilegiare la tematica dell'usabilità nella progettazione del servizio, risulta necessario individuare delle strategie che semplifichino il più possibile i compiti che devono essere svolti dall'utente. L'unica operazione che inevitabilmente resta a suo carico è l'upload del documento da trattare; non è infatti necessario richiedergli l'elencazione dei nominativi dei nominativi da trattare, in quanto questi possono essere dedotti automaticamente impiegando dei dizionari, dei quali va quindi valutato il contenuto e le modalità di utilizzo. <div></div>

Si scarta subito l'ipotesi di dedurre automaticamente i nominativi basandosi unicamente sul fatto che le iniziali di nomi e cognomi siano maiuscole; come già argomentato infatti l'uso delle lettere maiuscole non è limitato solo a questi usi e, inoltre, non si può avere la certezza che un cognome inizi con una maiuscola.

Sono disponibili fortunatamente alcuni dizionari di nomi ed altri di cognomi, in diverse lingue; si fa qui riferimento a quelli di "Data World" (un'azienda focalizzata sulla raccolta, produzione e pubblicazione di dataset: https://data.world) ([0037]).

Si inizia l'analisi inquadrando le dimensioni che un dizionario contenente nomi o cognomi avrebbe. Risalta subito all'occhio la differenza tra il numero di termini contenuti nei due casi: facendo riferimento ai soli nomi e cognomi italiani, risultano esistenti circa 350.000 cognomi ([0036]) e circa 9.000 nomi, dei quale circa 5.000 maschili e circa 4.000 femminili ([0037]); il numero dei cognomi è quindi quasi 40 volte più grande del numero dei nomi.<div></div>
Si ipotizza, per chiarire le idee, di applicare questi dizionari in uno scenario reale, in cui, ad esempio, si vuole trattare un documento di 10 pagine contenente 5.000 parole. Si trascurano inoltre i meccanismi che permettono di ricondurre un nome od un cognome ad un nominativo per concentrarsi unicamente sul numero di confronti necessari da effettuare nell'elaborazione. Nel peggiore dei casi possibili, ossia quando nessuna parola del documento compare tra i termini del dizionari, e dove occorre quindi confrontare ogni singola parola del documento con tutti i termini del dizionario, per semplice moltiplicazione si ottiene che l'impiego di un dizionario di nomi darebbe luogo a 45.000.000 confronti, mentre un dizionario di cognomi ben a 1.750.000.000 confronti. Se invece le parole nel documento fossero 50.000 si avrebbero 450.000.000 di confronti nel primo caso e 10.750.000.000 nel secondo. In sintesi, sebbene il rapporto tra il numero di confronti nei due casi rimanga sempre costante (circa 1:40) indipendentemente dalla lunghezza del documento, la differenza tra il numero di confronti cresce proporzionalmente al numero di parole che vengono sottoposte all'elaborazione. Per quantificare, infine, attraverso un unità di tempo, la differenza esistente tra l'impiego delle due diverse tipologie di dizionario, si realizza un semplice programma java, di cui si riporta qui sotto il contenuto del metodo principale, che realizza i confronti necessari attraverso l'uso di ''regular expression'':
<div></div>
<div style="font-family: monospace;">
final String regex = "\bLorenzo\b";<br/>
final String string = ... //testo di prova<br/>
<br/>
final Pattern pattern = Pattern.compile(regex, Pattern.MULTILINE);<br/>
final Matcher matcher = pattern.matcher(string);<br/>
int start, total;
<br/>
start = System.currentTimeMillis();
while (matcher.find()) {
System.out.println("Full match: " + matcher.group(0));
for (int i = 1; i <= matcher.groupCount(); i++) {
System.out.println("Group " + i + ": " + matcher.group(i));
}
} <br/>
total = System.currentTimeMillis() - start;
System.out.println("Total: " + total + " ms");
</div>
<div></div>
Eseguendo il test più volte, inserendo fino a 10 occorrenze della parola "Lorenzo" nel testo, si ha un tempo di elaborazione medio di circa 3 ms, con prestazioni di picco di 2 ms, ottenibili con poche occorrenze del nome presenti, e tempo di attesa massimo di 6 ms, dovuto alla presenza invece a una presenza più frequente del nome nel testo.
Questo fenomeno si comprende meglio ricordando che, come spiegato nel capitolo precedente, le ''regular expressions'' ottimizzano la ricerca, considerano le stringhe del testo trattato solo finché necessario, ossia fino a quando non vi è certezza che esse corrispondano o non corrispondano ad un match. Ogni volta che nel testo si presenta una parola che inizia con una lettera diversa dalla 'L' di "Lorenzo", la ricerca procede direttamente con la valutazione della parola successiva, ignorando i rimanenti caratteri della parola.

Risulta, invece, più onerosa la verifica della corrispondenza tra una stringa ed il pattern desiderato, poiché in questo caso vanno elaborati tutti i caratteri della parola. Come caso limite, si è posta come stringa da elaborare la sequenza di caratteri "Lorenzo " ripetuta 500 volte: il tempo di esecuzione medio del programma risultante, a parità di piattaforma, è stato di circa 25 ms.

Un'altra diretta conseguenza di questo meccanismo di confronto è che all'aumentare del numero di parole nel documento non corrisponde un eccessivo aumento del tempo di esecuzione: considerando un documento di 5000 parole, con 0 occorrenze del nome "Lorenzo" il tempo di esecuzione medio risulta di 9 ms, con 10 occorrenze di 10 ms, con 100 occorrenze di 15 ms.

Occorre precisare, prima di formulare ulteriori ragionamenti, che in documento di 5.000 parole potranno essere presenti al più 2500 coppie nome-cognome; in un dizionario con più di 2.500 termini almeno uno di questi non contribuirà nell'individuazione di un nominativo. Se poi sono presenti altre parole oltre ai nominativi nel documento, la percentuale di nomi che presenterà 0 occorrenze crescerà di conseguenza. Ad ogni modo, si sceglie di sviluppare i ragionamenti considerando necessario il tempo medio di 10 ms per individuare le occorrenze di un termine di un dizionario in un documento di 5.000 parole; questo tempo è sicuramente maggiore rispetto al caso reale, ma valutando per eccesso questo valore è possibile trascurare il tempo impiegato nelle altre operazioni di routine a supporto dell'algoritmo di ricerca.

Ritornando all'esempio di partenza, considerando quindi necessari 10 ms per individuare le occorrenze di un termine di un dizionario in un documento di 5.000 parole, risulta che l'identificazione di tutti i cognomi contenuti nel testo richieda circa 3.500 secondi, (quasi un'ora!), mentre l'individuazione dei nomi "solo" 90 secondi.
I tempi di attesa che l'utente dovrebbe aspettare sono estremamente elevati e irragionevoli, specialmente se calati nel contesto nelle ''web application''. Come primo espediente per ovviare al problema si decide di abbandonare completamente l'idea di impiegare un dizionario di cognomi, in quanto, seppur si individuassero delle soluzioni in grado di effettuare il riconoscimento di tutte le occorrenze di un termine in un documento indipendentemente dalla lunghezza in solo 1 ms (irreale), sarebbero comunque necessari 3 minuti e 50 secondi per l'elaborazione. Non verranno quindi neppure trattate possibili soluzioni che prevedono l'applicazione di entrambi i dizionari.

I 90 secondi richiesti dal dizionario di nomi, invece, risultano anch'essi eccessivi, ma attraverso opportune valutazioni si possono individuare delle strategie che consentono la minimizzazione del tempo necessario all'elaborazione dei documenti. Tali metodi di ottimizzazione saranno trattati in un successivo capitolo, mentre ora ci si continua a concentrare sulle modalità di impiego del dizionario.

Per inciso, si osserva che i problemi di efficienza sono strettamente legati al riconoscimento automatico dei nominativi, in quanto in questo caso devono essere applicate quasi una decina di migliaia di ''regex'' diverse; nel caso in cui i nominativi da elaborare e le ''regex'' a loro associate siano noti, si ha a che fare con un numero esiguo di pattern da trattare e l'esecuzione del programma risulta infinitamente più rapida.<div></div>

Per migliorare l'efficacia del servizio sarebbe opportuno introdurre nel dizionario anche nomi stranieri, sempre più diffusi in una società sempre più globalizzata. Il tempo di esecuzione medio del riconoscimento, già critico, crescerebbe ulteriormente: si decide allora di introdurre nel dizionario i soli nomi inglesi, in totale quasi 5500 ([0037]). Considerando sempre un tempo medio di esecuzione di 10 ms per nome, con un dizionario di circa 14.500 termini si avrebbe un tempo di esecuzione medio complessivo di 145 secondi, ossia pari a 2 minuti e 25 secondi, e risulta ancora possibile effettuare alcune ottimizzazioni che lo riducono ad un livello accettabile.

Una volta individuati i nomi contenuti nel documento occorre stabilire se essi fanno parte di un nominativo, progettando un'opportuna ''regular expression''. È importante notare che per conseguire questo scopo bisogna individuare la soluzione più efficiente possibile.

Un nominativo, come già ripetuto più volte, è composto da uno o più nomi e da un cognome. Individuato un nome, la priorità che si ha è verificare se accanto ad esso sia presente un cognome. Finora i cognomi sono stati supposti non regolamentati da alcun pattern specifico, ma è necessario formularne almeno uno per consentirne il riconoscimento automatico. È ragionevole supporre che un cognome sia formato da massimo due parole, separate da spazio o apostrofo, sempre inizianti entrambe con una maiuscola, fatta eccezione per la prima parola laddove essa sia una preposizione semplice o articolata oppure un articolo, tenendo conto dei possibili troncamenti, come <i>d'</i> e <i>dell'</i>. Inoltre per verificare se un termine adiacente al nome trovato rappresenti un nome si evita di impiegare nuovamente il dizionario per non gravare ulteriormente sul tempo di esecuzione. Inoltre, si nota che avendo supposto un cognome composto da massimo due parole inizianti con una lettera maiuscola, un altro nome, oltre quello trovato dal dizionario, viene già automaticamente riconosciuto qualora il cognome sia composto da una sola parola. Rinunciando ad individuare nominativi composti da tre nomi o più, si formula una ''regular expression'' per il riconoscimento automatico in seguito al identificazione di un nome, qui indicato con il tag <span style="font-family: monospace;"><nome></span>, supponendo il cognome come precedentemente indicato e ipotizzando la presenza di un ulteriore nominativo.
<div></div>
<div style="font-family: monospace;">
<prep> := d((a|e)(l(l[aeo]?)?|i|gli?)?|i)?|(ne|a|su)(l(l[aeo]?)?|i|gli)?|l[aeo]?|co[iln]?|i[ln]?|gli|per

<cognome> := (([A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]*|<prep>)('|\s))?[A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]+

<second_name> := [A-Z][a-zA-ZÀ-ÖØ-öø-ÿ]+

<regex> := (<second_name>\s)?(<nome>)\s<cognome>|<cognome>\s(<nome>)(\s<second_name>)?
</div>
<div></div>
Nella scrittura della ''regex'' si è prestata particolare attenzione all'utilizzo della simbologia per rendere l'espressione il più performante possibile, attraverso il massimo sfruttamento dei cortocircuiti logici e l'opportuno ordinamento dei caratteri (sono stati anteposti i caratteri comuni a più preposizioni od articoli). Inoltre, per alleggerire la ''regex'' si è rinunciato all'utilizzo dei caratteri dell'alfabeto latino non appartenenti ai primi due blocchi Unicode.
<div></div>
È mostrata in figura la corretta elaborazione di 57 possibili casi di cognomi diversi
<div></div>(QUI IMG [0F04])<div></div>
Si osserva tuttavia che in alcune circostanze, come nella frase "''di Amorosa Lorenzo non si hanno notizie''", accade che un parola ("''di''" in questo caso), non sia parte del cognome ma il programma non è in grado di riconoscerlo. Questa ambiguità è fortemente dipendente dal contesto e non è possibile trattarla senza significativi degradi delle performance; quindi è necessario rinunciare a trattarla, accettando riconoscimenti erronei. In altre situazioni, invece, dove magari si sta elaborando la stringa contenente il nominativo ''Mario Lorenzo'', risulta impossibile determinare quale tra i due termini sia il nome e quale il cognome; cioè significa che l'unico trattamento di "minimizzazione" automatico che risulta ragionevole applicare è la sostituzione del nominativo con uno pseudonimo, non il troncamento o l'alterazione dei nomi.
In conclusione, con il riconoscimento automatico dei nominativi si migliora complessivamente l'usabilità del servizio, in quanto l'utente non deve digitare i nominativi, ma la latenza introdotta è notevole, si è soggetti a rischi di ambiguità e non è in alcun modo esprimibile la preferenza su quali nominativi si desidera "minimizzare" o meno. La soluzione così ideata non risulta quindi adeguata.

====Soluzione ibrida adottata====
Entrambe le tipologie di riconoscimento prima individuate hanno significativi problemi, si cerca quindi di sintetizzare una soluzione in grado di trarre i vantaggi dell'una e dell'altra. Risulta efficace, in particolare, che il documento venga inizialmente trattato tramite dizionari, evitando all'utente l'onere di specificare i nominativi, e che in seguito venga lasciata all'utente la possibilità di intervenire.
Infatti, esso potrebbe voler esprimere delle preferenze su quali nominativi debbano essere trattati tra quelli individuati e gestire gli eventuali errori di riconoscimento dovuti a richieste di trattamento di nominativi aventi un nome non presente nel dizionario o anche dovuti a casi di ambiguità lessicale già presentati.

Una volta inserito il documento e terminata l'elaborazione tramite il dizionario, l'utente può sia richiedere l'immediato download del file ed effettuare le operazioni prima definite, attraverso un'opportuna interfaccia. Per fornire il supporto alle esigenze più disparate, si prevede la possibilità di:
# eseguire download del file trattato unicamente con il dizionario
# ripetere la "minimizzazione" del documento, specificando:
## nuovi nominativi
## quali nominativi tra quelli precedentemente individuati ''non'' si vogliono trattare
## quale parola/e dei nominativi individuati rappresenta il cognome (in tal caso, si possono utilizzare altri metodi, oltre alla sostituzione con pseudonimo, per il trattamento)
## quale parola/e dei nominativi individuati non compone il nominativo (situazione che si verifica quando ci si imbatte in una ambiguità).

Senza soffermarsi in questo momento sull'intera sequenza concreta di interazioni tra utente e servizio, si osserva che l'unico vincolo non funzionale da valutare resta il tempo medio di attesa dell'utente. L'usabilità complessiva è molto buona ed i vincoli funzionali sono soddisfatti.

===Scelta dei formati da trattare===

Una considerazione intuitiva, ed una buona prassi, è che un documento contenente dati personali sia pseudonimizzato o anonimizzato quanto prima possibile e cioè quando è ancora solo nelle mani del suo autore: questo approccio scongiura che informazioni sensibili e dati personali in chiaro ''sfuggano'' in rete.
Si può per questo ragionevolmente ipotizzare che i naturali destinatari del servizio siano gli stessi autori (creatori) che redigono il documento. Nello scenario tipico di utilizzo, infatti, il fruitore del servizio procederà al trattamento dei dati non appena avrà finito di scrivere il documento del quale, essendone autore, potrà scegliere il formato. Si osserva che potrebbe accadere che il documento sia redatto da terzi: in tal caso l'utente che richiede il trattamento può scegliere il formato in maniera indiretta concordandolo con il redattore. Avendo quindi l'utente la possibilità di stabilire il formato del proprio documento, risulta ragionevole progettare un servizio che lavori su un solo formato.
A questo punto occorre individuare quale sia il formato che maggiormente si presta alle finalità del servizio.<div></div>
Una possibilità è quella di richiedere all'utente di inserire come documento da trattare un semplice file di testo in formato ''txt'': in questo modo ci sarebbe il grande vantaggio di trattare file molto semplici, riducendo così al minimo la complessità realizzativa, e inoltre si avrebbe l'indipendenza dagli editor di testo utilizzati, in quanto tutti supportano i file in formato ''txt''.
Risulta tuttavia sconveniente utilizzare questo formato, poiché non ha alcuna capacità espressiva per gestire elementi complessi come tabelle, modifiche allo stile del testo e così via.
Bisogna quindi optare per un formato in grado di gestire questi elementi, al costo di aumentare la complessità della progettazione, ricordando sempre che è necessario allo stesso tempo che tale formato sia supportato da tutti i principali editor di testo.<div></div>
Con facilità è possibile individuare quali sono i formati di testo più comuni oltre al ''txt'': ''doc'', ''docx'', ''odt'', ''pdf'', ''pages'', ''rtf'', ''tex''. Si passa ora dunque a valutare quale tra questi formati potrebbe meglio soddisfare i requisiti prima enunciati.
Facendo una cernita iniziale sulla base delle finalità per le quali un formato è utilizzato, si può immediatamente escludere ''tex'', che trova impiego principalmente in ambito scientifico e matematico. In questo settore, infatti, non è richiesta generalmente l'applicazione delle procedura di trattamento dei dati. <div></div>
Si può inoltre abbandonare l'idea di trattare documenti con estensione ''pages'', formato proprietario di Apple, poiché utilizzati esclusivamente dall'omonimo editor di testo anch'esso proprietario, e i documenti con estensione ''rtf'', acronimo di ''Rich Text Format'', formato proprietario di Microsoft che supporta una formattazione avanzata, poiché, pur gestito da vari editor, è un formato decisamente datato (ultima versione 1.9.1 risalente a marzo 2008 ([0009])). <div></div>
Si esclude inoltre il formato ''pdf'' per motivi di usabilità: molti editor, infatti, consentono di esportare un documento in questo formato ma non permettono di importarlo. Un utente dopo aver effettuato l'anonimizzazione di un documento non può quindi proseguire modificandolo ulteriormente. Il ''Portable Document Format'', infatti, è ideato per realizzare dei documenti destinati alla sola lettura.
L'ultima esclusione, piuttosto immediata da effettuare, riguarda il formato ''doc'', binario e proprietario di Microsoft. Esso infatti risulta, a partire dal 2006, soppiantato dal formato ''docx'', sempre proprietario di Microsoft.

Si giunge infine a valutare quale tra gli ultimi due possibili formati rimanenti, ossia ''docx'' e ''odt'', si presta meglio alle finalità del servizio. In via preliminare si osserva che entrambi i formati possiedono ottime capacità espressive, hanno una struttura interna di simile complessità e sono entrambi supportati dai principali editor di testo. È necessario quindi effettuare delle analisi più approfondite per poter sceglierne uno tra i due.
La struttura del formato ''docx'', sviluppato da Microsoft e formalmente denominato ''Office Open XML Document (OOXML Document)'', è costituita da un file compresso .zip contenente un insieme di file ''XML''. Il formato ''OOXML'' permette la rappresentazione, oltre che di documenti testuali, anche di fogli elettronici (formato ''OOXML 'Workbook'', noto anche come ''xslx'') e di presentazioni (formato ''OOXML Presentation'', noto anche come ''pptx'') ([0008], [0013]).
Il formato inoltre è stato inizialmente standardizzato nel 2006 dall'<i>ECMA</i> (come ''ECMA-376'') e successivamente nel 2008 dall'<i>ISO</i> e dall'<i>IEC</i> (come ''ISO/IEC 29500'') in una versione ''transitional'', retrocompatibile con alcune versioni precedenti del formato contenenti elementi deprecati, e in una versione ''strict'', dove tali elementi non sono ammessi. I due standard sono stati poi successivamente aggiornati e sono tutt'ora oggetto di revisioni ([0002]).

Anche la struttura del formato open source ''odt'', sviluppato dall'<i>OASIS</i> e formalmente denominato ''OpenDocument Text'', è basata su uno zip contenente un insieme di file ''XML''. Inoltre, il formato ''OpenDocument Format (ODF)'' permette di trattare fogli elettronici (formato ''OpenDocument Spreadsheet'', noto anche come ''ods'') e presentazioni (formato ''OpenDocument Presentation'', noto anche come ''odp'') ([0007]). Anche ''OpenDocument Text'' è stato standardizzato, in particolare dall'<i>OASIS</i> stesso nel 2005 e dall'<i>ISO/IEC</i> nel 2006, ed è soggetto a revisioni e aggiornamenti ([0003]).

In sintesi, basandosi sulla struttura dei documenti e sulla standardizzazione dei formati, non è ancora possibile individuare quale sia il formato migliore. L'unico elemento che potrebbe portare punti a favore del formato ''odt'' è che esso, a differenza del formato ''docx'', è aperto, tuttavia, essendo le specifiche di entrambi i formati pubbliche, ciò non rappresenta un fattore determinante nell'elezione del formato.
Entrambi i formati, inoltre, sono largamente supportati dai word processors.

Le seguenti tabelle riepilogano il supporto all'uno ed all'altro formato dei ''word-processors'' più usati, ossia ''Microsoft Office Word'', ''LibreOffice Writer'', ''OpenOffice Writer'' e ''Pages''.
Le tabelle sono tratte da wikipedia ([0000], [0001], [0006]). <div></div>

<center><i>Supporto fornito dagli editor di testo al formato docx</i></center>
{| class="wikitable"
|-
! !! Microsoft Office Word !! LibreOffice Writer !! OpenOffice Writer !! Pages
|-
! Version
|| 2013, 2011 for Mac || All versions || 3.0 || '08
|-
! Operating systems
|| Windows, Mac OS X || Windows, OS X, Linux, Unix, Android || Windows, Linux, Unix, Mac OS X || Mac OS X
|-
! Office suite
|| Microsoft Office || || OpenOffice.org || iWork
|-
! Developer
|| Microsoft || The Document Foundation || Apache OpenOffice || Apple Inc.
|-
! License
|| proprietary || MPL || LGPL || proprietary
|-
! ECMA-376
|| yes || yes || yes || yes
|-
! ISO/IEC 29500:2008
|| yes || yes || ||
|-
! Notes
|| || || Import only ||
|}

<div></div>
<center><i>Supporto fornito dagli editor di testo al formato odt</i></center>
{| class="wikitable"
|-
! !! Microsoft Office Word !! LibreOffice Writer !! OpenOffice Writer
|-
! Version
|| 2007 SP2 || 4.0.3 || 3.0.0
|-
! Operating systems
|| Windows || Unix-based systems, Mac OS X, Solaris || Windows, Linux, Unix-based systems, Mac OS X, Solaris
|-
! Office suite
|| Microsoft Office || || OpenOffice.org
|-
! Developer
|| Microsoft || The Document Foundation || Apache OpenOffice
|-
! License
|| Proprietary || MPL || LGPL
|-
! ISO/IEC 26300:2006
|| yes || yes || yes
|-
! Notes
|| some limitations || Multiple ODF versions supported (ISO/ODF 1.0/1.1/1.2/1.2 Extended) || adjustable ODF version (ISO/ODF 1.2)
|}
<div></div>

Si possono effettuare le seguenti osservazioni:
* ''Microsoft Office Word'' è, in ambiente Microsoft, il word processor maggiormente usato; è molto usato anche in ambiente Apple Mac. Esso offre il pieno supporto al formato ''OOXML Document''; solo parzialmente invece gestisce il formato ''OpenDocument Text'': il processamento di file con estensione ''odt'' con questo editor comporta la perdita di alcune informazioni secondarie.
* ''LibreOffice Writer'', l'editor open source maggiormente utilizzato, supporta pienamente entrambi formati. Nato con lo scopo di gestire i file con formato ''OpenDocument Text'', attualmente supporta completamente anche il formato ''OOXML Document''.
* ''OpenOffice Writer'', un altro degli editor di testo tra i più utilizzati, supporta pienamente ''odt'', mentre è solo in grado di importare i file con estensione ''docx''.
* ''Pages'', il word process installato a default sui Mac della Apple e, di conseguenza anche maggiormente usato su questi dispositivi, non offre supporto al formato ''odt'', ma elabora correttamente i documenti con estensione ''docx'' ([0005],[0004]). <div></div>
Queste osservazioni evidenziano che quindi è impossibile adottare un formato supportato da tutti gli editor; la scelta va allora indirizzata verso quello maggiormente supportato dai word processor più popolari.
Per avere un'indicazione di ''popolarità'', e quindi per poter comprendere meglio quali tra gli editor prima citati siano i più usati, si può fare un'analisi, tramite motori di ricerca, di quanti file con una certa estensione siano presenti in rete.
È possibile, ad esempio, ricercare su Google i file che contengono nel proprio nome una determinata sequenza di caratteri o aventi una certa estensione (''filetype''). Sono qui presentati i risultati delle interrogazioni riguardo ai file aventi formato ''docx'', ''doc'' e ''odt'' ed il cui nome contiene uno dei caratteri, fra i più frequenti, "1" o "a" o "e". L'investigazione è stata effettuata inserendo nella barra di ricerca di Google le stringhe ''1 filetype:docx'', ''a filetype:docx'' e così via.

{| class="wikitable"
|-
! Formato cercato !! Documenti con "1" nel nome !! Documenti con "a" nel nome !! Documenti con "e" nel nome
|-
| docx || 16.900.000 || 12.800.000 || 8.730.000
|-
| odt || 736.000 || 667.000 || 507.000
|-
| doc || 32.300.000 || 26.300.000 || 21.500.000
|}

Effettivamente il formato più diffuso è il ''doc''; tuttavia esso è supportato per retro-compatibilità anche dagli editor che supportano formati ''OOXML'', con i quali non si ha difficoltà nel convertire i documenti dal formato ''doc'' al ''docx''. In conclusione, quale che sia l'editor più diffuso, è ragionevole adottare il formato ''OOXML Document'' per le finalità del servizio, in quanto molto diffuso, ben supportato dagli editor e avente ottime capacità espressive. Di conseguenza i documenti che saranno elaborati dovranno essere forniti dall'utente in tale formato. In successive sezioni verrà approfondita la struttura dei documenti ''OOXML''.

===Privacy by design===

L'Art. 25 del ''GDPR'', con i Considerando 75 e 78, ha per titolo e per oggetto la "protezione dei dati fin dalla progettazione e protezione per impostazione predefinita" ([0035]), perfettamente in linea con i concetti di "minimizzazione", già richiamati.<div></div>
Il senso dell'Art. 25 viene spesso sintetizzato con l'espressione "''PbD - privacy by design, privacy by default''" ([0035]). Il principio fissato nell'Art. 25 dovrà sempre più essere tenuto ben presente nell'ambito dell'ingegneria del software, in quanto impone di adottare nuove cautele nella realizzazione delle applicazioni software.<div></div>
Del principio ''PbD'' si è ben tenuto conto nella progettazione descritta in questa tesi. In particolare, relativamente alla ''privacy by design'', si è fatto in modo che nessun dato personale permanga registrato sul sistema di esecuzione, o altrove, al termine dell'applicazione. Anche laddove l'applicazione termini in modo anomale non vi sono strutture dati superstiti, che restano memorizzate sul sistema.<div></div>
Marginale in questa tesi è la nozione di ''privacy by default'', giacché l'applicazione non offre all'utente alcuna opzione che possa indurlo in errore ed acconsentire a trattamenti dei dati personali, oltre quello realizzato dall'applicazione.<div></div>
È utile osservare quanto sia importante esprimere queste impostazioni di progettazione fra le condizioni d'uso presentate all'utente: esse costituiscono uno dei presupposti affinché l'utente abbia piena fiducia (''trust'') nel servizio, lo utilizzi, lo divulghi, lo renda un servizio di successo.

==Architettura del servizio==

===I componenti software nell'architettura LAMP===

Il servizio è realizzato in forma di ''web-based application'' poiché, come già illustrato nell'introduzione, si intende renderlo disponibile per il massimo numero di utenti possibili. Nella progettazione e realizzazione dell'architettura web si adotta la piattaforma ''LAMP'', il cui nome deriva dall'acronimo dei componenti open source che la realizzano (il sistema operativo Linux, il server HTTP Apache, il sistema per la gestione di database relazionali MySQL ed il linguaggio di programmazione PHP). Poichè il modello è composto da quattro livelli, spesso si parla anche di ''stack LAMP''. Uno degli elementi di forza del modello ''LAMP'' è che i componenti dei vari ''layer'' sono sostituibili, a seconda delle esigenze, con dei componenti più adatti, tipicamente open source ([0015], [0018], [0019]). Basando la piattaforma su un sistema operativo della famiglia di Microsoft Windows, ad esempio, si ottiene uno ''stack WAMP'', mentre se si usa un sistema operativo Mac OS si realizza uno ''stack MAMP''. Un'architettura web basata sul modello ''LAMP'' può, inoltre, essere integrata con software open source che offre utili funzionalità, come, ad esempio, il monitoraggio (''Nagios''), il load balancing (''Linux Virtual Server''), la rilevazione di accessi illeciti (''Snort'') e il security testing (''netsniff-ng''). <div></div>
Si valutano ora brevemente la diffusione dei componenti tradizionali dello ''stack LAMP'' e le alternative maggiormente usate per i vari ''layer''.
Le distribuzioni Linux risultano essere la scelta più comune per l'ultimo ''layer'' dello ''stack''. Secondo W3Techs, infatti, nell'ottobre del 2013, il 58.5% dei web server a livello globale avevano come sistema operativo la distribuzione Debian o Ubuntu, mentre il 37.3% una tra RHEL, Fedora e CentOS([0016]). <div></div>
Tra i web server, Apache risulta essere maggiormente usato. Secondo le stime fatte da Netcraft, a giugno del 2014 circa il 51.9% del milione di siti web più trafficati al mondo usavano un web server Apache, il 19.2% nginx ed il 12.4% Microsoft ([0017]). <div></div>
I principali ''DBMS'' relazionali, oltre a MySQL, che possono essere presenti nello ''stack LAMP'' sono MariaDB e PostgreSQL, mentre tra i ''DBMS NoSQL'' MongoDB risulta essere il più comune. <div></div>
Nello stack, infine, il ruolo di linguaggio di programmazione, solitamente svolto dal linguaggio PHP, spesso è ricoperto dai linguaggi Perl o Python. <div></div>
Si osserva, ad ogni modo, che le informazioni sulla diffusione delle tecnologie non rappresentano un fattore vincolante nella scelta delle stesse, in quanto la piattaforma ''LAMP'' è anche aperta verso molti altri componenti oltre quelli citati; di conseguenza la scelta delle tecnologie da impiegare può essere effettuata basandosi principalmente sui requisiti e sulle specifiche del servizio. <div></div>

===Principi di progettazione per l'architettura===

====Single Responsibility Principle====

Per rendere il servizio maggiormente manutenibile ed estensibile, si presta particolare attenzione al rispetto del ''Single Responsibility Principle'' (''SRP'') ([0020]). Si cerca, quindi, di fattorizzare il software in più moduli, suddividendo tra questi le elaborazioni da svolgere. Un altro importante beneficio che si ottiene dalla fattorizzazione del codice è la riusabilità dei componenti. Ogni singolo modulo, infatti, svolge il proprio compito in maniera indipendente dal resto della applicazione ed è, quindi, riutilizzabile in altri scenari simili senza dover essere re-implementato. Inquadrando meglio questa metodologia di progettazione con i requisiti del servizio e la piattaforma web ''LAMP'', si individuano i due principali compiti a carico dell'applicazione:
* La gestione dell'interazione web con l'utente per la trasmissione del documento e dei nominativi da trattare
* Il processamento del documento per effettuare la "minimizzazione" dei dati.
Questi due differenti ''task'' saranno, quindi, portate a termine da componenti diversi.<div></div>
Progettando la struttura dell'applicazione in questo modo, si disaccoppia completamente la logica di business del servizio dalle interfacce web di comunicazione con l'utente. In un futuro sviluppo sarà possibile, quindi, realizzare nuove interfacce utilizzando altre tecnologie senza dover modificare la logica applicativa.

====Dependency Inversion Principle====

Un altro principio di design architetturale che risulta importante nella progettazione è il ''Dependency Inversion Principle'' (''DIP'') ([0038]). Esso si traduce nella realizzazione di componenti che non dipendono dalle specifiche implementazioni degli altri moduli del sistema, bensì dalle loro ''astrazioni''.
In relazione all'estensibilità e manutenibilità del prodotto software, infatti, l'impiego di moduli dipendenti direttamente dalla definizione dei metodi presenti in altri componenti risulta problematica: il modulo dipendente deve essere re-implementato ad ogni variazione del modulo da cui dipende.
Nella programmazione orientata agli oggetti, per rispettare questo principio, si su può fare uso di classi astratte o interfacce, costrutti che definiscono i moduli senza implementarli completamente o senza implementarli affatto.

===Stile architetturale REST===

Il modello architetturale del servizio che si sta definendo presenta una serie di caratteristiche, come ad esempio l'indipendenza dei moduli, che permettono di realizzarlo secondo il paradigma delle ''RESTful API''. L'espressione "Representational State Transfer" e il suo acronimo "REST" furono introdotti nel 2000 nella tesi di dottorato di Roy Fielding ([0021]), uno dei principali autori delle specifiche dell'Hypertext Transfer Protocol (HTTP). Roy Fielding descrive il ''Representational State Transfer'' come uno stile architetturale ("''architectural style''"), ovvero un'astrazione degli elementi di un'architettura all'interno di un sistema hypermedia distribuito. ''REST'' non specifica i dettagli dell'implementazione dei componenti e della sintassi del protocollo, ma definisce i ruoli dei componenti, i vincoli sulla loro modalità di interazione e la loro interpretazione.
Riassumiamo quindi i principi che deve rispettare una architettura ''REST'':
# Architettura Client-Server <br/>In una architettura ''REST'' viene data particolare importanza ai principi ''SRP'' e ''DIP'' prima citati, più generale si può affermare che l'architettura sposi il paradigma noto con il termine di "''Separation of Concerns''". Una ''Restful API'' applica questi principi in un architettura Client-Server, capace di supportare l'evoluzione indipendente della logica lato client e della logica lato server.
# Stateless <br/>La comunicazione tra utente e fornitore del servizio deve essere senza stato, quindi ogni richiesta del client deve contenere tutte le informazioni di cui il fornitore necessita per l'erogazione del servizio offerto. Questa ipotesi viene fatta per rendere una ''Restful API'' facilmente scalabile orizzontalmente.
# Uso della cache <br/>In un Architettura ''REST'' i messaggi di risposta inviati dal server devono esplicitamente indicare se possono essere memorizzati nella cache del client o di componenti middleware per il riutilizzo nelle richieste successive.
# Interfaccia uniforme <br/>I componenti devono essere in grado di comunicare attraverso un'interfaccia uniforme e le risorse devono essere trasferite in un formato standard. Inoltre l'utente deve poter effettuare la navigazione tra le risorse di suo interesse tramite collegamenti ipertestuali. Per inciso, si osserva che il protocollo HTTP usato correttamente rispetta i requisiti di un architettura ''REST'' e che nelle implementazioni delle ''RESTful API'' il formato più usato per la modellazione dei dati è JSON.
# Layered System <br/>In un sistema a livelli, componenti intermedi (come i proxy) possono essere collocati tra client e server per intercettare il traffico per scopi specifici; ad esempio il caching o la sicurezza. Una soluzione basata su ''REST'' può essere composta da più livelli architettonici, indipendenti l'uno dall'altro.
# Code on Demand <br/>Questo vincolo facoltativo è inteso principalmente a consentire aggiornamenti alla logica all'interno dei client (come i browser Web) indipendentemente dalla logica lato server. Una ''single page application'', ad esempio, rispetta in pieno questo punto.

Un'applicazione progettata sul modello dell'architettura ''REST'' ha quindi gli indiscutibili vantaggi di:
* consentire l'evoluzione indipendente delle diverse componenti
* avere un'interfaccia utente portabile con altri tipi di piattaforme
* permettere agevolmente la replicazione delle macchine server
* non vincolare moduli server e client a linguaggi e tecnologie specifiche.

L'architettura del servizio oggetto di questa tesi si trova già perfettamente in linea con alcuni dei vincoli discussi, ma sono necessarie alcune considerazioni. Il punto 1 ("architettura Client-Server") è chiaramente soddisfatto.
Il punto 2 ("Stateless"), direttamente collegato con i punti 3 e 5 ("Uso della cache", "Layered System"), può essere rispettato con facilità; a ogni richiesta di "minimizzazione" del client corrisponde la restituzione del documento trattato dal server, non c'è quindi necessita di avere uno stato nell'interazione.

Analizzando le caratteristiche di una applicazione stateless in relazione al principio ''privacy by design'' illustrato in precedenza, si osserva che l'assenza di stato determina la semplificazione delle problematiche critiche relative al principio. Non vengono conservate, infatti, informazioni contenenti dati sensibili, poiché dopo aver effettuato l'invio della risposta, sarà subito eliminato sul server il file elaborato.

Nei capitoli precedenti tuttavia si è detto che l'utente può ripetere più volte il trattamento di uno stesso documento nella stessa sessione di interazione; essendo il vincolo dell'efficienza già difficile da rispettare per via dell'elaborazione onerosa del documento, si può progettare una modalità alternativa del funzionamento con stato del servizio, applicabile in assenza di replicazione delle macchine server e sfruttando le ripetute richieste di trattamento per uno stesso documento.
Si può infatti memorizzare lato server il documento inviato dal client inizialmente e, alle successive richieste di trattamento del medesimo documento, evitarne la ritrasmissione da client a server. Per rispettare il ''PbD'', al termine della sessione di interazione il documento verrà rimosso dal server. Si nota, inoltre, che per predisporre il servizio alla gestione delle due diverse modalità di funzionamento si può utilizzare un parametro di configurazione a livello applicativo.
I punti 4 e 6 infine ("Interfaccia uniforme", "Code on Demand") si possono rispettare utilizzando il formato JSON per la trasmissione dei documenti e dei nominativi, e usando localmente sul client Javascript per offrire tutte le funzionalità del servizio in un'unica pagina html.

===Moduli software del servizio===

====Scelta dei componenti software====

Si opera ora la scelta delle tecnologie da utilizzare per i componenti dei 4 layer dello ''stack LAMP''. Per i due layer inferiori risulta piuttosto immediato decidere di usare le tecnologie presenti per default. Un sistema operativo Linux ed un web server Apache sono adatti all'architettura del servizio.
Inoltre anche il linguaggio di programmazione PHP può essere usato senza significativi problemi, anche se verranno fatte in seguito, in una sezione di questo capitolo, alcune considerazioni sulle problematiche di esecuzioni concorrenti di script PHP. Il linguaggio sarà impiegato in particolare per la realizzazione della logica necessaria a gestire l'interazione web con il cliente, mentre l'elaborazione del documento OOXML lato server sarà effettuata da un programma Java.

I due ''task'' principali del servizio sono delegati, quindi, a due programmi distinti realizzati con tecnologie diverse. Si concretizza in questo modo il principio ''SRP'' e, sfruttando l'<i>openness</i> della piattaforma LAMP, le funzionalità necessarie vengono realizzate attraverso i linguaggi più adatti.
La scelta del linguaggio Java per l'implementazione del ''main core'' della logica di business è dovuta alla libreria open source in ambiente java Docx4j ([40],[41]). Questa libreria è realizzata per il processamento delle tre tipologie di formati OOXML (''docx'', ''xslx'', ''pptx'') e permette tutte le possibili operazioni di creazione, lettura e modifica su questo tipo di documenti. Anche questa libreria sarà approfondita in sezioni successive. Si osserva, per inciso, che esistono altre librerie equivalenti in ambiente .NET.

Nella scelta del linguaggio di programmazione usato per elaborare i documenti ed effettuare i confronti tramite ''regular expressions'', un dato non di poco conto da considerare è l'encoding delle stringhe. In Java, in particolare, una stringa è rappresentata internamente come un array di char, ognuno codificato da 2 byte in formato UTF-16 ([0042]); la codifica esprime in 16 bit tutti i caratteri definiti dallo standard Unicode, quindi è possibile scegliere Java.

Per il ''layer'' della persistenza, infine, l'impiego di un database MySql risulta una buona scelta. Si osserva che questo livello non verrà utilizzato nella tradizionale maniera prevista dallo ''stack LAMP''. Infatti, generalmente, la base di dati viene interrogata direttamente dal componente che si occupa dell'interazione con l'utente (PHP) per il reperimento delle informazioni utili da restituire al client; nel servizio, invece, la base di dati sarà a supporto unicamente del programma Java, poiché gli unici dati persistenti da gestire sono i nomi del dizionario (si ricordi sempre il ''PbD'') e solo i moduli dell'eseguibile Java devono utilizzarli. Se il dizionario contenessero unicamente i nomi (senza informazioni accessorie correlate) e fossero usati in sola lettura, un semplice file di testo poteva essere sufficiente per la rappresentazione. Tuttavia, poiché saranno individuate tecniche di ottimizzazione nell'impiego dei dizionari che richiedono operazioni di scrittura e ordinamento dei dati, risulta opportuno usare un database relazionale.

====Logica di business e dinamiche di interazione====

Vengono presentati in questa sezione gli aspetti principali dei funzionamenti dei moduli del servizio. Per mettere bene a fuoco quali siano le meccaniche di interazione e i flussi di esecuzione dei programmi, si propone il diagramma di sequenza del tipico scenario di utilizzo. In questo schema UML si descrive il caso d'uso dove un utente, dopo aver inserito un documento ed averlo ricevuto "minimizzato", esprime delle preferenze e richiede poi un secondo trattamento.<div></div>
<div></div>(QUI IMG [0F00])<div></div>
Si descrivono quindi ora le principali operazioni che vengono eseguite.
All'avvio dell'interazione viene presentata una pagina PHP di benvenuto contenente le informazioni su come i dati personali vengano elaborati ed un ''file-picker'' per consentire l'upload di un documento ''OOXML''; nel momento in cui l'utente confermerà il caricamento del documento, esso verrà trasferito sul server.
Bisogna prestare particolare attenzione al comportamento del sistema nel caso in cui più utenti richiedano contemporaneamente l'esecuzione del servizio, e cioè alle problematiche di esecuzioni concorrenti di script PHP; è necessario, in particolare, evitare situazioni in cui i nomi dei file inviati dagli utenti siano in conflitto. Analizzando più in dettaglio il problema, ogniqualvolta un web server Apache riceve una richiesta HTTP per una pagina PHP, si ha la generazione di un nuovo processo che esegue il codice presentato nella pagina PHP richiesta. Supponendo quindi che N utenti eseguano l'invio del file contemporaneamente, si avrebbe che sul server N processi diversi dovrebbero procedere con la scrittura di un file. Ovviamente se due o più file condividono il nome almeno uno di essi sarà sovrascritto. Per risolvere questo problema, supponendo di voler salvare tutti i documenti in una cartella temporanea, occorre modificare il filename dei documenti inviati dagli utenti per esser certi di non incorrere in sovrascritture o altri tipi di errori correlati.
Una valida possibilità è l'inserimento di un ''prefisso'' univoco nel filename. Per la generazione di una stringa univoca da anteporre al filename, che permetta di distinguere file caricati da utenti diversi, si può direttamente usare il ''session id'' dell'utente. In PHP esso è determinato casualmente combinando ([0043]): l'IP del cliente, orario di attribuzione dell'id, un numero pseudo-casuale (con il ''PHP Linear Congruence Generator'') e, se presente un "''random source''" sul sistema operativo del Client (spesso chiamato impropriamente "''seme''"), un ulteriore numero pseudo-casuale.
Per introdurre ulteriore alea, necessaria se, ad esempio, un utente tenti l'upload di file omonimi (con contenuto interno diverso) e mantenga il medesimo ''session id'', si utilizza un ulteriore generatore pseudo-casuale per produrre un altro numero con cui comporre il prefisso.
Concatenando i due numeri generati si ha praticamente certezza di aver individuato un numero univoco nel sistema per il tempo in cui il servizio sarà erogato al cliente.

Una volta memorizzato il file, lo script PHP dovrà ricorrere all'invocazione del modulo Java, delegato al vero e proprio processamento del documento. Occorre quindi individuare un set di opzioni che consenta al modulo che gestisce l'interazione con il cliente di sfruttare al meglio il componente delegato all'elaborazione del documento, in qualunque circostanza; la totale indipendenza dei moduli, la loro sostituibilità e la replicazione possibile di macchine server sono solo alcuni dei fattori che rendono mutevole la configurazione del sistema. Va definito un protocollo di comunicazione, quindi, che astragga completamente dall'implementazione dei moduli o dalla locazione dei file.

Valutando i possibili flussi logici, anche con l'ausilio del diagramma di sequenza, si ha che i tipi di esecuzione sono due:
* "minimizzazione" con dizionario
* "minimizzazione" di specifici nominativi
Il protocollo di comunicazione tra i due moduli è costituito in entrambi i casi di una singola richiesta a cui segue una singola risposta. Più in particolare, lo script PHP invoca il comando Java esprimendo obbligatoriamente il path del file da trattare e opzionalmente l'elenco dei nominativi. A suo volta, il modulo Java restituisce i nominativi trovati, qualora non espressamente richiesti dallo script, e segnala la corretta terminazione dell'elaborazione.
Si definiscono come canali di comunicazione standard del protocollo gli argomenti presi in input dal modulo di processamento del documento e lo standard output del processo che esegue tale programma. Inoltre è importante definire un formato standard per la comunicazione dei nominativi tra moduli; è necessario quindi scegliere un pattern che permetta di determinare univocamente la composizione dei nominativi. Un possibile formato, espresso tramite ''regex'', è il seguente:
<div></div>
<span style="font-family: monospace;"> <nominativo> = ^(<nome>:)*<nome>;<cognome>$</span>
<div></div>
<span style="font-family: monospace;"> <nominativi> = ^(<nominativo>\s+)+$</span>
<div></div>
Dove nome e cognome sono una sequenza di caratteri Unicode come già discusso. Ulteriori opzioni importanti da definire nel protocollo per l'invocazione del programma che si occupa delle funzionalità di elaborazione sono le seguenti:
* path file da elaborare (opzione "-i <file_path>", obbligatoria)
* path con cui salvare il file elaborato (opzione "-o <file_path>", opzionale: per default viene creato un nuovo file automaticamente)
* abilitazione stampe verbose, da usare solo in fase di debug (opzione "-d", opzionale)
<div></div>
Una volta terminato il processamento, il modulo di gestione dell'interazione con l'utente dovrà accertarsi che l'<i>exit status</i> sia 0 e leggere dallo standard output del processo appena terminato, qualora si sia stata eseguita la "minimizzazione" con dizionario, l'elenco dei nominativi trovati. Se invece la "minimimizzazione" ha avuto luogo con i nominativi già specificati non sarà scritto nulla sullo standard output.
A margine si osserva che l'impiego dell'opzione "-d" deve sempre consentire una semplice individuazione dei nominativi trovati; in particolare, se tale opzione è specificata, nello standard output i nominativi compariranno con un ''header'' riconoscibile ("''NOMINATIVO=''").
Ritornando alla descrizione del flusso di esecuzione tipo, una volta che il modulo Java ha completato il trattamento del documento, lo script PHP ne effettuerà l'upload sul client e presenterà all'utente le opzioni già descritte nel capitolo sull'usabilità.
A questo punto l'interazione con client potrebbe concludersi, qualora si eseguisse il download e si chiudesse il browser, o continuare elaborando i ''suggerimenti'' dell'utente espressi dopo il primo trattamento. Le modalità di comunicazione dei moduli varierebbero leggermente come appena illustrato, mentre, a seconda della configurazione stateful o stateless del servizio, verrebbe eseguito o meno un nuovo upload del file dal client al server.<div></div>

Si osserva infine che, per predisporre a successivi studi di ottimizzazione il servizio e per agevolare tutti i possibili sviluppi futuri, si applica largamente nella progettazione del modulo di elaborazione Java il ''Dependency Inversion Principle'', in quanto si desidera realizzare classi estendibili ed intercambiabili.
In particolare, si introducono delle classi astratte per rappresentare in maniera generica il concetto di "''persona''" e "''minimizzatore''". È possibile infatti realizzare successivi studi per trattare ulteriori dati personali oltre che ai nomi e cognomi; inoltre, in base ai tipi di documenti trattati o eventuali altri fattori utili, è possibile studiare differenti tecniche di "minimizzazione" realizzate da differenti algoritmi "''minimizzatori''".
In particolare una "''persona''" dovrà sempre esporre un metodo "''minimizza''" che prende in input una stringa, la "minimizza" e la restituisce; il pattern con il quale si effettua la "minimizzazione" sarà fornito in implementazione a seconda dei dati sensibili di interesse.
Un "''minimizzatore''" esporrà sempre un metodo "''work''" che, presa in input una lista di persone ed un documento ''OXML'', con l'ausilio della libreria Docx4j, fornirà in output un documento del tutto "minimizzato"; la definizione delle modalità con cui si estrapolano le informazioni dal documento e con cui si invoca il metodo "''minimizza''" della classe persona sono confinate nell'implementazione.
Definendo delle classi astratte risulta, quindi, più veloce la realizzazione dei futuri componenti e si svincola il processo di "minimizzazione" dal tipo di dati che si "minimizzano" e viceversa.

====Le classi principali del progetto====
Le classi principali del progetto vengono quindi presentate in appendice. Esse sono:
* App.java, contenente il main
* Elaborator.java, che presenta il metodo "''work''"
* Persona.java, che presenta il metodo "''minimizza''"
* Testing.java, contenente alcune funzioni usate in fase di debug.

Gli script in PHP sono stati forniti dall'azienda come implementazione minimale e provvisoria, da perfezionare a seguito della eventuale definizione sulle modalità di presentazione del servizio su Internet.

Una considerazione di implementazione comune a tutte le classi deriva del principio ''Privacy by Design'', indifferentemente dalla modalità di configurazione stateful o stateless del servizio: è di fondamentale importanza che nel sistema non siano memorizzati permanentemente in alcun caso i documenti inviati dagli utenti del servizio.
Per realizzare un sistema robusto, per fronteggiare crash improvvisi del client o congestioni della rete, è opportuno impostare dei timeout lato server che procedano automaticamente alla eliminazione dei documenti degli utenti dopo un periodo di inattività troppo prolungato. Qualora invece si dovesse verificare un interruzione critica del servizio a causa di un errore logico del server o semplicemente per via di un'interruzione dell'alimentazione della macchina server, bisogna considerare altri metodi; essendo il servizio realizzato con un sistema operativo Linux, si può configurare il demone ''crond'' per eseguire a ogni reboot e, per sicurezza, una volta al giorno l'eliminazione dei file usati dall'applicazione tutti contenuti all'interno della cartella temporanea.

==Approfondimenti tecnologici==

===Analisi della struttura del formato OOXML===

Come argomentato, il formato dei documenti elaborati dal servizio progettato dovrà essere ''Office Open XML'', o ''OOXML''; si tratta di un formato ''XML-based'' per documenti di testo, fogli elettronici e presentazioni, in grado di rappresentare grafici, diagrammi, immagini e altro materiale grafico. La specifica fu sviluppata da Microsoft e adottata dall'<i>ECMA International</i> come standard ''ECMA-376'' nel 2006. Una seconda versione fu rilasciata nel 2008, una terza nel 2011, una quarta nel 2012 ed una quinta tra il 2015 ed il 2016 ([0010]). La specifica è stata adottata, inoltre dall'<i>ISO</i> e dall'<i>IEC</i> come standard ''ISO/IEC 29500'' a partire dal 2008 ([0011], [0012]).

====Linguaggi di markup====

Lo standard ''ECMA-376'' ([0010]) include tre differenti specifiche di linguaggio per ognuna delle tre principali categorie di documenti:
* ''WordprocessingML'' per i documenti testuali
* ''SpreadsheetML'' per i fogli elettronici
* ''PresentationML'' per le presentazioni elettroniche
* ''DrawingML'' ed altri linguaggi di markup di supporto per la rappresentazione di disegni, forme e diagrammi.
<div></div>
La specifica include sia gli schemi ''XML'' sia i vincoli espressi per iscritto. Ogni documento conforme al formato dovrà, quindi, rispettare gli schemi ''XML'' e dovrà essere codificato in ''UTF-8'' o ''UTF-16''. La specifica, inoltre, permette l'aggiunta di ''custom tag XML'' a supporto dei linguaggi di markup dati, per default nel formato ''OOXML'', consentendo quindi la libera personalizzazione dei documenti.

====File packaging====

Oltre alla specifiche relative ai linguaggi di markup, la seconda parte dell'<i>ECMA-376</i> ([0010]) definisce la struttura gerarchica dei file del formato adottando le ''Open Packaging Conventions'' (''OPC''). ''OPC'', una tecnologia ''file-container'' basata sul comune formato compresso ''zip'', che stabilisce che tutti i file che riguardano una stessa entità devono essere raggruppati in un unico package ([0014]). Un documento ''OOXML'' è, infatti, un archivio ''zip'' contenente alcuni files ''XML'' (detti anche ''parti'') organizzati in un singolo package. Questa frammentazione dei dati in più files rende più semplice e veloce l'accesso ai dati stessi e riduce le possibilità di una loro corruzione. Le ''parti'' possono contenere qualsiasi tipo di dato; per tenere traccia della relazione tra una ''parte'' e la sua tipologia di contenuto, senza basarsi sull'estensione del file, è presente nel package, nella cartella radice della gerarchia, il file denominato ''[Content_Types].xml'', il quale mappa appunto queste associazioni. È mostrata qui ad esempio l'associazione tra la ''parte'' rappresentante il documento principale e il suo ''ContentType''.
<div style="font-family: monospace;">
<Override PartName="/word/document.xml" ContentType="application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml"/>
</div>
Le informazioni relative alle relazioni che ogni ''parte'' ha con le altre ''parti'', con risorse esterne e con il package in sé sono mantenute separatamente dal contenuto della ''parte'' stessa. Tali informazioni sono presenti, infatti, all'interno delle cartelle denominate ''_rels'': ne esiste una per il package nel suo complesso e una per ogni sotto-cartella del package contenente delle ''parti'' coinvolte in delle relazioni. In questo modo i riferimenti che una ''parte'' ha verso altre ''parti'' o risorse sono salvati una sola volta e possono essere aggiornati con semplicità se necessario, senza dover modificare il contenuto stesso delle ''parti'' coinvolte. È mostrato qui un esempio di relazione contenuta in ''_rels/.rels'' relativa al documento principale e al suo schema.
<div style="font-family: monospace;">
<Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument" Target="word/document.xml"/>
</div>
Il documento principale, ossia il file ''word/document.xml'', ha inoltre numerose relazioni con altre ''parti'', come ad esempio ''word/styles.xml'' e ''word/footer.xml'', e risorse esterne collegate con degli URI. Per descrivere queste relazioni si usa la cartella ''word/_rels''.

====Parti di un Documento OOXML====

Vengono qui presentate le ''parti'' che sono caratteristiche esclusive di un ''WordprocessingML package'', non presenti quindi negli altri due formati ''OOXML''. È importante osservare che alcune di esse sono facoltative e sono presenti nel package solo se necessario.

Le ''parti'' relative al vero e proprio contenuto testuale sono:
* ''Main Document'', contiene le informazioni principali ed è salvata come ''word/document.xml''
* ''Header'', contiene i dati relativi alle intestazioni ed è salvata in ''word/header.xml''. Ogni sezione del documento può avere intestazioni diverse per la prima pagina, per le pagine pari e per le dispari, quindi possono esserci molteplici ''parti header''
* ''Footer'', contiene le informazione relative al piè pagina ed è salvata in ''word/footer.xml''. Può essere presente più volte, per motivi analoghi alla ''parte header''
* ''Footnotes'', contiene le eventuali note a piè pagina del documento ed è salvata come ''word/footnotes.xml''
* ''Endnotes'', contiene le note di chiusura del documento ed è salvata in ''word/endnotes.xml''.

Sono presenti poi delle ''parti'' relative allo stile e alle impostazioni del documento:
* ''Style Definitions'', contiene la definizione di un insieme di stili usati dal documento, salvata in ''word/styles.xml''
* ''Font Table'', contiene informazioni riguardo i font usati, salvata in ''word/fontTable.xml''
* ''Numbering Definitions'', contiene le definizioni sulla struttura delle liste contenute nel documento, salvata in ''word/numbering.xml''
* ''Document Settings'', specifica come il word processor debba trattare il documento (spell checking, gestione delle revisioni, etc.), contenuta in ''word/settings.xml''
* ''Web Settings'', contiene informazioni su come il documento debba essere convertito in ''HTML'' se richiesto, contenuta in ''word/webSettings.xml''.

Sono presenti anche delle ''parti'' che rappresentano testo secondario:
* ''Comments'', contiene i commenti sul documento inseriti attraverso un word processor
* ''Glossary'', contiene dati testuali aggiuntivi secondari, ne è permessa una sola. Tutte le ''parti'' prima elencate, tranne il ''Main Document'', possono comparire una seconda volta in relazione alla ''parte glossary''.

====Analisi del Main Document====

Il file ''document.xml'', elemento principale di un documento ''WordprocessingML'', è costituito da due tipi di informazioni:
* ''properties'', che definiscono lo stile e la formattazione del testo
* ''stories'', che rappresentano il contenuto testuale delle varie parti del documento.

Le ''properties'' verranno trattate in misura minore. Queste informazioni sono espresse attraverso una struttura XML gerarchica che ha come elemento radice il nodo ''document''. Esso ha due nodi figli:
* ''background'', che contiene alcune ''properties'' che descrivono lo sfondo del documento
* ''body'', che contiene tutti i rimanenti contenuti ed è potenzialmente molto complesso.

Si osserva che per le finalità del trattamento dei dati risultano di primario interesse le ''stories'' e che è opportuno effettuare un'analisi ''bottom-up'' del problema: anziché considerare la gerarchia a partire dal ''body'' (nodo padre) partiremo dalla rappresentazione più semplice del testo contenuta nel documento (nodi figli).

Facendo direttamente riferimento allo standard ''ECMA-376'' ([0010]), si evince che l'unico nodo che contiene puro testo ha il nome ''t'' (''Text''). Questo elemento contiene una stringa rappresentante gli esatti caratteri che vengono poi mostrati negli editor a video. Il nodo ''Text'' non presenta figli e l'unico nodo padre che può avere è ''r'' (''Run''). Quest'altro nodo definisce una regione di testo con comuni proprietà (ad esempio l'uso del grassetto). Attraverso l'uso di tag ''t'' ed ''r'' quindi si rappresenta una regione di testo formattata con differenti elementi stilistici.
Occorre però evidenziare che un nodo ''r'' può presentare molti altri figli oltre a ''t'', come ad esempio immagini, in quanto rappresenta un'area generica del documento.
Si supponga quindi di avere due nodi ''Text'' fratelli, ossia figli dello stesso nodo ''r'': essi rappresenteranno semanticamente un unico blocco logico se e solo se compariranno a video come una sequenza di parole continua. Questo fenomeno è facilmente identificabile anche nel file ''XML'' descrittivo: due sequenze di parole mostrate a video adiacenti compaiono infatti nel file ''XML'' in due righe consecutive; se invece due parti di testo dovessero essere intervallate ad es. da un'immagine nel documento ''XML'' ci sarebbe un tag ''drawing'' a dividere i due tag ''t''. Dalla consecutività dei nodi ''Text'' nel file ''document.xml'' si può determinare quali siano i blocchi logici da trattare.
Un insieme di ''Run'' infine può essere figlio di diversi nodi, ma ciò non è di rilevante importanza, in quanto ogni area di testo individuata dal nodo ''Run'' rappresenta già un blocco logico a sé e, di conseguenza, contiene sufficienti informazioni per la "minimizzazione".
L'unico caso di rilievo nel quale bisogna valutare quale sia la gerarchia a monte di un nodo ''Run'' è nell'elaborazione di una tabella. In tal caso, in realtà, occorre verificare opportunamente la strutturazione della gerarchia processata. Per chiarezza espositiva viene mostrata la rappresentazione in formato ''OOXML'' di una tabella con una riga e due colonne (senza l'uso di ''properties'' per la formattazione stilistica).
<br/>
<div style="font-family: monospace;">
<w:tbl>
<w:tr>
<w:tc>
<w:p>
<w:r>
<w:t>Cella A</w:t>
</w:r>
</w:p>
</w:tc>
<w:tc>
<w:p>
<w:r>
<w:t>Cella B</w:t>
</w:r>
</w:p>
</w:tc>
</w:tr>
</w:tbl>
</div>

Come si osserva in figura, in una tabella il nodo ''r'' sarà figlio del nodo ''p'' (''Paragraph''), il quale a sua volta sarà contenuto in un noto ''tc'' (''Table Cell''). Celle di una tabella appartenenti ad una stessa riga saranno presenti all'interno dello stesso ''tr'' (''Table Row'') ed infine tutte le righe della tabella saranno inserite del tag ''tbl'' (''Table'').

Per determinare quindi se due nodi ''Text'' sono scritti in due colonne adiacenti di una stessa riga (e quindi costituiscono un unico blocco logico) è necessario verificare che per i due nodi ''Text'':
# il nodo "padre" '''non sia''' in comune
# il nodo "padre di 2° livello" sia ''Paragraph'' e '''non sia''' in comune
# il nodo "padre di 3° livello" sia ''Table Cell'' e '''non sia''' in comune
# il nodo "padre di 4° livello" sia ''Table Row'' e '''sia''' in comune
# i nodi "padre di 3° livello" '''siano''' consecutivi.
Se tutte queste ipotesi sono soddisfatte, le due celle vanno "minimizzate" come unico blocco logico.

Si valutano infine gli ultimi vincoli emersi nell'analisi sull'interpretazione della formattazione di un documento.
In particolare, descrivendo le parti che compongo un documento ''OOXML'', era già emerso che alcune sezioni di testo, ossia note a piè pagina ed intestazioni, compaiono in altri file ''XML'' e non in ''document.xml''. Questi file (''header.xml'', ''footer.xml'', ''endnotes.xml'', etc.) sono tutti raccolti in un package ("''word''") e la grammatica ''XML'' è la stessa usata per il Main Document.
Si conclude osservando che il problema della divisione in sillabe delle parole non si pone, in quanto la divisione sillabica mostrata a video dai word-processors è calcolata dinamicamente; in particolare, su una porzione di testo viene applicata la sillabazione (ove necessario) se è presente tra le ''properties'' di quella regione di documento il tag ''hyphenationZone''.

====La libreria in ambiente java open source Docx4j====

La libreria Docx4j offre completo supporto alla manipolazione di documenti ''docx'' (compressione e decompressione archivio zip, generazione file ''XML'' necessari, etc.). Offre inoltre un'utile mappatura in specifici oggetti Java della gerarchia ''XML'' presente nei vari file del formato.
Uno tra gli elementi più interessanti è la tecnica con cui vengono recuperati i nodi dai file ''XML'', in quanto si fa impiego del linguaggio standard W3C ''XPath'' ([0044], [0045]). Con ''XPath'' è possibile esprimere con una stringa un sottoinsieme di nodi presenti in una gerarchia ''XML'' non solo in base al loro nome o valore, ma anche in relazione alla posizione reciproca rispetto agli altri nodi. Riferendoci alle problematiche del servizio risulta, ad esempio, significativamente agevolato il trattamento di dati personali in forma tabellare.
Si osserva infine che la libreria attribuisce un id univoco ad ogni nodo del documento, di conseguenza se ne può trarre vantaggio nei confronti tra i nodi.

===Ottimizzazioni del processo di minimizzazione===

===Tecnologie complementari===

La redazione di questa tesi è avvenuta su Mediawiki, la più importante fra le piattaforme wiki essendo il motore di Wikipedia.

Le piattaforme wiki sono riconosciute come elemento caratterizzante dell’evoluzione Internet al Web 2.0, cioè al web nel quale gli utenti-navigatori, fino ad allora "''consumatori"'' ("''consumers"'') di contenuti si sono trasformati essi stessi in "''produttori"'' ("''producers"''), e cioè in "''prosumers"''.

Un ''wiki'' è fondamentalmente un sito web che contiene informazioni e che consente agli utenti di editare facilmente il suo contenuto.

Nel redigere una pagina wiki si utilizza ciò che è chiamato ''wikitext" per definire capitoli, paragrafi, hyperlinks, elementi di formattazione della pagina, etc.; sebbene il ''wikitext" risulti non difficile da apprendere, quasi ogni piattaforma wiki è corredata da editor di tipo visuale, che non richiede alcuna conoscenza della sintassi del ''wikitext"; tuttavia è esperienza comune che utilizzare direttamente il ''wikitext" induce a concentrarsi maggiormente sui contenuti e non sulla formattazione. Il linguaggio ''wikitext'' è strettamente correlato con il linguaggio HTML, infatti nella scrittura è possibile utilizzare tag come h1, span, div e così via, oltre che la sintassi esclusiva di ''wikitext''; simmetricamente una pagina prodotta da media wiki è costituita da HTML ben formato e direttamente importabile in ogni word processor.

I wiki presentano una funzionalità di grande utilità nella redazione di documenti articolati: la tracciatura delle successive revisioni ("''Cronologia"''). La possibilità di ripercorrere l’evoluzione del testo è davvero d’aiuto quando si fissano idee originali in uno scritto, cercando di definirle, precisarle, chiarirle, come è avvenuto in effetti, anche nella redazione di questa tesi. Per curiosità, si segnala che, pur avendo redatto la maggior parte del testo off-line, la pagina wiki di questa tesi conta oltre 50 revisioni.

Per inciso, si osserva che è stata molto utile la funzionalità di "ricerca nel codice" offerta dalla piattaforma di revisione online GitHub nella corretta comprensione della libreria Docx4j, il cui codice sorgente è ivi rilasciato.

Si conclude infine dicendo che per ottimizzare le procedure di debug del codice sono stati realizzati utili tool a riga di comando per Linux per la rapida estrazione-modifica-ricompattazione di documenti ''OOXML''. Si propone in appendice un comando bash per questi scopi.

==Sviluppi futuri==

In questa sezione si fa cenno, senza poterle approfondire, ad alcune interessanti questioni emerse nello svolgimento della tesi.

===Accesso al servizio web===

In fase iniziale, il servizio web potrà essere reso accessibile in forma completamente aperta, senza richiedere cioè la registrazione dell’utente o l’autenticazione dell’utente già registrato. In questo modo, in effetti, si premia la facilità d’uso, ma si incorre nella nota problematica di un uso malevolo, costituito da accessi a raffica, finalizzati a saturare il server e generare una condizione di ''DoS – Denial of Service''. Diverse sono le tecniche che possono essere adottate per contrastare questo tipo di accessi malevoli, come richiedere di superare "''captcha''" e/o introdurre ritardi crescenti ed eventualmente blocchi in risposta ad accessi prevenienti con alta frequenza dallo stesso indirizzo IP.
È possibile anche pensare ad un accesso previa registrazione ed autenticazione dell’utente, penalizzando l’immediatezza di utilizzo del servizio, ma eventualmente ottenendo l’indirizzo email degli utenti che acconsentono a lasciarlo per successive finalità marketing.
È possibile, infine, un utilizzo misto, contando in un cookie il numero di accessi eseguiti e richiedendo all’utente di registrarsi per continuare ad utilizzare il servizio, dopo qualche accesso.

===Ampliamento dinamico del dizionario===

Nel restituire il documento elaborato all'utente, gli si da la possibilità di richiedere una nuova elaborazione, dopo aver indicato i nominativi che fossero sfuggiti; pare inesauribile, infatti, la "fantasia" dei genitori nel dare nome ai propri figlioli!
I nominativi indicati dall'utente sono sfuggiti al servizio perché non presenti nel dizionario: facilmente viene in mente l’idea di arricchire il dizionario con i nominativi indicati dall’utente. Va però considerato il caso che l’utente in malafede indichi nominativi fasulli al fine di inquinare il dizionario.
Il caso malevolo può essere affrontato attraverso una strategia che preveda non direttamente l'inserimento del nuovo nominativo nel dizionario, ma invece l'utilizzo di un concetto di "candidatura": il nuovo nominativo viene registrato, ma si attende di avere un certo numero di utenti che lo propongono prima di approvarne l'inserimento nel dizionario.
Può anche essere utilizzato un concetto di "attendibilità" della candidatura di un nuovo nominativo, verificando ad esempio l'utente che lo propone scarichi effettivamente il file rielaborato.
Nel caso l'accesso avvenga con autenticazione, e cioè identificando gli utenti, si apre la possibilità di individuare e bannare gli utenti malevoli.

===Natura del documento e ricorrenza del nominativo===

Si coglie facilmente la differenza di formato fra un documento in forma di elenco (es. una graduatoria) da un documento in forma di relazione (es. una sentenza giudiziaria). Differenze di questo tipo potrebbero essere utilizzate per escludere o ammettere la ripetizione dei nominativi.
Per meglio dire: in un elenco la ripetizione di un nominativo è di fatto da escludersi o va trattata come omonimia. In una relazione, l’individuazione di un nominativo può essere utilizzata per ricercarlo direttamente in altri punti del documento stesso.

===Altri dati personali===

Altri dati personali sono trattabili con le stesse tecniche analizzate in questa tesi: date e luoghi di nascita, codici fiscali, indirizzi, email, numeri di telefono, sesso etc. In qualche caso, come per i codici fiscali, l’individuazione del pattern da trattare è persino più semplice.
Diversi studi ([0039]) hanno dimostrato che, utilizzando set di dati personali parziali, è possibile la re-identificazione dei soggetti, pur in documenti pseudonimizzati. È questo un altro motivo per estendere i trattamenti descritti anche agli altri dati personali richiamati.

===Altri alfabeti===

È possibile estendere il sotto-insieme di caratteri Unicode utilizzati nelle ''regex'' per elaborare documenti scritti in altri alfabeti non latini.

==Conclusioni==

Questa tesi è partita da un problema basilare, quasi scolastico, dell'informatica: la ricerca di un testo in un documento, al fine della sua cancellazione o modifica.

Il problema si è subito discostato dalla sua formulazione basilare, principalmente perché, nei casi d'uso, il documento da ricercare non è un semplice testo ("''plain text''") ma invece è il prodotto di un ''word-processor'': quindi è costituito da una struttura XML più o meno complessa, rappresentante formattazioni, riferimenti interni o esterni, note, etc. La ricerca deve avvenire nei soli nodi di puro testo, individuando ed escludendo dall'analisi lessicale gli elementi testuali di mark-up che non costituiscono contenuto informativo. Nell'approfondire le strutture ed i concetti XML ho potuto notare quanto essi siano ricorrenti in molti ambiti dell'informatica.

Nell'analisi delle specifiche, un'altra complicazione si è presto aggiunta: l'usabilità del servizio cresce drasticamente se si evita di chiedere all'utente, come si era pensato in un primo tempo di fare, quali siano le stringhe (i nominativi) da ricercare e trattare; è nata allora l'idea di reperire queste stringhe in un dizionario di nomi ed in un dizionario di cognomi, considerando anche le permutazioni dei lemmi reperiti. Ho così dovuto approfondire alcuni problemi tipici dei dizionari, come il loro ampliamento automatico con tecniche oggi comprese nel ''machine-learning''. Non ho potuto "resistere" alla tentazione di ''formalizzare la matematica'' in base alla quale ho costruito le strategie di ricerca.

Spunto per la tesi è stata la recente legislazione in materia di dati personali, il GDPR. Esaminandone gli articoli pertinenti, ho maturato una riflessione generale: sempre più il software dovrà essere progettato e realizzato anche alla luce di altre discipline, non solo di quelle informatiche, come le discipline giuridiche ed il diritto.

Durante la fase iniziale della collaborazione con l'azienda mi sono dedicato alla messa a punto delle specifiche; ciò mi ha permesso di comprendere quanto questa fase sia importante e come completezza e precisione delle specifiche siano alla base di un progetto efficace.

Molto importanti sono state la analisi relative al tipo e formato dei documenti da assumere come input ed alla presentazione ottimale del servizio rispetto all'usabilità.

Centrale nel lavoro ed avvincente è stata la definizione della strategia per il riconoscimento dei lessemi attraverso la costruzione dinamica di ''regex'' idonee. In questo fase del lavoro, anche per passione personale, ho approfondito le questioni del riconoscimento "di testi nei testi" che legano, fin dalle origini, l'informatica e la linguistica.

La fase di definizione dell'architettura del servizio mi ha permesso di ripercorrere molte le materie studiate nei tre anni del Corso di Ingegneria Informatica, affrontando argomenti come il Single Responsibility Principle, il Dependency Inversion Principle, lo "stile" architetturale REST. Molto istruttiva è stata anche la riflessione sulla scomposizione del servizio in moduli software.

Come sempre accade nell'affrontare un progetto nuovo, sono nate molte nuove idee; ho così immaginato numerosi sviluppi futuri, sia a perfezionamento funzionale dell'accesso web al servizio, sia ad estensione delle specifiche per coprire casi applicativi contigui (es. quando il dato che si vuole trattare è un codice fiscale). Dovendo necessariamente tener presente che questo lavoro è una tesi, verificherò con il supporto del mio relatore come poterne proseguire lo sviluppo.

==Bibliografia==

<div></div>[0000]https://en.wikipedia.org/wiki/Comparison_of_Office_Open_XML_software
<div></div>[0001]https://en.wikipedia.org/wiki/Comparison_of_OpenDocument_software
<div></div>[0002]https://en.wikipedia.org/wiki/Standardization_of_Office_Open_XML
<div></div>[0003]https://en.wikipedia.org/wiki/OpenDocument_standardization
<div></div>[0004]https://support.apple.com/en-us/HT202227
<div></div>[0005]https://en.wikipedia.org/wiki/Pages_(word_processor)
<div></div>[0006]https://en.wikipedia.org/wiki/Comparison_of_word_processors
<div></div>[0007]https://en.wikipedia.org/wiki/OpenDocument
<div></div>[0008]https://en.wikipedia.org/wiki/Office_Open_XML_file_formats
<div></div>[0009]https://en.wikipedia.org/wiki/Rich_Text_Format
<div></div>[0010]https://www.ecma-international.org/publications/standards/Ecma-376.htm
<div></div>[0011]https://www.iso.org/standard/51463.html
<div></div>[0012]https://www.iso.org/standard/71691.html
<div></div>[0013]https://en.wikipedia.org/wiki/Office_Open_XML
<div></div>[0014]https://en.wikipedia.org/wiki/Open_Packaging_Conventions
<div></div>[0015]https://en.wikipedia.org/wiki/LAMP_(software_bundle)
<div></div>[0016]https://w3techs.com/blog/entry/debian_ubuntu_extend_the_dominance_in_the_linux_web_server_market_at_the_expense_of_red_hat_centos
<div></div>[0017]https://news.netcraft.com/archives/2014/06/06/june-2014-web-server-survey.html
<div></div>[0018]https://whatis.techtarget.com/definition/LAMP-Linux-Apache-MySQL-PHP
<div></div>[0019]https://www.ibm.com/cloud/learn/lamp-stack-explained
<div></div>[0020]https://en.wikipedia.org/wiki/Single_responsibility_principle
<div></div>[0021]https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
<div></div>[0022]https://en.wikipedia.org/wiki/Latin_script_in_Unicode
<div></div>[0023]https://it.wikipedia.org/wiki/ISO/IEC_8859-1
<div></div>[0024]http://www.treccani.it/enciclopedia/uso-delle-maiuscole_%28La-grammatica-italiana%29/
<div></div>[0025]https://en.wikipedia.org/wiki/Ambiguity#Linguistic_forms
<div></div>[0026]Steven L. Small; Garrison W Cottrell; Michael K Tanenhaus (22 October 2013). Lexical Ambiguity Resolution: Perspective from Psycholinguistics, Neuropsychology and Artificial Intelligence. Elsevier Science. ISBN 978-0-08-051013-2.
<div></div>[0027]http://www.treccani.it/vocabolario/disambiguazione/
<div></div>[0028]R. Navigli, K. Litkowski, O. Hargraves. 2007. SemEval-2007 Task 07: Coarse-Grained English All-Words Task. Proc. of Semeval-2007 Workshop (SemEval), in the 45th Annual Meeting of the Association for Computational Linguistics (ACL 2007), Prague, Czech Republic, pp. 30–35 http://www.aclweb.org/anthology/S/S07/S07-1006.pdf
<div></div>[0029]https://wordnet.princeton.edu/
<div></div>[0030]R. Navigli, S. P. Ponzetto. BabelNet: Building a Very Large Multilingual Semantic Network. Proc. of the 48th Annual Meeting of the Association for Computational Linguistics (ACL 2010), Uppsala, Sweden, July 11-16, 2010, pp. 216-225. http://aclweb.org/anthology/P/P10/P10-1023.pdf
<div></div>[0031]Roventini A., Alonge A., Calzolari N., Magnini B., Bertagna F. (2000), "ItalWordNet: a Large Semantic Database for Italian", Proc. of the 2nd International Conference on Language Resources and Evaluation (LREC 2000), Athens, Greece, 2000, pp. 783-790.
<div></div>[0032]E. Pianta, L. Bentivogli, C. Girardi. MultiWordNet: developing an aligned multilingual database, Proc. of the First International Conference on Global WordNet, Mysore, India, January 21-25, 2002. http://multiwordnet.fbk.eu/paper/MWN-India-published.pdf
<div></div>[0033]https://www.iso.org/standard/28245.html
<div></div>[0034]https://www.gpdp.it/web/guest/regolamentoue
<div></div>[0035]https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=uriserv:OJ.L_.2016.119.01.0001.01.ITA&toc=OJ:L:2016:119:TOC
<div></div>[0036]https://www.corriere.it/Primo_Piano/Cronache/2006/09_Settembre/15/cognomi.shtml
<div></div>[0037]https://data.world/axtscz/italian-first-names
<div></div>[0038]https://en.wikipedia.org/wiki/Dependency_inversion_principle
<div></div>[0039]https://imperialcollegelondon.app.box.com/s/lqqcugie51pllz26uixjvx0uio8qxgo5/file/493461282808
<div></div>[0040https://www.docx4java.org/trac/docx4j]
<div></div>[0041]https://github.com/plutext/docx4j
<div></div>[0042]https://docs.oracle.com/javase/9/docs/api/java/lang/String.html
<div></div>[0043]https://github.com/php/php-src/blob/master/ext/session/session.c
<div></div>[0044]https://github.com/plutext/docx4j/search?q=getJAXBNodesViaXPath+in%3Afile&type=Code
<div></div>[0045]https://www.w3.org/TR/xpath-30/
<div></div>[0046]
<div></div>[0047]
<div></div>[0048]

==Indice delle figure==

[0F00]https://en.wikipedia.org/wiki/Latin_script

[0F01]Diagramma di Venn 1

[0F02]Diagramma di Venn 2

[0F03]Diagramma di Venn 3

[0F04]Esito unit test regex (cartella immagini)

[0F05]Inforgrafica GDPR

[0F06]Diagramma di sequenza UML

[0F07]Formula unicità valore elementi in un insieme

[0F08]Primo calcolo valutazione algoritmo

[0F09]Secondo calcolo valutazione algoritmo

[0F10]Terzo calcolo valutazione algoritmo