analisi comparata di due ontologie in ambito biomedico

Transcript

UNIVERSITÀ POLITECNICA DELLE
MARCHE
FACOLTÀ DI INGEGNERIA
Corso di Laurea Specialistica in Ingegneria Informatica
ANALISI COMPARATA
DI DUE ONTOLOGIE
IN AMBITO BIOMEDICO:
SNOMED CT E ROME
Tesi di laurea di:
Relatore: Chiar.mo
Marta Gentile
Prof. Aldo Franco Dragoni
Correlatori:
Ing. Mauro Mazzieri
Ing. Germano Vallesi
Anno Accademico 2009/2010
I computer sono incredibilmente veloci, accurati e stupidi.
Gli uomini sono incredibilmente lenti, inaccurati e intelligenti.
Insieme sono una potenza che supera l'immaginazione
Albert Einstein
Abstract
Il settore sanitario attualmente presenta dei problemi d'interoperabilità, che
possono essere risolti dalle ontologie.
In questa tesi vengonno illustrati i risultati di un'analisi comparata tra due
ontologie in ambito biomedico: SNOMED CT (la realtà attualmente più
diusa a livello internazionale) e ROME (alternativa italiana sviluppata
dal CNR). Gli aspetti chiave del confronto spaziano dalla diusione e accettazione a livello internazionale, alla correttezza dell'ontologia, per giungere all'individuazione dell'espressività e valutazione della complessità computazionale delle due.
L'obiettivo nale è ottenere un chiaro quadro della situazione attuale, delle
alternative esistenti più signicative per l'Italia, per capire verso quale direzione sia meglio dirigersi nei prossimi anni.
Contents
1 Introduzione
1.1
1.2
1.3
Ontologie
3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.1.1
Denizioni . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.1.2
Classicazioni . . . . . . . . . . . . . . . . . . . . . . .
5
1.1.3
Vantaggi e applicazioni . . . . . . . . . . . . . . . . . .
6
OWL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.2.1
Struttura
. . . . . . . . . . . . . . . . . . . . . . . . .
8
1.2.2
Sottolinguaggi . . . . . . . . . . . . . . . . . . . . . . .
10
1.2.3
OWL2 . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
. . . . . . . . . . . . . . . . . . . . . . . .
12
1.3.1
Logiche descrittive
Denizione del formalismo di base . . . . . . . . . . . .
13
1.3.2
Description languages . . . . . . . . . . . . . . . . . . .
13
1.3.3
La famiglia dei linguaggi
. . . . . . . . . . . . . .
14
1.3.4
Terminologia-TBox . . . . . . . . . . . . . . . . . . . .
15
1.3.5
Descrizione del mondo-ABox . . . . . . . . . . . . . . .
16
1.3.6
Inferenza . . . . . . . . . . . . . . . . . . . . . . . . . .
16
1.3.7
Estensioni del linguaggio . . . . . . . . . . . . . . . . .
18
AL
2 SNOMED CT
19
2.1
Panoramica
2.2
Storia
2.3
Componenti base
2.4
2.5
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
Utilizzi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
. . . . . . . . . . . . . . . . . . . . . . . . .
26
2.4.1
Concetti . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.4.2
Descrizioni . . . . . . . . . . . . . . . . . . . . . . . . .
32
2.4.3
Relationships
. . . . . . . . . . . . . . . . . . . . . . .
33
Nazionalizzazione . . . . . . . . . . . . . . . . . . . . . . . . .
43
2.5.1
Introduzione ai principi terminologici . . . . . . . . . .
43
2.5.2
Tradurre SNOMED CT
. . . . . . . . . . . . . . . . .
45
2.5.3
Sorgenti di informazione
. . . . . . . . . . . . . . . . .
52
2.5.4
Processo di traduzione e problemi del post-traduzione .
53
1
2.5.5
2.6
Esperienze di alcuni release centre translating
. . . .
Considerazioni sulla struttura e tecnologia di SNOMED CT
57
2.6.1
Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
2.6.2
History Mechanism . . . . . . . . . . . . . . . . . . . .
59
2.6.3
Subset Mechanism
60
2.6.4
Cross Mapping Mechanism . . . . . . . . . . . . . . . .
60
2.6.5
Extensions . . . . . . . . . . . . . . . . . . . . . . . . .
61
2.6.6
Applicazioni e servizi SNOMED CT . . . . . . . . . . .
61
. . . . . . . . . . . . . . . . . . . .
3 ROME
3.1
3.2
3.3
63
Panoramica
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Componenti base
. . . . . . . . . . . . . . . . . . . . . . . . .
4.2
4.3
63
65
3.2.1
Entità principali
. . . . . . . . . . . . . . . . . . . . .
68
3.2.2
Entità materiali e immateriali . . . . . . . . . . . . . .
75
3.2.3
Object properties . . . . . . . . . . . . . . . . . . . . .
77
Utilizzi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
4 Analisi
4.1
55
.
79
Correttezza dell'ontologia
. . . . . . . . . . . . . . . . . . . .
79
4.1.1
ROME . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
4.1.2
SNOMED CT . . . . . . . . . . . . . . . . . . . . . . .
Espressività
84
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
4.2.1
ROME . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
4.2.2
SNOMED CT . . . . . . . . . . . . . . . . . . . . . . . 103
4.2.3
Confronto
. . . . . . . . . . . . . . . . . . . . . . . . . 104
Complessità computazionale . . . . . . . . . . . . . . . . . . . 106
4.3.1
Cenni sulle classi di complessità . . . . . . . . . . . . . 106
4.3.2
ROME . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4.3.3
SNOMED CT . . . . . . . . . . . . . . . . . . . . . . . 109
4.3.4
Confronto
. . . . . . . . . . . . . . . . . . . . . . . . . 110
5 Conclusioni
111
2
Chapter 1
Introduzione
Il problema della condivisione della conoscenza è sempre stato, nella storia dell'uomo, di fondamentale importanza per lo sviluppo della società. Tale
problema al giorno d'oggi è ancora più visibile nel settore sanitario, il quale
è aitto da un problema di comunicazione: clinici e organizzazioni utilizzano spesso diversi termini clinici che signicano la stessa cosa (ad esempio
infarto del miocardio e infarto miocardico). Perciò ogni qualvolta si presenti
la necessità di inserire i dati medici in diversi database, sorgono inevitabili
problemi di integrazione che andrebbero risolti caso per caso.
Una prima soluzione a tale problema potrebbe essere l'adozione di un
sistema di codici accettato e vericato a livello internazionale, una sorta di
grande vocabolario a cui tutti possano fare riferimento e che permetta lo
scambio di informazioni indipendentemente dalla lingua in cui le informazioni
stesse sono originariamente espresse. Un codice standardizzato della medicina è stato paragonato alla necessità di unità di misura omogenee per le
scienze siche.
In realtà questo risolve solo in parte il problema: vi è la necessità di rappresentare tali informazioni in modo che siano comprensibili e processabili
anche dalle macchine, passando dunque dalla descrizione dei dati a quella
della conoscenza. Servono quindi le ontologie.
In questo capitolo verranno introdotte le nozioni fondamentali di argomenti quali le ontologie, OWL e le logiche descrittive, utili per la comprensione dei prossimi capitoli.
3
1.1 Ontologie
1.1
4
Ontologie
1.1.1
Denizioni
Il termine ontologia è preso in prestito dalla losoa: l'ontologia come
branca della losoa è la scienza di ciò che vi è, dei tipi e strutture di oggetti,
proprietà, eventi, processi e relazioni in ogni settore della realtà(Barry Smith).
In informatica, un'ontologia è una disciplina descrittiva o realista che non
cerca una spiegazione, bensì una descrizione della realtà classicando tutti
i tipi di entità, comprese le relazioni con cui esse sono collegate tra di loro.
Fornisce dunque una rappresentazione formale, condivisa ed esplicita di una
concettualizzazione di un dominio di interesse.
Il termine ontologia è entrato in uso nel campo dell'intelligenza articiale e della rappresentazione della conoscenza, per descrivere il modo in cui
diversi schemi vengono combinati in una struttura dati contenente tutte le
entità rilevanti e le loro relazioni in un dominio. In tal caso un'ontologia è
una:
•
Specicazione di una concettualizzazione (Gruber), nel contesto della
conoscenza e della condivisione di dati;
•
Un insieme di assiomi logici progettati per descrivere il signicato inteso di un vocabolario(Guarino);
•
Il soggetto dell'ontologia è lo studio delle categorie delle cose che esistono o possono esistere in qualche dominio. Il prodotto di tale studio,
chiamato una ontologia, è un catalogo dei tipi di cose, che si assume
esistano in un dominio di interesse D, dalla prospettiva di una persona
che usa un linguaggio L allo scopo di parlare di D( Sowa).
Per essere utilizzabili, le ontologie devono essere espresse in una notazione
concreta.
Un linguaggio per ontologie è un linguaggio formale con cui
viene costruita un'ontologia. Esistono diversi linguaggi, proprietari o basati
su standard, per la denizione di ontologie: OWL rappresenta l'attuale standard per ontologie in ambienti web.
Nel dominio sanitario si parla di ontologie biomediche:
esse sono con-
centrate sulla denizione delle classi biologiche principali e delle relazioni tra
loro. Le ontologie in medicina diventano l'infrastrutture di base per garantire
l' interoperabilità semantica. I sistemi di informazione medica devono essere
capaci di comunicare complessi e dettagliati concetti medici (possibilmente
espressi in dierenti linguaggi) in modo non ambiguo.
1.1.2 Classicazioni
1.1.2
5
Classicazioni
Una delle possibili classicazioni delle ontologie è svolta in base al dominio
che rappresentano o al livello di dettaglio che forniscono. Vi sono dunque le:
•
Top-level ontologies (o general o foundational ontologies): considerano
gli aspetti più generici e astratti ravvisabili nella realtà intesa nella
sua completezza. Considerano i concetti generali come oggetto, processo, tempo, comuni a diversi domini;
•
Domain ontologies: incentrate su uno specico contesto. Si occupano
dell'analisi categoriale e relazionale che si specica in una peculiare
porzione di realtà;
•
Application ontologies: ontologie progettate per uno specico task;
•
Reference ontologies: strato intermedio tra le ontologie top-level e le
ontologie di dominio. Sono sviluppate indipendentemente da un particolare scopo e servono come moduli condivisibili tra domini. Tecnicamente sono ontologie di dominio, in quanto si riferiscono ad un contesto
ben denito, come il diritto, l'agricoltura o la medicina.
Nonostante
tutto possono essere viste come top level per quanto riguarda il dominio
a cui si rivolgono.
Una seconda classicazione invece distingue tra:
•
Ontologie leggere:
sono semplici strutture tassonomiche di termini
primitivi o compositi con le relative denizioni.
Lo scopo è denire
i concetti impiegati in un determinato dominio o in una certa comunità d'uso. Il ruolo di queste ontologie è più quello di sostenere i servizi
terminologici
•
1
piuttosto che spiegare o denire il loro signicato inteso.
Ontologie assiomatiche: forniscono una assiomatizzazione logica rigorosa. Considerano non solo le relazioni tra i termini, ma soprattutto la
formale struttura del dominio che deve essere rappresentato. Si presentano in forme diverse e possono avere diversi livelli di generalità, ma una
particolare rilevanza è goduta delle cosiddette ontologie fondazionali:
esse utilizzano un linguaggio formale molto espressivo, sono utilizzate
come ponte tra le concettualizzazioni alternative e come traduttori del
signicato inteso nei diversi ambienti, grazie alla possibilità che danno
di denire una struttura terminologica trasversale alle comunità d'uso.
1 Inferenze sulla base di relazioni fra i termini
1.1.3 Vantaggi e applicazioni
6
Le ontologie leggere svologno un ruolo complementare a quello delle ontologie
assiomatiche: le prime possono essere costruite semi-automaticamente, ad
esempio sfruttando tecniche di machine learning; le seconde invece richiedono
un più faticoso lavoro umano, che può trarre beneci immensi dai risultati e
discipline come la losoa, la linguistica e le scienze cognitive.
1.1.3
Vantaggi e applicazioni
I vantaggi delle ontologie in ambito informatico possono essere riassunti
in due punti principali:
•
Possibilità di eettuare elaborazioni software avanzate: ragionamento
automatico, classicazione e svariate tecniche per la risoluzione di problemi;
•
Facilitare lo scambio di informazioni fra diversi sistemi
Questi vantaggi sono ancora più evidenti nel caso delle ontologie biomediche:
esse consentono infatti di costruire sistemi d'informazione sanitaria più potenti e interoperabili; di supportare la necessità di trasmissione dei processi
sanitari, il riuso e la condivisione dei dati dei pazienti; di fornire criteri basati
sulla semantica per supportare dierenti aggregazioni statistiche per diversi
scopi e di supportare l'integrazione della conoscenza e dei dati.
In sintesi
i vantaggi si traducono in supporto all'intera pratica sanitaria per medici,
infermieri, ausiliari e anche per i pazienti stessi, quindi in migliori cure e
assistenza sanitaria.
D'altro canto molti sono scettici sull'impatto che le ontologie possono
avere sulla progettazione e il mantenimento dei sistemi di informazione sanitari del mondo reale.
Tra i principali esempi di applicazioni delle ontologie in ambito sanitario
si possono citare:
•
Le cartelle cliniche elettroniche:
sono una versione elettronica delle
cartelle cliniche cartacee;
•
I sistemi di supporto decisionale: rappresentano un supporto per l'assunzione
di decisioni di tipo gestionale per i clinici.
1.2 OWL
1.2
7
OWL
OWL (Ontology Web Language) è un linguaggio per descrivere le classi
e le relazioni che le collegano inerenti ai documenti e alle applicazioni web.
OWL è parte del Semantic Web Stack della W3C, come ragurato in Figura1.1:
Figure 1.1: Semantic Web Stack della W3C
•
Alla base dello stack vi sono gli URI (Uniform Resource Identier),
ossia stringhe che identicano univocamente risorse generiche (indirizzi
web, documenti, immagini, les, servizi, indirizzi di posta elettronica).
Gli URL (Uniform Resource Locator) sono un sottoinsieme degli URI:
mediante URL si identicano risorse speciche della rete.
L'Unicode
è invece un sistema di codica che assegna un numero (o meglio, una
combinazione di bit) a ogni carattere in maniera indipendente dal programma, dalla piattaforma o dalla lingua;
•
L' XML (eXtensible Markup Language) permette di esplicitare la struttura di un documento in modo formale mediante marcatori (mark-up),
garantendo l' interoperabiltà sintattica;
•
L'RDF (Resource Description Framework) invece serve per descrivere
relazioni semantiche tra risorse. In questo contesto, OWL è un linguaggio per l'aggiunta di un servizio inferenziale a RDF.
1.2.1 Struttura
1.2.1
8
Struttura
Elementi base
Una ontologia OWL inizia con due componenti iniziali standard:
•
Lo spazio dei nomi XML: è una collezione di nomi di entità usate in
uno o più le sorgenti. Fornisce un mezzo per interpretare in maniera
non ambigua gli identicatori e rendere il resto della presentazione
dell'ontologia molto più leggibile.
•
L' intestazione dell'ontologia: è una collezione di aermazioni riguardanti
l'ontologia.
Segue le denizione delle classi. Un elenco riassuntivo degli elementi base di
OWL è riportato di seguito:
•
Classi semplici e individui: molti usi di una ontologia dipendono dalla
possibilità che orono di ragionare sugli individui. Per fare ciò in modo
utile ed eciente serve un meccanismo per descrivere le classi a cui
gli individui appartengono e le proprietà che essi ereditano in virtù
dell'appartenenza alle classi stesse: l'insieme degli individui che sono
membri di una classe vengono chiamati estensione di quella classe.
Classi semplici con nome: le classi di uno specico dominio possono essere denite semplicemente dichiarandone il nome. Il costrutto
OWL fondamentale per denire la tassonomia delle classi è
rdfs:subClassOf. Esso mette in relazione una classe specica con
una più generica.
Individui: sono introdotti principalmente dichiarando la loro appartenenza ad una classe.
•
Proprietà semplici: le proprietà permettono di asserire fatti generali
riguardo i membri delle classi e di asserire fatti specici riguardo gli
individui. Vengono distinte in base a se mettono in relazione individui
con individui (object properties) o individui con tipi di dati (datatype
properties). È possibile specicare le caratteristiche di una proprietà
allo scopo di fornire un meccanismo molto potente per agevolare ragionamenti sulle proprietà stesse.
Tali caratteristiche permettono di
distinguere tra:
Proprietà transitive: se una proprietà P è specicata come transitiva, allora per ogni x, y e z si ha logicamente che: P(x,y) e P(y,z)
implicano P(x,z);
1.2.1 Struttura
9
Proprietà simmetriche: se una proprietà P viene denita simmetrica, allora per ogni x e y si ha che: P(x,y) se e solo se P(y,x);
Proprietà funzionali: se una proprietà P viene denita come funzionale, allora per tutte le x, y e z si ha che:
P(x,y) e P(x,z)
implicano y = z;
Proprietà inverse: se una proprietà P1 viene denita come la proprietà inversa di P2, allora per tutte le x e y si ha che: P1(x,y) se
e solo se P2(y,x);
Proprietà funzionali inverse :
se una proprietà P viene denita
come una proprietà funzionale inversa, allora per tutte le x, y e z
si ha che: P(y,x) e P(z,x) implicano y = z.
È possibile limitare ulteriormente l'intervallo dei valori che una proprietà può
assumere in specici contesti, mediante i seguenti meccanismi:
•
allValuesFrom e someValuesFrom:
sono meccanismi locali, ovvero si
applicano solo alla classe in cui sono deniti. La restrizione
owl:allValuesFrom richiede che per ogni istanza della classe che ha
delle istanze della specica proprietà, i valori della proprietà devono
essere tutti membri appartenenti alla classe indicata nella clausola della
owl:allValuesFrom. La proprietà owl:someValuesFrom è simile: la differenza tra queste due formulazioni è la dierenza che sussite tra i due
quanticatori universale ed esistenziale.
•
owl:cardinality : permette di specicare esattamente il numero di elementi in una relazione.
•
owl:has value: permette di specicare delle classi sulla base dell'esistenza
di particolari valori della proprietà.
Class expressions
OWL fornisce altri costrutti addizionali per creare le cosiddette class expressions (o classi complesse). Le class expressions possono essere annidate
tra di loro senza che ci sia bisogno di creare un nome per ogni classe intermedia. OWL supporta a tale scopo i seguenti costrutti:
•
Operatori di insieme (intersectionOf, unionOf, complementOf );
•
Classi enumerate (oneOf ): per specicare una classe mediante l'enumerazione
diretta dei suoi membri;
1.2.2 Sottolinguaggi
•
10
Classi disgiunte (disjointWith): garantisce che un individuo che è membro di una classe non può essere contemporaneamente una istanza di
un'altra specica classe.
1.2.2
Sottolinguaggi
OWL fornisce tre sottolinguaggi di espressività crescente, progettati per
essere utilizzati da determinate comunità di sviluppatori e utenti:
•
OWL Lite: aiuta quegli utenti che hanno soprattutto bisogno di una
gerarchia di classicazione con semplici restrizioni;
•
OWL DL: supporta quegli utenti che vogliono il massimo dell' espressività senza perdere la completezza computazionale
2
e la decidibilità
3
dei sistemi di ragionamento. OWL DL comprende tutti i costrutti del
linguaggio OWL con delle restrizioni. OWL DL si chiama così a causa
della sua corrispondenza con la logica descrittiva
•
SHOIN 4 ;
OWL Full è destinato agli utenti che vogliono la massima espressività
e libertà sintattica di RDF, senza garanzie computazionali;
1.2.3
OWL2
OWL 2 è un ampliamento e revisione di OWL. Nella Figura 2 l'ellisse
al centro rappresenta la nozione astratta di una ontologia, che può essere
pensata sia come una struttura astratta che come un grafo RDF. Nella parte
superiore della gura vi sono varie sintassi concrete che possono essere utilizzate per serializzare e scambiare ontologie: la sintassi primaria per lo scambio
di OWL 2 è RDF/XML. In basso vi sono le due speciche semantiche che
deniscono il signicato di ontologie OWL 2: la semantica diretta e la semantica basata su RDF, mentre un teorema di corrispondenza fornisce un
collegamento tra le due. Queste due semantiche sono utilizzate da ragionatori e altri strumenti, ad esempio per rispondere a problemi di consistenza di
classi, sussunzione e query di recupero delle istanze.
La semantica diretta assegna signicato direttamente alla struttura dell'
ontologia, ottenendo una semantica compatibile col modello teorico semantico della logica descrittiva:
le ontologie che soddisfano queste condizioni
sintattiche sono chiamate ontologie OWL 2 DL.
OWL 2 aggiunge nuove funzionalità rispetto alla versione OWL 1.1, tra
2 Tutte le conclusioni hanno la garanzia di essere calcolabili
3 Tutte le computazioni niscono in un tempo denito
4 Vedere paragrafo 1.3.3
1.2.3 OWL2
11
Figure 1.2: OWL2
cui l'introduzione di syntactic sugar e di nuovi costrutti più espressivi.
I proli OWL 2 sono sotto-linguaggi (sottoinsiemi sintattici) di OWL 2
che orono vantaggi importanti in scenari di applicazione particolari:
•
OWL 2 EL: indicato per applicazioni in cui sono necessarie ontologie
molto grandi, e in cui il potere espressivo può essere sacricato per
ottenere garanzie nelle prestazioni (sono poste restrizioni sintattiche
su costrutti e assiomi). Il prolo EL++ è concepito come il massimo
sottoinsieme di OWL 2 DL;
•
OWL 2 QL: indicato per applicazioni in cui vengono utilizzate ontologie
relativamente leggere per organizzare un gran numero di individui, e
dove è utile o necessario accedere ai dati direttamente tramite query
relazionali;
•
OWL 2 RL: indicato per applicazioni in cui vengono utilizzate ontologie
relativamente leggere per organizzare un gran numero di individui, e
1.3 Logiche descrittive
12
dove è utile o necessario operare direttamente sui dati in forma di triple
RDF.
Ogni prolo è denito come una restrizione sintattica delle speciche strutturali di OWL 2: ciascuno dei proli raggiunge un trade-o rinunciando a
parte della potenza espressiva di OWL in cambio di diversi beneci computazionali e/o implementativi.
1.3
Logiche descrittive
Le Logiche Descrittive
5
(Description Logics, DLs) sono una famiglia di
6
formalismi di rappresentazione della conoscenza : esse rappresentano la conoscenza di un dominio di applicazione (detto mondo) denendo per prima i
concetti rilevanti del dominio (la terminologia) e poi utilizzando questi concetti per specicare proprietà di oggetti e individui che occorrono nel dominio
(la descrizione del mondo).
Le DL sono dotate di una semantica formale
basata su logica.
L'enfasi è data al ragionamento: esso permette di inferire conoscenza rappresentata implicitamente dalla conoscenza che è esplicitamente contenuta nella
7
base di conoscenza .
Problemi di decidibilità e complessità dei problemi di inferenza dipendono
dal potere espressivo delle DL: da un lato DL molto espressive possono avere
problemi inferenziali dovuti ad una elevata complessità, o possono essere anche indecicibili; d'altro canto DL molto snelle (con procedure di ragionamento
ecienti) potrebbero non essere sucientemente espressive da rappresentare
i concetti importanti di una data applicazione.
La ricerca del trade-o tra l'espressività delle DL e la complessità dei loro
problemi di reasoning è uno dei principali problemi nella ricerca. Tuttavia,
8
l' intrattabilità di ragionamento
non impedisce a una DL di essere usata
in pratica, grazie alle sosticate tecniche di ottimizzazione che sono usate
nell'implementazione di sistemi basati su DL.
5 D'ora in poi saranno indicate anche con DL
6 Branca dell'intelligenza articiale che studia il modo in cui avviene il ragionamento
umano e si preoccupa di denire dei simbolismi o dei linguaggi che permettano di formalizzare la conoscenza, al ne di renderla comprensibile alle macchine per potervi fare dei
ragionamenti automatici ed estrarre così nuova conoscenza
7 Detta anche Knowledge base (KB): è un tipo speciale di database per la gestione della
conoscenza
8 L' essere non-polinomiale nel peggiore dei casi. Vedere paragrafo 4.3.1
1.3.1 Denizione del formalismo di base
1.3.1
13
Denizione del formalismo di base
Un sistema di rappresentazione della conoscenza basato su logica descrittiva fornisce dei mezzi per impostare una base di conoscenza, per ragionare
sul suo contenuto e per manipolarlo. La gura 1.3 mostra l'architettura di
un sistema tale.
Una base di conoscenza comprende due componenti: un TBox e un ABox.
Il TBox introduce la terminologia, ossia il vocabolario di un dominio di applicazione, mentre l'ABox contiene le asserzioni circa individui del vocabolario.
Il vocabolario è costituito da concetti (concept), che denotano insiemi di individui, e regole (role names), che denotano relazioni binarie tra individui. In
aggiunta, tutti i sistemi DL permettono ai loro utenti di costruire descrizioni
complesse di concetti e ruoli: il TBOX può essere usato per assegnare nomi
a descrizioni complesse.
Un sistema DL non memorizza solo terminologie e asserzioni, ma ore
anche servizi di reasoning su esso.
Figure 1.3: Architettura di un sistema di rappresentazione della conoscenza
basato su Logica Descrittiva
1.3.2
Description languages
Le logiche descrittive vengono espresse in modo formale tramite i linguaggi descrittivi. I concetti atomici e i ruoli atomici sono descrizioni elementari: partendo da essi è possibile costruire descrizioni complesse per induzione utilizzando i costruttori di concetto. In notazione astratta si usano
le lettere A e B per i concetti atomici, la lettera R per i ruoli atomici e le
1.3.3 La famiglia dei linguaggi
AL
14
lettere C e D per le descrizioni di concetti.
I linguaggi descrittivi sono distinti in base ai costruttori che forniscono.
Il linguaggio
AL (Attributive Language) è stato introdotto come un linguag-
gio minimale di interesse pratico. Gli altri linguaggi di questa famiglia sono
estensioni di
AL.
Le descrizioni di concetti in
AL
sono realizzate seguendo le seguenti re-
gole sintattiche:
C,D
→A: concetto atomico;
>: concetto universale;
⊥: concetto bottom;
¬A: negazione atomica;
CuD: intersezione;
∀R.C: quanticatore universale;
∃R.>: quanticatore esistenziale
limitato.
AL,
Al ne di denire una semantica formale associata ai concetti
considera l'interpretazione I, che consiste in un insieme non vuoto
I
∆
si
(il do-
minio dell'intrepretazione) e in una funzione di intrepretazione che assegna
I
I
ad ogni concetto atomico A un insieme A ⊆ ∆ e ad ogni ruolo atomico R
I
I
I
una relazione binaria R ⊆ ∆ ×∆ .
1.3.3
La famiglia dei linguaggi
Aggiungendo altri costrutti ad
AL
AL si ottengono linguaggi molto più espres-
sivi:
• U:
comprende il costrutto per l'unione di concetti: CtD;
• E:
comprende il quanticatore esistenziale completo:
∃R.C.
Esso dif-
ferisce dal quanticatore esistenziale limitato (∃R.>) perché nell'ambito
del quanticatore possono comparire anche concetti arbitrari e non solo
il concetto universale;
• N:
• C:
comprende le restrizioni numeriche:
≤(almeno)
comprende la negazione di concetti arbitrari:
Estendendo
e
≥(al
massimo);
¬C.
AL con alcuni dei costrutti sopra indicati si ottengono particolari
AL[U ][E ][N ][C ], dove ad ogni
linguggi, denominati da una stringa nella forma
lettera corrisponde la presenza dei corrispondenti costrutti.
Da un punto di vista semantico questi linguaggi non sono tutti distinti: vi
sono infatti le seguenti equivalenze CtD
≡ ¬(¬Cu¬D)
e
∃R.C ≡ ¬∀R.¬C.
1.3.4 Terminologia-TBox
15
È evidente che l'unione e il quanticatore esistenziale possono essere espressi
usando la negazione: di conseguenza si assume che essi siano disponibili in
tutte le lingue che contengono la negazione e viceversa. Perciò spesso si usa
la lettera
C
al posto delle lettere
UE .
9
La notazione letterale standard include anche :
• S:
estende la DL
ALE
con l'ulteriore possibilità di denire la chiusura
transitiva di un ruolo;
• H:
fornisce la possibilità di denire gerarchie tra ruoli;
• O:
asserisce la presenza dell'operatore di enumerazione;
• I:
permette di riferirsi al ruolo inverso;
• F, N , Q:
caratterizzano le possibilità di denire cardinalità rispetti-
vamente funzionale, semplice e qualicata (in ordine di espressività
crescente);
• (D):
descrive la possibilità di riferirsi a domini concreti.
La semantica dei concetti identica i linguaggi descrittivi come frammenti
della logica dei predicati del primo ordine.
1.3.4
Terminologia TBox
Una terminologia è costituita da un insieme di denizioni con cui si possono introdurre concetti atomici come abbreviazioni per indicare concetti più
complessi.
Nel dettaglio, un TBoX contiene assiomi terminologici, cioè aermazioni su
come i concetti o i ruoli sono collegati gli uni agli altri. Essi hanno la forma
di:
•
Denizioni C≡D (R≡S): sono assiomi specici, uguaglianze sul cui lato
sinistro vi è un concetto atomico.
Le denizioni sono utilizzate per
introdurre nomi simbolici al posto di descrizioni complesse. Un insieme
nito di denizioni T è chiamato una terminologia o TBox se non vi
sono nomi simbolici deniti più di una volta.
•
Assiomi di inclusione CvD (RvS): si usa l'inclusione per concetti che
non si è in grado di denire completamente. Un insieme di assiomi T
9 Per approfondimenti consultare il The description logic handbook: theory, implementation, and applications(Baader,F.,McGuinness,D.L.,Nardi,D.,Patel-Schneider,P.F.)
1.3.5 Descrizione del mondo-ABox
16
è un terminologia generalizzata se sul lato sinistro di ogni assioma vi è
un concetto atomico e per ogni concetto atomico vi è al più un assioma
in cui esso compare sul lato sinistro.
1.3.5
Descrizione del mondo-ABox
Il secondo componente di una base di conoscenza, in aggiunta al Tbox, è
la descrizione del mondo (Abox). Nell' ABox si descrive un particolare stato
di un dominio tramite asserzioni su individui. Si possono fare aermazioni
dei due tipi seguenti:
•
Asserzione di concetto C(a): asserisce che l'individuo a appartiene al
concetto C;
•
Asserzione di ruolo R(b,c): aerma che l'individuo c è un role-ller R
(argomento del ruolo R) per l'individuo b.
A volte singoli nomi (chiamati anche nominals) sono presenti non solo nell'
ABox, ma anche nel TBox.
Tra i costruttori di concetto che impiegano
individui vi sono il costruttore set { a1, ... ,an } e il costruttore lls R:a .
1.3.6
Inferenza
Un sistema di rappresentazione della conoscenza basato su DL è in grado
di svolgere determinati tipi di ragionamento deniti come inferenze logiche.
Nel dettaglio, i reasoning tasks per un Tbox sono:
•
Soddisfacibilità:
un concetto ha senso se c'è qualche interpretazione
che soddisfa gli assiomi di T (cioè un modello di T) tale che il concetto
indica un insieme non vuoto secondo questa interpretazione. Un concetto con questa proprietà si dice essere soddisfacibile rispetto a T e
insoddisfacibile altrimenti. La verica della soddisfacibilità dei concetti
è un problema di inferenza chiave;
•
Sussunzione: verica se un concetto è più generale di un altro.
Un
concetto C è sussunto da un concetto D se in ogni modello di T l'insieme
denotato da C è un sottoinsieme dell'insieme contrassegnato da D;
•
Equivalenza: dati due concetti C e D, verica se è vero che in ogni
modello della base di conoscenza si ha che le interpretazioni dei due
concetti coincidono;
1.3.6 Inferenza
•
17
Disgiunzione: dati due concetti C e D, verica se è vero che in ogni
modello della base di conoscenza si ha che le interpretazioni dei due
concetti sono insiemi disgiunti.
Al ne di ottenere procedure di decisione per ognuna delle quattro inferenze
discusse in realtà è suciente sviluppare algoritmi che decidono la sola soddisfacibilità dei concetti, a condizione che il linguaggio supporti la congiunzione
così come la negazione di concetti arbitrari, e contenga il concetto insoddisfacibile
10
.
Inoltre, per lo sviluppo di procedure di ragionamento è concettualmente più
semplice astrarre dal TBOX o, il che è lo stesso, ritenere che esso sia vuoto.
Se T è un TBox aciclico, si possono sempre ridurre i problemi di ragionamento riguardanti T a problemi riguardanti il TBox vuoto.
I Reasoning tasks per un ABox invece sono:
•
Consistenza: un ABox A è consistente rispetto ad una TBox T se vi è
una interpretazione che è un modello di A e T. Si può dire semplicemente che A è consistente se è consistente rispetto al TBox vuoto;
•
Instance check: data una base di conoscenza KB, ovvero una TBox T
ed un ABox A, e dati un termine C ed un nominale, stabilisce se C(a)
è conseguenza logica di KB;
•
Retrieval: dato un ABox A e un concetto C, trova tutti gli individui
tali che C(a) è conseguenza logica di A;
•
Realization: dato un individuo e un insieme di concetti, trova il concetto più specico C dell'insieme per cui C(a) è conseguenza logica di
A.
Il ragionamento su concetti (TBox) può essere a sua volta ricondotto alla
verica di consistenza: la soddisfacibilità dei concetti può essere ridotta a
consistenza dell' ABox perché C è soddisfacibile se C(a) è consistente.
10 Per approfondimenti, consultare il The description logic handbook: theory, implementation, and applications, Baader,F.,McGuinness,D.L.,Nardi,D.,Patel-Schneider,P.F.,
Cambridge University Press
1.3.7 Estensioni del linguaggio
1.3.7
18
Estensioni del linguaggio
È possibile inoltre esprimere relazioni tra insiemi di role-ller di dierenti
11
(complessi) ruoli, tramite restrizioni numeriche e costrutti più espressivi
•
:
Costruttori di ruoli: dato che i ruoli sono interpretati come relazioni
binarie, si possono impiegare i soliti operatori (ad esempio gli operatori
booleani) sulle relazioni binarie per formare nuovi ruoli;
•
Restrizioni numeriche espressive:
si possono prendere in considera-
zione le cosiddette restrizioni numero qualicate, dove le restrizioni
numeriche riguardano role-llers appartenenti ad un certo concetto;
•
Role-values-maps: sono una famiglia di costrutti molto espressivi. In
dettaglio, una role chain è una composizione del tipo R1◦R2. . .◦Rn
di nomi di ruolo.
Se R e S sono role chain, allora R⊆S e R=S sono
role-value-maps.
11 Per approfondimenti, consultare il The description logic handbook: theory, implementation, and applications, Baader,F.,McGuinness,D.L.,Nardi,D.,Patel-Schneider,P.F.,
Cambridge University Press
Chapter 2
SNOMED CT
2.1
Panoramica
SNOMED CT (Systematized Nomenclature of Medicin-Clinical Terms) è
la terminologia clinica sanitaria più completa e multilingue al mondo (utilizzata in circa 50 paesi, tra cui non compare l'Italia).
Il suo obiettivo è
rappresentare precisamente le informazioni cliniche in tutti i campi di applicazione dell' assistenza sanitaria: fornisce infatti contenuti clinici per la
documentazione clinica e collabora con altri standard internazionali. È una
risorsa essenziale per le cartelle cliniche elettroniche, con un contenuto completo e validato scienticamente.
Attualmente è ancora viva la questione se si tratti o no di una ontolo-
1
gia: secondo i documenti uciali rilasciati dalla HITSDO , SNOMED CT è
denito come una terminologia clinica sempre più guidata da principi ontologici, in quanto soggetto a continue revisioni; in letteratura invece lo si
denisce un'ontologia. Uno dei primi risultati dello studio riportato in questa
tesi è che eettivamente presenta tutte le caratteristiche di un'ontologia,
sebbene non di alta qualità secondo quelli che sono i canoni dell'ingegneria
2
ontologica .
SNOMED CT presenta le seguenti caratteristiche peculiari, che contribuiscono ad una sua diusa adozione:
•
Completezza: dispone di un' ampia copertura di argomenti relativi alla
salute e di una profondità senza precedenti, che consente ai medici di
registrare i dati al livello adeguato di granularità;
•
Scalabilità: il numero di concetti in SNOMED CT continua a crescere,
1 Ente che ne detiene i diritti, vedere paragrafo 2.2
2 Vedere paragrafo 4.1
19
2.1 Panoramica
20
come ragura il trend degli ultimi anni in gura 2.1;
•
Flessibilità: applicazioni speciche tendono a concentrarsi su un sottoinsieme ristretto del contenuto di SNOMED CT. Inoltre, quando singole giurisdizioni hanno esigenze che vanno al di là di quelle che possono
riettersi in una terminologia a livello mondiale, possono sviluppare
estensioni locali o nazionali.
Figure 2.1:
Numero di concetti attivi di SNOMED CT dal 2002 al 2008.
(Fonte: www.hitsdo.org)
•
Supporto di dierenti lingue: sebbene la International Release includa
concetti e relazioni indipendenti dal linguaggio, essa incorpora dei framework per gestire diverse lingue e dialetti;
•
Cross maps: fornisce collegamenti espliciti con classicazioni e schemi
di codica connessi alla salute in uso in tutto il mondo (ad esempio
3
classicazioni di diagnostica, come ICD-9-CM, ICD-O3, e ICD-10 , così
come la classicazione OPCS-4 degli interventi).
Le distribuzioni di SNOMED CT sono composte da una serie di prodotti:
•
SNOMED CT terminology les, composti da Concetti, Descrizioni, Relationships;
3 La classicazione ICD (dall'inglese International Classication of Diseases) è la classicazione internazionale delle malattie e dei problemi correlati, stilata dall'Organizzazione
mondiale della sanità (OMS-WHO)
2.1 Panoramica
21
•
Strumenti tecnici per sostenere lo sviluppo e la richiesta di elaborazioni;
•
Un insieme di standard alleati SNOMED CT, che consentono a SNOMED
CT di interoperare in modo ecace con e/o mapparsi con altri standard
internazionali;
•
Norme di attuazione per l'uso di SNOMED, tra cui Traduzioni e
Re-
ference Implementetion Instructions;
•
Servizi per mantenere un database in linea con i concetti necessari;
•
Opere derivate che contribuiscono alla diusione e l'uso di SNOMED:
regole di implementazione, guide di riferimento.
2.2 Storia
2.2
22
Storia
SNOMED CT è il risultato di uno sviluppo congiunto dell'NHS (National
4
Health Service ) in Inghilterra e il CAP (College of American Pathologists).
È stato costituito nel 1999 dalla convergenza di SNOMED RT (SNOMED
Reference Terminology, sistema di classicazione multiassiale) e CTV3 (Cli-
5
nical Terms Version3 ). SNOMED CT è stato in reltà avviato nel 1965 come
SNOP (Systematized Nomenclature of Pathology), e successivamente esteso
in altri campi della medicina.
Nel 2007 i diritti di proprietà intellettuale di SNOMED CT sono stati trasferiti dalla CAP alla SNOMED SDO nella creazione formale della IHTSDO
(International Health Terminology Standards Development Organisation):
organizzazione internazionale no-prot con sede in Danimarca. La IHTSDO
possiede e gestisce i diritti di SNOMED CT, compreso il diritto di rilasciare
6
le licenze SNOMED CT necesssarie per poterlo utilizzare .
La HITSDO ha una serie di membri, divisi in due categorie: i membri
fondatori (ossia i paesi che hanno lanciato l'organizzazione stessa nel 2007,
come gli Stati Uniti, Canada, Australia, Regno Unito, Danimarca, Svezia,
Lituania, Paesi Bassi, Nuova Zelanda) e i soci ordinari (quei paesi che hanno
aderito/aderiscono successivamente).
I membri hanno una serie di diritti e responsabilità, tra cui coordinare le
richieste di integrazioni o modiche a SNOMED CT da ciascun paese.
L'
IHTSDO's online Request Submission System consente infatti ai National
Release Centers
7
dei paesi membri e ad altri utenti autorizzati di richiedere
modiche o aggiunte al contenuto della International Release di SNOMED
CT.
L'organizzazione fattura ogni membro di tasse annuali, calcolate in base al
reddito nazionale lordo dalla banca mondiale. Nella gura 2.2 è riportata una
porzione della tabella dove sono indicate le quote che ogni nazione dovrebbe
8
pagare se decidesse di diventare membro, espresse in dollari statunitensi .
Secondo l' ultimo aggiornamento risalente al 2007 e pubblicato sul sito uciale della organizzazione, l'Italia dovrebbe pagare una tassa annua di circa
680.000 dollari statunitensi.
4 Il Servizio Sanitario Britannico
5 Classicazione computer-based conosciuta come Read Codes Version 3
6 SNOMED CT è un Crown copyright, copyright per tutte le pubblicazioni governative
7 I centri di rilascio nazionale
8 ATLAS è un fattore di conversione usato nel calcolo del reddito nazionale lordo (GDI).
USD sta per dollari statunitensi
2.2 Storia
23
Figure 2.2: Porzione della tabella che riporta le tasse annuali per i potenziali
membri della HITSDO. (Fonte: www.HITSDO.org)
La HITSDO lavora con altre organizzazioni che stabiliscono standard per
promuovere l'uso coerente della terminologia, tra cui:
•
HL7 - Health Level 7 : SNOMED è uno standard registrato nel HL7
Vocabulary Technical Committee per l'uso in messaggi HL7;
•
DICOM - Digital Imaging and Communications in Medicine;
•
ISO - International Organization for Standardization;
•
X12 - Accredited Standards Committee;
•
American Academy of Ophthalmology;
2.2 Storia
24
•
ANSI - American National Standards Institute (Stati Uniti);
•
Il progetto Australian General Practice Vocabulary;
•
CHI-consolidated Health Informatics Initiative (Stati Uniti);
•
IOM - Institute of Medicine (Stati Uniti);
•
National Committee on Vital and Health Statistics (United States);
•
NCVHS Subcommittee on Standards and Security.
Inoltre la World Health Organization (WHO) e l'IHTSDO discutono attivamente le possibilità di armonizzazione tra le due organizzazioni.
Ciò ha
incluso la costituzione di un Interim Harmonization Panel avvenuta tra il
luglio 2008 e marzo 2009.
2.3 Utilizzi
2.3
25
Utilizzi
SNOMED CT è utilizzato principalmente come:
•
Standard per le informazioni cliniche: le applicazioni software possono
utilizzare i concetti, le gerarchie e le relazioni SNOMED CT come un
punto di riferimento comune per l'analisi dei dati;
•
Base per applicazioni di analisi: le organizzazioni di assistenza sanitaria
possono sviluppare applicazioni di analisi ecaci per condurre i risultati
della ricerca, valutare la qualità e il costo delle cure e progettare linee
guida di un trattamento ecace.
I vantaggi del suo impiego in questi contesti sono:
•
Informazioni più facilmente accessibili e complete: i fornitori di servizi
sanitari sono supportati nel processo di assistenza sanitaria (anamnesi,
malattie, cure, risultati di laboratorio ecc.) con risultati migliori per i
pazienti;
•
Trattamento facilitato: una terminologia clinica può consentire a un
fornitore di cure sanitarie di identicare i pazienti sulla base di alcune
informazioni codicate nelle loro cartelle.
Per utilizzare SNOMED CT serve una licenza di aliazione, che può essere
richiesta da individui e organizzazioni appartenenti o no a paesi membri:
•
Se la richiesta di utilizzo proviene da individui e organizzazioni presenti
nel territorio di un paese membro, basta contattare il centro di rilascio
nazionale, che fornirà SNOMED CT gratuito per gli utenti o potrà
addebitare una piccola tassa per il recupero dei costi;
•
Per i paesi a basso reddito, a partire dal 2009 le licenze di aliazione
per l'uso di SNOMED CT sono rilasciate a titolo gratuito;
•
Se la richiesta di utilizzo proviene da un paese non membro e non a
basso reddito, è necessario richiedere la licenza di aliazione on-line,
utilizzando un servizio apposito.
Ottenuta la licenza si è contattati
ogni 6 mesi dalla HITSDO per un resoconto dell'utilizzo che si è fatto
di SNOMED CT, e vine conseguentemente fatturata la tasse di licenza
applicabile. Sono esenti dal pagamento i progetti di ricerca qualicati,
di benecenza e i progetti per scopi umanitari.
2.4 Componenti base
2.4
26
Componenti base
2.4.1
Concetti
Un concetto rappresenta un preciso signicato clinico ed è identicato
da un identicativo numerico (conceptID). Ad esempio il conceptID 55679008
indica il concetto Peribronchial pneumonia (disease).
I concetti attivi sono più di 311.000, numero che è in continua crescita grazie
alla collaborazione internazionale (gura 2.1).
Ogni concetto è rappresentato da:
•
Un Fully Specied Name (FSN): fornisce una rappresentazione humanreadable;
•
Relazioni con altri concetti: gli danno una denizione formale;
•
Una serie di termini: spiegano il concetto in un modo human-readable.
La rappresentazione dei concetti è molto granulare: i concetti possono essere generali o possono rappresentare sempre più specici livelli di dettaglio
(granularità maggiore), consentendo ai clinici di scegliere il livello di dettaglio
che preferiscono (Figura 2.3).
2.4.1 Concetti
27
Figure 2.3: Granularità dei concetti SNOMED CT
I contenuti sono divisi in gerarchie: il Root concept è il supertipo dei
concetti top-level e di tutti i concetti al di sotto di essi (gura 2.4). L'elenco
completo delle gerarchie è il seguente:
•
Clinical nding : rappresenta i risultati di una osservazione, valutazione
o giudizio clinico. Include le condizioni cliniche sia normali che anormali
(ad es. Poor posture). Contiene la sotto-gerarchia Disease (ad esempio
Tuberculosis);
•
Procedure : descrive le attività svolte nella fornitura di assistenza sanitaria (ad esempio Appendectomy ), come procedure invasive, somministrazione di farmaci, procedure di imaging, procedure amministrative;
•
Observable entity : descrive questioni o procedure che possono produrre
una risposta o un risultato (ad esempio colore dell'unghia);
2.4.1 Concetti
28
Figure 2.4: Gerarchia dei concetti SNOMED CT
•
Body structure: descrive le strutture anatomiche normali e anormali.
Normali strutture anatomiche possono essere utilizzate per specicare
il sito del corpo interessato da una malattia o una procedura (ad es.
Structure of the mitral valve). Contiene la sotto-gerarchia Body structure, altered from its oríginal anatomical structure (morphologic abnormality);
•
Organism:
rappresenta organismi di rilevanza in medicina umana e
animale (ad esempio Streptococcus pyogenes). È utilizzata anche nella
modellazione delle cause delle malattie;
•
Substance: descrive le sostanze generali e i componenti chimici di Pharmaceutical/biologic product (ad esempio Insulin).
Sotto-gerarchie di
Substance comprendono anche, ma non sono limitate a:
stance
Body sub-
(concetti per rappresentare sostanze del corpo), Dietary sub-
stance, Diagnostic substance;
•
Specimen: concetti che rappresentano entità che si ottengono da un
esame o analisi, di solito da un paziente (ad esempio samples obtained
by prostate biopsy );
•
Special concept: contiene la sotto-gerarchia Inactive concept, che è il
supertipo per tutti i concetti che sono stati ritirati e che contengono
un riferimento a un corrispondente concetto attivo nella terminologia;
2.4.1 Concetti
•
29
Pharmaceutical/biologic product: gerarchia di livello superiore che consente di distinguere chiaramente i prodotti faramaceutici (products) dai
loro costituenti chimici (substances). I livelli di prodotti farmaceutici
rappresentati nella International Release comprendono:
Virtual Medicinal Product (VMP): è il livello più granulare. Nel
Fully Specied Name è compreso il nome del prodotto, il dosaggio
e come si presenta la dose (ad es. Diazepam 5mg tablet);
Virtual Therapeutic Moiety (VTM): il Fully Specied Name include solo il nome del prodotto (ad es. Diazepam). Tutti i VMP
hanno un collegamento diretto col VTM attraverso una relationship IS_A
9
;
Product category : tipicamente descrivono comuni categorie di farmaci usati nella prescrizione (ad es. sex hormone product).
Inoltre, sono state sviluppate delle estensioni per gli Stati Uniti e il
Regno Unito per rappresentare gli Actual Medicinal Products (AMPs):
i concetti AMP contengono marca e informazioni speciche del paese, e
non sono rappresentati all'interno della International Release di SNOMED
CT. Una estensione Actual Medicinal Products ha un link diretto al
suo equivalente virtuale nella International Release attraverso la relationship IS_A. La gura 2.5 ragura una porzione della gerarchia dei
Pharmaceutical/biologic product.
9 Vedere capitolo 2.4.3
2.4.1 Concetti
30
Figure 2.5: Gerarchia Pharmaceutical/ biologic product
•
Physical object: descrive gli oggetti naturali e fatti dall'uomo (ad es.
Articial kidney );
•
Physical force: descrive le forze siche che possono svolgere un ruolo
nel provocare lesioni (ad es. Spontaneous combustion);
•
Event: rappresenta eventi, escluse le procedure e gli interventi (ad es.
ood);
2.4.1 Concetti
•
31
Environment or geographical location: descrive i tipi di ambienti e i
nomi di località, quali i paesi, gli stati e le regioni (ad es.
Canary
islands, o Intensive care unit);
•
Social context: descrive le condizioni sociali e le circostanze rilevanti per
l'assistenza sanitaria, come lo stato di famiglia, la situazione economica,
il patrimonio etnico e religioso (ad es. Ethnic group: Afro-Caribbean),
lo stile di vita, e le occupazioni;
•
Staging and scales: contiene le sotto-gerarchie:
Assessment scales: nomi di scale di valutazione (ad es. Glasgow
coma scale);
Tumor stagin: nomi di sistemi di stadiazione del tumore (ad es. International Federation of Gynecology and Obstetrics -FIGO- staging );
•
Linkage concept: rappresenta i concetti utilizzati per il collegamento
dei concetti tra loro. Contiene le sotto-gerarchie:
Link assertion : consente l'utilizzo di concetti SNOMED CT nell'ambito
di relazioni tra asserzioni previste da HL7;
Attribute: utilizzati per indicare la relazione o il tipo di relazione
tra 2 oggetti SNOMED CT:
∗
Dening attributes:
·
IS_A attribute:
per la denizione delle gerarchie tra i
concetti;
·
Concept model attribute: ad esempio Laterality, Procedure site, Finding site, Associated morphology.
∗
Non-dening attributes:
·
Concept history attribute: utilizzati per tracciare le relazioni temporali tra i concetti, come replaced by, same
as;
·
Unapproved attribute:
utilizzati per tracciare relazioni
non previste dai modelli pre-coordinati in SNOMED CT,
come Relieved by.
•
Qualier value: contiene alcuni dei concetti utilizzati come valori per
attributi SNOMED CT (ad es. left);
2.4.2 Descrizioni
•
32
Record artifact: descrive una entità che è stata creata da una o più
persone allo scopo di fornire ad altre persone informazioni su eventi o
stati di cose. Un record è virtuale (indipendente dalla sua particolare
istanziazione sica), e si compone dei suoi elementi di informazione, di
solito le parole e le frasi, ma anche i numeri, graci, e altri elementi
informativi;
•
Situation with explicit context: SNOMED CT ha sviluppato un context
model per consentire agli utenti e/o implementatori di specicare il
contesto usando la terminologia, senza dipendere da una particolare
struttura record (ad es.
Family history:
Myocardial infarction, No
family history of stroke, Nasal discharge present, Suspected epilepsy ).
2.4.2
Descrizioni
Il secondo componente base di SNOMED CT è costituito dalle descrizioni:
si tratta di termini o nomi assegnati ad un concetto per spiegarne meglio il
signicato. Le descrizioni presenti sono quasi 800.000.
Vi sono tre tipi di descrizioni:
•
Fully Specied Names (FSN): forniscono un modo univoco per nominare un concetto. Terminano con un semantic tag in parentesi alla ne
del concetto che indica la categoria semantica a cui appartengono (ad
es. Disorder, Organism, Person, ecc.). Un esempio di FSN è Hematoma
(morphologic abnormality);
•
Preferred Term: catturano la parola comune o frase usata dai medici
per nominare un concetto. Non sono necessariamente univoci per ogni
concetto. Ad es. il concetto Repair of common bile duct (procedure)
54987000 ha il Preferred Term Choledochoplasty ;
•
Synonyms: lo scopo è quello di rappresentare qualsiasi ulteriore termine
che rappresenta lo stesso concetto del FSN. Anche i sinonimi non sono
necessariamente univoci per ogni concetto.
Le descrizioni possono essere multiple, nel senso che più descrizioni potrebbero essere associate ad uno stesso concetto. Ad esempio, alcune delle descrizioni associate al ConceptID 22298006 sono:
•
Fully Specied Name: Myocardial infarction (disorder) - DescriptionID
751689013 ;
•
Preferred term: Myocardial infarction - DescriptionID 37436014 ;
2.4.3 Relationships
33
•
Synonym: Cardiac infarction - DescriptionID 37442013 ;
•
Synonym: Heart attack - DescriptionID 37443015 ;
•
Synonym: Infarction of heart - DescriptionID 37441018.
2.4.3
Relationships
Terzo e ultimo elemento chiave di SNOMED CT è costituito dalle relationship: esse collegano i concetti tra di loro. Di conseguenza ogni concetto
risulta essere logicamente denito attraverso le sue relazioni con altri concetti. Le relationships attualmente presenti sono circa 1.360.000.
Ogni concetto attivo SNOMED CT (ad eccezione del concetto root SNOMED
CT Concept) ha almeno una relationship IS_A con un concetto supertipo.
Una relationship viene assegnata solo quando tale relazione è sempre vera.
Le principali tipologie di relationships sono:
•
Dening relationships: usate per modellare i concetti e creare le loro
denizioni logiche. Ulteriore distinzione è fatta tra le:
IS-A relationship: servono a creare gerarchie tra concetti, quindi
a creare relazione del tipo padre-glio.
L'esempio in gura 2.6
mostra come un concetto possa avere più di una relationship IS_A
con altri concetti;
Figure 2.6:
Esempio di gerarchia multipla in SNOMED CT
Dening attribute: gli attributi di collegano due concetti appartenenti a diverse gerarchie e stabiliscono il tipo di relazione tra loro.
Ogni attributo ha un dominio, che indica la gerarchia a cui uno
specico attributo può essere applicato, e un range, che indica
2.4.3 Relationships
34
l'insieme dei valori ammessi per ciascun attributo: del range possono far parte anche più gerarchie. L'esempio in gura 2.7 mostra
i due concetti polmonite e struttura dei polmoni, collegati attraverso l'attributo nding site:
ciò signica che la polmonite
viene riscontrata nella parte del corpo chiamata struttura polmonare.
Vi sono oltre 50 diversi tipi di attributi di questo tipo in SNOMED
Figure 2.7: Esempio di dening attribute in SNOMED CT
CT. Gli attributi hanno relazioni gerarchie tra loro, come avviene
per i concetti: un attributo generale è genitore di uno o più sot-
10
totipi specici di tale attributo
•
.
Qualifying relationships: opzionali e non-dening, possono essere ap-
11
plicati da un utente o implementatore in post-coordination
•
Historical: collegano concetti inattivi a concetti attivi;
•
Additional: rappresentano altre caratteristiche.
;
Dening attributes
Le gerarchie a cui sono assegnati i Dening attributes sono chiamate
gerarchie principali (ad esempio Procedure, Clinical nding, Pharmaceuti-
10 Il paragrafo successivo approfondisce ulteriormente l'agomento
11 Per creare una singola espressione costituita da diversi concetti collegati da attributi
2.4.3 Relationships
35
cal/Biologic product, Situation with explicit context, Event, Specimen, e
Physical object). Le gerarchie che non utilizzano gli attributi sono chiamate
invece gerarchie di sostegno (Social context, Substance, Organism, e Observable entity ): esse possono essere usate come valori degli attributi nella
denizione dei concetti delle gerarchie principali.
Gli attributi hanno relazioni gerarchice tra loro, formando delle role hierarchies: un attributo generale è genitore di uno o più sottotipi specici di
tale attributo.
Di seguito è riportato un elenco dei principali attributi utilizzabili nelle
gerarchie principali:
•
ATTRIBUTI PER DEFINIRE CONCETTI CLINICAL FINDING:
FINDING SITE: specica la parte del corpo colpita da una condizione. Ad esempio: kidney disease (disorder) FINDING SITE
kidney structure (body structure) ;
ASSOCIATED MORPHOLOGY : specica i cambiamenti morfologici visti a livello dei tessuti o a livello cellulare che sono
l'elemento caratterizzante di una malattia. Ad esempio: pancreati-
tis (disorder) ASSOCIATED MORPHOLOGY inammation (morphologic abnormality) ;
ASSOCIATED WITH : rappresenta un'associazione clinicamente
rilevante tra i concetti, senza né aermare né escludere un nesso
di causalità o sequenzialità tra i due.
Sussume i seguenti, più
specici, attributi nella role hierarchy:
∗
AFTER: modella concetti in cui un clinical nding si verica
dopo un altro clinical nding o procedure. Ad esempio: post
viral disorder (disorder) AFTER viral disease (disorder);
∗
DUE TO : collega un clinical nding direttamente alla sua
causa. Ad esempio: cheilitis due to atopic dermatitis(disorder)
IS_A cheilitis (disorder) DUE TO atopic dermatitis (disorder);
∗
CAUSATIVE AGENT : identica l'agente eziologico diretto di
una malattia. Ad esempio: bacterial endocarditis (disorder)
CAUSATIVE AGENT superkingdom bacteria (organism).
SEVERITY : rappresenta il livello di gravità per un concetto clinical nding. L'uso dell'attributo severity è spesso relativo. Questo
attributo non viene utilizzato nella distribuzione della International Release;
2.4.3 Relationships
36
CLINICAL COURSE: rappresenta sia il decorso che l'insorgenza
di una malattia. Ad esempio: acute amebic dysentery (disorder)
CLINICAL COURSE sudden onset and/or short duration (qualier value);
EPISODICITY : specica il primo episodio di una malattia di un
paziente.
Non viene utilizzato nella distribuzione della Interna-
tional Release;
INTERPRETS: entità in corso di valutazione o di interpretazione,
usato insieme a has interpretation;
HAS INTERPRETATION : designa l'aspetto della sentenza in
corso di valutazione o di interpretazione di un concetto (ad es.
la presenza, l'assenza, il grado, la normalità, l'anormalità, ecc.).
Ad esempio: decreased muscle tone (nding) INTERPRETS muscle tone (observable entity) HAS INTERPRETATION decreased
(qualier value);
PATHOLOGICAL PROCESS: fornisce informazioni sul processo
patologico di base per una malattia che non è strutturale e che
non è rappresentata dall' attributo associated morphology.
Ad
esempio: disease caused by parasite (disorder) PATHOLOGICAL
PROCESS parasitic process (qualier value);
HAS DEFINITIONAL MANIFESTATION : collega i disorders ai
clinical ndings che sono sempre presenti, per denizione;
OCCURRENCE: si riferisce al periodo specico della vita durante il quale una condizione si presenta per la prima volta. Ad
esempio: childhood phobic anxiety disorder (disorder) OCCURRENCE childhood (qualier value);
FINDING METHOD: specica il mezzo attraverso il quale un
clinical nding (accertamento clinico) è stato determinato.
Ad
esempio: nding by palpation (nding) FINDING METHOD palpation (procedure);
FINDING INFORMER: specica la persona o altro soggetto da
cui l'informazione clinical nding è stato ottenuta. Ad esempio:
complaining of a headache (nding) FINDING INFORMER subject of record or other provider of history (person);
•
ATTRIBUTI PER DEFINIRE CONCETTI PROCEDURE:
METHOD : rappresenta l'azione che viene eseguita nella procedura. Ad esempio: incision of ureter (procedure) METHOD incision action (qualier value);
2.4.3 Relationships
37
PROCEDURE SITE: parte del corpo su cui si agisce o che è colpita da una procedura. Ad esempio:
procedure on colon (proce-
dure) PROCEDURE SITE colon structure (body structure). Sussume nella role hierarchies gli attributi più specici:
∗
PROCEDURE SITE - DIRECT : utilizzato quando l'azione
del procedimento è direttamente rivolta ad una struttura corporea o ad un sito piuttosto che a qualcos' altro (ad esempio
un dispositivo) che si trova lì. Ad esempio: biopsy of femur
(procedure) METHOD biopsy action (qualier value) PROCEDURE SITE - DIRECT bone structure of femur (body
structure);
∗
PROCEDURE SITE - INDIRECT : descrive la parte del corpo
che è interessata, ma non è l'oggetto diretto della procedura.
Ad esempio: removal of calculus of urinary bladder (procedure) METHOD removal action (qualier value) PROCEDURE SITE - INDIRECT urinary bladder structure (body
structure).
PROCEDURE MORPHOLOGY : specica la morfologia o struttura anormale del corpo coinvolta nella procedura. Sussume nella
role hierarchy gli attributi più specici:
∗
DIRECT MORPHOLOGY : descrive la morfologia a cui la
procedura è diretta. Ad esempio: excision of benign neoplasm
(procedure) METHOD excision action (qualier value) DIRECT MORPHOLOGY neoplasm, benign (morphologic abnormality);
∗
INDIRECT MORPHOLOGY : rappresenta una morfologia che
è interessata, ma non è il bersaglio diretto dell' azione in corso
di esecuzione.
Ad esempio:
removal of mesh from wound
(procedure) INDIRECT MORPHOLOGY wound (morphologic abnormality).
PROCEDURE DEVICE: descrive i dispositivi associati ad una
procedura. Ad esempio: catheter procedure (procedure) DEVICE
catheter, device (physical object). Questo attributo generale sussume nella role hierarchy gli attributi più specici:
∗
DIRECT DEVICE: dispositivo su cui il metodo agisce direttamente.
Ad esempio:removal of arterial stent (procedure)
DIRECT DEVICE arterial stent (physical object);
∗
INDIRECT DEVICE: modella un'azione fatta su qualcosa che
si trova in o su un dispositivo, ma non è fatta direttamente sul
2.4.3 Relationships
38
dispositivo stesso. Ad esempio: excision of vegetations from
implanted mitral valve (procedure) METHOD excision action
(qualier value) INDIRECT DEVICE mitral valve prosthesis,
device (physical object);
∗
USING DEVICE: strumento o apparecchiatura utilizzata per
eseguire un'azione. Ad esempio: core needle biopsy of larynx
(procedure) METHOD biopsy action (qualier value) USING
DEVICE core biopsy needle, device (physical object);
∗
USING ACCESS DEVICE: strumento o attrezzatura utilizzata per accedere al sito di una procedura.
Ad esempio:
arthroscopic synovial biopsy (procedure) METHOD biopsy
action (qualier value) USING ACCESS DEVICE arthroscope, device (physical object);
ACCESS: descrive il percorso utilizzato per accedere al sito di
una procedura. È utilizzato per distinguere tra procedure aperte,
chiuse e percutanee. Modiche all' attributo ACCESS sono state
approvate ma non ancora pienamente attuate nell'ultima release.
DIRECT SUBSTANCE: descrive la sostanza sulla quale il metodo
della procedura agisce direttamente.
Ad esempio:
injection of
prostaglandin (procedure) DIRECT SUBSTANCE prostaglandin
(substance);
PRIORITY : priorità assegnata ad una procedura.
Ad esempio:
emergency cesarean section (procedure) PRIORITY emergency
(qualier value);
HAS FOCUS: specica il clinical nding o la procedure che è
il focus di una procedura.
Ad esempio:
cardiac rehabilitation
assessment (regime/therapy) HAS FOCUS cardiac rehabilitation
(regime/therapy);
HAS INTENT : specica l'intento di una procedura. Ad esempio:
diagnostic bronchoscopy (procedure) HAS INTENT diagnostic intent (qualier value);
RECIPIENT CATEGORY : specica il tipo di individuo o gruppo
su cui l'azione della procedura viene eseguita.
Per esempio può
essere utilizzato nelle procedure delle banche di sangue per differenziare se la procedura è stata eseguita sul donatore o sul destinatario del sangue;
REVISION STATUS: specica se la procedura è primaria o no.
Ad esempio: primary repair of inguinal hernia (procedure) REVISION STATUS primary operation (qualier value);
2.4.3 Relationships
39
ROUTE OF ADMINISTRATION : specica il percorso attraverso
il quale una sostanza viene somministrata. Ad esempio: inhaled
drug administration (procedure) ROUTE OF ADMINISTRATION
by inhalation (route) (qualier value);
SURGICAL APPROACH : specica l'accesso al sito di una procedura chirurgica.
Ad esempio:
abdominal hysterectomy (pro-
cedure) SURGICAL APPROACH abdominal approach (qualier
value);
USING SUBSTANCE: descrive la sostanza utilizzata per eseguire
l'azione di una procedura, ma non è la sostanza sulla quale il
metodo della procedura agisce direttamente.
Ad esempio: con-
trast radiography of esophagus (procedure) USING SUBSTANCE
contrast media (substance);
USING ENERGY : descrive l'energia utilizzata per eseguire un'azione.
Ad esempio: gamma ray therapy (procedure) USING ENERGY
gamma radiation (physical force).
•
ATTRIBUTI PER DEFINIRE CONCETTI SPECIMEN :
SPECIMEN PROCEDURE: identica la procedura con cui un
campione è ottenuto.
Ad esempio: Specimen from stomach ob-
tained by total gastrectomy (specimen) SPECIMEN PROCEDURE
Total gastrectomy (procedure);
SPECIMEN SOURCE TOPOGRAPHY : specica la parte del
corpo da cui si ottiene un campione. Ad esempio: Cervix cytologic material (specimen) SPECIMEN SOURCE TOPOGRAPHY
Cervix uteri structure (body structure);
SPECIMEN SOURCE MORPHOLOGY : indica l'anomalia morfologica da cui si ottiene un campione.
Ad esempio: Specimen
from cyst (specimen) SPECIMEN SOURCE MORPHOLOGY Cyst
(morphologic abnormality);
SPECIMEN SUBSTANCE: tipo di sostanza di cui un campione
è costituito.
Ad esempio: Pancreatic uid specimen (specimen)
SPECIMEN SUBSTANCE Pancreatic uid (substance);
SPECIMEN SOURCE IDENTITY : tipo di individuo, gruppo o
ubicazione sica da cui i campioni sono stati raccolti. Ad esempio: Blood specimen from blood donor (specimen) SPECIMEN
SOURCE IDENTITY Blood donor (person).
•
ATTRIBUTI PER DEFINIRE CONCETTI BODY STRUCTURE:
2.4.3 Relationships
40
LATERALITY : posizione di una struttura del corpo (a sinistra,
a destra o bilaterale). Ad esempio: Left kidney structure (body
structure) LATERALITY Left (qualier value).
•
ATTRIBUTI PER DEFINIRE CONCETTI PHARMACEUTICAL/
BIOLOGIC PRODUCT :
HAS ACTIVE INGREDIENT : indica il principio attivo di un farmaco. Ad esempio: Naproxen 500mg tablet (product) HAS ACTIVE INGREDIENT Naproxen (substance);
HAS DOSE FORM : specica la forma in cui si presenta la dose di
un prodotto. Ad esempio: Digoxin 0.1mg capsule (product) HAS
DOSE FORM Oral capsule (qualier value).
•
ATTRIBUTI PER DEFINIRE CONCETTI SITUATION WITH EXPLICIT CONTEXT
12
.
Default context: un concetto SNOMED CT senza alcun contesto
dichiarato esplicitamente ha un contesto soft-default: vuol dire
che la constatazione è eettivamente vericata, si sta vericando
per il soggetto del documento (il paziente) e si sta vericando
attualmente (o in un determinato momento in passato);
Axis modiers: i seguenti sei attributi sono utilizzati per la modellazione dei concetti dipendenti dal contesto in SNOMED CT: essi
sono detti attributi modicatori di contesto e permettono la rappresentazione di diversi contesti. Infatti modicano il signicato
di un Clinical nding o di una Procedure in un modo che cambia
l'asse o la gerarchia del concetto. Ad esempio in Urine protein test
not done (situation) PROCEDURE CONTEXT Not done (qualier value), il concetto che ne risulta non è un sottotipo di Urine
protein test (procedure):
∗
ASSOCIATED FINDING: specica il concetto Clinical nding il cui contesto è stato modicato. Ad esempio: Family
history of stroke (situation) ASSOCIATED FINDING Cerebrovascular accident (disorder);
∗
FINDING CONTEXT : indica se il Clinical nding associato
è noto o sconosciuto, se è presente o assente. Ad esempio: No
12 Il signicato trasportato da un concetto SNOMED CT in un documento sanitario è
aetto dal contesto in cui è memorizzato. Per esempio cancro della mammella può essere:
storia familiare di cancro alla mammella, storia passata di cancro alla mammella o
diagnosi corrente di cancro alla mammella
2.4.3 Relationships
41
cough (situation) ASSOCIATED FINDING Cough (nding)
FINDING CONTEXT Known absent (qualier value);
∗
ASSOCIATED PROCEDURE: collega i concetti della gerarchia Situation with explicit context con i concetti della gerarchia Procedure per le quali vi è un ulteriore contesto specicato.
Ad esempio:
Operative procedure planned (situa-
tion) ASSOCIATED PROCEDURE Surgical procedure (procedure);
∗
PROCEDURE CONTEXT : indica il grado di completamento
di una procedura. Ad esempio: Operative procedure planned
(situation) ASSOCIATED PROCEDURE Surgical procedure
(procedure) PROCEDURE CONTEXT Planned (qualier value);
∗
TEMPORAL CONTEXT : indica il tempo di insorgenza di
un Clinical nding o Procedure, esprimendo se era presente
quando il concetto è stato inserito nel documento. Ad esempio:
History of hematuria (situation) ASSOCIATED FIN-
DING Blood in urine (nding) TEMPORAL CONTEXT In
the past (qualier value);
∗
SUBJECT RELATIONSHIP CONTEXT : specica la relazione
tra il soggetto del record e il soggetto del Clinical nding o
della Procedure in corso di registrazione. Ad esempio: Father
smokes (situation) ASSOCIATED FINDING Smoker (nding)
SUBJECT RELATIONSHIP CONTEXT Father (person).
•
ATTRIBUTI PER DEFINIRE CONCETTI EVENT : nel gennaio 2006
un numero limitato di concetti sono stati spostati dalla gerarchia Clinical nding alla gerarchia Event (ASSOCIATED WITH, CAUSITIVE
13
AGENT, DUE TO, AFTER, OCCURRENCE)
•
ATTRIBUTI PER DEFINIRE CONCETTI PHYSICAL OBJECT :
HAS ACTIVE INGREDIENT : è applicato anche ai concetti della
gerarchie Pharmaceutical/biologic product
•
.
14
.
ROLE GROUPS: un Role group combina una coppia attributo-valore
con un'altra o più coppie attributo-valore (gura 2.8). Serve per aggiungere chiarezza alle denizioni dei concetti:
13 Non sono ancora state stabilite politiche editoriali denitive per l'uso di attributi nella
gerarchia
Event
14 Non sono ancora state stabilite politiche editoriali denitive per l'uso dell'attributo
nella gerarchia
Physical object
2.4.3 Relationships
42
CLINICAL FINDING che richiedono più attributi ASSOCIATED
MORPHOLOGY e più attributi FINDING SITE;
PROCEDURES che richiedono più attributi METHOD e più attributi PROCEDURE SITE
15
.
Figure 2.8: Esempio di Role Group in SNOMED CT
15 Tuttavia i
Role groups
non sono limitati ai concetti
Clinical nding
e
Procedure
2.5 Nazionalizzazione
2.5
43
Nazionalizzazione
Per nazionalizzazione si intende il processo di traduzione di SNOMED
CT nella lingua target della nazione che decide di utilizzarlo. In Italia ovviamente il processo di nazionalizzazione non è in atto, dato che SNOMED
CT non è in uso: tuttavia in questo capitolo verrà descritto a grandi linee
come andrebbe svolto, quali sono i punti salienti e le principali problematiche,
facendo anche riferimento a concrete esperienze di altre nazioni.
Innanzitutto è necessario chiarire che per nazionalizzazione non si intende
una semplice traduzione letterale dei concetti, termine a termine, spesso
scorretta e fuorviante, ma un processo più complesso.
Esso coinvolge di-
rettamente diverse tipologie di soggetti, tra cui traduttori, revisori, esperti
in materia, validatori, dirigenti e membri di un editorial board (comitato
editoriale) o di un gruppo equivalente di esperti che stabilisce le linee guida
linguistiche e terminologiche per la traduzione nella lingua target specica. I
presupposti per coloro che sono coinvolti nella traduzione, verica e convalida
dei contenuti di SNOMED CT sono: l'avere una certa familiarità con i principi terminologici su cui SNOMED CT si basa; il conformarsi alle IHTSDO
Style Guides
16
; la consapevolezza di questioni delicate come la scelta delle
varianti lessicali, delle tecniche di traduzione e l'importanza di assicurare la
coerenza linguistica.
2.5.1
Introduzione ai principi terminologici
L' idea di base nella scienza della terminologia è la distinzione tra un approccio onomasiologico e un approccio semasiologico (applicato in lessicograa).
In un approccio onomasiologico il punto di partenza è il concetto, mentre in
un approccio semiasologico il punto di partenza è l'espressione linguistica,
vale a dire la parola/termine.
L' approccio da preferire in un processo di
traduzione è quello onomasiologico.
In riferimento al Triangolo di Ogden-Richard (gura 2.9), si può distinguere tra:
•
Concetto:
unità di conoscenza creata da un' unica combinazione di
caratteristiche;
•
Designazione: rappresentazione di un concetto da un simbolo che lo
denota;
•
Termine: denominazione verbale di un concetto generale in un campo
specico.
16 Linee guida stilate dalla HITSO
2.5.1 Introduzione ai principi terminologici
44
Il termine indica un concetto, e un concetto si rifesce ad un oggetto particolare.
Figure 2.9: Triangolo di Ogden-Richard
2.5.2 Tradurre SNOMED CT
45
I sistemi concettuali permettono di inserire un concetto sconosciuto in un
contesto semantico. I sistemi più comuni si basano su:
•
Generic relationships : IS_A - relationship (gura 2.10);
•
Partitive relationships: PARTE OF - relationship (gura 2.11).
Figure 2.10: IS-A - relationship
Figure 2.11: PARTE OF - relationship
In SNOMED le gerarchie sono rappresentate con una scala verticale in cui
ogni livello è illustrato per mezzo di un nuovo paragrafo tabulato (gura 2.4).
Le denizioni invece sono le rappresentazioni dei concetti per mezzo di dichiarazioni
descrittive, che servono per dierenziare tra loro i concetti connessi.
Esse
possono essere espresse in logica descrittiva: è quanto accade in SNOMED
CT, dove i concetti sono deniti dalle loro relationships gerarchiche (IS-A relationship) e dai dening attribute.
2.5.2
Tradurre SNOMED CT
L' obiettivo della traduzione è fornire descrizioni accurate e prive di ambiguità dei concetti SNOMED CT nella lingua di destinazione (lingua target): è
46
bene in questo contesto utilizzare un principio di traduzione concept-based
17
,
ed è fondamentale denire linee guida linguistiche, incluse regole sintattiche,
morfologiche e ortograche.
Bisogna tenere inoltre presente che il nucleo della terminologia SNOMED
CT non è perfetto: l'architettura CT è in fase di grandi cambiamenti e miglioramenti e i membri del team di traduzione devono rivedere e analizzare le
relazioni di ogni concetto al ne di chiarire il signicato di un termine.
L' approccio di base alla traduzione prevede una collaborazione interdisciplinare tra specialisti nell'ambito sanitario, informatico, linguistico e terminologico, e si trova ad arontare il problema di garantire il giusto equilibrio
nel fornire termini coerenti, utilizzabili e clinicamente accettabili.
Per la
traduzione di termini complessi è necessario avere un relativamente elevato
livello di conoscenza della terminologia di dominio, così da comprendere il
signicato del termine del linguaggio sorgente; ma per una traduzione corretta è necessario anche esaminare la posizione gerarchica del concetto e le
relazioni del concetto con gli altri concetti.
Il usso di lavoro di traduzione, illustrato in gura 2.12, è a grandi linee
il seguente: preso un concetto, si deve innanzitutto cercare il suo vero signicato individuando qual è la sua posizione all'interno dell'ontologia. Nel caso
di dubbi sul signicato, si devono cercare esempi concreti del suo utilizzo in
specici contesti. Chiarito dunque il signicato, si può passare alla ricerca
del termine equivalente nella lingua target.
17 Approccio onomasiologico, vedere paragrafo 2.5.1
47
Figure 2.12: Flusso di lavoro di traduzione di SNOMED CT
I principi linguistici generali da seguire sono:
•
Prendere in considerazione i requisiti linguistici locali;
•
Stabilire i principi preliminari generali per la scelta di varianti lessicali
(ad esempio in lingua danese e tedesca è comune utilizzare il puro latino
o il greco all'interno del dominio di anatomia, termini ibridi per termini
diagnostici o termini che descrivono le procedure, termini nazionali in
altri casi);
•
È bene evitare espressioni colloquiali (slang), che invece possono essere aggiunte in seguito come sinonimi;
•
È bene anche seguire raccomandazioni stabilite da un consiglio o autorità nazionale linguistica;
•
È utile prendere in considerazione le pratiche speciche relative a termini medici pubblicati in riviste mediche nazionali.
48
Tra le principali problematiche linguistiche e terminologiche vi sono:
•
La selezione del termine migliore per il concetto, tale da soddisfare le
esigenze di:
Univocità;
Correttezza linguistica: rispettando le regole sintattiche e ortograche
nazionali;
Trasparenza: un termine dovrebbe essere auto-esplicativo;
Riconoscibilità internazionale: meglio preferire termini basati su
latino e greco;
Accettazione psicologica: considerando le preferenze dei medici e
la pratica comune;
Sistematicità e coerenza: usando soluzioni morfologiche e sintattiche simili per i termini che coprono concetti semanticamente
simili.
I suddetti requisiti spesso entrano in conitto: pertanto il gruppo incaricato di stabilire le regole per la traduzione di SNOMED CT in un
linguaggio specico target spesso deve svolgere un compito dicile.
•
Il problema dell' equivalenza dei termini:
Variazioni nazionali o culturali: parte della terminologia della lingua di partenza, basata su strutture amministrative o pratiche
cliniche britanniche o americane, non è necessariamente accettata
globalmente. Può essere necessario elaborare nuove sottogerarchie
all'interno di una edizione nazionale;
False Friends : concetti apparentemente equivalenti nella lingue
di partenza e di destinazione, ma che in realtà non lo sono.
•
La scelta della tecnica di traduzione: esistono diverse tecniche di traduzione
applicabili. La gura 2.13 ne riporta degli esempi.
•
Il vericarsi di questioni sintattiche:
L'uso del gerundio: in alcune lingue non è comune quanto lo è
in inglese. Pertanto è necessario sostituire il termine con un'altra
frase;
La scelta del tipo di costruzione: le regole della lingua non possono
essere tutte ssate. Si devono dunque seguire le abitudini cliniche
e/o si deve seguire la costruzione della lingua di origine;
49
Figure 2.13: Elenco di alcune tecniche di traduzione
I verbi coniugati: andrebbero usati con cautela ed evitati nella
gerarchia Procedure, poiché il passato richiama un contesto temporale (ad esempio salivary gland abscess drained dovrebbe essere
drainage of salivary gland). I verbi coniugati anderebbero invece
usati in gerarchie come Clinical nding o Situation per esprimere
una occorrenza (ad esempio Patient has gone abroad);
L' ordine delle parole: va fatto riferimento alle regole ortograche
ordinarie e prevalenti nella lingua di destinazione.
Nei suddetti casi bisogna vericare se è possibile stabilire una serie di
norme riguardanti la costruzione morfo-sintattica di espressioni nella
lingua target.
•
La scelta delle varianti lessicali:
a seconda della lingua un termine
medico potrebbe essere puramente greco-latino (ad esempio diabetes
mellitus), ibrido, puramente nazionale (ad esempio stomach ache). In
tali casi è necessario accertarsi se ci sono delle regole generali (per la
scelta della variante lessicale) o aree semantiche dove la pratica impone
l'uso di una certa variante lessicale.
50
Scendendo più nel dettaglio, tra i principi linguistici specici vanno considerati i seguenti aspetti:
•
Nomi di organismi (batteri, virus, piante, animali, ecc.): a meno che
non entri chiaramente in conitto con la politica linguistica nazionale, i
nomi degli organismi devono essere considerati come termini scientici
universali (internazionali). La gerarchia Organism fa uso dei nomi in-
18
ternazionali tassonomici
•
;
Denominazioni chimiche e biochimiche, ingredienti di farmaci, enzimi
e nomi di ormoni:
un termine che si riferisce ad una sostanza chi-
mica contenuta in un farmaco può essere un nome di un determinato
ingrediente (appartenente alla gerarchia PRODUCT ) o una denominazione generica per la sostanza stessa chimica (appartenente alla gerarchia SUBSTANCE). È comune nella lingua di destinazione applicare
diversi principi ortograci per i PRODUCT rispettivamente alle SUBSTANCE. È bene inoltre vericare se ci sono delle regole o abitudini che
dovrebbero essere prese in considerazione nella lingua target per quanto
riguarda l'ortograa delle sostanze chimiche e di agenti biochimici, ingredienti, enzimi o ormoni;
•
Parole straniere e abbreviazioni: le linee guida nazionali di traduzione
devono indicare la misura in cui le parole straniere sono accettabili
nella lingua di destinazione: le parole straniere che vengono accettate
devono essere conformi alle norme ortograche del linguaggio originale
(ad esempio gli accenti nelle parole francesi).
Per quanto riguarda invece acronimi e sigle, esse danno luogo in genere
19
a una serie di dubbi
: pertanto il numero delle sigle ammesse nella
terminologia dovrebbe essere mantenuto allo stretto minimo necessario;
•
Eponimi
20
: il problema nel LSP (Language for Specic Purposes) medico
è che alcuni termini possono essere utilizzati solo in aree geograche
ristrette: tuttavia a volte essi possono essere accettati al ne di rendere
la terminologia psicologicamente accettabile dal punto di vista clinico.
I traduttori dovrebbero essere consapevoli della necessità di vericare
se un determinato eponimo nella lingua di partenza è usato anche nella
lingua di destinazione e se riette adeguatamente lo stesso concetto;
18 In riferimento ai Taxonomy resources della home page del NCBI
19 Ad esempio l'acronimo AIDS ha un corrispettivo acronimo francese e spagnolo diverso:
SIDA
20 Un eponimo è un personaggio che dà il suo nome, nel caso della medicina, a sindromi,
malattie, segni clinici, metodiche diagnostiche e terapie
•
51
21
Forma determinata versus forma nuda
: nella maggior parte dei ter-
mini e delle espressioni in SNOMED CT i sostantivi sono presenti nella
loro forma nuda. Comunque sia a volte l'articolo determinativo è utilizzato in connessione con i concetti di cui vi è uno solo per tipo (ad
esempio in alcuni concetti Body structure, come the stomach). È necessario dunque vericare se ci sono delle regole generali riguardo l'uso
di forme determinate/nude che dovrebbero essere prese in considerazione nella terminologia della lingua target, o particolari convenzioni
che dovrebbe prevalere nei termini tradotti
•
22
;
Plurale versus singolare: in generale né i Fully Specied Names né i Preferred Terms dovrebbero essere rappresentati al plurale, a meno che i
termini non rappresentino concetti raggruppati (ad esempio procedures
23
relating to eating and drinking )
. Bisogna dunque capire se l'uso del
plurale è assolutamente necessario al ne di trasmettere il signicato
del concetto;
•
Lettere minuscole versus maiuscole: in generale tutti i termini dovrebbero usare le lettere minuscole
24
. Bisogna ad ogni modo seguire anche
le regole della lingua target per quanto riguarda l'uso delle lettere minuscole rispetto alle maiuscole, e indagare se ci sono ragioni speciche
per cui un concetto particolare dovrebbe iniziare con/comprendere le
lettere maiuscole o minuscole;
•
Punteggiatura, segni tipograci, simboli e cifre:
Virgole e trattini:
sono utilizzati in SNOMED CT per aggiun-
gere informazioni supplementari a un termine (ad esempio well
child visit, newborn).
Le virgole sono utilizzate anche in lingua
inglese per accorciare termini SNOMED e/o per costruire termini
nei quali la caratteristica più importante è presentata alla testa
della frase (ad esempio: fracture, closed, comminuted, with displacement);
Barre: vengono utilizzati per indicare la o (congiunzione con valore disgiuntivo). Ad esempio: T2b (IIB): Fallopian tube/ovarian
tumor with extension to other pelvic structures;
21 Rispettivamente si riferiscono ad un sostantivo con o senza articolo determinativo
22 Questo tema è attualmente in discussione presso i modellisti di SNOMED CT: in
futuro la forma determinata sarà abbandonata, ove possibile
23 Anche questi concetti sono in procinto di essere cambiati
24 Secondo la terminologia ISO Standard 704, la lettera minuscola nella prima parola del
termine è raccomandata, a meno che non si tratti di un eponimo, un termine scientico
universale, o un nome proprio: ad es.
Behçets syndrome, ECG nding, blood group A
2.5.3 Sorgenti di informazione
Parentesi e due punti:
52
sono spesso utilizzati in SNOMED CT
per aggiungere informazioni semantiche ai concetti o accorciare
termini.
Ad esempio:
FH: cardiac disorder
(dove FH sta per
family history );
•
Abbreviazioni e unità di misura: per quanto riguarda le abbreviazioni,
è probabile che nella lingua di destinazione ci siano acronimi locali accettabili. In generale bisogna essere molto cauti e ammettere solo quelli
ampiamente utilizzati.
Per le unità di misura invece è bene rispettare le linee guida dell' International System of Units;
•
Trattini: può essere utile nella lingua di destinazione inserire un trattino in:
Forme ibride e combinate;
Composti contenenti un eponimo o una parola straniera, o in particolare composti lunghi:
ad esempio pathological - anatomical
analysis;
In connessione con le parole che contengono abbreviazioni, lettere
o segni: ad esempio DNA(-)molecule;
In connessione con alcuni pressi: ad esempio non(-)infectious.
Bisogna in ogni modo vericare se ci sono norme riguardanti l'uso dei
trattini nella lingua target sucientemente chiare e/o devono essere
stabilite linee guida speciche.
2.5.3
Sorgenti di informazione
Fonti di riferimento valide e approvate dovrebbero essere a disposizione
dei traduttori, per consentire la ricerca di informazioni su concetti specici
attraverso esempi testuali, denizioni e spiegazioni. Tali riferimenti possono
essere di vario tipo:
•
Riferimenti disponibili in formato elettronico: consentono l'accesso a:
Termini già approvati e tradotti: che contengono costruzioni e/o
combinazioni di parole simili;
Documenti interni: come le linee guida nazionali per la traduzione,
la panoramica delle decisioni dell' Editorial Board e gli elenchi di
esempi di termini tradotti e/o termini corretti che rappresentano
specici problemi semantici o morfo-sintattici;
2.5.4 Processo di traduzione e problemi del post-traduzione
Libri di testo:
53
che riguardano i domini e le aree della pratica
clinica;
File o libri di riferimento: che rappresentano versioni nazionali di
25
dizionari medici
;
Articoli medici: reperibili in versioni elettroniche di riviste mediche
di fama nazionale.
•
Riferimenti ad internet: tra cui link alle varie tassonomie autorevoli o
nomenclature
2.5.4
26
.
Processo di traduzione e problemi del post-traduzione
Il processo di traduzione richiede diverse fasi:
1. Translation: ci devono essere sempre almeno due persone coinvolte nella
traduzione iniziale: un traduttore e un proof-reader
27
per la verica. È
fondamentale che essi abbiano competenze di elevato livello linguistico
ed una buona conoscenza nel settore dell'assistenza sanitaria.
I loro
ruoli sono:
•
Tradurre i termini della lingua di origine in termini della lingua
target;
•
Correggere le bozze dei termini tradotti prima di passarli a ulteriori riesami;
•
Sollevare eventualmente questioni dubbie in modo che le principali
decisioni siano prese dall' Editorial Board.
2. Review :
a prescindere dalla correzione di bozze, una seria revisione
deve essere eettuata dai professionisti di servizi sanitari e sociali. Essi
devono confermare che i termini tradotti riettano i concetti di base
e che siano conformi agli orientamenti linguistici e alle regole generali
della lingua target.
Possono inoltre mandare indietro i termini inac-
cettabili ai traduttori per la correzione e consultare l' Editorial Board
su questioni dubbie.
25 Ad esempio la versione nazionale della Nomenclatura Chimica, o della Nomencatura
Anatomica, ecc.
26 Ad esempio www.genenames.org per l'elenco di geni umani, www.iupac.org per i nomi
delle sostanze di laboratorio e delle procedure, ecc.
27 Correttore di bozze
2.5.4 Processo di traduzione e problemi del post-traduzione
54
3. Editing : l' Editorial Board dovrebbe essere composto da un team interdisciplinare di professionisti - all'interno di settori quali la medicina e
infermieristica, la linguistica e la terminologia, la scienza o le tecnologie
dell'informazione, le specialità paramediche ecc - che hanno una buona
conoscenza e comprensione della lingua inglese di base. Essi devono:
•
Denire e mantenere le linee guida a cui tutti coloro che sono
coinvolti nel processo di traduzione devono aderire;
•
Determinare la validità dei libri di testo e riferimenti messi a disposizione di traduttori e revisori;
•
Garantire che tutti i partecipanti siano costantemente informati
delle decisioni prese;
•
Agire come un organo consultivo per i traduttori e i revisori;
•
Creare ed evolvere le decisioni di massima, che saranno inevitabilmente richieste nel corso della traduzione;
•
Trattare con traduzioni particolarmente complesse e questioni sollevate dai traduttori e revisori;
•
Approvare i termini che soddisfano i requisiti;
•
Raccogliere e registrare gli errori e i quesiti correlati riguardanti il
contenuto del core di SNOMED CT, da sottoporre alla IHTSDO.
4. Monitoraggio dei progressi: un responsabile di progetto e/o coordinatore deve eettuare una valutazione continua del progresso di traduzione,
deve amministrare il progetto generale e vigilare su di esso.
Tra i principali problemi del post-traduzione, vi sono:
•
Il rischio che i traduttori e i revisori possano avere frainteso il termine
della lingua originale;
•
Il rischio che un determinato termine, comunque corretto, non sia accettabile per i medici che magari hanno l'abitudine di usare altri termini
per esprimere lo stesso concetto.
In questo contesto, la validazione clinica dei termini tradotti svolge un ruolo
importante: la convalida deve essere eettuata da medici su sottoinsiemi di
concetti relativi alla propria specializzazione.
È necessaria inoltre una politica in materia di mantenimento della terminologia nella lingua target e di feedback con la IHTSDO: può darsi che alcuni
dei termini nazionali e concetti che vengono aggiunti nell' estensione della lingua target siano tradotti in inglese, al ne di essere inclusi nel SNOMED CT
Core.
2.5.5 Esperienze di alcuni release centre translating
2.5.5
55
Esperienze di alcuni release centre translating
Lo studio sulle esperienze danesi e svedesi
28
in merito alla traduzione di
SNOMED CT nella propria lingua ha portato ai seguenti risultati, utili per
chi sia in procinto di avviare la nazionalizzazione di SNOMED CT:
•
La Danimarca:
Ha impiegato un certo numero di risorse umane così spartite: 1012 traduttori professionisti, 10-12 revisori, 12 in redazione, 4-6
nella gestione del progetto;
La traduzione e revisione ha coinvolto circa 10.000 concetti al
mese;
Il tempo necessario per la traduzione è stato di circa 2 minuti per
concetto, per la revisione lo stesso;
In redazione invece sono servite 12.800 ore all' anno a cura dell'
Editorial Board e 1.400 ore all' anno per terminologi.
La principale lezione che hanno appreso da tale esperienza è che sarebbe
stato meglio iniziare la traduzione dalle dening relationships.
•
la Svezia:
Ha impiegato 37 risorse umane nel usso di lavoro: 15 traduttori
29
(società di traduzione), 15 controllori della qualità
, 7 membri
del comitato di redazione (traduttori, terminologi, medici);
Sono serviti due anni (dal 2007 al 2009) per approvare solo 130.000
preferred terms
30
.
Tra le principali lezioni apprese vi sono:
La necessità di una maggiore formazione per tutti i partecipanti
su SNOMED CT, sulla traduzione concept-base, sulle linee guida
linguistiche e su applicazioni software;
La necessità di includere diverse competenze (medici e terminologi) nell' Editorial Board, organizzarli in piccoli gruppi e dividere i compiti e le responsabilità.
28 Relative al 2009
29 Medici alle dipendenze del National Board of Health and Welfare
30 Contavano di concludere per il 2010
2.5.5 Esperienze di alcuni release centre translating
56
In denitiva si può concludere che le risorse umane necessarie per un processo
di traduzione di SNOMED CT sono circa 30-40 persone, per completare la
nazionalizzazione in 2/3 anni.
2.6 Considerazioni sulla struttura e tecnologia di SNOMED CT
2.6
57
Considerazioni sulla struttura e tecnologia
di SNOMED CT
La struttura e la tecnologia che stanno dietro SNOMED CT consente alle
organizzazioni di implementarlo e integrarlo nei loro processi e applicazioni
clinici e aziendali.
SNOMED CT ore inoltre funzionalità aggiuntive per
facilitare la personalizzazione di una applicazione per soddisfare le particolari
esigenze di un'organizzazione. La struttura dati sommaria è rappresentata
in gura 2.14, e spiegata nel dettaglio nei prossimi paragra.
SNOMED CT è distribuito come un insieme di le di testo delimitati da
Figure 2.14: SNOMED CT Data Structure Summary
tag, rappresentati secondo la specica della codica Unicode UTF-8. Alcuni
31
di questi les sono obbligatori per tutti i terminology servers
SNOMED (le
Core Structure e i Subset Mechanisms); altri sono necessari per supportare il
mapping alle classicazioni e agli altri schemi di codica (le Cross Mapping
Tables); altri ancora sono necessari per sostenere i servizi di controllo della
versione (le History Tables); inne vi sono dei le di valore aggiunto (le Word
31 Software che forniscono una vasta gamma di servizi collegati alla terminologia
2.6.1 Tabelle
58
and Phrase Search Tables, le Canonical Table).
Uno dei primi passi nella rappresentazione delle risorse SNOMED CT è
quello di decidere in che modo tali risorse saranno memorizzate e accessibili:
le opzioni includono l'uso di un database relazionale, un database ad oggetti
o di una struttura le proprietaria.
È possibile importare i le distribuiti
direttamente in uno schema di database e utilizzarlo come risorsa SNOMED
CT al centro di un terminology server, il quale dovrebbe essere in grado di
importare i le di distribuzione SNOMED CT nella forma interna utilizzata
per memorizare la risorsa. Il processo di importazione dovrebbe importarei
i le di base (Concepts, Descriptions, and Relationships) e un selezionato
insieme di Subsets .
2.6.1
Tabelle
Le tre tabelle Concepts table, Descriptions table, e Relationships table
sono comunemente denominate Core tables (gura 2.15). L'associazione di
una serie di Descriptions e un insieme di Relationships con ogni Concept
viene implementato utilizzando il ConceptID, che è la chiave primaria o
esterna nelle tre tabelle.
Nel dettaglio:
Figure 2.15: Core tables di SNOMED CT
•
Concepts Table: contiene tutti i concetti SNOMED CT. Ogni concetto
è rappresentato da una riga della tabella, e ogni riga della Concepts
Table contiene i seguenti campi:
ConceptIDs: è la chiave primaria della Concepts Table;
SNOMEDID e CTV3ID: gli originali identicativi rispettivamente
in SNOMED RT e CTV3
32
per ogni concetto che ha avuto origine
2.6.2 History Mechanism
59
in tali terminologie;
FullySpeciedName
33
: viene visualizzato sia nella Concepts Table
che nella Descriptions Table;
ConceptStatus: indica se un concetto è in uso (attivo) o è stato
ritirato:
in tal modo, i dati codicati con questi concetti sono
adeguatamente accessibili e possono essere recuperati anche molto
tempo dopo che sono stati codicati;
IsPrimitive:
indica se o no un concetto è stato contrassegnato
come primitivo (atomico) durante il processo di modellazione.
Questa opzione può essere utile in applicazioni avanzate che sfruttano le caratteristiche di logica descrittiva di SNOMED CT
•
34
.
Descriptions Table: contiene i termini utilizzati per descrivere un concetto SNOMED CT. Comprende i seguenti campi:
DescriptionID: chiave primaria di questa tabella;
DescriptionType:
indica se la descrizione è un Fully Specied
35
Name (FSN), un Preferred Term o un Synonym
;
LanguageCode: associa ogni descrizione ad una determinata lingua o dialetto;
•
Relationships Table: contiene le relazioni tra i concetti SNOMED CT.
Una relazione in tabella è memorizzata come una combinazione di tre
concetti nell'ordine:
ConceptID1 - RelationshipType - ConceptID2,
sfruttando i seguenti campi:
RelationshipID: identica in modo univoco ogni set di tre concetti
in una relationship, e serve come chiave primaria della tabella;
ConceptID1 : il primo concetto nella relationship;
RelationshipType: il tipo di relationship che esiste tra i due concetti;
2.6.2
ConceptID2 : il concetto target nella relationship.
History Mechanism
Il contenuto di SNOMED CT evolve con ogni release. L' History Mechanism tiene conto di questo e coinvolge le seguenti tabelle:
2.6.3 Subset Mechanism
•
Component History Table:
60
include le eventuali modiche ai compo-
nenti SNOMED CT (Concepts, Descriptions, Subsets, Cross Maps);
•
Component History References Table: fornisce un riferimento da un
componente inattivo SNOMED CT a un componente attivo nella release in corso.
2.6.3
Subset Mechanism
Un Subset si riferisce ad un insieme di Concepts, Descriptions o Relationships che sono appropriati per una particolare lingua, dialetto, paese,
organizzazione, utente o contesto. Il Subset Mechanism può essere utilizzato
per ricavare le tabelle che contengono solo una parte di SNOMED CT: è costituito da un elenco di identicatori SNOMED (SCTIDs), dove ogni SCTID
si riferisce a un componente di SNOMED CT che è un membro del Subset
(chiamato Subset Member ).
Per analogia, si può pensare a SNOMED CT come un libro: un Subset è
come una voce di indice che punta ad una serie di pagine relative a un particolare argomento.
I Subsets vengono rilasciati con due tabelle:
•
Subsets Table: ogni riga della tabella descrive una release di un Subset;
•
Subset Members Table: ogni riga della tabella rappresenta un membro
di un Subset (un Concept o una Description).
2.6.4
Cross Mapping Mechanism
Il meccanismo del Cross mapping consente a SNOMED CT di riferirsi
eettivamente ad altre terminologie e classicazioni. Ogni cross map collega
un concetto SNOMED CT con un altro schema di codica, chiamato schema
target. La struttura SNOMED CT a sostegno del Cross mapping contiene
tre tabelle:
•
Cross Map Sets Table: ogni riga della tabella rappresenta uno schema
target per la quale sono disponibili Cross maps;
•
Cross Maps Table: ogni riga della tabella rappresenta una opzione per
la mappatura di un SNOMED CT concept a un codice target o a una
serie di codici nello schema target;
•
Cross Map Targets Table: ogni riga della tabella rappresenta un codice
o una serie di codici del sistema target, che fornisce una mappatura per
uno o più SNOMED CT concepts.
2.6.5 Extensions
2.6.5
61
Extensions
Il meccanismo di Extensions consente alle aziende autorizzate di aggiungere Concepts, Descriptions, Relationships e Subsets al core (contenuto
centrale) della SNOMED CT International Release, ad esempio per aggiungere la terminologia specializzata necessaria ad un' organizzazione.
2.6.6
Applicazioni e servizi SNOMED CT
SNOMED Clinical Terms può ricoprire molti ruoli nelle applicazioni software per l'assistenza sanitaria. La IHTSDO fornisce contenuti che possono
essere caricati in queste applicazioni, ma non fornisce alcun software. I requisiti dettagliati per l'integrazione di SNOMED CT in una particolare applicazione dipendono dagli usi che se ne vuole fare, dalla percezioni degli utenti
e dagli ambienti tecnici in cui l'applicazione è implementata.
Tra le possibili applicazioni vi sono:
•
Sistemi di cartelle cliniche abilitate SNOMED CT : che incorporano
immissione di dati clinici, supporto alle decisioni, collegamenti a basi di
conoscenza, analisi sosticate, interfacce per messaggi di segnalazione,
supporto per record di comunicazione o di condivisione, ecc.;
•
Data warehouses: che memorizzano e analizzano record espressi con
concetti codicati SNOMED CT;
•
Sistemi dipartimentali diagnostici: che inviano reports che includono
concetti codicati SNOMED CT ad altri sistemi;
•
Dispositivi di raccolta dei dati:
gestiti manualmente e utilizzati per
l'ingresso di una gamma limitata di concetti codicati, usati frequentemente;
•
Sistemi di supporto decisionale: che usano concetti SNOMED CT per
rappresentare linee guida e protocolli per la distribuzione ad altri sistemi;
•
Sistemi per creazione di query : per l'analisi di dati detenuti da altri
sistemi, alcuni dei quali contengono dati codicati SNOMED CT;
•
Sistemi di codica: che mappano i concetti codicati SNOMED CT (inseriti manualmente o letti da un record elettronico), con classicazioni
36
come ICD10
;
36 Classicazione internazionale delle malattie e dei problemi correlati
2.6.6 Applicazioni e servizi SNOMED CT
•
62
Sistemi per supportare la progettazione/realizzazione di messaggi: che
veicolano informazioni speciche, utilizzando un set specicato di identicatori di concetti SNOMED CT.
Chapter 3
ROME
3.1
Panoramica
1
ROME è una ontologia italiana, sviluppata negli ultimi anni dal CNR .
L'acronimo signica Reference Ontology in Medicine: una reference ontology
2
è uno strato intermedio tra le ontologie top-level e le ontologie di dominio .
È stata progettata per fare da ponte tra più sistemi specici, per garantire
la coerenza semantica per i sistemi di informazioni eterogenei che possono essere applicati al settore sanitario.
È composta da circa 200 entità generali, e si basa sulla ontologia fon-
3
dazionale DOLCE
da cui eredita la distinzione fondamentale tra entità en-
duranti e perduranti:
•
Enduranti: entità che, nel momento in cui sono presenti, sono interamente presenti, nel senso che tutte le loro parti proprie sono presenti
(ad esempio un dispositivo medico);
•
Perduranti: entità che si prolungano nel tempo accumulando diverse
parti temporali: perciò in qualsiasi momento sono presenti, alcune delle
loro parti temporali (come le loro fasi precedenti o future) possono
essere non presenti (ad esempio una visita specialistica).
4
ROME è scritta in OWL e può essere sfogliata da strumenti come Protégé .
Le fonti principali per la sua costruzione sono state:
1 L' ultima pubblicazione disponibile di ROME è relativa al 2007
3 Descriptive Ontology for Linguistic and Cognitive Engineering
4 Ambiente di sviluppo per ontologie. Vedere paragrafo 3.2
63
3.1 Panoramica
•
64
La UMLS Semantic Network: è un componente dell' Unied Medical
5
Language System (UMLS)
e consiste in una serie di categorie e re-
lazioni che vengono utilizzate per classicare le voci della banca dati
centrale di UMLS;
•
I termini topmost del Foundational Model of Anatomy (FMA): si tratta
di una ontologia di dominio che rappresenta un insieme coerente di
conoscenze riguardanti l' anatomia umana.
5 Compendio di molti vocabolari delle scienze biomediche
3.2 Componenti base
3.2
65
Componenti base
I componenti base di ROME sono stati esplorati utilizzando Protégé: un
ambiente di sviluppo per ontologie.
Aprendo il le OWL di ROME con Protégé, viene visualizzato il workspace
principale, che mostra un overview dell'ontologia, incluse le metriche sui suoi
contenuti e le annotazioni circa l'intera ontologia (gura 3.1).
Figure 3.1: Protégé: workspace principale di ROME
3.2 Componenti base
66
Il tab Entities è l'ambiente principale dell'editor: da questa locazione è
possibile esplorare tutte le classi, proprietà e individui dell'ontologia. Questo
modello di selezione è globale: quando una classe, proprietà o individuo è selezionato nell'albero sul lato sinistro, il pannello destro cambia per mostrare
i dettagli della selezione. Così, espandendo la gerarchia sulla sinistra e selezionando una classe o proprietà, sulla destra è visualizzata l'appropriata
descrizione: eventuali annotazioni e la descrizione dell'entità (gura 3.2).
Figure 3.2: Protégé: tab Entities di ROME
3.2 Componenti base
67
Il tab OWLViz mostra una rappresentazione graca della gerarchia delle
classi (gura 3.3)
Figure 3.3: Protégé:tab OWLviz di ROME
Dall'analisi dell'ontologia sono emersi i seguenti risultati relativi ad alcune
6
metriche generali :
•
METRIC ONTOLOGY: 282 classes, 19 Object Property, 0 Data Property, 0 individuals;
•
CLASS AXIOMS: 301 assiomi SubclassOf, 0 assiomi EquivalentClasses
e Disjoint Classes. Tutte le classi e le ObjectProperties sono sottoclassi
di Thing ;
•
OBJECT PROPERTY AXIOMS: 0;
•
DATA PROPERTY AXIOMS: 0;
•
INDIVIDUAL AXIOMS: 0;
6 Vedere paragrafo 1.2. Per chiarimenti consultare http://www.w3.org/
3.2.1 Entità principali
•
68
7
ANNOTATION AXIOMS: annotationAssertion axioms:19 , annotationPropertyDomain axioms:0, annotationPropertyRahngeOf axioms:
0;
Si tratta dunque di un'ontologia molto semplice.
3.2.1
Entità principali
Nell'ambito di questa tesi è stato eettuato lo studio delle entità principali di ROME no a 3 livelli di profondità.
Di seguito ne è riportata una
8
decrizione, documentata con le immagini tratte da Protégé .
Al primo livello vi sono le entità Endurant, Perdurant e Quality (gura
3.4):
Figure 3.4: Entità principali in ROME
7 Solo </rdfs:comment>
8 A titolo esemplicativo vengono mostrati solo per
Perdurant
tre versioni equivalenti
della stessa denizione: la descrizione visualizzata da Protégé nel tab Entities, la visualizzazione di Protégé nel tab OWLviz e il codice OWL. Per le altre entità verrà invece
riportato solo il graco Protégé del tab OWLviz, per evitare la ridondanza
69
Perdurant
La descrizione dell'entità Perdurant è visibile in modo molto intuitivo
nella nestra Protégé riportata in gura 3.5.
Dalla denizione emerge che la classe Perdurant ha due superclassi: la classe
Figure 3.5: Descrizione di Perdurant in Protégé
Spatio-temporal-particular, e una classe anonima che rappresenta le entità
che possono realizzare solo delle Functions.
Tale denizione coincide col seguente codice OWL:
<owl:Class rdf:about=http://www.loa-cnr.it/Files/DLPOnts/DOLCE-Lite_397.owl#PERDURANT>9
<rdfs:comment rdf:datatype=http://www.w3.org/2001/XMLSchema#string>Questo è DOL</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
<owl:allValuesFrom rdf:resource=le:/C:/RACER/ROME/R4.owl#FUNCTION/>
<owl:onProperty>
<owl:ObjectProperty rdf:ID=ACCOMPLISH/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Class rdf:about=`http://www.loa-cnr.it/Files/DLPOnts/DOLCE-Lite_397.owl#SPATIO-TEMPORALPARTICULAR/>
</rdfs:subClassOf>
</owl:Class>
La restrizione owl:allValuesFrom presente nel codice richiede che per ogni
istanza della classe che ha delle istanze della specica proprietà, i valori della
proprietà devono essere tutti membri appartenenti alla classe indicata nella
9 Riferimento a DOLCE-LITE_397. Vedere paragrafo 4.2.1
70
clausola della owl:allValuesFrom. Questo vuol dire, come già accennato, che
per tutti i Perdurants, se realizzano qualcosa, quel qualcosa sono delle Functions.
Perdurant ha come glio diretto Process (gura 3.6).
Process è suddiviso in processo biologico (ad esempio processo patologico)
Figure 3.6: Process in ROME
e processo non-biologico (ad esempio, indagine diagnostica).
La gura 3.7
mostra questo livello più apporofondito di dettaglio:
Figure 3.7: Biologic Process e Non Biologic Process in ROME
71
Endurant
I gli principali di Endurant nella gerarchia sono (gura 3.8):
Figure 3.8: Endurant in ROME
•
Function: funzioni biologiche e non biologiche (gura 3.9);
Figure 3.9: Function in ROME
•
Physical endurant: gli enduranti sici possono essere biologici (ad esempio entità anatomiche) o non-biologici (ad esempio i dispositivi)(gura
3.10);
•
Non-physical endurant: enduranti non sici (gura 3.11).
Figure 3.10: Physical endurant in ROME
Figure 3.11: Non physical endurant in ROME
72
73
Quality
L'entità Quality si riferisce alla qualità astratta di un Endurant. Ad esempio Anomalia di struttura anatomica congenita non rappresenta l'entità
anatomiche in sé, ma è la qualità astratta collegata ad essa (gura 3.12).
In dettaglio:
Figure 3.12: Quality in ROME
•
Physical quality : (gura 3.13);
Figure 3.13: Physical Quality in ROME
•
Biomedical quality : (gura 3.14);
Figure 3.14: Biomedical Quality in ROME
74
3.2.2 Entità materiali e immateriali
3.2.2
75
Entità materiali e immateriali
Aspetto peculiare in ROME è il fatto che considera anche le entità immateriali e non tangibili, cioè che non hanno una controparte materiale. Ad
esempio i diversi signicati di diagnosi sono rappresentati in ROME nei
seguenti modi:
1. Atto di identicare una malattia dai suoi sintomi: classicato come
diagnostic investigation
→
10
non-biologic process
→
perdurant;
2. Decisione presa da una diagnosi: classicato come diagnosis
mation entity
→
→ infor-
non-physical endurant;
3. Breve descrizione tecnica rappresentata in alcune classicazioni: classicato come disease
→
nosological entity
→
non-physical endurant;
La distinzione basilare tra le entità materiali e non materiali (gura 3.15)
è stata adottata dal livello superiore del Foundational Model of Anatomy,
secondo cui le Entità materiali possono essere suddivise in:
•
Strutture anatomiche: ad esempio parti corporee, organi, ecc.;
•
Sostanze del corpo;
•
Body topographic entities.
Mentre le Entità non materiali che hanno rilevanza anatomica, ma non una
controparte materiale, possono essere suddivise in:
•
Giunzioni
11
, a loro volta suddivise in:
Giunzioni bona-de: i conni interni che comportano una discontinuità spaziale (buchi, fessure, feritoie) o eterogeneità qualitativa
(di materiale di costituzione). Esse sono classicate in: conuenze,
giunzioni tra cavità, raccordi tra le strutture anatomiche e frontiere;
•
Giunzioni at: sono superci anatomiche convenzionali o linee.
Spazi del corpo: suddivisi in lumina, cavità e orizi.
Questa caratteristica di ROME è una estensione e ranamento del tipo semantico Body Space o Junction di UMLS-SN
12
.
10 Il simbolo in questo contesto indica la relazione 'IS_A'
11 Conni tra le diverse strutture anatomiche
12 In UMLS-SN questa distinzione collassa in una singola categoria di un gruppo di
entità eterogenee, sia materiali (ad esempio, le articolazioni) che non-materiali (ad esempio
cavità)
3.2.2 Entità materiali e immateriali
Figure 3.15: Non-Material e Material Anatomical Entity in ROME
76
3.2.3 Object properties
3.2.3
77
Object properties
Per quanto riguarda invece le Object properties, l'analisi con Protégé
ha evidenziato che ve ne sono solo di tipi semplici (non vi sono proprietà
13
funzionali, inverse, transitive ecc.
), e sono tutte glie di TopObjectProperty
(senza altre gerarchie intermedie). L'elenco è visualizzato in gura 3.16.
Figure 3.16: Object properties in ROME
3.3 Utilizzi
3.3
78
Utilizzi
Gli impieghi concreti principali di ROME sono:
•
La progettazione di ontologie di dominio speciche associate alla Reference Ontology:
possono essere considerate come dei plug-in che
coprono diversi domini.
Ne è un esempio l'ontologia del Mechanical
Circulatory Support Systems (MCSS)
14
. L'ontologia è collegata a uno
strumento che è in grado di eseguire delle query sia per trovare un
modello di macchina dato un insieme di caratteristiche, che per recuperare l'eettiva macchina installata in un determinato reparto o
dipartimento. L'ontologia può essere utilizzata per dare consigli a un
chirurgo cardiaco che sta cercando il dispositivo ottimale da impiantare
in un paziente;
•
Il supporto alla continuità delle cure:
un esempio di questo tipo di
impiego si è avuto nell'ambito del progetto e-Heart Failure
15
, per sup-
portare la continuità delle cure per pazienti con insucienza cardiaca.
Tale progetto ha previsto la progettazione e sviluppo di un ambiente
di lavoro cooperativo basato su un Electronic Patient Record (EPR),
le cui informazioni cliniche sono classicate ROME.
14 Sistemi di supporto circolatorio meccanici: un particolare tipo di dispositivo mappato
in ROME come
Endurante sico non biologico
15 Avviato nel 2002 dalla provincia di Trento
Chapter 4
Analisi
4.1
Correttezza dell'ontologia
Il primo aspetto considerato nell'analisi oggetto della tesi è l'accuratezza
delle ontologie. In linea generale, una ontologia high-quality dovrebbe essere modularizzata, con netta separazione tra una ontologia formale toplevel (ad esempio DOLCE), una reference ontology di conoscenza medica
condivisa (anatomia, siologia, patologia, procedure mediche, ecc.) e un in-
1
sieme di (sotto)ontologie di dominio delle dierenti specialità mediche .
La metodologia d'analisi seguita è stata dierente per le due ontologie in
2
quanto ROME ce l'avevamo a disposizione ; SNOMED no, in quanto l'Italia
non ne possiede la licenza.
4.1.1
ROME
Da un punto di vista teorico ROME è una reference ontology: si basa
sulla ontologia formale DOLCE ed è ben distinta dalle ontologie di dominio.
Perciò è una ontologia che soddisfa i canoni di una buona ingegnerizzazione.
Tuttavia è stata svolta un'analisi più accurata e dettagliata utilizzando
Protégé: lo si è utilizzato per navigare e studiare l'ontologia, ma anche per
vericare la soddisfacibilità delle classi ROME sfruttando il suo reasoner
(HermiT).
Analizzando tutte le entità ROME, sono state individuate le seguenti
imprecisioni:
•
Incompletezza: ROME spesso fornisce solo una parziale istanziazione
di certi livelli di dettaglio. Ad esempio, tra i segni clinici generali vi
2 Il le OWL di ROME ci è stato fornito dal CNR
79
4.1.1 ROME
80
sono solo febbre e perdita di peso(gura 4.1).
Figure 4.1: ROME: Clinical-sign
Lo stesso accade tra i sintomi: ci sono solo angoscia, dolore, e mancanza d'appetito(gura 4.2).
Sarebbe preferibile fermarsi ad un livello di dettaglio superiore e la-
Figure 4.2: ROME:Symptom
sciare la descrizione accurata dell'entità da espandere ad altre ontologie
di dominio; oppure, nel momento in cui si scegliesse di scendere ad un
certo livello di dettaglio, esplicitarne tutte le entità che lo caratterizzano;
4.1.1 ROME
•
81
Poca chiarezza: vi sono relazioni poco chiare. In particolare vi sono 11
diversi tipi di relazioni part of , la cui dierenza non è né intuibile né
espicitata (gura 4.3).
Tra gli esempi di utilizzi vi è la descrizione di Body Structure:
si
Figure 4.3: Relazioni part of evince che è una struttura anatomica, è almeno part of_4 di Body
System, ed è almeno part of_1 di Organism (gura 4.4), ma la distinzione tra queste due ultime proprietà non è intuibile.
Se la distinzione tra tali proprietà è signicativa, sarebbe meglio esplicitarla nei commenti associati; se invece non lo è, sarebbe consigliabile
unicare i nomi sotto un'unica proprietà part of .
Per classicare l'ontologia invece bisogna aprire il menù Reasoner di Protégé
e selezionare uno dei reasoner disponibili.
Avviato il reasoner (nel nostro
caso HermiT), la gerarchia delle classi nel tab Entities cambia, mostrando
3
la gerarchia delle classi inferita. Le eventuali classi insoddisfacibili
appaiono
4.1.1 ROME
82
Figure 4.4: Esempio di utilizzo delle relazioni part of in rosso sotto la classe Nothing, mentre tutto il resto appare nella gerarchia
sotto le loro superclassi inferite.
Avviando il reasoner di Protégé, la classicazione di ROME viene fatta senza
errori, quindi l'ontologia non presenta classi insoddisfacibili (gura 4.5).
4.1.1 ROME
83
Figure 4.5: Classicazione di ROME svolta col reasoner HermiT di Protégé
4.1.2 SNOMED CT
4.1.2
84
SNOMED CT
Per l'analisi della correttezza di SNOMED CT è stata seguita una metodologia dierente rispetto a ROME: partendo dagli errori più comuni e importanti
riportati in letteratura, ne è stata eettuata una verica puntuale sfruttando
dei browser consultabili gratuitamente su internet
gare l'ontologia.
4
che permettono di navi-
In questo modo si è trovato riscontro di esempi concreti
di problemi ontologici di SNOMED in riferimento a DOLCE come ontologia
formale top-level, e si è anche constatato che molti errori sono stati corretti
5
nelle ultime release .
Nel dettaglio, l'analisi della struttura di SNOMED CT ha rivelato una
serie di errori ontologici e di ingegneria della conoscenza. I più importanti
sono descritti di seguito e documentati con le immagini tratte dai suddetti
6
browser :
•
Uso comune di ereditarietà multipla, con errori frequenti di sussunzione: ad esempio bevanda alcolica, tramite il suo genitore alcool ingestibile (gura 4.6), è sussunto da alcool etilico e da sostanza di abuso
(gura 4.7). Da un punto di vista losoco nessuna di queste sussunzioni è vera: le bevande alcoliche contengono alcol etilico che svolge un
ruolo di sostanza di abuso (per quanto riguarda gli esseri umani);
4 http://snomed.dataline.co.uk, http://terminology.vetmed.vt.edu/default.htm
5 SNOMED CT è continuamente soggetto a cambiamenti, modiche e integrazioni grazie
alla collaborazione internazionale dei stati membri della HITSDO
6 I concetti oggetto dello studio sono visualizzati in neretto al centro, invece i loro
genitori sono indicati in rosso
4.1.2 SNOMED CT
Figure 4.6: Bevanda alcolica in SNOMED CT
85
4.1.2 SNOMED CT
Figure 4.7: Alcool ingestibile in SNOMED CT
86
4.1.2 SNOMED CT
•
87
7
Mancanza di mereologia esatta per l'anatomia : è dicile immaginare
che un oggetto possa essere una parte corretta di due regioni che sono
mereologicamente scollegate. Ad esempio struttura del nervo tibiale è
direttamente sussunto sia da parte della coscia (parte superiore dell'arto
inferiore) che da struttura della gamba (parte inferiore dell'arto inferiore)(gura 4.8);
Figure 4.8: Struttura del nervo tibiale in SNOMED CT
•
Errori nella gerarchia:
la gerarchia a volte viola le regole delle basi
dell' ingegneria ontologica, mostrando una classicazione incoerente
con DOLCE. Ad esempio fumatore è sussunto dal comportamento del
fumare il tabacco(gura 4.9).
DOLCE invece distingue chiaramente
tra un ruolo e l'agente che svolge il ruolo;
7 Per mereologia si intende lo studio delle relazioni tra le parti e il tutto
4.1.2 SNOMED CT
88
Figure 4.9: Fumatore in SNOMED CT
•
Omissione di relazioni apparentemente ovvie: ad esempio labbra screpolate è glio di constatazione dell'aspetto del labbro (gura 4.10); anche labbro leporino, in quanto malattia che deforma il labbro, dovrebbe
essere collegato a constatazione dell'aspetto del labbro: invece non lo
è (gura 4.11).
Di certo non ci si può aspettare che una terminologia di grandi dimensioni sia completa. Tuttavia, tali omissioni hanno la conseguenza che
molte inferenze non possono essere fatte correttamente;
4.1.2 SNOMED CT
Figure 4.10: Labbra screpolate in SNOMED CT
Figure 4.11: Labbro leporino in SNOMED CT
89
4.1.2 SNOMED CT
•
90
La gerarchia viola a volte il pensiero medico e le conoscenze in campo
biomedico. Ad esempio disease (condizione anormale di un organismo),
è sussunto da clinical nding (risultato di osservazioni cliniche): questo
non è propriamente corretto dal punto di vista medico, in quanto si
tratta di concetti medici mutuamente disgiunti (gura 4.12).
Figure 4.12: Disease in SNOMED CT
Gli errori ontologici sono probabilmente causati dal fatto che SNOMED CT
è stato sviluppato dando la massima priorità alle esigenze dei clinici, vale a
dire trovare facilmente i concetti oggetto della loro ricerca.
Le occorrenze
frequenti di questi errori possono creare problemi alla razionalità del ragionamento automatico. Tuttavia SNOMED è in continua evoluzione, e si può
condare in una continua correzione di questi errori grazie alla collaborazione
internazionale di cui gode.
4.2 Espressività
4.2
91
Espressività
Il secondo aspetto dell'analisi riguarda una valutazione dell'espressività
delle due ontologie. Esse sono espresse utilizzando diversi proli della famiglia
dei linguaggi OWL. Come descritto approfonditamente nel paragrafo 1.2,
OWL è il linguaggio ontologico per il web, raccomandato dalla W3C, attualmente alla versione 2: ha le sue radici nelle logiche decsrittive (DL). Come
si è approfondito nel paragrafo 1.3, le DL sono delle famiglie di formalismi
per la rappresentazione strutturata della conoscenza: ne esistono diversi tipi,
ognuno caratterizzato dalla presenza di diversi costrutti, quindi da dierenti
livelli di espressività e di complessità.
Ciò che si vorrebbe idealmente in un linguaggio è una elevata espressività
e una bassa complessità computazionale: in realtà questo non è possibile perché all'aumentare dell'espressività del linguaggio in genere aumenta anche la
complessità computazionale, perciò ci si accontenta di raggiungere un buon
trade-o tra le due. L'obbiettivo delle prossime sezioni sezione è determinare
quale delle due ontologie raggiunge il miglior trade-o.
4.2.1
ROME
Dalla dichiarazione dei namespace in ROME si evince che esso utilizza al
suo interno elementi di OWL (relativi all'ultima versione, quindi OWL2) ed
elementi di DOLCE-Lite 397:
xmlns:owl=http://www.w3.org/2002/07/owl#
xmlns:dol=http://www.loa-cnr.it/Files/DLPOnts/DOLCE-Lite_397.owl#
A sua volte DOLCE-Lite 397 include nell dichiarazione dei namespace un
riferimento alla ontologia DOLCE-Lite:
xmlns:dol=http://www.loa-cnr.it/ontologies/DOLCE-Lite#
Pertanto su ROME è stata svolta un'analisi esaustiva (utilizzando Protégé)
dei costrutti OWL eettivamente impiegati nella denizione delle sue entità.
Per le entità usate in ROME ma denite in DOLCE-Lite 397 e DOLCELite si è andati ad analizzarne la denizione originaria. Trovati quindi tutti
i costrutti OWL eettivamente impiegati in ROME, ne è stata individuata
la corrispondenza con gli operatori delle DL, e in denitiva si è giunti alla
individuazione della specica DL in cui ROME è espressa.
Di seguito è riportato in dettaglio il risultato di tale analisi.
4.2.1 ROME
92
DL secondoProtégé
La DL di ROME, indicata sul workspace principale di Protégé, è
(gura 4.13).
In dettaglio la DL
ALE
8
è composta dalle seguenti DL :
Figure 4.13: DL di ROME secondo Protégé
• AL:
• E:
corrisponde agli operatori:
Negazione atomica;
Intersezione di concetti;
Restrizione universale;
Quanticatore esistenziale limitato.
corrisponde all'operatore quanticatore esistenziale completo.
Invece la DL di DOLCE-Lite 397 è
SHIF
(gura 4.14).
In dettaglio essa è composta dalle seguenti DL:
Figure 4.14: DL di DOLCE-Lite 397 secondo Protégé
• S:
corrisponde alla DL
• H:
gerarchie tra ruoli;
• I:
ALC
9
, con l'aggiunta di ruoli transitivi;
proprietà inversa;
8 Per ulteriori dettagli vedere il paragrafo 1.3.2
9 La DL C introduce la negazione di concetti complessi
ALE
4.2.1 ROME
• F:
93
proprietà funzionale.
Inne, la DL di DOLCE-Lite è
SHI
(gura 4.15).
Si può notare che gli operatori della DL
ALE
sono già presenti nella
Figure 4.15: DL di DOLCE-Lite secondo Protégé
SHI ,
SHIF .
DL
che a sua volta può essere considerata un sottoinsieme della DL
Il fulcro dell'analisi pertanto è stato individuare quali operatori della DL
SHIF
sono realmente utilizzati in ROME.
Analisi di DOLCE-Lite 397
Le entità ROME le cui denizioni fanno riferimento alla ontologia di
più alto livello DOLCE-Lite 397 sono: Endurant; Non-Physical-Endurant;
Physical-Endurant; Physical Quality; Quality; Perdurant; Spatio-TemporalParticular.
Iniziando l'analisi da Endurant, ricordiamo che essa è una delle classi di
livello superiore in ROME (gura 4.16).
La sua denizione OWL è la seguente:
Figure 4.16: Endurant in ROME
4.2.1 ROME
94
<owl:Class rdf:about=&dol;ENDURANT>
<rdfs:subClassOf rdf:resource=&dol;SPATIO-TEMPORAL-PARTICULAR/>
<rdfs:comment rdf:datatype=&xsd;string>Questo è DOL</rdfs:comment>
</owl:Class>
Considerando che &dol è il simbolo utilizzato al posto di http://www.loacnr.it/Files/DLPOnts/DOLCE-Lite_397.owl
10
, segue che la denizione ori-
ginale di Endurant va cercata in DOLCE-Lite 397.
Pertanto, la descrizione di Endurant in DOLCE-Lite 397, secondo la visualizzazione di Protégé, è riportata in gura 4.17.
Tale descrizione coincide con la denizione OWL:
Figure 4.17: Endurant in DOLCE-Lite 397
10 Denizione inserita nel namespace, il cui codice è riportato all'inizio del paragrafo
4.2.1
4.2.1 ROME
95
<owl:Class rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#endurant>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#participant-in/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#perdurant/>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#quality/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#specic-constant-constituent/>
</owl:onProperty>
<owl:allValuesFrom rdf:resource=http://www.loa-cnr.it/ontologies/DOLCE-Lite#endurant/>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource=http://www.loa-cnr.it/ontologies/DOLCE-Lite#abstract/>
<rdfs:subClassOf>
<owl:Class rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#spatio-temporal-particular/>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:allValuesFrom rdf:resource=http://www.loa-cnr.it/ontologies/DOLCE-Lite#endurant/>
<owl:onProperty>
<owl:ObjectProperty rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#part/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype=http://www.w3.org/2001/XMLSchema#string >The main characteristic
of endurants is that all of them are independent essential wholes. This does not mean that the corresponding property (being an endurant) carries proper unity, since there is no common unity criterion
for endurants. Endurants can 'genuinely' change in time, in the sense that the very same endurant as a
whole can have incompatible properties at dierent times. To see this, suppose that an endurant - say
'this paper' - has a property at a time t 'it's white', and a dierent, incompatible property at time t' 'it's
4.2.1 ROME
96
yellow': in both cases we refer to the whole object, without picking up any particular part of it. Within
endurants, we distinguish between physical and non-physical endurants, according to whether they have
direct spatial qualities. Within physical endurants, we distinguish between amounts of matter, objects,
and features.</rdfs:comment>
<owl:disjointWith>
</owl:disjointWith>
</owl:Class>
Analizzando tutti i costrutti presenti in tale denizione, sono stati individuati
i corrispondenti operatori delle DL. Nel dettaglio:
•
Il costrutto OWL <owl:someValuesFrom>, visualizzato in Protégé come
SOME (gura 4.17), corrisponde in DL al quanticatore esistenziale
completo
•
∃R.C,
quindi alla DL
E;
Il costrutto OWL <owl:allValuesFrom>, visualizzato in Protégé come
ONLY (gura 4.17), corrisponde in DL al quanticatore universale
∀R.C,
•
quindi alla DL
AL;
Il costrutto OWL <owl:disjointWith>, visualizzato in Protégé come
DISJOINT CLASSE (gura 4.17), è esprimibile in DL con la combinazione del costrutto di inclusione
terminologici
11
) e di negazione
¬,
v
(utilizzato per formare assiomi
quindi alla DL
C;
Prodeguendo con l'analisi, si è andati a cercare la denizione OWL della
superclasse anonima di Endurant: Particular and (endurant or perdurant or
quality), classe equivalente a Spatio-temporal-particular. La sua denizione
è la seguente:
<owl:Class rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#spatio-temporal-particular>
<owl:equivalentClass>
<owl:Class>
<owl:intersectionOf rdf:parseType=Collection>
<owl:Class>
<owl:unionOf rdf:parseType=Collection>
<owl:Class rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#endurant/>
<owl:Class rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#quality/>
</owl:unionOf>
4.2.1 ROME
97
</owl:Class>
<owl:Class rdf:about=http://www.loa-cnr.it/ontologies/DOLCE-Lite#particular/>
</owl:intersectionOf>
</owl:Class>
</owl:equivalentClass>
<rdfs:comment rdf:datatype=http://www.w3.org/2001/XMLSchema#string
>Dummy class for optimizing some property universes. It includes all entities that are not reications of
universals ('abstracts'), i.e. those entities that are in space-time.</rdfs:comment> </owl:Class>
Dal codice appena riportato risulta che i nuovi costrutti OWL utilizzati sono:
•
Il costrutto OWL <owl:intersectionOf>, visualizzato in Protégé come
AND (gura 4.17), corrisponde all'operatore intersezione di concetti
quindi alla DL
•
u,
AL;
Il costrutto OWL <owl:unionOf>, visualizzato in Protégé come OR(gura
4.17), corrisponde all'operatore di disgiunzione
t,
quindi alla DL
U.
Dato che nella denizione di Endurant (ma anche nella denizione di altre entità o proprietà come Participant-In, Perdurant, Quality, Specic-ConstantConstituent, Abstract, Spatio-Temporal-Particular, Part) sono presenti dei
12
riferimenti a DOLCE-Lite
, è stato necessario andare ad analizzare anche
la denizione di queste entità in DOLCE-Lite.
Analisi di DOLCE-Lite
Iniziando dalla denizione di Endurant in DOLCE-Lite, si è potuto notare che essa coincide con quella in DOLCE-Lite 397.
Si è andati dunque avanti guardando alla denizione di Participant-In. La
sua denizione OWL è la seguente:
<! Object property: http://www.loa-cnr.it/ontologies/DOLCE-Lite.owl#participant-in >
<owl:ObjectProperty rdf:about=#participant-in>
<rdfs:subPropertyOf>
<owl:ObjectProperty rdf:about=#immediate-relation-i"/> </rdfs:subPropertyOf>
<owl:inverseOf>
<owl:ObjectProperty rdf:about=#participant/>
12 Come
si
evince
dal
codice
OWL
cnr.it/ontologies/DOLCE-Lite#endurant>,
<owl:Class
rdf:about=
http://www.loa-
<owl:ObjectProperty
http://www.loa-cnr.it/ontologies/DOLCE-Lite#participant-in/>, ecc.
rdf:about=
4.2.1 ROME
98
</owl:inverseOf>
<rdfs:domain>
<owl:Class rdf:about=#endurant/>
</rdfs:domain>
<rdfs:range>
<owl:Class rdf:about=#perdurant/>
</rdfs:range>
</owl:ObjectProperty>
Analizzando tutti i costrutti presenti in tale denizione, sono stati individuati
i corrispondenti operatori delle DL:
•
Il costrutto <rdfs:subPropertyOf>, che corrisponde all'operatore di inclusione
•
v
utilizzato per creare gerarchie tra ruoli, quindi alla DL
H;
Il costrutto <owl:inverseOf>, che corrisponde alla proprietà inversa
−
R , quindi alla DL I .
Facendo il punto della situazione, dall'analisi della sola enità Endurant di
ROME, risulta che i costrutti utilizzati nella sua denizione sono:
•
Il quanticatore esistenaziele completo;
•
Il quanticatore universale;
•
L' operatore di intersezione;
•
L' operatore di unione;
•
Il disjoint with.
Nel complesso essi corrispondono alla DL
ALC .
ALC
esprimibili con con l'operatore
sintetizza anche le DL
di negazione (DL
C)
E
ed
U ,perché
Ricordiamo che la DL
e gli operatori di congiunzione e quanticatore univer-
sale presenti nella DL
AL13 .
Quindi sono stati già trovato costrutti corrispondenti ad un sottoinsieme
della DL
SHIF :
l'utilizzo della DL
in particolare, della DL
H, I ,
13 Vedere il paragrafo 1.3.3
e parte della
S
SHIF
è stato individuato nora
(solo la DL
ALC ).
4.2.1 ROME
99
Prosieguo dell'analisi
Si è deciso di sospendere l'analisi esaustiva perché inutile: l'analisi si è
concentrata sulla ricerca solo di esempi di ruoli transitivi (per ottenere una
piena DL
•
S)
e proprietà funzionali (corrispondenti alla DL
F ):
Ruoli transitivi: in DOLCE-Lite 397 vi sono 6 proprietà transitive(gura
4.18).
Tra esse vi è la proprietà Part (gura 4.19).
Figure 4.18: Ruoli transitivi in DOLCE-Lite 397
Figure 4.19: Proprietà transitiva Part in DOLCE-Lite 397
4.2.1 ROME
100
Tale proprietà è usata nelle denizioni delle classi Endurant e NonPhysical Endyrant in DOLCE-Lite 397 (gura 4.20), quindi risulta essere coinvolta in ROME.
Facendo nuovamente il punto della situazione, grazie all'individuazione
Figure 4.20: Utilizzi della proprietà Part
di almeno un utilizzo di ruoli transitivi in DOLCE-Lite 397 nella denizione
di entità coinvolte indirettamente in ROME, si può aermare che nora della DL
SHIF
corrispondenti alle DL
vengono utilizzati in ROME solo gli operatori
H, I
ed
S
(stavolta completa).
4.2.1 ROME
•
101
Proprietà funzionali: l'unica proprietà funzionale in DOLCE-Lite 397
è life (gure 4.21 e 4.22).
Figure 4.21: Proprietà funzionali in DOLCE-Lite 397
4.2.1 ROME
102
Figure 4.22: Proprietà funzionale Life in DOLCE-Lite 397
Andando ad indagare tra i suoi utilizzi, risulta che non compare in
nessuna delle denizioni delle entità di DOLCE usate in ROME (gura
4.23).
Si può dedurre che ROME non utilizza proprietà funzionali.
4.2.2 SNOMED CT
103
Figure 4.23: Utilizzi della proprietà Life
L'analisi sull' espressività di ROME perciò può ritenersi conclusa: essa
corrisponde alla DL
4.2.2
SHI .
SNOMED CT
Per SNOMED CT ci si è dati delle pubblicazioni in merito: il limite di
non avere tale ontologia a disposizione anche in questo caso non ha costituito
un grosso problema.
SNOMED CT è espresso in OWL 2 EL++: è un prolo di OWL2, con
pochissimi costrutti a disposizione (è dunque poco espressivo). Tale linguaggio si basa sulla DL
EL++,
la cui sintassi e semantica è descritta in gura
4.24.
In particolare, GCI sta per General Concept Inclusion (denizione di assiomi terminologici), mentre RI sta per Role Inclusions (costruzione di ruoli
complessi)
14
.
14 Per un approfondimento ulteriore sugli operatori vedere i paragra 1.3.4 e 1.3.7
4.2.3 Confronto
104
Figure 4.24: Sintassi e semantica della DL
4.2.3
EL++
Confronto
Da un confronto tra le DL
EL++(di SNOMED CT ) e SHI
(di ROME),
risulta che esse presentano un sottoinsieme di operatori coincidenti, più degli
operatori eccedenti ambo i lati.
In dettaglio,
•
EL++
ha i seguenti operatori in più rispetto a
SHI :
Nominal: utilizzo di nomi di individui non solo nell'ABOX ma anche
nella costruzione dei concetti
15
, usati per l'enumerazione (infatti né
ROME né DOLCE-Lite hanno individui, e nessuna delle due usa il
costrutto oneOf per l'enumerazione);
•
Inclusione di ruoli con a sinistra role chains
16
: SNOMED CT usa una
forma ristretta di questo costrutto, che altrimenti sarebbe molto espressivo e sorgente di indecidibilità;
•
Domini concreti
Invece la DL
SHI
17
.
ha in più rispetto alla DL
EL++
i seguenti operatori
15 Per un approfondimento ulteriore vedere il paragrafo 1.3.5
18 Per un approfondimento ulteriore vedere i paragra 1.3.2 e 1.3.3
18
:
4.2.3 Confronto
•
Disgiunzione;
•
Negazione;
•
Quanticatore universale;
•
Ruolo inverso.
105
Si è cercato in seguito riscontro di tali risultati a livello del linguaggio OWL:
in particolare dando un'occhiata ai costrutti del corrispondente prolo OWL2
EL++, risulta che tra le feature supportate vi sono:
•
Enumerazioni che coinvolgono un singolo elemento (ObjectOneOf ) o
una singola costante (DataOneOf );
•
Object property inclusion (SubObjectPropertyOf ), che coinvolgono possibilmente anche Property chains, e Data property inclusion (SubDataPropertyOf );
•
Inclusioni complesse tra Object properties (dove per coplesse ci si riferisce
al fatto che la property chains possono trovarsi sul lato sinistro).
Invece le feature mancanti di OWL2 EL++ (rispetto ad OWL2) sono:
•
Quanticazione universale di una classe (ObjectAllValuesFrom) o Data
range (DataAllaValuesFrom);
•
Disgiunzione (ObjectUnionOf, DisjointUnion);
•
Negazione (ObjectComplementOf );
•
Inverse object properties (InverseObjectProperties).
Tutto questo conferma l'analisi fatta.
In conclusione non si può aermare quale delle due logiche descrittive sia
più espressiva.
4.3 Complessità computazionale
4.3
106
Complessità computazionale
Terminata l'analisi sull'espressività lo studio è proseguito verso l'individuazione
del potere computazionale, legato all'espressività, delle due ontologie.
4.3.1
Cenni sulle classi di complessità
Con complessità di un algoritmo o ecienza di un algoritmo ci si
riferisce alle risorse di calcolo da esso richieste. Partendo dunque dalla misurazione delle risorse computazionali, si possono denire le seguenti classi di
complessità:
•
La classe TIME(f(n)) è l'insieme dei problemi che ammettono una
macchina di Turing che li risolve e che opera in tempo f(n)
•
19
;
La classe NTIME(f(n)) è l'insieme dei problemi che ammettono una
macchina di Turing non deterministica che li risolve e che opera in
tempo f(n);
•
La classe SPACE(f(n)) è l'insieme dei problemi che ammettono una
macchina di Turing che li risolve e che opera in spazio f(n)
•
20
;
La classe NSPACE(f(n)) è l'insieme dei problemi che ammettono una
macchina di Turing non deterministica che li risolve e che opera in
spazio f(n).
Si possono così denire le seguenti classi di complessità:
•
L=SPACE(log(n));
•
NL=NSPACE(log(n));
•
k
P=∪k>0 TIME(n ).
Per risolvere i problemi appartenenti alle classi n qui elencate sono noti
algoritmi che terminano in tempo polinomiale rispetto alla dimensione
dei dati;
•
k
NP=∪k>0 NTIME(n ): per questi problemi sono noti algoritmi che terminano in un numero di passi polinomiale rispetto alla dimensione dei
dati nel caso si possa utilizzare un numero indeterminato di macchine
19 Dato un input x di lunghezza n, la macchina M produce il risultato in f(n) passi
20 Dato un input x di lunghezza n, la macchina M utilizza f(n) celle temporanee per
eettuare la computazione
4.3.2 ROME
107
in parallelo, o nel caso si utilizzi una macchina di Turing non deterministica. La sigla NP sta per non-deterministic polinomial (polinomiale
nondeterministico): tutti gli algoritmi realizzabili su calcolatori sici
risolvono questi problemi in tempo esponenziale rispetto a n;
•
k
PSPACE=∪k>0 SPACE(n );
•
k
NSPACE=∪k>0 NSPACE(n );
•
nk
EXPTIME=∪k>0 TIME(2 ): per questi problemi sono noti solamente
algoritmi che terminano in un numero di passi esponenziale rispetto
alla dimensione dei dati, indipendentemente dal modello di calcolo.
Tra queste classi sono note le seguenti relazioni di equivalenza:
•
L
⊆
NL
•
L
⊆
PSPACE;
•
P
⊆
EXPTIME.
4.3.2
⊆
P
⊆
NP
⊆
PSPACE
=
NSPACE
⊆
EXP;
ROME
Per lo studio della complessità computazionale di ROME è stato suciente individuare la complessità (nota in letteratura) di una logica descrittiva che utilizza un sottoinsieme dei costrutti presenti nella logiche descrittiva
con cui è espressa ROME: tale risultato è stato poi vericato utilizzando un'
applicazione disponibile sul web (un complexity navigator).
Nel dettaglio, un risultato noto in letteratura
21
è che per la DL
ALE
i
problemi di sussuzione (a cui sono conducibili gli altri problemi di reasoning
se sono presenti gli operatori di intersezione e il concetto insoddisfacibile)
e soddisfacibilità (a cui sono conducibili gli altri problemi di reasoning se
presente la negazione)
22
23
sono NP-COMPLETI
: considerando che tutti gli
24
operatri presenti nella DL ALE sono anche presenti nella DL SHI
si può
dedurre che la complessità della DL SHI è almeno NP. Questi risultati sono
riferiti a problemi con semplici espressioni di concetti. Se si iniziano a considerare gli assiomi (quindi il TBox) in genere la complessità aumenta.
Indagando ulteriormente, è stata individuata la complessità esatta del ragionamento per la DL
SHI
di ROME, servendosi di un complexity navigator
21 Per approfondimenti consultare il The description logic handbook: theory, implementation, and applications, Baader,F.,McGuinness,D.L.,Nardi,D.,Patel-Schneider,P.F.
23 I problemi NP-completi sono i più dicili problemi nella classe NP
4.3.2 ROME
108
25
disponibile per la consultazione gratuitamente su internet
(gura 4.25): la
classe di complessità risulta essere EXP-TIME COMPLETE sia per quanti
riguarda la soddisfacibilità dei concetti che per quanto riguarda la consistenza
dell'ABox.
In letteratura il comportamento esponenziale nel tempo di calcolo delle
Figure 4.25: Complessità delle DL
SHI
secondo il complexity navigator
logiche descrittive è giusticato facendo riferimento all' esplorazione di alberi
26
AND e OR
. Intuitivamente, esso è legato alle seguenti due origini indipen-
denti di complessità:
•
L'AND BRANCHING: corrisponde al controllo indipendente di tutti i
successori di un individuo. È responsabile della dimensione esponenziale di un singolo modello candidato. Il suo comportamento esponenziale è dovuto all'interazione del quanticatore esistenziale col quanticatore universale (come accade per la DL
•
ALE );
L'OR BRANCHING: corrisponde alla dierente scelta di applicazione
di una regola non deterministica. È responsabile del numero esponenziale di dierenti modelli candidati.
Il suo comportamento esponen-
ziale è dovuto alla presenza del costruttore di disgiunzione che rende
25 http://www.cs.man.ac.uk/ ~ezolin/dl/#note8
26 Per approfondimenti consultare il The description logic handbook: theory, implementation, and applications, Baader,F.,McGuinness,D.L.,Nardi,D.,Patel-Schneider,P.F.
4.3.3 SNOMED CT
109
un concetto soddisfacibile da più di un modello (come accade per la
DL
ALU ).
L'intrattabilità di ragionamento (cioè l'essere non polinomiale nel caso peggiore) non impedisce tuttavia di usare la DL in pratica, se l' implementazione
di sistemi basati su qualche DL usano sosticate tecniche di ottimizzazione
e se le basi di conoscenza sono di dimensioni realistiche, come accade per
ROME.
4.3.3
SNOMED CT
Per l'analisi della complessità computazionale di SNOMED CT ci si è
ancora dati dei risultati pubblicati in letteratura
27
, secondo i quali esso pre-
senta buone proprietà computazionali per ontologie su larga scala: fornisce
infatti ragionamento in tempo polinomiale.
In dettaglio, uno dei risultati noti è che la DL
DL
EL++)
è trattabile:
28
TBox ciclici che aciclici
dono
EL++,
EL
(sottoinsieme della
è infatti decidibile in tempo polinomiale sia per
. Aggiungendo alla DL
EL
i costrutti che la ren-
il problema di sussunzione (quindi anche gli altri problemi di
reasoning grazie ai costrutti presenti) resta decidibile.
Tale DL è sucientemente espressiva da permetterne il suo eettivo impiego
per la descrizione del dominio di interesse, ed è trattabile anche considerando
l'inclusione generalizzata di ruoli.
Le cause delle sue buone proprietà sono le seguenti:
•
Assenza del quanticatore universale, che causerebbe un ragionamento
EXP-time completo;
•
Utilizzo solo di una forma ristretta di role-value-maps, che altrimenti
sarebbe causa di indecidibilità.
Gli stessi risultati sono stati riscontrati sulle pubblicazioni della W3C, secondo le quali le ontologie espresse utilizzando il linguaggio OWL 2 EL++
(tra cui appunto SNOMED CT) hanno tutte problemi di ragionamento controllabili in tempo polinomiale.
27 Per approfondimenti consultare gli articoli Pushing the EL Envelope e Pushing
the EL Envelope Further (Institute for Theoretical Computer Science TU Dresden)
Baader,F.,Brandt,S.,Lutz, C.
28 SNOMED CT usa un TBOX aciclico
4.3.4 Confronto
4.3.4
110
Confronto
Sintetizzando i risultati sopra riportati, si può aermare che SNOMED
CT presenta buone proprietà computazionali per ontologie su larga scala:
fornisce infatti ragionamento in tempo polinomiale.
ROME invece presenta un comportamento esponenziale nel tempo di calcolo: una ontologia con tale complessità è utilizzabile solo per basi di conoscenza di piccole dimensioni, grazie anche alle sosticate tecniche di ottimizzazione presenti oggigiorno, ma al crescere delle dimensioni della base
di conoscenza il ragionamento diventerebbe in trattabile.
In denitiva appare evidente che SNOMED CT presenta proprietà computazionali migliori rispetto a ROME.
Chapter 5
Conclusioni
Nell'ambito del lavoro presentato in questa tesi sono stati introdotti innanzitutto i vantaggi dell'utilizzo delle ontologie in ambito biomedico, traducibili in migliore interoperabilità e maggiori capacità elaborative, e in sintesi migliore assistenza sanitaria.
Quindi è stato svolto uno studio su due ontologie particolarmente signicative in ambito biomedico: SNOMED CT nell'ambito internazionale, ROME
nell'ambito nazionale italiano.
Ne è conseguita un'analisi comparata tra le due ontologie sotto diversi aspetti:
di carattere generale - come la diusione e accettazione - e di carattere più
prettamente ingegneristico, quali la correttezza delle ontologie in riferimento
alle regole di una buona ingegnerizzazione, la determinazione delle eettive
logiche descrittive con cui sono espresse (dunque dei livelli di espressività
posseduti) e della conseguente complessità computazionale. Si è giunti così
all'obiettivo nale: tirar fuori delle valutazioni conclusive sul confronto risultante tra le due ontologie sotto tutti questi proli.
Innanzitutto la grossa distizione tra le due ontologie oggetto dell'analisi
riguarda la diusione:
SNOMED CT è diusa e accettata a livello inter-
nazionale; ROME è utilizzata solo in Italia, e in sporadiche applicazioni.
Sotto il prolo invece della correttezza ontologica, l'analisi svolta su SNOMED
CT ha rivelato la presenza di errori che spesso violano i principi dell'ingegneria
ontologica; l'analisi svolta su ROME invece ha mostrato la correttezza dell'
ontologia secondo i suddetti principi, sebbene siano comunque presenti delle
imprecisioni.
Per quanto riguarda l'espressività, l'analisi ha portato all'individuazione delle
logiche descrittive sulle quali le due ontologie si basano (analizzandone i singoli costrutti del linguaggio OWL eettivamente impiegati), e dal confronto
è conseguito che non si può aermare quale delle due ontologie sia più espressiva.
111
112
Per quanto riguarda inne la complessità computazionale legata all'espressività
precedentemente determinata, si è individuato che per ROME risulta essere
esponenziale (quindi intrattabile al cresecere della mole di dati), mentre per
SNOMED CT è polinomiale, quindi trattabile anche per grandi quantità di
dati.
Al ne di valutare quale alternativa sarebbe migliore per l'Italia, non
bisogna dimenticare che lo scopo primario delle ontologie è garantire l' interoperabilità: quindi la scelta sarebbe tra un'interoperabilità solo nazionale,
quindi ROME, e una internazionale, cioè SNOMED CT.
Nel primo caso tuttavia ROME andrebbe estesa con l'aggiunta di altre ontologie di dominio al ne di raggiungere una maggiore copertura di argomenti
in ambito sanitario, ma a causa della sua complessità il ragionamento diverrebbe intrattabile, quindi di fatti l'ontologia sarebbe inutilizzabile.
Nel secondo caso, sarebbe necessario diventare membri della HITSDO (con
il relativo pagamento della tassa annuale) per poter collaborare al lavoro
internazionale di correzione dei contenuti dell'ontologia, e occorrerebbe un
lavoro iniziale di nazionalizzazione, ma sicuramente sarebbero garantitate
una completa interoperabilità e ottime proprietà computazionali.
Ringraziamenti
Sarei negligente se non ringraziassi tutte le persone che mi hanno aiutata a sopravvivere all'esperienza di altri tre anni d'università: mi hanno
sostenuto nei momenti di dicoltà, incoraggiato nei momenti di sconforto, si
sono rallegrate con me nei piccoli/grandi successi ... e mi sono semplicemente
state accanto in tutti gli altri momenti, contribuendo in modo concreto al
raggiungimento di questo mio importante traguardo: questa tesi è dedicata
a voi miei cari.
Inizio dalla persona che, sebbene nella storica e perenne concorrenza tra
ingegneri informatici ed elettronici mi abbia assegnato il titolo di pigia tasti,
ha dato un tocco di brio alla mia vita in questi ultimi anni, ha riempito le mie
giornate (a volta anche troppo!), ma senza la quale il mio mondo perderebbe
i colori: grazie Eros, hai reso più completa la mia vita facendomi scoprire
quanto sia più bella se vissuta in due.
Grazie ai miei stupendi genitori che hanno sempre saputo sostenermi e
consigliarmi, facendomi avvertire il loro calore anche a 500km di distanza: è
dicile immaginare un mondo senza l'appoggio del mio papà e i buoni consigli della mia mamma.
La mia adorata sorellina e il mio caro cognato sono stati decisivi: grazie
per l'aiuto sempre pronto e concreto, la presenza costante ...
e gli innu-
merevoli passaggi al pronto soccorso! Prometto di essere meno sbadata...
Grazie ai mei quasi suoceri e cognati: sono felice di essere entrata a far
parte della vostra allegra compagnia.
E poi ci sono tutti i miei amici di questi anni universitari: i compagni di
corso: compagni di avventura e sventura; il gruppo della Pastorale Universitaria, che ha arricchito il mio periodo di studi attribuendogli un valore più
alto; il gruppo Giovani delle Grazie per le belle e ricche chiacchierate fatte
insieme. Grazie anche al gruppo di nuoto del CUS per i momenti di svago;
grazie alla mia cara mamma mensa ERSU per avermi nutrita in questi anni
... e un grazie speciale va alle mie innumerevoli coinquiline: tra momenti
di condivisione e di tirate per capelli, tra momenti di condenze e di litigi,
tra periodi più o meno pacici ...
tutte quante mi avete arricchito e fatto
crescere.
Grazie alle persone che erano con me all'inizio dei miei studi ma che
nel corso di questi ultimi anni mi hanno lasciato per raggiungere un posto
migliore: grazie Don Enzo e zio Vittorio.
Grazie al Professor Dragoni e al suo gruppo di ricerca, che con la loro
semplicità e dedizione rendono migliore questa università.
E inne un grazie lo devo anche a tutto la sta dell'Ospedale Careggi di
Firenze e a tutti i sioterapisti che mi hanno seguito in questi ultimi anni:
grazie per aver rimesso in sesto la mia povera spalla con tanta competenza,
permettendomi di portare a termine i miei studi.
Spero di non aver dimenticato nessuno: in ogni caso vi porto tutti nel
mio cuore.
Bibliography
Ontologie
Ontologie BS
[1] OpenClinical, http://www.openclinical.org/
[2] Barry Smith:
textitchapter "Ontology" of Blackwell Guide to the Philosophy of Computing and Information, Oxford: Blackwell, (2003).
HITSDO
ROME
[3] HITSDO, http://www.hitsdo.org
[4] Pisanelli, D.M., Battaglia, M., De Lazzari, C.: ROME: a Re-
ference Ontology in Medicine, New Trends in Software Methodologies,
Tools and Techniques-Proceedings of the sixth SoMeT 07, (2007).
SNOMED CT
Ontological
[5] Héja,G.,Surján,G.,Varga,P.:
CT,
First
European
Conference
on
analysis
SNOMED
CT,
of
SNOMED
Copenhagen-
Denmark(2006).
Browsers
[6] Snoflake
browser,
http://snomed.dataline.co.uk,
Snomed
Ct
Core Browser, http://terminology.vetmed.vt.edu/default.htm
W3C
DL
[7] W3C, http://www.w3.org/
[8] Baader,F.,McGuinness,D.L.,Nardi,D.,Patel-Schneider,P.F.
The description logic handbook:
:
theory, implementation, and applica-
tions, Cambridge University Press, (2003).
EL
[9] Baader,F.,Brandt,S.,Lutz, C.: Pushing the EL Envelope, Institute
for Theoretical Computer Science TU Dresden, Germany
EL2
[10] Baader,F.,Brandt,S.,Lutz, C.: Pushing the EL Envelope Further,
Institute for Theoretical Computer Science TU Dresden, Germany
Complexity
[11] Complexity
of
reasoning
in
http://www.cs.man.ac.uk/ ~ezolin/dl/#note8
115
Description
Logics,

analisi comparata di due ontologie in ambito biomedico

Transcript

Documenti analoghi

Riccardo Antonini e attualmente consulente in progetti di realta

SEMANTIC WEB

Davide Truffo

Rappresentazione della Conoscenza nel Semantic Web

URban moRphology and deSign: Rome in miami

Lodging Near Lateran University

mauro monesi - Arcobaleno 85 srl

ART ET FASCISME EN ITALIE

PONTE DELLA MUSICA ROME, ITALY

Lingua straniera