We can not solve our problems with the same level of thinking that created them.

Albert Einstein

Un semplice esempio ...

Un semplice esempio …

InformationExtraction

Partendo dal web, da email, chat e documenti non strutturati, ossia sottoforma di testo libero, attraverso opportune tecniche e strumenti è possibile costruire dei “motori”  in grado di individuare ed estrarre le informazioni in essi contenute, determinare le  relazioni che intercorrono e la loro provenienza. Certo la complessità dell’interpretazione del linguaggio naturale può non consentire ancora, in taluni casi,  una precisione assoluta ma la capacità di individuare con buona precisione entità (es. persone fisiche, persone giuridiche, beni materiali, località, date, indirizzi, ecc.), le loro relazioni  e le conseguenti proprietà che si possono derivare (es. per una persona fisica la data il luogo di nascita, il suo indirizzo di residenza, il luogo di lavoro, ecc.) consente di arricchire archivi di informazioni più strutturati, mantenendo al contempo una mappa aggiornata tra le informazioni stesse e la loro origine.

IRUtilization

La mappa di informazioni e sorgenti di origine diventa la base su cui costruire, ad esempio, strumenti di facilitazione e potenziamento nella ricerca e nella navigazione di sistemi di gestione documentale. L’impiego, oltre che per classici valori di ricerca, può avvenire mediante la navigazione dell’albero, costruito/aggiornato durante l’estrazione, delle entità individuate, delle loro proprietà e delle relazioni che esse hanno tra loro. In questo modo si aprono innumerevoli ulteriori scenari  nel trattamento di informazioni altrimenti perdute e delle loro fonti di origine: ad es. individuare e mettere in relazione tra loro  le fonti (email, chat, pagine web, documenti) in cui si parla di un tal Mario Rossi di Bologna che lavora in ACME e che risulta scomparso da una certa data. L’annotazione, durante il processo di estrazione, delle informazioni e delle relazioni direttamente all’interno delle fonti può inoltre consentire una consultazione più chiara, diretta e controllata anche della singola fonte, evidenziando secondo le necessità dell’utilizzatore il livello di dettaglio desiderato nell’evidenziazione delle informazioni.

 

Le esigenze ...

Le esigenze

Il mondo in cui viviamo e lavoriamo è una fonte infinita di dati. Molti di essi sono ben

catalogati e accessibili in archivi e “database” organizzati per facilitare la ricerca, l’analisi e la sintesi in informazioni, essenziali per ragionare, fare ipotesi e prendere decisioni.

Per contro l’uso di internet e del web mette in evidenza anche l’enorme quantità di dati e informazioni presenti in miliardi di pagine e documenti disseminati in ogni parte del mondo. Inoltre anche all’interno di ogni organizzazione, privata o pubblica, oltre agli archivi ben organizzati dei sistemi ERP, CRM, PLM, ecc, esistono delle grandi moli di documenti di varia natura che nascondono al loro interno   un’ulteriore vastissima quantità di informazioni le quali, se portate alla luce e rese accessibili in modo strutturato, potrebbero letteralmente cambiare in molti casi la nostra percezione e il valore delle nostre decisioni.

Il “problema” è che   tutto questo infinito patrimonio informativo è contenuto in documenti e pagine scritte generalmente sottoforma di testo libero, in lingue diverse, spesso con alfabeti diversi e quindi in forme tutt’altro che strutturate e atte a consentire una loro identificazione, sintesi e catalogazione. L’uso dei motori di ricerca sul web o di un sistema di gestione documentale evidenzia il limite accennato.

Anche l’impiego dei più sofisticati motori, come ad esempio Google, a fronte di una ricerca che vada oltre all’individuazione di alcune parole chiave in combinazione tra loro ma che esprima, attraverso una frase, un concetto obiettivo trova numerosi ostacoli nel processo di estrazione. Il limite risiede nel fatto che un’”espressione di ricerca“ non è solo da considerare come una serie di parole a se stanti, ma come una frase con un suo significato (“semantica frasale)” che deriva dall’insieme delle regole fonetiche, ortografiche, morfologiche, lessicali e sintattiche di una lingua: la grammatica.

Allo stesso modo, ai fini accennati, non è sufficiente identificare le pagine o i documenti che possano attendibilmente riferirsi a quanto espresso, come con un tradizionale motore di ricerca, ma è necessario reiterare su ciascun documento un processo di ricerca, determinazione ed estrazione dei dati e delle informazioni ricercate sulla base di uno scopo preciso, per evitare di lasciare di nuovo questo impossibile (per ragione di tempo) compito all’essere umano, attraverso la lettura di ogni documento identificato e la catalogazione manuale dei dati interessati.

Tutto ciò passa attraverso i processi di “Information Extraction” (IE) basati sul Natural Language Processing (NLP) inteso come un insieme di tecniche e strumenti dedicati all’analisi e all’elaborazione del linguaggio usato comunemente dalle persone in forma scritta e orale.

Torna all’inizio della sezione

Alcuni campi di applicazione ...

Alcuni campi di applicazione

Relazioni di accompagnamento al bilancio

La relazione sulla gestione costituisce uno dei principali documenti allegati al bilancio

d’esercizio; il suo scopo è fornire, attraverso informazioni finanziarie e non, una visione globale che consenta al lettore del bilancio di comprendere la situazione della società e l’andamento della gestione, in chiave attuale e previsionale.

Andando oltre e più in dettaglio rispetto al bilancio stesso, in generale, questo documento contiene, tra le altre, informazioni circa la posizione della società nell’ambiente in cui opera, l’analisi della struttura patrimoniale e finanziaria e dei risultati della gestione, la descrizione degli indicatori finanziari e non finanziari e informazioni relative ai rischi e alle incertezze.

E’ indubbio che i contenuti informativi in esso presenti vanno spesso ben al di là dell’essere una mera trasposizione discorsiva di dati provenienti dal “sistema gestionale”, ma costituiscono una rielaborazione di analisi e sintesi effettuata da un esperto della materia (“esperto di dominio”). Il documento, pur ricorrendo a rappresentazioni sintetiche, come tabelle, grafici, ecc, riporta in genere molte delle sue principali informazioni attraverso l’uso del linguaggio naturale proprio del “dominio” amministrativo/finanziario.

Di relazioni sulla gestione se ne possono usualmente avere diverse per ogni esercizio annuale, su base trimestrale o quadrimestrale, ed esse, di anno in anno, “accumulano” un qrande quantità di informazioni e “concetti” sviluppati, di volta in volta, dagli “esperti di dominio” (amministratori, revisori, ecc) e che rischiano di andare perduti o, quantomeno, non completamente utilizzati.

Un “sistema” IT che analizzi questi documenti sulla base del loro contenuto in linguaggio naturale alla ricerca di “concetti”, informazioni e dati da rendere fruibili in forma strutturata e catalogata permette di estendere la conoscenza di una organizzazione, facilitando inoltre il compito degli “esperti di dominio”, lasciati liberi da compiti di rilettura e rianalisi completa dei precedenti documenti, in ogni operazione di auditing e valutazione dell’organizzazione.

