Modelli concettuali e architetture Object-Oriented per la progettazione e lo sviluppo di una Digital Scholarly Platform

Modelli concettuali e architetture
Object-Oriented
per la progettazione e lo sviluppo di una
Digital Scholarly Platform
Seminario di Cultura Digitale
25 Maggio 2016
Angelo Mario Del Grosso, Istituto di Linguistica Computazionale “A. Zampolli” (ILC-CNR)

Di Cosa NON Parlerò
- Tecnologie Web: HTML, CSS, Javascript
- eXtensible Markup Language (XML)
- Text Encoding Initiative (TEI)
- Semantic Web e Ontologie
- Digital Scholarly Editing
- Natural Language Processing
- Trattamento automatico dei Corpora
- Dibattito sulla definizione delle Digital Humanities
- Digital Philology, Computational Philology, ePhilology
- Collaborative Philology vs Cooperative Philology
- Infrastrutture di Ricerca come Clarin, Dariah, etc.
Angelo Mario Del Grosso - Seminario LABCD - 25 Maggio 2016 - Modellazione OO per DH

Di Cosa Parlerò
- Introduzione e Motivazioni
- Digital Scholarly Platform
- Object-Oriented Design
- Object-Oriented Paradigm
- OOP & OOAD
- UML
- SOLID Principles
- Design Patterns
- Designing the Scholarly Platform
- Conceptual class models
- Scholarly API, Components and Modules
- Risultati
- Progetti e Iniziative in corso
- Saussure, G2A, Clavius, Talmud, Omega
- Conclusioni
- Bibliografia

Linguistic Analysis and Parsing
Text Encoding and Digital Scholarly Editing Digital Resources and Digital Archives
Settori di ricerca di riferimento
Software Engineering and
Software Development
Data Structures and
Algorithms
Information Extraction
and Classification
String Manipulation and Alignment
Image Processing
Linked Open Data and Semantic Web
Thesauri, Lexicons
and Ontologies
InfoVis Semantic Analysis
Incontro tra
discipline computazionali,
tecnologie informatiche e discipline
umanistiche

La rappresentazione formale e strutturata di varie tipologie di dati testuali, al fine di codificarli,
elaborarli, persisterli, indicizzarli, interpretarli, confrontarli e recuperarli, è stata ed è ancora una
sfida per l’applicazione di tecnologie digitali e computazionali nell’ambito degli studi umanistici.
Rappresentare ed elaborare documenti testuali

In ambito del textual scholarship è sentita l’esigenza di sviluppare sistemi che
consentano di:
➔ navigare in grandi archivi di testi e di immagini digitali
favorendo il ritrovamento di fenomeni testuali e
intertestuali (passi paralleli, citazioni esplicite o implicite);
➔ favorire il ritrovamento di errori e varianti testuali in
documenti che rappresentano la storia di una stessa opera
(es. copie di manoscritti con variazioni);
➔ consentire di produrre indici e concordanze sia del testo
che delle informazioni di contesto (es. apparato critico),
aumentando le possibilità di effettuare scelte editoriali
corrette;
➔ lavorare ad un testo in modo collaborativo da parte di una
molteplicità di utenti, anche con diverse specializzazioni
(filologi, linguisti, storici, filosofi, ecc.);
Il problema e le necessità degli studiosi del testo

Proprietà fondamentali della risorsa testuale
Molteplicità
Proprietà legate alla rappresentazione digitale del
contenuto di un documento
Proprietà legate alla rappresentazione digitale del
documento
Supporto
Edizione
Interpretazione
Livello
Versione
Granularità
Posizione
Layer
Struttura
Semantica
Stile
Comportamento

Sfide, motivazioni, obiettivi
Produzione e acquisizione di accurati e dettagliati oggetti testuali digitali
Sviluppo di robusti, efficienti e flessibili componenti software al fine di
elaborare e manipolare le risorse testuali acquisite
Integrazione dei dati e dei servizi in una piattaforma di ricerca
Generalizzare i problemi degli studi letterari all’interno del mondo digitale
attraverso un processo di analisi del dominio e la definizione di
specifiche funzionalità
Modellare la rappresentazione digitale delle fonti testuali attraverso l’uso
di diagrammi semi-formali e attraverso la definizione di tipi di dato
astratti
Sviluppare tecnologia
basata su appropriate
strutture dati,
algoritmi, APIs,
Abstract Data Type
Disporre liberamente dei dati e del codice sorgente degli
artefatti (Open Source)
Sviluppare strumenti basati su componenti riusabili
(Librerie)
Collaborare direttamente con la comunità di riferimento sia
per quanto riguarda l’acquisizione e l’arricchimento dei dati
testuali, sia per quanto riguarda lo sviluppo del software

