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

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 AnalysisIncontro 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 diagramClass 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 AlmasAngelo Mario Del Grosso - Seminario LABCD - 25 Maggio 2016 - Modellazione OO per DH

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 Theorie 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 FiltriNote, 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 searchesSemantic 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 Albanesicomputer scientist

Andrea Bellandicomputer scientist

Giulia Benottodigital humanist

Angelo Mario Del Grossoinformation engineer

Emiliano Giovannetticomputer scientist

Simone Marchicomputer scientist

Ouafae NahliArabic expert

Silvia Piccinilinguist

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

[email protected]@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...

Education

Transcript of Modelli concettuali e architetture Object-Oriented per la progettazione e lo sviluppo di una Digital...