Consolidamento di anagrafiche di prodotto

In ogni impresa la proliferazione di nuove anagrafiche e di duplicati è causata spesso dai limiti di gestione e dalla complessità dei processi dei sistemi informativi utilizzati, nei quali dati e informazioni, oltre che su “database” strutturati, sono contenuti anche in fonti discorsive di varia natura (pagine web, cataloghi, relazioni e rapporti tecnici, documenti marketing e commerciali, ecc).

Inoltre nei sempre più frequenti processi di fusione, acquisizione, creazione di reti di imprese risulta determinante la capacità di mettere a fattor comune, in un complesso omogeneo e coerente, questa mole di informazioni in genere organizzate, catalogate, codificate e descritte secondo criteri e modalità differenti.

Grazie alla tecnologia semantica è possibile analizzare e ricostruire automaticamente il patrimonio di anagrafiche dell’organizzazione a partire da tutte le sorgenti disponibili, strutturate e non, supportando e facilitando processi di normalizzazione, razionalizzazione, ottimizzazione e riorganizzazione.

Gestione magazzino

La gestione di un inventario, attraverso l’uso del software, come noto, è ormai ampiamente supportata dalle funzionalità del sistema informativo:

  • avvio dell’inventario con selezione dei prodotti da inventariare.
  • conta fisica dei prodotti selezionati per l’inventario.
  • inserimento dei dati di esistenza dei prodotti inventariati nel programma di gestione.
  • chiusura della procedura d’inventario per la valorizzazione finale.

La maggior parte dei documenti necessari, anche a fini fiscali, sono altresì prodotti direttamente dalle procedure IT di supporto. Tuttavia in numerose organizzazioni i documenti aggiuntivi del “ciclo del magazzino” possono essere diversi e numerosi. Si pensi ad esempio a quelli relativi all’analisi e al controllo dei rischi, alla gestione della qualità del prodotto o a quelli che descrivono modalità e aspetti legati al deperimento di merci e prodotti aventi effetto diretto sui criteri di valorizzazione. Anche in questi casi il numero, la qualità e il valore delle informazioni contenute va molto al di la di quanto presente nel sistema informativo tradizionale.

Un processo di “information extraction” basato sull’analisi e la comprensione di documenti discorsivi in linguaggio naturale è in grado di estendere l’identificazione, la raccolta e la catalogazione di dati e informazioni utili a migliorare la gestione dell’organizzazione.

Verbali di inventario in ambito civilistico

Il   processo   verbale   d’inventario contiene:

  • la descrizione degli immobili, mediante l’indicazione   della   loro   natura,   della   loro situazione, dei loro confini e dei numeri del catasto e delle mappe censuarie;
  • la descrizione e la stima dei mobili, con la   specificazione   del   peso o del   marchio per gli oggetti d’oro e d’argento;
  • l’indicazione della quantità e specie delle monete per il danaro contante;
  • l’indicazione   delle   altre   attività   e passività;
  • la   descrizione   delle   carte,   scritture   e in fine dall’ufficiale procedente.

Documenti che, pur nascendo in forma non strutturata e secondo forme e linguaggio proprio del “dominio” giuridico, riportano nel loro contenuto una vasta e ricca quantità di informazioni che, se estratte e catalogate con un processo di “information extraction”, possono concorrere ad arricchire i “database” strutturati e alimentare i processi di controllo e gestione, senza obbligare a sistematici interventi di rilevazione e annotazione manuale da parte di esperti umani.

Documenti di supporto alle autorità investigative

Durante le attività delle forze dell’ordine vengono generati e utilizzati una gran quantità di documenti, in gran parte discorsivi, nel linguaggio del relativo “dominio” e non immediatamente riconducibili, nel loro contenuto, a rappresentazioni strutturate tipiche di un “database” digitale. Si pensi ai verbali di interrogatorio, alle sentenze, ecc.

In essi sono menzionate e circostanziate numerosissime informazioni:

  • persone fisiche
  • persone giuridiche
  • organizzazioni prive di personalità giuridica
  • organizzazioni criminali e gruppi terroristici
  • stupefacenti
  • armi e strumenti di offesa
  • mezzi di comunicazione
  • ecc.

e, per ciascuna di esse, dettagli informativi come nome, cognome, soprannome, data/luogo di nascita, denominazione e tipologia dell’organizzazione, ecc.

Le informazioni, e le relazioni tra esse, se non indicate esplicitamente in forma digitale al momento della redazione del documento, per essere identificate ed estratte richiedono un successivo intervento da parte di un “esperto del dominio” il quale, attraverso un processo di annotazione consapevole, evidenzi cosa mettere in evidenza a fini di analisi, sintesi e successiva catalogazione digitale. Anche in questo caso un’applicazione di “information extraction” basata su tecniche di Natural Language Processing, predisposta sul dominio specifico, è in grado di supportare e automatizzare in misura diversa l’identificazione e la raccolta organizzata di dati e informazioni.

 

Torna all’inizio della sezione

Cosa significa ...

Cosa significa

Estrarre informazioni da una “sorgente” scritta in linguaggio naturale comporta intuitivamente lo sviluppo di una capacità di interpretazione semantica legata alla lingua utilizzata e, non meno importante, al contesto espressivo e terminologico del campo a cui essa si riferisce (“dominio”).

Con il termine Natural Language Processing (NLP) s’intende un insieme di tecniche e strumenti dedicati all’analisi e all’elaborazione del linguaggio usato comunemente dalle persone in forma scritta, orale e, al limite, gestuale.

La comprensione del linguaggio naturale è spesso considerata un problema di IA-completo poiché si ritiene che il riconoscimento del linguaggio richieda una conoscenza estesa del mondo e una grande capacità di comprensione. Questo processo è reso particolarmente difficile a causa delle caratteristiche intrinseche di ambiguità del linguaggio umano e, per questo motivo, esso è suddiviso in fasi diverse simili, per certi versi, a quelle che si riscontrano nel processo di elaborazione di un tradizionale linguaggio di programmazione.

In particolare un processo completo di elaborazione richiede di effettuare:

  • Analisi lessicale: scomposizione di un’espressione linguistica in elementi atomici detti token; nel caso del linguaggio naturale scritto, essi sono rappresentati da parole, segni di punteggiatura, cifre, ecc.
  • Analisi grammaticale: associazione delle parti del discorso a ciascuna parola nel testo;
  • Analisi sintattica: arrangiamento dei token in una struttura sintattica (ad albero: parse tree) 
  • Analisi semantica: assegnazione di un significato (semantica) alla struttura sintattica e, di conseguenza, all’espressione linguistica. Nell’analisi semantica la procedura automatica che attribuisce all’espressione linguistica un significato tra i diversi possibili è detta disambiguazione.