Introduzione e Motivazioni
Gli strumenti disponibili per lo studio scientifico
dei documenti testuali generalmente sono
sviluppati senza considerare i metodi e i principi
legati alla progettazione orientata agli oggetti
L’impiego di criteri di progettazione software
orientati agli oggetti consente di implementare una
robusta e flessibile piattaforma costituita da vari
moduli specializzati - indipendenti, ma cooperanti
- in grado di soddisfare efficacemente ed
efficientemente le complesse esigenze degli
studiosi. La progettazione e lo sviluppo di applicazioni
software per lo studio dei testi non si limita a
trasformare una sequenza di operazioni definite
tramite una descrizione informale verso una
sequenza di operazioni descritte formalmente e che
possono quindi essere eseguite dal calcolatore, ma
deve necessariamente prevedere una organizzazione
più complessa tra i vari attori in gioco e la
definizione di Tipi di Dato Astratti (ADTs).

Progettare e Sviluppare Servizi e Componenti software per una
piattaforma orientata allo studio scientifico del testo
Progettare una piattaforma web per l’analisi scientifica dei testi è una attività complessa in
quanto le scelte progettuali sono numerose e spesso devono essere fatte avendo a
disposizione informazioni incomplete, anche discordanti e con requisiti molto esigenti

- Paradigma Object-Oriented
- Incapsulamento
- Astrazione
- Ereditarietà
- Polimorfismo
- Unified Modeling Language (UML)
- Diagrammi per la progettazione
Caratteristiche principali della metodologia
- Principi di Base (SOLID Principles)
- Single Responsibility Principle
- Open/Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
- Architecture and Design Patterns
- GoF
- POSA
- Application Programming Interfaces (API)
- Modularity and Components

Introduzione al paradigma orientato agli oggetti
- Il paradigma ad oggetti può essere contrapposto al paradigma procedurale
- Sequenza di operazioni con una specifica di input e di output relativa ad una “funzione”
- Generalmente l’output di una operazione diviene l’input dell’operazione successiva
- La filosofia del paradigma ad oggetti
- Definire un sistema software come una collezione di oggetti di vario tipo che interagiscono tra loro
attraverso delle interfacce ben definite (APIs)
- Definire componenti riusabili con specifiche responsabilità in grado di contenere e gestire dati
➢ I componenti di un sistema ad oggetti vengono visti come astrazioni (ADTs) in grado sia di conservare
uno stato (campi dato/proprietà) sia di eseguire operazioni (metodi) per la manipolazione e l’elaborazione
del componente stesso e/o di altri componenti astratti che vi interagiscono.
○ L’esecuzione di una procedura diviene una sequenza di passi, ciascuno dei quali è assegnato ad un
singolo componente che a sua volta può comunicare con altri componenti e decomporre
ulteriormente l’esecuzione del lavoro assegnato
■ L’implementazione di un sistema più o meno complesso si riduce ad assemblare una
collezione di oggetti con responabilità ben definite
➢ Differenza sostanziale tra paradigma procedurale e paradigma ad oggetti:
○ L’ elaborazione dei dati e i dati stessi sono fusi in un unica entità

Introduzione al paradigma orientato agli oggetti cont...
- Classi
- Identificare diverse tipologie di entità, definire categorie e gerarchie.
- Creare (istanziare) oggetti appartenenti ad uno specifico tipo di dato.
- Interfacce
- Definire le modalità di interazione tra le varie componenti di un sistema.
- Specificare il “cosa” senza dettagliare il “come”.
- Definire formalmente i requisiti di un componente.
- Accedere agli oggetti delle classi che le implementano (ADTs).
- Ereditarietà e Composizione
- Porre in essere meccanismi di riuso.
- Estendere e modificare le caratteristiche di oggetti genitore (ereditarietà).
- Utilizzare oggetti di altre classi per comporre il proprio specifico comportamento.
- Incapsulamento
- Specificare (esporre) solo il comportamento dei componenti attraverso meccanismi di astrazione,
- Nascondere le implementazioni interne e rendere pubbliche solo le specifiche esterne.
- Impedire ai client del componente di dipendere dai propri dettagli.
- Polimorfismo e binding dinamico
- Riferire oggetti di tipo diverso.
- Gli oggetti riferiti devono essere conformi al tipo di dato che li riferisce.
- Invocare a tempo di esecuzione operazioni senza conoscere a tempo di compilazione chi
concretamente le implementa.
- Coesione e accoppiamento
- Valutare il grado di cooperazione e di uniformità tra le entità di un modulo per ottenere una data
funzionalità (coesione).
- Valutare il grado di interdipendenda tra le varie entità di un modulo (accoppiamento).
- Desiderata: progettare ed implementare un sistema che abbia alta coesione dei moduli e basso
accoppiamento tra essi (obiettivo non banale da raggiungere).

