Uno schema ontologico
Il primo passo per costruire un accesso semantico ai dati è quello di costruire uno schema ontologico. Ma come la costruiamo?
L'ontologia servirà a delineare le strade che collegano gli oggetti del dominio, e permetterà di sapere meglio come fare a muoversi tra questi oggetti. Questa immagine è di certo una descrizione riduttiva, che lascia il lettore con molte domande in testa, prego però di rimandare un momento le domande e di tenere bene a mente questa immagine: pian piano la renderemo qualche cosa di più concreto.
Innanzi tutto ho parlato di acceso semantico, usando un termine generico. Voglio fermarmi un attimo a sottolineare questa cosa. Uno schema ontologico può essere utile in molti casi. Non bisogna pensare solamente alla navigazione di documenti da parte di utenti. In qualsiasi caso io debba indicare come si collegano due oggetti lo schema diventa indispensabile. In alternativa si è condannati a costruire applicazioni non estensibili, troppo dipendenti dalla situazione. Ad esempio per descrivere le funzioni delle classi che compongono un sistema, bisogna utilizzare uno schema (oggi si ricorre allo xml). Quando non necessitiamo di fornire con lo schema un accesso diretto ai dati e dobbiamo modellare relazioni complesse, i linguaggi ontologici (come RDFs) sono delle ottime soluzioni. Per una migliore comprensione del valore dell'ontologia rimandiamo all'articolo Cos'è e a cosa serve il Web Semantico.
Abbiamo oggetti ma non sappiamo come si collegano
Ritorniamo alla nostra immagine. L'ontologia è la mappa dei percorsi che portano da un oggetto all'altro. Spesso noi abbiamo degli oggetti, dei documenti, dei pezzi di codice, che sono collegati tra loro, ma non abbiamo modo di descrivere questa cosa da nessuna parte. L'ontologia ha come primo scopo quello di descrivere questi collegamenti.
La prima cosa che dobbiamo perciò chiederci quando modelliamo un ontologia è questa: cosa dobbiamo dire, cosa dobbiamo farne dei nostri oggetti, come li chiamiamo in causa. In alcuni casi potremmo voler descrivere documenti che trattano di quegli oggetti. In altri casi possiamo aver bisogno di tenere traccia di un processo produttivo. In altri ancora tenere traccia delle scelte e delle attività operate da un utente.
Il processo nella quale dovrà essere inserito lo schema, diventa il punto focale della modellazione. Se siamo in grado di metterlo in luce con chiarezza sapremo quali oggetti descrivere.
Solitamente si chiamano ontologie di scopo (task ontology) quelle che rappresentano la struttura dei processi. Le ontologie che forniscono gli oggetti specifici della nostra applicazione vengono invece dette di dominio (domain ontology).
Ontologie di Scopo
Riprenderemo l'esempio fatto in un I linguaggi del Web Semantico. Eravamo partiti con l'intenzione di sviluppare un'ontologia in supporto ad una operazione molto semplice: archiviare dei corsi di elearning, con la possibilità di mettere bene in luce gli argomenti trattati. Per fare questo dobbiamo costruire una struttura di concetti che descriva l'archiviazione.
Un concetto può essere proprio quello di Archiviazione. Questo concetto potrebbe avere come attributi: contenuto, data e locazione. Volendo si potrebbe pensare di aggiungere attributi come "archiviatore", la persona che ha archiviato il corso. Questi concetti possono essere semplici stringhe, come ad esempio data, ed allora riporteranno solo un valore, oppure possono puntare ad altre classi. Il contenuto punterà ad un corso o simili, la locazione ad un path ecc.
Un altro concetto che potrebbe essere utile al processo può essere quello di Erogazione. A quanti utenti, oppure a che categoria di utenti, è stato erogato il corso?
Qui voglio prevenire una facile obiezione. Per fare queste cose serve proprio un ontologia? Non si potrebbe tranquillamente utilizzare un database?
Certamente il database è in grado di gestire questo genere di collegamenti fra dati. Ma il database serve ad archiviare dati. Le ontologie sono file xml. Il loro scopo è descrivere una struttura e dare delle preinformazioni sugli oggetti. Dire che tipo di dati accettano, dire con quali altri oggetti si collegano.
Ontologie di Dominio
Una volta che abbiamo a disposizione i concetti di scopo possiamo pensare agli oggetti che compongono il nostro dominio. Teniamo ben presente alcune cose. La modellazione delle ontologie è una modellazione per classi. Il meccanismo dell'ereditarietà consente di definire una unica volta gli attributi che classi ad uno stesso livello ereditano da un padre. La possibilità di definire come valore di un attributo un'altra classe consente di stabilire qualsiasi tipo di relazione fra classi. Queste sono relazione nel senso che si dice che si potrà esprimere il valore di quell'attributo solo servendosi di istanze della classe a cui punta.
Non sempre è però immediato capire cosa dobbiamo definire come attributo, cosa come classe, cosa come attributo che richiami una classe. In questa sessione mostreremo varie possibilità di modellare le classi nel tentativo di fornire alcune soluzioni tramite esempi pratici.
Innanzi tutto possiamo dare alcune regole generali che possono aiutare a ottenere una buona modellazione. Generalmente può essere buona norma non dare alle classi nomi a volte al plurale a volte al singolare. Si può essere portati a utilizzare il plurale per classi che dovranno contenere più individui, il singolare per classi che indicano realtà generiche o astratte.
La classe rappresenta solo una categoria, uno schema. Spesso si mettono i nomi al plurale pensando alla classe come ad un contenitore. Ma questa è una cattiva interpretazione della funzione della classe nell'ontologia. Scegliere un unico modo di comportarsi, nominare sempre al plurale o sempre al singolare, aiuta a non cadere in questa confusione.
Un'altra cosa da tenere in considerazione è il fatto che l'albero dell'ontologia deve essere bilanciato nella granularità. Se una classe A di livello 5 (perché ha su un ramo un padre 2, un padre 3, e un padre 4) ha su un altro ramo come padre una classe B di livello 2. Significa che probabilmente non ho approfondito sufficientemente la granularità del ramo del concetto B.
In pratica verrei a trovarmi con concetti collegati fra loro ma uno su un ramo molto più profondo dell'altro. Questo indica come un buco nella definizione dei concetti e suggerisce che si debba colmare questa discrepanza inserendo nuovi concetti.
Una osservazione simile si può fare nel caso in cui ci si trovasse con una classe A con un numero molto alto di figli. Questa situazione, se non è chiaramente giustificata, è indice di un deficit di definizione. Quello che bisogna fare è quindi ricercare proprietà in comune fra le varie classi figlie di A in modo da raggrupparle con l'aggiunta di nuove classi. All'opposto modellare una classe con un unico figlio è una scelta strana e deprecabile. Suddividere una classe significa stabilire che alcune proprietà e caratteristiche devono riferirsi ad oggetti diversi. Suddividere con una unica classe pare perciò ingiustificato.
Modellando il dominio ci si può trovare di fronte ad alcune situazioni tipiche. Mostreremo ora attraverso degli esempi come è possibile comportarsi. Riprendiamo il nostro scenario dei corsi di elearning.
Potremmo iniziare a costruire le classi partendo dall'elemento centrale del nostro dominio: la lezione. Avrò certamente una classe Lezione. Questa classe sarà composta da vari attributi: argomento, ore, materiale... Ore potrebbe essere una classe semplice, che accetta dati di tipo stringa. Argomento e materiale sono attributi complessi, composti a loro volta da più elementi, per questo gli attributi punteranno ad un'altra classe.
Argomento e materiale vanno perciò definite come classi. Argomento potrebbe avere come attributi titolo ed un livello di specializzazione. Materiale potrebbe avere come attributo chiamato url. Siccome i documenti che compongono il materiale della lezione possono essere diversi questo attributo dovrà poter essere ripreso più volte, e avere quindi una cardinalità da uno a molti.
Più lezioni formano un corso. Potremmo quindi definire una classe corso con l'attributo ha-lezione che punta alla classe Lezione. Il corso potrebbe avere questo attributo riempito con un numero indefinito di istanze di Lezione.
Agganciare oggetti e scopo
Ma il dominio non si è pensato genericamente, non si è voluto descriverlo solo con lo scopo di descriverlo. Avevamo in mente una precisa operazione che doveva svolgersi nel dominio. Per questo abbiamo bisogno di descrivere i soggetti protagonisti di queste operazioni. Osservando con attenzione ci accorgiamo che i soggetti che entrano in gioco non possono essere definiti riferendosi semplicemente al concetto di persona.
Intanto potremmo voler indicare come soggetto attore una organizzazione. Esempio nel caso che si voglia indicare il fornitore di alcuni tipi di materiale o l'organizzazione alla quale appartiene un determinato individuo. Inoltre una persona intesa come individuo non coincide con il ruolo che quell'individuo assume. Una persona può in effetti assumere più ruoli, alcuni ruoli sono poi temporanei (es. studente).
Modelleremo perciò il dominio inserendo una classe Agente con sottoclasse Persona e Organizzazione. Tra i vari attributi di Persona avremo ha-ruolo che punterà ad una classe. Definiremo quindi una classe Ruolo che nel nostro caso avrà come sottoclassi Docente, Tutor, Utente.
Definiti gli attori possiamo pensare ad alcune classi in grado di collegare soggetti, oggetti e scopi. Gli esempi variano moltissimo dalla applicazione che si ha in mente. Facciamo qui un esempio fra tanti possibili.
Alla classe Lezione potremmo pensare di aggiungere una proprietà che si chiama Livello_di_Specializzazione. Questa proprietà ha il compito di tener traccia del livello di specializzazione col quale è stato preparata la lezione. La proprietà punta inoltre alla classe Specializzazione. Nella classe Specializzazione abbiamo a sua volta due attributi. Uno indica il tipo di utenti, e punta ad un classe Utente, uno indica la preparazione di questi utenti, e potrebbe essere benissimo una stringa.
Questo piccolo esempio mostra le capacità espressive di uno schema ontologico. Ogni lezione può avere un livello di specializzazione che dipende dal tipo di utenti a cui si rivolge e dalla preparazione che si presume questi abbiano. La proprietà in pratica ha un grado, con una sorta di restrizione a seconda della tipologia di utente a cui si attribuisce.
Tool per modellare ontologie
Il lavoro della modellazione non è insomma facile. Può essere utile farsi aiutare da un tool. Un tool può venire in soccorso al modellatore sostanzialmente in due modi. Fornire una visualizzazione grafica dell'ontologia, e quindi avere sotto occhio l'intreccio di relazioni tra classi, ed evitare di scrivere il codice a mano, riducendo gli errori involontari. Il codice generato è molto semplice. Non qui il caso quindi che l'applicazione istupidisca il codice sorgente.
Proponiamo due esempi di tool per la modellazione di schemi ontologici. Il primo è Protegè-2000. Un tool che proponiamo in quanto sicuramente il più diffuso e affidabile. Proponiamo poi OntoMaker, un tool sviluppato in italia. Purtroppo non di altissima qualità, ma che ha il pregio di inserirsi in un sistema integrato di tool, affiancando un tool per la costruzione dei metadati e di uno per la navigazione semantica.