Le moderne piattaforme di NLP usano un approccio machine learning, spesso di tipo statistico. Questo paradigma è sostanzialmente diverso dai classici approcci rule based, che costringono a scrivere un rilevante numero di regole per l’analisi di un testo, e sembra essere più promettente in molti casi. Il settore di NLP che fa uso di tecniche di machine learning è denominato Natural Language Learning (NLL).

Le tecniche di apprendimento automatico consentono, infatti, di derivare un insieme di regole attraverso l’analisi di un significativo numero di esempi di testi (corpora), tratti dal dominio applicativo d’interesse. In questo contesto un corpus è un insieme di documenti (a volte singole frasi) che sono stati annotati manualmente indicando le informazioni corrette che devono essere apprese e che portano a differenti risposte per i valori da rilevare, ciascuna caratterizzata da un valore di probabilità.

Tuttavia, in funzione della complessità del processo di analisi e della vastità o meno del dominio, le tecniche di apprendimento automatico possono essere affiancate o, in alcuni casi anche sostituite, da quelle di tipo “rule-based”. In diversi casi ben circostanziabili, l’individuazione di determinate forme espressive o l’assegnazione di un significato a una struttura sintattica, precedentemente determinata, possono essere più agevolmente determinati attraverso la scrittura di regole di interpretazione delle combinazioni morfologico-lesiccali-grammaticali e di struttura mediate dall’impiego di opportuni glossari e dizionari.

L’ Information Extraction (IE) ha come obiettivo l’estrazione automatica di informazioni strutturate da documenti non strutturati o semi-strutturati. Esempio tipico riguarda l’annotazione di documenti multimediali. Va detto che il problema è intrinsecamente complesso e pertanto l’approccio produce risultati accettabili solo per contesti che siano stati ben delineati.

In un processo di IE tre sono i livelli crescenti su cui intervenire:

  • Named Entity Recognition: riconoscimento di nomi propri di entità (quali persone, organizzazioni e luoghi), riconoscimento di espressioni temporali (es. date), di indirizzi, e di altre particolari informazioni (es. importi, voci di bilancio, ecc.).   Il compito più semplice è denominato Named Entity Detection (NED) che si limita a identificare le entità senza alcuna conoscenza circa gli specifici valori (istanze). Ad esempio, nella frase “Mario Rossi è affiliato al clan dei Marsigliesi”, si è in grado di estrarre come informazione che Mario Rossi è una persona ma senza avere necessariamente conoscenza di chi sia o di chi potrebbe essere.
  • Coreference Resolution: rilevamento di legami di coreferenza (ovvero l’insieme dei rinvii allo stesso referente: es. “Gianni disse che egli sarebbe andato a casa”) e di anafora (ovvero riferimenti tra porzioni di testo più o meno distanti fra loro: es. “alla riunione arrivò anche Carlo ma nessuno lo notò”).
  • Relationship Extraction: riconoscimento di legami associativi tra entità, ad esempio dalla frase “Mario Rossi risiede a Bologna.” si può dedurre la relazione di residenza che sussiste tra una persona (Mario Rossi) e una località (Bologna).

Nella pratica di un’applicazione di IE è però spesso necessario affrontare insieme i tre aspetti precedenti. Un semplice esempio per tutti potrebbe essere la frase:

“Mario Rossi è nato a Milano il 22/07/1953 e risiede a Milano. Egli ha lavorato a Roma presso il Ministero dell’economia. Il suo recapito telefonico è 329728321.”

Un corretto processo di IE dovrebbe riconoscere che sussiste una relazione tra il soggetto MARIO ROSSI e la città di MILANO in quanto quest’ultima ne rappresenta il luogo di nascita, e pertanto dovrebbe determinare come proprietà della persona la data di nascita con valore “22/07/1953” e il luogo di nascita con valore “MILANO”. Allo stesso modo tra il soggetto MARIO ROSSI e la città MILANO sussiste una relazione “residenza a” che potrebbe determinare l’attribuzione del valore MILANO a una proprietà “residenza” della persona fisica. Attraverso il riconoscimento della coreferenza espressa dal pronome “suo” dovrebbe poi identificare come ulteriore attributo di ROSSI il recapito telefonico con valore “329728321”. Mediante il riconoscimento della coreferenza espressa da “egli” dovrebbe poi identificare un’ulteriore relazione di “impiego in” tra MARIO ROSSI e l’organizzazione “MINISTERO DELL’ECONOMIA” la quale potrebbe essere attribuita come valore a una proprietà “lavora in” della persona fisica.

Questo semplice esempio dimostra come l’applicazione di una tecnica di IE orientata alla identificazione e ricostruzione di informazioni strutturate, difficilmente possa prescindere da una equilibrata combinazione di tutti gli aspetti: NER, COREFERENCE, RELATIONSHIP.

A complicare le cose, inoltre, sono le diverse forme e combinazioni espressive, a volte anche non pienamente corrette dal punto di vista grammaticale, con cui queste informazioni possono essere riportate.

Ad esempio:

“Mario Rossi, amico di Carlo Verdi, è nato a Milano il 22/07/1953 dove risiede attualmente dopo un periodo di attività nella capitale negli anni 1990-2010. Lavorando presso il Ministero dell’economia ha maturato esperienze significative per l’incarico. Il recapito telefonico a cui contattarlo è 32912345678.”

in cui la presenza, a diverso titolo, di un’altra persona fisica, e di espressioni discorsive più estese e ricche di coreferenze, implicite ed esplicite, rendono la comprensione semantica automatica assai complessa.

Torna all’inizio della sezione

Strumenti ...

Strumenti

In un panorama globale esistono numerosi strumenti e piattaforme “open source” di supporto alla progettazione e realizzazione di applicazioni di IE basate su NLP. Essi si differenziano sotto vari aspetti, tra cui il tipo di licenza, i linguaggi di sviluppo e gli ambienti supportati, l’interoperabilità con altri ambienti, la copertura in termini di funzionalità offerte ovvero il livello di generalità delle soluzioni, la disponibilità di documentazione adeguata e il sostegno offerto agli sviluppatori di applicazioni.

Per un elenco dei principali tool e di alcune risorse linguistiche è possibile consultare:

Stanford CoreNLP