Utilizzo della nozione di Tipi di Dato Astratto (ADT)
content
String content = new String(“seq di cara”);
URI id = URI.create(“//source/text/000”);
Text text = Text.of(content, id);
id
text
Qualsiasi testo
//source/text/000
URI String
Riferimenti
ad Oggetti
Istanze di
classi (Oggetti)

Introduzione allo Unified Modeling Language
Documentare e descrivere un sistema è strategico se si
ha l’obiettivo di progettare in modo collaborativo una
applicazione complessa che si rivolge ad una comunità i
cui requisiti sono in continua evoluzione.
Lo standard de-facto, sancito dalla Object Management
Group - OMG 2003, per la progettazione e la
documentazione di sistemi orientati agli oggetti è lo
Unified Modeling Language (UML).
L’UML è un linguaggio semi-formale che sfrutta una
notazione grafica per progettare software. Attraverso i
diagrammi messi a disposizione dal linguaggio è
possibile definire, tra le altre cose, le componenti e i
modelli concettuali delle classi di un sistema, oltre alle
relazioni che intercorrono tra le entità.
La documentazione generata con l’UML è
universalmente riconosciuta e compresa. Essa può
quindi essere discussa, migliorata e presentata in
modo collaborativo in conferenze e articoli della
comunità di riferimento.
Esempio di diagramma UML dei casi d’uso

Introduzione allo Unified Modeling Language
Definisce la dimensione
statica del sistema senza
tener conto del tempo
Definisce la dimensione
comportamentale del
sistema
Definisce le operazioni,
le interazioni e le
attività degli oggetti

Diagrammi UML e relazioni tra entità
Use case diagram
Class Diagram
Gli elementi dei diagrammi sono inter-connessi attraverso vari tipi di
relazioni: Associazione, Dipendenza, Composizione, Aggregazione,
Specializzazione, Implementazione, Realizzazione, etc...

Diagramma di Sequenza e Diagramma dei Componenti
CIST… Componenti Libreria
Componenti sviluppati per il modulo di lemmatizzazione e
relative interfacce di “require” e “provide”
La modalità di interazione delle componenti definisce il
comportamento del sistema. In particolare, il tipo di
relazione determina gli aspetti di dipendenza tra i vari
moduli.
Diagramma di sequenza che descrive l’
interazione tra le varie componenti del
sistema di analisi linguistica

In molti linguaggi di programmazione OO come Java o C++, una classe derivata si dice che
estende o che eredita da una superclasse e può implementare e sovrascrivere metodi della
classe genitrice (override) completando il meccanismo di binding dinamico. Questi
meccanismi sono il cuore del paradigma ad oggetti, ma sono anche fonte di molte
limitazioni se usati senza ponderazione (favorire la composizione all’ereditarietà).
Ancora sulla Ereditatierà e sul Polimorfismo
L’ereditarietà è un meccanismo alla base del paradigma orientato agli oggetti. Esso consente di
generalizzare funzionalità e di attivare pratiche di riuso dei componenti. In particolare, la relazione
di ereditarietà intercorre tra due classi, una classe antenato detta superclasse, e una classe
discendente detta derivata o sottoclasse. Sfruttare adeguatamente il meccanismo del polimorfismo
permette di progettare sistemi maggiormente flessibili e estensibili.

Un componente è una unità di
produzione e di rilascio indipendente
che, combinata con altre componenti,
forma un sistema complesso e
modulare. I componenti ben
progettati devono assicurare:
- Massima Coesione
- Minimo Accoppiamento
Dagli Oggetti ai Componenti: una questione di granularità

OOAD: Analisi dei requisiti e definizione delle componenti
Generalmente il processo di Analisi, Progettazione e Sviluppo software (OOAD) inizia con una fase di analisi,
nella quale si definiscono i requisiti del sistema e i casi d’uso che l’applicazione intende supportare. In ambito
DH è importante coinvolgere la comunità fin dalle prime fasi di sviluppo e condividere tutte le scelte di
design con gli “utenti finali”.
- A partire da questa fase è possibile creare un primo modello del sistema e identificare le componenti di
base dell’applicazione
User stories by courtesy of Bridget Almas

Modelli Concettuali Object Oriented
Al fine di progettare ed implementare uno strumento efficace,
efficiente, riusabile ed estensibile per lo studio scientifico del
testo, è essenziale definire un modello concettuale delle classi e le
relazioni essenziali che intercorrono tra esse
Identificare le giuste classi e le
responsabilità da attribuire ad esse è
un compito tutt’altro che banale.
Molte metodologie sono state
avanzate per guidare questa fase
progettuale e quasi tutte prevedono
un lavoro di affinamento iterativo.
Lo studio e la conoscenza
approfondita del dominio di
interesse e l’applicazione sistematica
dei principi dell’Object-Oriented
sono di fondamentale importanza.
La definizione del Modello
Concettuale delle Classi è un passo
fondamentale per la realizzazione di
una applicazione software orientata
agli oggetti. Il Modello corrisponde
ad entità identificabili nel dominio
analizzato e sono oggetti e concetti
noti agli utenti del sistema.
il Modello in tal senso è una
semplificazione e una astrazione
della realtà, ne definisce e ne coglie l’
essenza.

Rappresentazione dei dati e API
Particolare attenzione è
rivolta alla definizione di
opportune Application
Programming Interface (API).
La standardizzazione e la
specifica delle Interfacce di
Programmazione
garantiscono genericità,
flessibilità e robustezza delle
soluzioni identificate.
Version b =
VersionManager.select(Version.BASE);
Witness baseDocument =
Witness.getDoc(b);
Source word =
baseDocument.getStream(
Granularity.LEAF).positionAt(“3”);
String wordString = word.toString();
Analizzare il dominio e modellarlo sfruttando il paradigma ad oggetti
attraverso opportune API che identifichino specifici casi d’uso

API come metalinguiaggio e linguaggio Domain Specific
Document teiDocument = AbstractBuilderFactory.buildDocument(
new File("features.properties"),
new File("teiDocument.xml"));
Sentence[] sentences = teiDocument.getSentences();
Le Application Programming Interfaces (APIs)
garantiscono:
1) la disponibilità a lungo termine delle funzionalità
pubbliche dei componenti (servizi ed entry point)
2) lo sviluppo community-driven degli strumenti
software, producendo in tal modo una sorta di meta-
linguaggio
3) la separazione tra le applicazioni dei client dalle
implementazioni fornite dai provider
4) l’utilizzo intuitivo del tool (shallow understanding)
I client della piattaforma invocano i servizi esposti dai
componenti attraverso entry-point nettamente separate
dalle entità che ne implementano le funzionalità

I principi base dell’Object Oriented - SOLID
Durante la realizzazione di un sistema ad oggetti, il progettista deve scegliere tra diverse soluzioni che
rispondono a particolari requisiti. Esistono delle regole e dei principi che possono guidare il processo di
identificazione delle classi, dei componenti, delle funzionalità e dei meccanismi che regolano la loro
interazione.
● I principi SOLID sono alla base di una buona
progettazione dei sistemi orientati agli oggetti.
● Astrarre e incapsulare le parti che variano è il
meccanismo alla base di quasi tutti i principi che
regolano la progettazione orientata agli oggetti
Il termine SOLID è un acronimo
mnemonico che indica un insieme di cinque
principi introdotti nell’ambito della
programmazione ad oggetti da un famoso
ingegnere, Robert Cecil Martin.
● Conoscere opportunamente questi principi è essenziale per
“sfruttare” al massimo il paradigma Object-Oriented e le
sue caratteristiche di base: Riusabilità e Estensibilità.
● Single Responsibility Principle (SRP)
● Open-Close Principle (OCP)
● Liskov Substitution Principle (LSP)
● Interface Segregation Principle (ISP)
● Dependency Inversion Principle (DIP)

Single Responsibility Principle (SRP)
➔ Un oggetto deve avere una ed una sola resposabilità e
tale responsabilità deve essere completamente
incapsulata in una classe (coesione).
- Una classe deve avere una sola ragione per cambiare
➔ La progettazione di una piattaforma per lo studio del testo deve
comprendere un insieme di moduli poco accoppiati e ben definiti, con
singole responsabilità e poche dipendenze, facilmente comprensibili e
manutenibili.

Single Responsibility Principle (SRP) - Esempio

Open-Close Principle (OCP)
➔ Gli oggetti e i componenti devono essere progettati
mantenendoli “aperti” per le estensioni, ma “chiusi”
per le modifiche.
- Cambiare il comportamento di una parte del
sistema senza compromettere l’intera l’
applicazione
➔ Gli utenti di una piattaforma per lo studio del testo sono molteplici e con
requisiti e necessità che variano ed aumentano nel corso del tempo e nel
corso della progettazione e dello sviluppo del sistema.

Open-Close Principle (OCP) - Esempio

Liskov Substitution Principle (LSP)
➔ I riferimenti agli oggetti che prevedono anche classi
derivate devono preservare sempre lo stesso
comportamento anche nel caso in cui si utilizzi una
classe derivata.
- Le sottoclassi devono essere sostituibili dalle proprie
classi base
➔ Gli utenti di un sistema per lo studio del testo necessitano di una
piattaforma flessibile, ma allo stesso tempo estremamente robusta

Liskov Substitution Principle (LSP) - Esempio

Interface Segregation Principle (ISP)
➔ Gli utenti (client) di un componente o di un oggetto
non devono dipendere da interfacce che non usano
- Molte interfacce specifiche sono da preferire ad
una singola interfaccia generica
➔ Le entità che costituiscono una piattaforma per lo studio del testo giocano
vari ruoli in relazione a vari punti di vista e in relazione agli utenti che le
utilizzeranno

Interface Segregation Principle (ISP) - Esempio

Dependency Inversion Principle (DIP)
➔ Le entità astratte non devono dipendere da entità
concrete. Le astrazioni non devono dipendere dai
dettagli implementativi, ma i dettagli implementativi
devono dipendere sulle astrazioni.
- Dipendere solo dalle interfacce e dalle astrazioni
➔ Gli utenti della piattaforma utilizzano moduli flessibili e uniformi che
dipendono solo dai servizi che espongono (interfacce) e non da come
questi vengono realizzati (dettagli interni). Ciò permette di cambiare l’
implementazione dei componenti del sistema senza cambiare l’
interazione con essi.