Il gruppo di ricerca di Stanford University mette a disposizione una serie di strumenti di NLP (http://nlp.stanford.edu/software/corenlp.shtml , http://nlp.stanford.edu/publications.shtml) che sono complessivamente denominati Stanford CoreNLP. Stanford CoreNLP è rilasciato con GNU General Public License.

Stanford CoreNLP è un framework Java per la gestione di pipeline (sequenze di processi di elaborazione) per l’annotazione di documenti che ha avuto negli anni una rilevante espansione nell’architettura e nelle funzionalità registrando una notevole diffusione in molti ambienti scientifici e industriali.

Architettura Stanford NLP

Il framework fornisce esclusivamente API Java e, sebbene preveda una gestione multi-thread su singola macchina, non si occupa dello “scaling” su nodi di calcolo. Questa scelta, soddisfacente per la maggior parte delle applicazioni e per la semplicità della soluzione, consente di affrontare problematiche di NLP minimizzando gli sforzi d’apprendimento e di personalizzazione sulla base delle specifiche esigenze applicative, costituendo un vantaggio di CoreNLP rispetto ad altri tool

Stanford NLP: linguaggi risorsepiù sofisticati quali UIMA (Unstructured Information Management Architecture) e GATE (General Architecture for Text Engineering). Lo sviluppatore deve solo possedere conoscenze di Java.

Da sottolineare che negli anni il core è stato reso disponibile anche per l’utilizzo da altri linguaggi, quali C#, F#, PERL, Pyton, Ruby, Javascript.

Il framework è offerto con un’ampia scelta di modelli e risorse di annotazione per la lingua inglese e, nel tempo, anche per altre lingue tra cui Francese, Tedesco, Cinese e Arabo. Molto poco è invece attualmente disponibile per la lingua italiana.

Nell’ambito della piattaforma di Stanford, di rilievo è anche Protégé per la gestione di ontologie OWL nel dominio di interesse, come descrizione formale di classi, proprietà e relazioni.

UIMA

UIMA: ArchitetturaUIMA (Unstructured Information Management Architecture) è l’unico insieme di strumenti per content analytics che è stato riconosciuto come standard OASIS (Organization for the Advancement of Structured Information Standards) nel 2009. UIMA è un’architettura software per lo sviluppo di strumenti per l’analisi multi-modale di informazioni non strutturate e la loro integrazione con tecnologie di ricerca realizzate da IBM.

Il codice sorgente per un’implementazione di riferimento del framework è stata resa disponibile dapprima su SourceForge e, successivamente, nel sito web http://uima.apache.org/index.html di Apache Software Foundation. Un uso specifico di UIMA è in ambito clinico, ad esempio il sistema CTAKES (Clinical Text Analysis and Knowledge Extraction System) per l’estrazione di conoscenza da cartelle cliniche di pazienti. 

UIMA consente la decomposizione delle applicazioni in vari moduli, ad esempio:

  • “language identification”
  • “language specific segmentation”
  • “sentence boundary detection”
  • “entity detection (person/place names …)”.

Ogni componente implementa interfacce definite dal framework e provvede a fornire metadati tramite descrittori XML. I componenti possono essere scritti in Java o C++.

In aggiunta UIMA fornisce funzionalità per l’incapsulamento dei componenti come servizi di rete, e può scalare verso volumi molto elevati replicando i processi su un cluster di nodi in rete.

Apache UIMA è un’implementazione open source di UIMA sotto licenza Apache.

OpenNLP

OpenNLP  è  una libreria Apache per analisi di testi che supporta vari tipi di azione:

  • “tokenization”
  • “sentence segmentation”
  • “part-of-speech tagging”
  • “named entity extraction”
  • “chunking”
  • “parsing”
  • “coreference resolution”.

Fornisce anche la possibilità di eseguire machine learning e può essere utilizzato anche in ambiente .NET.

GATE

GATE è un’infrastruttura open source per lo sviluppo di sistemi di IE proposta da University of Sheffield.

La piattaforma comprende principalmente:

  • GATE Developer: un ambiente integrato per lo sviluppo di componenti di elaborazione del linguaggio (“language processing”) supportato da un’ampia gamma di informazioni ed esempi e arricchito da una vasta scelta di componenti aggiuntivi (“ plugins “) che ne estendono le potenzialità
  • GATE Teamware un ambiente web collaborativo per la gestione in team dei processi di annotazione di insiemi di documenti, basato sull’impiego del “workflow engine” JBPM.
  • GATE Embedded: un framework e una libreria di componenti per l’integrazione e l’utilizzo da un’applicazione esterna dei servizi e dei processi realizzati attraverso GATE Developer.
  • Una soluzione “cloud” per l’elaborazione in “hosting” di processi di NLP/IE su larga scala (GATE Cloud.net)
  • GATE Mímir: (Multi-paradigm Information Management Index and Repository) utilizzabile per l’indicizzazione e la ricerca di testi, annotazioni, schemi semantici (ontologie) e valori delle istanze. Esso consente di effettuare ricerche composte attraverso la combinazione libera di dati testuali, di struttura, linguisitci e semantici.

Nell’ambito di GATE Developer di rilievo è la presenza di un plugin in grado di consentire la gestione di ontologie OWL nei formati RDF/XML, N3, NTriples and Turtle, quindi compatibile con gli analoghi strumenti disponibili su altre piattaforme. La definizione di un’ontologia, oltre a rappresentare la struttura classi, proprietà e relazioni del dominio di interesse, permette di estendere, nell’approccio “rule based”, le capacità di analisi attraverso il principio dell’ereditarietà e la generazione di glossari e dizionari derivati dai valori delle istanze associate alle diverse classi.

Lo sviluppo di una nuova applicazione basata sull’architettura di GATE prevede una fase preliminare in cui l’utente sceglie quante e quali processing resources utilizzare, definendo per ognuna di esse le language resources coinvolte.

Il formato per la rappresentazione dei dati in GATE è denominato annotation, e il sistema fornisce il supporto per l’elaborazione di testi in formato:

  • Plain Text
  • HTML
  • SGML
  • XML
  • RTF
  • Email
  • PDF (some documents)
  • Microsoft Office (some formats)
  • OpenOffice (some formats)
  • UIMA CAS XML format
  • CoNLL/IOB

La piattaforma si presta ottimamente per realizzazioni sia “rule-based” che “machine learning”.

Un’interessante applicazione basata su GATE è ANNIE (A Nearly-New Information Extraction system). ANNIE utilizza una serie di risorse per riconoscere istanze di entità (persone, organizzazioni, luoghi, date, indirizzi, ecc.) all’interno di un testo. ANNIE si basa su algoritmi a stati finiti e sul linguaggio JAPE (Java Annotation Pattern Engine).

I vari tool ella piattaforma GATE sono “open source” rilasciati generalmente con licenze GNU. L’Università di Sheffield prevede anche forme di consulenza e sviluppo commissionato per la personalizzazione di GATE per specifiche esigenze; alcuni servizi possono essere richiesti a Ontotex e Matrixware, partner principali del progetto GATE.

Torna all’inizio della sezione

La piattaforma GATE ...

Utilizzo della piattaforma GATE

La piattaforma GATE, attraverso le funzionalità di base e i numerosi plugin disponibili, può essere agevolmente impiegata in processi di NLP e IE sia con approccio “rule based” che “machine learning”.

Approccio “rule based”

Un esempio di sequenza di elaborazione (pipeline) “rule based” dedicata al NER (Named Entity Recognition) è costituito dall’applicazione ANNIE, disponibile come plugin insieme agli altri strumenti della piattaforma. ANNIE consente l’”annotazione”, tra l’altro, delle entità: persone, organizzazioni, località, date, ecc.

L’”annotazione” in GATE rappresenta una sequenza di parole oggetto del riconoscimento, definita, nella sua ampiezza di copertura in funzione degli obiettivi di identificazione ed estrazione; ha una denominazione (“annotation type”) e delle proprietà (feature) atte a contenere valori derivati durante il processo di IE. La denominazione degli “annotation type” e delle “feature” sono determinati nell’ambito dell’applicazione in funzione del significato e delle esigenze di rappresentazione formale.

Ad esempio per la semplice frase:

“Mario Rossi, nato a Milano il 22/07/1953, risiede a Monza dove lavora presso la società VORTEX di Vimercate.

l’annotazione si può presentare come:

Gate-Esempio-1

“Mario Rossi” rappresenta, attraverso nome e cognome, una “persona fisica” e “VORTEX”, attraverso la sua denominazione, una “persona giuridica”.

Nell’esempio l’annotazione “Mario Rossi” potrebbe avere come “annotation type”   persona e come “featurenome=Mario e cognome=Rossi

Un’annotazione viene riportata in un documento elaborato sottoforma di “tag XML” utili anche a una rappresentazione grafica interattiva in un’applicazione di visualizzazione e navigazione delle annotazioni create. Mediante opportune funzionalità del framework le annotazioni possono anche essere registrate esternamente, ad esempio su DBMS relazionale, file CSV, ecc.

Le annotazioni, in quanto portatrici di informazioni (un nome e delle proprietà), possono essere create attraverso fasi successive, incrementando il dettaglio della rappresentazione venendo utilizzate nell’approccio “rule based” in un affinamento successivo sino alla determinazione delle annotazioni finali di interesse. Al termine del processo le annotazioni intermedie, di servizio, se non più necessarie, potranno essere eliminate.

Il corpo di elaborazione principale è costituito dalla pipeline, intesa come sequenza di “process resource” (PR) ciascuna dedicata a un compito particolare in relazione alle esigenze di NLP e IE.

In ANNIE la tipica pipeline e schematizzabile come nella figura riportata sotto.

Gate: process resources

Ciascun PR, come modulo base, è essenzialmente costituito da un corpo di elaborazione standard realizzato in JAVA che, dedicato a un fine preciso, genera o modifica sul documento le proprie “annotazioni di servizio” che potranno essere agevolmente impiegate nei PR successivi.

In particolare:

PR Gazetteer à genera   gli “annotation type”, denominati Lookup, finalizzati alla rappresentazione di termini, singoli o in sequenza, che trovano un riscontro nel sistema dei “gazetteer” (dizionari) dei valori tipici/notevoli.

PR NE Transducer à contiene le logiche di elaborazione per regole che determinano, sulla base delle precedenti annotazioni di servizio, il riconoscimento delle entità presenti nel documento. Una logica di elaborazione viene espressa attraverso un linguaggio formale (JAPE) che suddivide il processo analisi ed estrazione attraverso diverse fasi (file di estensione .jape) eseguite in sequenza, ciascuna contenente all’interno una serie di regole eseguite secondo una priorità specificata.

ANNIE, pur costituendo un esempio assai didattico, è pero costruito sulla lingua inglese. Nel caso di altre lingue, anche mantenendo le medesime logiche di elaborazione del plugin base, sarebbero necessarie delle modifiche come riassunto nella simbologia della figura seguente.

Gate/ANNIE: personalizzazione dei componenti

In particolare il “PR Tokenizer” potrebbe dover ad esempio essere adeguato nelle regole che identificano particolari forme di punteggiatura o abbreviazione tipiche dell’italiano. Il “PR Gazetteer” certamente dovrebbe essere completatamente rivisitato nei valori riportati sui glossari aggiungendo o sostituendo le traduzioni relative alla lingua italiana. Il PR “POS Tagger” dovrebbe essere completamente sostituito per generare annotazioni di servizio relative alla grammatica italiana.

Un esempio

A titolo di esempio didattico elementare, per riassumere, vediamo una rivisitazione di ANNIE, tra le tante possibili.

Si consideri la pipeline ANNIE in cui i nomi dei PR sono del tutto arbitrari e, in ogni caso, personalizzabili:

Gate/Annie: esempio pipeline

Il PR “Tokeniser” non è stato modificato in quanto il processo di “tokenizzazione” che riconosce e annota “word” (parole), “number” (numeri) e “punctuation” (simboli di punteggiatura) viene considerato adeguato anche per le regole di scrittura italiana.

Allo stesso modo il PR “Sentecnce splitter”, che annota separatamente le frasi, non è stato modificato, in quanto le regole di identificazione di una frase, attraverso la punteggiatura, sono considerate valide anche per l’italiano.

Il PR “GLOSSARY-GAZETTERR” deve essere invece rivisitato nei contenuti dei relativi glossari di supporto. Parlando nella fattispecie di persone fisiche e persone giuridiche (organizzazioni) potranno essere modificati o aggiunti una serie di glossari relativi ad esempio ai nomi di persona maschili e femminili, ai titoli di studio (dott., ing., ecc) o, separatamente, alle formule di riferimento a persone fisiche o giuridiche (sig., sig.ra, srl, spa, ecc) e altre informazioni utili alle regole applicate successivamente dalle grammatiche JAPE del PR “JAPEPLUS-NE-TRANSDUCER”.

Il PR “MORPH-IT-GAZETTEER” rappresenta invece un semplice esempio per effettuare un “POS tagging” per l’annotazione delle caratteristiche morfologico-lessicali di base, in sostituzione del PR “POS Tagger” standard di ANNIE. Senza alcuna modifica nel codice JAVA di elaborazione standard del PR base di ANNIE, si agisce introducendo un glossario contenente un dizionario morfologico-lessicale valido per la lingua italiana.

Nel caso dell’esempio è utilizzato MORPH-IT di uso libero e sviluppato da Marco Baroni e Eros Zanchetta. Il glossario riporta su campi distinti le diverse forme e, per ciascuna, il “lemma” e le caratteristiche morfologiche

cameriere~lemma=cameriera~morfologia=NOUN-F:p

cameriere~lemma=cameriere~morfologia=NOUN-M:s

camerieri~lemma=cameriere~morfologia=NOUN-M:p

camerini~lemma=camerino~morfologia=NOUN-M:p

camerino~lemma=camerino~morfologia=NOUN-M:s

cameristica~lemma=cameristico~morfologia=ADJ:pos+f+s

cameristiche~lemma=cameristico~morfologia=ADJ:pos+f+p

cameristici~lemma=cameristico~morfologia=ADJ:pos+m+p

cameristicissima~lemma=cameristico~morfologia=ADJ:sup+f+s

cameristicissime~lemma=cameristico~morfologia=ADJ:sup+f+p

cameristicissimi~lemma=cameristico~morfologia=ADJ:sup+m+p

cameristicissimo~lemma=cameristico~morfologia=ADJ:sup+m+s

Il PR “JAPEPLUS-NE-TRANSDUCER” è invece una elaborazione completamente diversa finalizzata al riconoscimento di persone fisiche e persone giuridiche applicato alla lingua italiana, e nelle cui regole JAPE sono tenute in conto e utilizzate tutte le annotazioni di servizio diverse e aggiuntive, precedentemente menzionate.

Effetto del PR “ANNIE Tokeniser”

Ciascun elemento (token) viene annotato con un “annotation type” denominato “Token”.

La sua denominazione, come quella delle proprietà e dei valori relativi, si ricorda qui senza ripeterlo oltre, che è arbitraria e personalizzabile.

Gate/Annie: esempio PR Tokeniser

Ogni riga dell’elenco rappresenta un’annotazione, quindi di tipo “Token”, ed è distinta dalle altre attraverso il suo identificatore “Id”; “Start” e “End” indicano la posizione del carattere di partenza e di fine dell’annotazione. Ogni annotazione, riferita a ogni specifico termine riconosciuto, riporta attraverso le proprietà (feature) le relative informazioni di formato.

Effetto del PR “GLOSSARY-GAZETTEER”

Ciascun elemento (token o sequenza di token) riconosciuto in uno dei glossari specificati viene annotato con un “annotation type” denominato “LookupGlossary”.

Tra i vari si hanno:

Gate/Annie: esempio di LookupOgni annotazione presenta nelle proprietà informazioni realtive alla lingua di riferimento e di classificazione (“majorType” e “minorType”) legate al glossario attraverso cui è stato effettuato il riconoscimento.

Effetto del PR “MORPH-IT-GAZETTEER”

Ciascun elemento (token) riportato come “forma” nel dizionario morfologico-lessicale, viene annotato come “LookupMorph-it”.

Gate/Annie: esempio Morph-It

Per ciascun elemento annotato le proprietà riportano il “lemma” di riferimento e le caratteristiche morfologiche (“morfologia”), qui indicate su di un’unica feature ma che potrebbero essere a loro volta suddivise su proprietà diverse, allo scopo di agevolare la stesura delle successive regole di riconoscimento delle entità.

Naturalmente l’esecuzione del “POS Tagging” attraverso l’impiego di un PR Gazetteer non è l’unica tecnica e, in molti casi, nemmeno la più indicata. Esistono in ambito di ricerca e come “open source” diversi strumenti di natura statistica i quali, attraverso un processo di apprendimento curato da “esperti del dominio linguistico” in esame, permettono di generare degli artefatti poi reimpiegabili dalla piattaforma GATE per la generazione di annotazioni a questo scopo. A titolo di puro esempio si menziona, tra i diversi, TREETAGGER disponibile anche con un kit di artefatti già predisposto per un sottoinsieme della lingua italiana e facilmente integrabile in una pipeline GATE ricorrendo alla documentazione tecnica d’uso della piattaforma GATE.

Naturalmente in un ambito applicativo reale la determinazione del vocabolario linguistico pertinente al “dominio” e l’esecuzione delle operazioni di training costituiscono parte integrante ed essenziale per un buon risultato del “POS tagging”. Questa attività richiede competenze di team di carattere linguistico, l’esperienza del dominio di interesse e quelle IT relative alla piattaforma tecnologica utilizzata.

Effetto del PR “JAPEPLUS-NE-TRANSDUCER”

L’esecuzione del processo, nella sequenza della pipeline, può pertanto utilizzare le annotazioni di servizio prodotte sin qui. A questo tipo di processo è associabile un complesso di grammatiche di regole in linguaggio JAPE, suddivise in diversi file di estensione “.jape” e, a loro volta, eseguite in una sequenza indicata in un apposito file di descrizione della “sequenza multifase”.

Poiché obiettivo dell’esempio è identificare in questo passo le entità relative a persone fisiche e giuridiche, il risultato potrà essere del tipo:

In cui ad esempio la grammatica riconosce la persona giuridica “VORTEX” attraverso un “lemma” “società” attribuendo alla proprietà “denominazione” il valore del testo ricoperto dalla corrispondente annotazione.

Nel caso della persona fisica:

La grammatica di esempio applicata, oltre a riconoscere e annotare “Mario Rossi” come persona fisica, si spinge oltre nel determinare alcune informazioni derivanti dal riconoscimento di relazioni che si traducono nell’assegnazione del valore delle proprietà “Data di nascita” e “Luogo di nascita”.

Nell’esempio didattico non vi è alcun livello di “analisi sintattica”. Le uniche informazioni disponibili di carattere grammaticale sono quelle di tipo morfologico e lessicale. Le regole orientate al NER (Named Entity Recognition) del PR “JAPEPLUS-NE-TRANSDUCER” risulteranno quindi più limitate e “povere” rispetto al caso in cui fosse stato precedentemente eseguito anche un PR di “analisi sintattica” che abbia prodotto opportune annotazioni atte alla rappresentazione a più alto livello della struttura delle frasi.

Considerazioni generali nell’approccio “ruled based”

E’ evidente che l’organizzazione di glossari e grammatiche di regole è strettamente correlata, oltre che alla lingua e ai formati di codifica, anche al contesto di applicazione (“dominio”), rispetto al quale particolari terminologie, sigle, forme espressive e significati possono comportare rilevanti ed essenziali specializzazioni nelle diverse fasi del processo di elaborazione.

L’utilizzo di glossari e grammatiche di regole non deve far pensare a GATE come a un mero “motore di pattern matching testuale”, in cui il riconoscimento sia fondato sulla semplice rilevazione di sequenze di termini, in prossimità o meno tra loro. Il valore è intrinsecamente espresso dalla capacità delle regole di saper utilizzare propriamente tutte le informazioni disponibili (dei glossari, morfologiche, lessicali, sintattiche) in modo da interpretare il linguaggio e le informazioni contenute in espressioni altamente variabili da brano a brano e da documento e documento.

Nel constatare quanto ciò sia ancora molto lontano da una reale comprensione semantica delle parole e di una frase, tale approccio può comunque costituire un enorme passo avanti in diversi campi di applicazione.

Sviluppare una pipeline sulla piattaforma GATE, attraverso GATE Developer, significa, in estrema sintesi, comporre in funzione degli obiettivi e del tipo di elaborazione necessaria un insieme di PR selezionati tra quelli disponibili tra i plugin, e revisionare o realizzare i contenuti specifici di ognuno di essi. In un progetto applicativo reale potrà poi anche essere necessario, per esigenze specifiche, realizzare in linguaggio JAVA anche dei propri template di processo, seguendo gli standard e le indicazioni del framework GATE Embedded.

Tutte le annotazioni generate possono agevolmente essere registrate su DB o file esterni per essere poi rielaborate e ogni generica pipeline può essere eseguita da un’applicazione esterna JAVA attraverso l’applicazione del framework GATE Embedded. Per l’impiego su altre piattaforme e linguaggi di sviluppo, le classi JAVA generate dovrebbero prima essere incapsulate attraverso dei “wrapper” per consentirne l’impiego nel diverso ambiente.

Aspetti di progettazione “rule-based”

La progettazione e la realizzazione di un sistema di grammatiche JAPE deve prevedere un’organizzazione modulare e condizionale per l’impiego di glossari, grammatiche e pipeline che sappia gestire:

  • differenti livelli di profondità di IE;
  • riuso di grammatiche elementari;
  • utilizzo in diverse modalità dei glossari esistenti (in funzione del livello di profondità o della tipologia dei documenti).

Una pipeline Pi è una sequenza di PR, {PR1, PR2, …, PRn} applicata a un set (corpus) di documenti, al limite anche uno solo. Un PRi generico di una pipeline può essere sempre eseguito in modo incondizionato oppure in modo condizionato al verificarsi di una specifica condizione.

Un progetto applicativo potrà prevedere, in generale, la presenza di diverse pipeline per diverse esigenze di IE. Tuttavia il progetto deve garantire che esse possano comunque condividere, attraverso i relativi PR, parti in comune: glossari, grammatiche jape, script groovy ecc. secondo logiche modulari.

Nel progetto si deve inoltre tener conto dei seguenti vincoli:

  • la “condizionalità” di un PR di una pipeline è solo “binaria”: ESEGUI/NON ESEGUI;
  • le regole di una grammatica jape determinano un’annotazione non solo sulla base della loro priorità ma anche, e primariamente, sulla base dell’assunzione, nel caso di regole che scattano su sequenze di token in intersezione tra loro, della scelta della sequenza con la maggior ampiezza di copertura.

Per una generica pipeline Pi i PR che la compongono vengono pertanto definiti, laddove necessario, attraverso la forma condizionale.

Per un generico tipo di PR la “condizionalità” consente di impostare una pipeline basata su sequenze multiple di PR, dello stesso tipo e non, eseguibili nella corretta sequenza attraverso l’impostazione di parametri di esecuzione, valorizzabili manualmente in GATE Developer (durante la fase di realizzazione e test) oppure da un’applicazione JAVA attraverso le API del framework GATE Embedded.

Approccio “machine learning”

Nella piattaforma GATE sono disponibili diversi plugin per affrontare aspetti di NLP e IE attraverso l’approccio “machine learning”. Questa tecnica si bassa essenzialmente su metodi di natura statistica secondo l’applicazione di diversi algoritmi.

Schematicamente qualsiasi approccio “machine learning” è comunque basato sui seguenti passi:

  • annotazione manuale di un campione documentale relativo al dominio interessato, sufficientemente numeroso e adeguatamente rappresentativo, su cui indicare gli elementi di interesse da riconoscere
  • configurazione dei criteri di analisi del campione documentale annotato in relazione alle caratteristiche e alle proprietà degli elementi annotati e di quelli in prossimità
  • ciclo di applicazione del campione documentale annotato e del file di configurazione al “motore” di analisi in modalità evaluation, al fine di valutare l’attendibilità e la qualità dei risultati statistici ottenibili, ripetendo le operazioni fino a ottenere il miglior risultato possibile
  • applicazione del campione documentale annotato e del file di configurazione finali al motore di analisi in modalità training

Il motore produrrà una serie di artefatti (essenzialmente matrici di rappresentazione statistica delle condizioni e degli elementi informativi che portano al risultato desiderato) che costituiscono il modello statistico desunto dal motore dai dati di addestramento.

  • Il modello statistico generato potrà essere applicato dal motore di analisi a documenti diversi dal campione operando in modalità application

Poiché la complessità dell’argomento non consente, in poche pagine, una trattazione adeguata nel seguito viene fornita una breve trattazione per esempi basata sull’impiego del plugin “Batch Learning Plugin”, utilizzato secondo l’applicazione degli algoritmi di SVM (Support Vector Machine).

A titolo didattico si supponga di voler approntare il processo di riconoscimento NER (Named Entity Recognition) di persone fisiche mediante la tecnica in esame.

Annotazione manuale di un campione documentale

Ciascuno dei documenti del campione dovrà essere opportunamente annotato indicando le istanze di interesse, nel nostro caso indicate attraverso il nome di entità “SoggettoFisico”. 

ML: annotazione del campione

Configurazione dei criteri di analisi del campione

Il file di configurazione del motore di analisi oltre a prevedere una serie di parametri relativi a:

  • algoritmo impiegato (nel nostro caso SVM)
  • metodo especifiche opzioni tecniche di esecuzione dell’algoritmo

necessita dell’indicazione degli attributi che entrano in gioco nel processo di elaborazione statistica.

Se ad esempio le annotazioni di riferimento si volessero considerare in relazione alle caratteristiche e alle proprietà dei token dell’annotazione e di quelli immediatamente in prossimità si potrebbero specificare come attributi di analisi:

Tipo annotazione Caratteristiche espresso dal valore della feature Intervallo di prossimità
Token Orth: l’essere maiuscolo l’iniziale, interamente maiuscolo, tutto minuscolo [-1,1]
Token Kind: l’essere un numero, una parola o un simbolo di punteggiatura [-2,2]
Token String: il valore della stringa del token [-3,3]
LookupGlossary majorType: tipologia del glossario [-3,3]
LookupGlossary minorType: sottotipologia del glossario [-3,3]
LookupGlossary Lemma:: lemma della forma relativa alla stringa del token [-3,3]
LookupGlossary Morfologia: morfologia della forma relative alla stringa del token [-3,3]

Attraverso la configurazione il motore di analisi calcolerà una distribuzione statistica che metta in relazione, o meglio in separazione, gli elementi annotati tenendo in considerazione le proprietà indicate nella tabella precedente per ogni token coinvolto dall’analisi e con un livello di prossimità, tra i vari token e i pattern di interesse, specificato per ogni attributo di analisi.

Il procedimento è alquanto complesso da descrivere in poche parole e per l’approfondimento degli algoritmi alla base delle SVM si consiglia di effettuare approfondimenti sulla numerosa documentazione scientifica disponibile sul web.

Analisi in modalità evaluation       

Il campione documentale annotato e la configurazione sono applicati al motore di analisi in modalità evaluation.

Tipicamente, ma è configurabile anche in modo diverso, il motore procede in N passi (valore configurabile) suddividendo i documenti del campione in N raggruppamenti distinti su ciascuno dei quali calcolare il modello statistico per poi riapplicarlo ai restanti documenti al di fuori del raggruppamento corrente e calcolare i valori di precisione e qualità riscontrati su ogni passo. Al termine le misure rilevate a ogni passo sono rielaborate per determinare la distribuzione media dei risultati. Tutte le rilevazioni e i risultati della fase di evaluation vengono infine presentati all’utente perché possa procedere con gli eventuali affinamenti.

Applicazione del modello a un insieme diverso di documenti

Il modello statistico determinato viene applicato a un insieme di documenti, ovviamente diverso da quello campione, determinando come risultato un’annotazione per ogni sequenza di token rispondente alla distribuzione. Ogni riconoscimento è inoltre caratterizzato dall’indicazione una probabilità di buon riconoscimento.

ML: applicazione di un modello

Considerazioni generali nell’approccio “machine learning”

Con il “machine learning” prevale l’impegno di addestramento e verifica finalizzato al training finale del motore di analisi.

Nel caso “rule based” l’impegno è quello di disegnare un insieme di glossari e grammatiche di regole in grado di effettuare l’analisi e i riconoscimenti richiesti.

In entrambi i casi è richiesto un team caratterizzato da un equilibrato mix di competenze ed esperienze che spaziano dal campo linguistico, alla conoscenza del dominio sino alla padronanza degli strumenti tecnologici.

Va infine osservato che gli approcci “rule based” e “machine learning” non sono necessariamente da considerare mutuamente esclusivi. A seconda delle esigenze e delle circostanze essi possono essere combinati determinando il miglior risultato possibile.

Torna all’inizio della sezione

L'approccio e il metodo ...

L’approccio e il metodo

Come in ogni progetto IT è assolutamente necessario definire lo “scenario d’uso” dell’applicazione.

[DSU] – Definizione scenario d’uso

Destinatari  
  Esigenze
  Aspettative (obiettivi)
 

Risultati (misura dei risultati à metriche di misura)

   
Funzionalità  
  Casi d’uso
  Criteri e livelli di accessibilità e impiego in relazione alle diverse esigenze dello scenario
 
Sorgenti documentali/informative non strutturate da trattare (caratteristiche, formati, ubicazione, reperibilità, ecc) 

A seconda dello scenario i diversi aspetti coinvolti potranno differire ampiamente tra loro, variando gli scopi di impiego e, appunto, esigenze e obiettivi che si riflettono sull’equilibrio realizzativo dei processi di “information extraction”.

Le stesse sorgenti non strutturate da elaborare potrebbero essere anche ampiamente diverse, arrivando, in taluni scenari, a coinvolgere oltre a documenti anche mail, pagine web ecc., con rilevanti, o quantomeno differenti, caratteristiche di espressione linguistica dei contenuti.

Delineato, analizzato e documentato lo scenario d’uso di interesse si perverrà alla definizione:

  • del contesto linguistico (italiano, inglese, ecc.)
  • del dominio di applicazione recante terminologie, forme espressive e aspetti semantici del contesto, da “dominare” pienamente attraverso le competenze degli “esperti di dominio”.

 Importante è predefinire le metriche di misura dei risultati, in termini di precisione e qualità del risultato dei processi di annotazione automatica dai quali effettuare l’estrazione di informazioni, come ad esempio quelli già previsti sulla piattaforma GATE.

Sulla base dello scenario d’uso individuato e descritto si potrà procedere con i passi seguenti.

[ERP] – Individuazione entità, proprietà e relazioni

L’analisi deve portare alla costruzione e alla documentazione dell’ontologia completa del dominio di interesse per lo scenario, articolata in classi, sottoclassi, proprietà e relazioni e, infine, alla valorizzazione delle istanze principali in relazione al contesto.

Non meno importante, in questa fase, la verifica di una corretta identificazione e denominazione delle entità informative individuate in relazione al dominio e alle pratiche di impiego e di rappresentazione dei destinatari d’uso.

[PBD] – Progettazione della base di dati

Il disegno della base dati, prima concettuale e poi logico-fisico, determinerà, in funzione delle esigenze funzionali e degli scopi della soluzione, le strutture dati necessarie per il miglior utilizzo delle informazioni estraibili attraverso i processi di IE.

In funzione dello scenario la base dati potrà essere di tipo relazionale, NoSQL o mista, e ciò comporterà approcci e forme di rappresentazione differenti ma sicuramente tutte ruotanti intorno al dominio di interesse espresso dalle ontologie e in funzione delle esigenze tecnologiche IT impiegate per il soddisfacimento dei requisiti dell’applicazione.

[PIE] – Progettazione della base di IE

Il punto di partenza è costituito dai seguenti elementi:

  • Sorgenti non strutturate individuate in [DSU]
  • Ontologie definite in [ERP]
  • Base di dati disegnata in [PBD]
  • Esigenze funzionali definite in [DSU]
  • Gradualità dell’implementazione funzionale dell’applicazione sulla base di quanto rilevato in [DSU] ed economicamente sostenibile

I principali compiti di questa fase sono riassumibili come:

  • Analisi delle sorgenti non strutturate
     
  • Formati di interesse, tipologie di documenti
 
  • Espressioni linguistiche di riferimento (operando in approccio “rule-based” ciò risulta necessario per la determinazione e l’impiego di glossari, elementi morfologico-lessicali e sintattici)
 
  • Effetto dell’applicazione di eventuali diversi livelli di analisi e interpretazione delle sorgenti in funzione della loro tipologia e/o del grado di dettaglio richiesto/ottenibile
  • Individuazione dell’impiego di eventuali forme di “machine learning” propedeutiche o di supporto alle grammatiche “rule-based”.
  • Progettazione delle modalità e delle sequenze di training per le eventuali parti di “machine learning”.
  • Progettazione delle pipeline (sequenze di processi) di IE per la generazione delle annotazioni strutturate in relazione alle esigenze funzionali dell’applicazione

Data la generale complessità nell’affrontare e rappresentare i termini di interesse per i processi IE, in sintonia con i criteri di gradualità di crescita nel tempo dell’applicazione, potrebbero essere individuati attraverso l’ontologia una serie di “sotto-domini” da affrontare successivamente nel tempo secondo una roadmap di evoluzione dell’applicazione.

[PAPP] Progettazione dell’applicazione di impiego dei risultati di IE

Il punto di partenza è costituito dai seguenti elementi:

  • Ontologie definite in [ERP]
  • Risultati di [PIE]
  • Base di dati disegnata in [PBD]
  • Esigenze funzionali definite in [DSU]
  • Gradualità dell’implementazione funzionale dell’applicazione sulla base di quanto rilevato in [DSU] ed economicamente sostenibile

I principali compiti di questa fase sono riassumibili come:

  • progettazione del sistema di schedulazione e gestione dell’elaborazione delle pipeline di IE
  • progettazione dell’integrazione dei risultati di IE alla base dati (relazionale e NoSql)
  • progettazione delle funzioni applicative estese/aggiunte in relazione all’utilizzo dei dati estratti da IE e disponibili sulla base dati
  • progettazione della gestione (alimentazione, manutenzione, monitoraggio, controllo) dei glossari/dizionari di supporto.

Metodo progetto NLP-IE

Torna all’inizio della sezione

 

Scarica i contenuti come documento

Scarica i contenuti come documento

 


--Clicca qui per PDF--