Dependency Inversion Principle (DIP) - Esempio

Design Patterns
La progettazione di un sistema software spesso deve risolvere
problematiche comuni a molteplici scenari.
Questo ha portato nel corso del tempo a definire molte soluzioni
robuste e riusabili per molti problemi ricorrenti. I Design Patterns.
Un Design Pattern è una soluzione ad un problema
ricorrente di progettazione. Si compone di un insieme di
classi che attraverso il meccanismo di delega e di
ereditarietà permette di risolvere elegantemente ed
efficacemente tale problema.
Queste soluzioni possono essere adattate e perfezionate
per il particolare dominio dello studio scientifico del
testo.
I Design Patterns hanno giocato e giocano un ruolo fondamentale nella progettazione e
documentazione della Digital Scholarly Platform.

Design Patterns cont...
La migliore risorsa per approfondire i più noti Design Patterns è il classico
catalogo scritto da Gamma, Helm, Johnson, and Vlissides (aka Gang of Four -
GoF) Design Patterns: Elements of Reusable Object-Oriented Software
I Design Pattern permettono:
- di utilizzare le componenti della
piattaforma indipendentemente
da come le sue parti vengono
create e assemblate.
- di organizzare efficacemente la
struttura delle componenti
coinvolte uniformando sia i
servizi esposti sia le responsabilità
delle varie entità
- di implementare strategie di
elaborazione e algoritmi tra le
componenti in modo flessibile e
dinamico
Creazionali (5) Strutturali (7) Comportamentali (11) 23 Patterns
★ Singleton
★ Abstract
Factory
★ Prototype
★ Factory
Method
★ Builder
★ Proxy
★ Flyweight
★ Bridge
★ Facade
★ Decorator
★ Adapter
★ Composite
★ Observer
★ Template Method
★ Command
★ Iterator
★ State
★ Mediator
★ Strategy
★ Chain of Resp.
★ Visitor
★ Interpreter
★ Memento

Design Patterns cont...
Pattern creazionali, come il
singleton e il factory, pattern di
behavior, come lo observer e
pattern strutturali come il proxy
sono stati utilizzati per modellare
il dominio di interesse e per
progettare i componenti del
sistema per lo studio dei testi.
I design pattern aiutano a
creare un modello object-
oriented delle entità del
dominio il più possibile
disaccoppiato e astratto.

Esempio Design Patterns (Factory)
Il Factory permette di disaccoppiare in modo molto elegante la creazione e l’uso di un
oggetto dalla sua classe concreta. I vantaggi di tale meccanismo sono molteplici. Tra i quali vi
è la possibilità di sfruttare pienamente il meccanismo di binding dinamico in modo del
tutto trasparente al Client.

Esempio Design Patterns (Composite Component)
Il Composite Component è un Design
Pattern che modella la struttura
gerarchica di una risorsa attraverso un’
unica interfaccia e due diversi tipi di nodi
concreti. Vale a dire, i nodi intermedi e i
nodi foglia sono entrambi specializzazione
della stessa classe base

Esempio Design Patterns (Observer)
Uno dei problemi più ricorrenti nell’ambito dello studio scientifico dei testi è mantenere
aggiornato lo stato di diverse entità che condividono informazioni. Il pattern
Observer permette di creare un modello disaccoppiato ed efficace per la gestione di
risorse correlate

Esempio Design Patterns (Strategy)
Il diagramma UML mostra l’utilizzo di più
pattern in sinergia per la realizzazione
del componente di analisi linguistica
multilingua.
In base al testo da analizzare il sistema
è in grado di istanziare le componenti
adatte ed elaborare correttamente il
testo che l’utente ha selezionato
(pattern strategy)

La natura gerarchica della rappresentazione digitale delle risorse testuali incoraggia l’
utilizzo del pattern Visitor per l’attraversamento delle entità del modello in modo
flessibile e personalizzabile
Esempio Design Patterns (Visitor)

Verso la modellizzazione Object-Oriented della Piattaforma
Grazie alle esperienze maturate in seno a numerose
iniziative nel campo delle Digital Humanities, è stato
possibile realizzare alcuni modelli concettuali basati sui
principi e sulle tecniche precedentemente introdotti.

Modelli Concettuali Object Oriented (Tradition and Editorial Text)
Modello che semplifica la
tradizione di un testo.
I testimoni sono fonti primarie
che veicolano un testo, ma con
errori e varianti.
Sarà opera dell’editore studiare
la molteplicità delle fonti e
stabilire quale sia il testo da
accogliere e ricostruire
Modello concettuale delle classi progettato ed implementato per il
sistema del progetto PRIN 2008 “Per una edizione digitale dei
manoscritti di F. de Saussure”

Modelli Concettuali Object Oriented (Source-Composite)
Modello delle classi che aggiunge la
prospettiva della annotazione e la
separazione tra supporto e contenuto,
mantenendo una visione gerarchica.
Il Modello implementa anche alcuni
Design Pattern tra i più conosciuti
come il Composite Component, il
Typed-Relationship, il Pattern Role.
Il modello è stato progettato e
implementato per il sistema del
progetto ERC Ideas Advanced Grant
249431 “Greek into Arabic.
Philosophical Concepts and Linguistic
Bridges”.

Modelli Concettuali Object Oriented (Annotation-Locus)
Modello delle classi che elabora
ulteriormente l’idea della fonte primaria
come separazione tra supporto e
contenuto. Il Modello si basa sul concetto
di stand-off e permette di rappresentare
vari livelli e varie dimensioni di
annotazione con varie gerarchie, anche
sovrapposte.
Il modello è stato progettato e
implementato per il sistema
realizzato per l’iniziativa
“Clavius on The Web”.

Esempio di utilizzo del Modello
text = Text.of("Un qualsiasi testo da annotare.",
URI.create("//source/text/000"));
annotation = AnnotationText.of("Annotazione sul testo",
URI.create("//annotation/text/123"));
annotation.addLocus(text, 13, 18); /*annotata la parola testo*/
annotation.save();

Casi di studio e implementazioni dei vari modelli
➔ Saussurre
➔ GreekIntoArabic
➔ Clavius
➔ Talmud
➔ Verso Omega

PRIN - “Per una edizione digitale dei manoscritti di F. de Saussure”
- la trascrizione del testo deve indicare tutte le varie fasi
redazionali del testo (cancellature, correzioni, aggiunte, ecc.)
- necessità di visualizzazione dell’immagine digitale (per
controllo del testo sia per l’editore che per il fruitore)
- accesso alla trascrizione e all’immagine digitale (con zoom,
etc.)
Coordinato dal Professore Daniele Gambarara dell’Università della Calabria
Obiettivo:
Progettazione e sviluppo di una applicazione Web per lo studio e l’edizione dei manoscritti di
Ferdinand de Saussure. (l’edizione del manoscritto Théorie des sonantes, pubblicata da Maria Pia
Marchese nel 2002)
Partecipanti:
- Università della Calabria;
- Università di Firenze;
- Consiglio Nazionale delle Ricerche - Istituto di Linguistica Computazionale "Antonio
Zampolli" (CNR-ILC, Pisa);
- Università di Salerno.
Requisiti:

L’applicazione “de Saussure” - visualizzazione parallela
La visualizzazione principale dell’applicazione include i fogli trascritti dei manoscritti
L’immagine e il testo sono visualizzate in parallelo con in nota tutte le fasi redazionali del testo

L’applicazione “de Saussure” - Indici e Concordanze
Un importante funzionalità del sistema è la ricerca di termini plurilingui presenti nel testo.
Un utente può cercare una parola sia per forma sia per lemma e verificarne la presenza nel testo
Result page

Comment Area
Comment List Transcription
Classification
Text & Image Selection
Image
L’applicazione “de Saussure” - Annotations and Comments
Funzionalità essenziale è rappresentata dalla annotazione e dal commento.
Un utente seleziona un frammento e lo annota/commenta sfruttando un sistema di classificazione

The ERC project Ideas, Advanced Grant 249431
Greek into Arabic: Philosophical Concepts and Linguistic Bridges
Coordinato dalla Prof.ssa Cristina D’Ancona dell’Università di Pisa
Obiettivo:
Progettazione e sviluppo di una applicazione Web per lo studio della traduzione di
alcuni capitoli delle Enneadi di Plotino in arabo. Traduzione nota con il titolo di
Pseudo-Teologia di Aristotele. Realizzata nel IX sec.
Partecipanti:
- Università di Pisa
- Università di Bochum (Germania);
- Consiglio Nazionale delle Ricerche - Istituto di
Linguistica Computazionale "Antonio Zampolli"
(CNR-ILC, Pisa).
- I testi in greco e in arabo devono essere allineati e gestiti in
modo sincronizzato (per lo studio della traduzione)
- I testi devono essere annotati semanticamente e
linguisticamente (per lo studio dei fenomeni di traduzione)
- Ricerca avanzata crosslinguistica (legami tra gli indici e le
concordanze dei due testi)
Requisiti:

Greek into Arabic - Pericopatura parallela
La caratteristica di base del sistema è lo studio parallelo dei testi in lingua greca e araba
Un utente segmenta i due testi associando le porzioni che hanno un legame intertestuale (pericopatura)

La funzionalità di ricerca avanzata permette di interrogare il testo attraverso un lessico greco-arabo
Un utente esperto chiede al sistema di visualizzare i luoghi del testo impostando vari filtri crosslinguistici
Greek into Arabic - Concordanze contrastive

Greek into Arabic - Analisi linguistica
La funzionalità di analisi linguistica del testo permette di aggiungere informazioni morfosintattiche
Un utente esperto studia i fenomeni linguistici dei due testi con l’ausilio del calcolatore

- piattaforma integrata per accesso e navigazione via Web dei
manoscritti e delle informazioni racchiuse in essi
- riproduzione digitale del facsimile accompagnata dalla sua
trascrizione, l’analisi linguistica del testo latino e le
annotazioni lessicali e semantiche
- creazione di una risorsa termino-ontologica dedicata al
dominio astronomico e matematico del XVI-XVII secolo,
chiamata CLAVIUS
Il progetto Clavius On the Web
Finanziato dal Registo.it con sede presso il CNR di Pisa
Obiettivo:
Progettazione e sviluppo di una applicazione Web per la valorizzazione del carteggio
di Cristoforo Clavio con i grandi scienziati e studiosi dell’epoca: 330 lettere trasmesse
dai codici APUG 529-530
Partecipanti:
- Istituto di Informatica e Telematica (IIT-CNR)
- Archivio Storico della Pontificia Università Gregoriana (APUG)
- Istituto di Linguistica Computazionale "A. Zampolli" (ILC-CNR)
Requisiti:

La prima funzionalità implementa il supporto alla trascrizione delle lettere
Un utente esperto visualizza l’immagine facsimile del manoscritto e ne trascrive il contenuto

La seconda funzionalità implementa il supporto per l’annotazione semantica delle lettere
Un utente esperto arricchisce il testo grazie ad un sistema di annotazione orientato al web semantico (RDF)

La caratteristica di analisi semi automatica della lingua latina
Un utente chiede al sistema di analizzare il contenuto testuale delle lettere per poi correggere eventuali errori

Progetto Traduzione Talmud Babilonese
- velocizzare il processo di traduzione;
- produrre una traduzione omogenea;
- far lavorare una molteplicità di utenti, con differenti profili:
- allo stesso testo;
- nello stesso tempo;
- da qualsiasi parte del mondo;
- assistere nella redazione dell’edizione a stampa.
Finanziato dal MIUR e monitorato dalla Presidenza del Consiglio dei Ministri
Obiettivo:
Produrre una traduzione in Italiano del Talmud Babilonese da pubblicare attraverso
una edizione a stampa e una edizione digitale
Partecipanti:
- Consiglio Nazionale delle Ricerche
- Unione delle Comunità Ebraiche Italiane
- Collegio Rabbinico Italiano
Requisiti:

Albero delle Fonti Tabella delle Traduzioni e Filtri
Note, Glossari, Suggerimenti e
Analisi Linguistica
Il pannello principale implementa tutte le funzionalità per il supporto alla traduzione

La gestione dei glossari permette di descrivere i termini più significativi del testo
Uno studioso può recuperare i termini annotati e visualizzare la descrizione e il luogo dove occorrono

Il sistema, opportunamente personalizzato, è in sperimentazione anche nelle scuole secondarie
Gli studenti approfondiscono i classici analizzando e commentando un testo e le relative traduzioni
Versione “Educational” della piattaforma

Verso una piattaforma per lo studio scientifico dei testi
Image
management
Multilayered
Annotation
Lexica,
terminologies
and ontologies
Assisted
Translation
Text
Processing
Linguistic
Analysis
Advanced
Search
Editing and
Publishing
Full text searches
Semantic
searches
Linguistic
searches

❏ Definizione dei requisiti e delle specifiche utente guidata dalla comunità e dal dominio (user-stories, use-
cases, user-scenarios, story-boards)
❏ Definizione dei tipi di dato astratti (entità e funzionalità) che sintetizzino le caratteristiche comuni del
dominio (e.g., testo, documento, annotazione, apparato, corpus, indici, catalogo, etc)
❏ Definizione di modelli software in grado di esemplificare le complesse relazioni esistenti tra i tipi di dato
astratti del dominio d’interesse
❏ Definizione di soluzioni generiche e riusabili (Pattern) per il design di strumenti software
❏ Definizione di Moduli e Componenti riusabili che offrano chiare e condivise Application Programming
Interface (API)
❏ Definizione di architetture flessibili in grado di conseguire l’estensibilità degli artefatti (μ-kernel)
❏ Definizione di Servizi Web condivisi dalla comunità in grado di richiamare le funzionalità dei componenti
da remoto (μ-services, RESTfull e simili)
❏ Definizione di algoritmi e strutture dato efficaci ed efficienti per la risoluzione di problemi specifici
(ottimizzazione, pecision-recall, indexing, matching, querying, etc)
Il progetto di sviluppo di una piattaforma per lo studio scientifico dei testi deve necessariamente impiegare una
metodologia robusta di analisi, progettazione e implementazione del software.
Concludendo… c’è tanto da fare!!
Riusabilità, Flessibilità, Estensibilità e Manutenibilità delle componenti nonchè coesione tra le entità e basso
accoppiamento tra i moduli.

Ma… in pratica?
- Inoltre, l’umanista digitale può trovarsi nella condizione di dover
mettere il cappello dell’informatico:
- In questi casi, una maggiore consapevolezza dei problemi e
delle possibili soluzioni tecniche che tipicamente si incontrano
nello sviluppo di software per le digital humanities può essere
di grande aiuto
- In uno scenario nel quale gli strumenti digitali sono sviluppati
secondo i principi dell’OO, l’umanista digitale sarà agevolato nel
suo lavoro di studio, dato che, tali strumenti, saranno:
- robusti e sicuri
- facilmente modificabili
- maggiormente comprensibili

Davide Albanesi
computer scientist
Andrea Bellandi
computer scientist
Giulia Benotto
digital humanist
Angelo Mario Del Grosso
information engineer
Emiliano Giovannetti
computer scientist
Simone Marchi
computer scientist
Ouafae Nahli
Arabic expert
Silvia Piccini
linguist
Web application development, Requirement analysis, Design and
development of object-oriented software, Databases
Ontologies and Lexica, Knowledge Engineering, Uncertain
Knowledge, Computer-Assisted Translation, Translation Memory
Distributional Semantics, Information extraction from texts,
Distributional analysis of literary texts, Semantic relation extraction
Models for Object-Oriented Applications, Digital Humanities, Text
Processing, Text Encoding, Scholarly Editing
Knowledge Engineering, Ontologies, Computational Lexica, Natural
Language Processing, Information Extraction from texts
Natural Language Processing, Term extraction, Ontology learning,
Software engineering
Natural Language Processing, Morphosyntax of Arabic, Arabic
Lexicography
Computational Lexicography, Terminology, Ontologies, Knowledge
Representation
languages: Java, SQL
languages: Java, XML, OWL
languages: Latin, Perl
languages: Java, XML, UML
languages: Java, OWL
languages: Java, C, Perl, Bash
languages: Latin, Greek, Sanskrit, Old Slavonic, Classic Armenian,
Lithuanian, Latvian, Bulgarian, Russian, German
languages: Arabic, French
La squadra del laboratorio presso l’ILC
Hanno contribuito ai lavori presentati anche il dott. Andrea Bozzi, la dott.ssa Nilda Ruimy, il dott. Federico
Boschetti e tutti i partecipanti ai vari progetti menzionati

Riferimenti bibliografici
● A. Bozzi, "Computer-assisted scholarly editing of manuscript sources," in New publication cultures in the
humanities: exploring the paradigm shift, P. Davidhazi, Ed. Amsterdam: Amsterdam University Press, 2014,
pp. 99-115.
● A. Bozzi, “Edizione elettronica e filologia computazionale”, in A. Stussi (a cura di), “Fondamenti di critica
testuale”, Il Mulino Manuali, Bologna, 2006, pp. 207-232.
● F. Buschmann, K. Henney, and D. C. Schmidt, Pattern-Oriented Software Architecture, On Patterns and
Pattern Languages, ser. Pattern-Oriented Software Architecture. Hoboken: John Wiley & Sons, 2007.
● G. Crane, B.Seales, and M. Terras, “Cyberinfrastructure for Classical Philology,” Digital Humanities
Quarterly, 3 (1), 2009.
● M. Fowler, “Analysis Patterns: Reusable Object Models”. Menlo Park, Calif. ; Harlow : Addison Wesley.
1996.
● E. Gamma, R. Helm, R.Johnson, and J. Vlissides, “Design Patterns: Elements of Reusable Object-Oriented
Software”. Reading, Mass: Addison-Wesley, 1995.
● M. Lamé, V. Valchera, and F. Boschetti, “Epigrafia digitale. Paradigmi di rappresentazione per il trattamento
digitale delle epigrafi,” Epigraphica, LXXIV vol. 1-2, 2012, pp. 331-338.
● M. McCandless, E. Hatcher, and O. Gospodneti , “Lucene in action”, Manning, 2010.
● P. Robinson, "Towards a theory of digital editions," Variants, no. 10, pp. 105-131, 2013.
● R. Siemens, M. Timney, C. Leitch, C. Koolen, A. Garnett et al., "Toward modeling the social edition: An
approach to understanding the electronic scholarly edition in the context of new and emerging social media,"
Literary and Linguistic Computing, vol. 27, no. 4, pp. 445-461, 2012.
● G. Stewart, G. Crane, and A. Babeu: A New Generation of Textual Corpora. JCDL 2007, pp. 356–365.

Grazie per l’attenzione
Angelo Mario Del Grosso
DOMANDE…?
Seminario LABCD - Pisa, 25.05.2016
angelo.delgrosso@ilc.cnr.it
angelodel80@gmail.com
Modelli concettuali e architetture
Object-Oriented
per la progettazione e lo sviluppo di una
Digital Scholarly Platform

Modelli concettuali e architetture Object-Oriented per la progettazione e lo sviluppo di una Digital Scholarly Platform

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (10)

Similar to Modelli concettuali e architetture Object-Oriented per la progettazione e lo sviluppo di una Digital Scholarly Platform

Similar to Modelli concettuali e architetture Object-Oriented per la progettazione e lo sviluppo di una Digital Scholarly Platform (20)

More from Laboratorio di Cultura Digitale, Università di Pisa

More from Laboratorio di Cultura Digitale, Università di Pisa (20)

Modelli concettuali e architetture Object-Oriented per la progettazione e lo sviluppo di una Digital Scholarly Platform