Dopo aver affrontato gli aspetti teorici e le metodologie di progettazione, andiamo ora ad approfondire le tecnologie e i linguaggi utilizzati nella fase di implementazione di una ontologia.
Quali caratteristiche deve avere un linguaggio per la definizione di ontologie?
Un linguaggio per la definizione di ontologie deve permettere al progettista di poter scrivere delle asserzioni in maniera tale da renderle comprensibile alle macchine. Se consideriamo ad esempio una asserzione già vista in precedenza:
Madre ≡ Donna ⊓ ∃ haFiglio.Persona
il linguaggio ontologico deve essere abbastanza espressivo da permettere di esprimere le relazioni tra i concetti e per fare ciò deve innanzitutto permettere di effettuare la distinzione tra i concetti e le relazioni. Infatti, mentre per noi umani la distinzione tra queste due categorie può apparire naturale, per una macchina diventa difficile, se non in alcuni casi impossibile effettuare tale distinzione. Per questo il linguaggio utilizzato deve arricchire le informazioni presenti nell’asserzione con altre informazioni che siano comprensibili dalle macchine. Un esempio esemplificativo potrebbe essere il seguente:
inizio concetto
Donna
fine concetto
In questo caso abbiamo usato dei marcatori, dei delimitatori univoci che permettono alla macchina di capire che il termine Donna è usato per indicare un concetto. Lo stesso procedimento può essere usato per delimitare le definizioni delle relazioni e così via. Tali informazioni aggiuntive sono definite metadati e rappresentano la chiave di volta nell’implementazione di un KRS, in quanto i metadati sono informazioni comprensibili dalla macchina (machine understandable).
L’ uso efficace dei metadati, tuttavia, richiede che vengano stabilite delle convenzioni per la semantica:
- la sintassi
- la struttura
La sintassi riguarda l’organizzazione sistematica dei metadati per l’elaborazione automatica e facilita lo scambio e l’ utilizzo dei metadati tra applicazioni diverse. La struttura può essere vista come un vincolo formale sulla sintassi, per una rappresentazione consistente della semantica.
Ed ecco la soluzione…
Un linguaggio particolarmente diffuso e apprezzato si presta a rispondere alle nostre esigenze: l’XML (eXstensible Markup Language). Questo linguaggio, aperto, indipendente dalla piattaforma e ben standardizzato, permette di aggiungere facilmente dei metadati alle risorse attraverso il processo di serializzazione e permette altresì di definire nuovi linguaggi per gli utilizzi più disparati. Andiamo ora ad analizzare alcuni linguaggi utilizzati nella definizione di ontologie che permettono la serializzazione XML: RDF, OWL e il recente OWL 2. Infine approfondiremo anche l’interfaccia DIG.
Antonio Cicirelli
Il Web Semantico al servizio delle aziende!
Sicuramente sapete cosa è il Data Warehousing (anche io lo sapevo, ma una rinfrescatina può solo far bene, quindi vediamo come ce lo spiega wikipedia).
Questo post nasce dall’intelligente domanda di una lettrice del blog che mi ha sottoposto il seguente quesito: “il web semantico può essere utilizzato dalle aziende per ridurre i costi di data warehouse? Se si, attraverso quale procedimento?”.
Quando ho letto la domanda mi sono detto: “bella domanda!”. Ma soprattutto:
Cosa c’entra il Web Semantico con il Data Warehousing?
Ammettendo da subito la mia ignoranza su tale aspetto, ho ringraziato la lettrice e mi sono informato. E colgo l’occasione per ringraziare ancora Sara per avermi permesso di approfondire questo interessantissimo argomento.
Ieri e oggi: cambiano le tecnologie ma i problemi restano…
La prima considerazione importante da fare su questo argomento riguarda la prima fase del processo di Data Warehousing, ovvero la fase di ETL.
Ancora oggi le sorgenti di dati a disposizione di una azienda continuano ad essere eterogenee, nonostante l’alto grado di digitalizzazione raggiunto ai giorni nostri. In passato l’eterogeneità era generata dalla copresenza nelle realtà aziendali di dati memorizzati in Database e dati presenti su supporti non informatici (essenzialmente materiale cartaceo), e lo sforzo maggiore richiesto alle aziende per effettuare il data mining era proprio quello di estrarre i dati dalle sorgenti non informatizzate per caricarli in un database e renderli disponibili ai processi di data mining.
Oggi il problema è diverso; nonostante la quasi totalità dei dati sia presente all’interno dei database, l’evoluzione tecnologica e aziendale, oltre a portare miglioramenti, ha portato anche nuove “sfide”: la crescita delle aziende e le acquisizioni aziendali, i confini delle intranet che lentamente svaniscono e si integrano con internet, le architetture orientate ai servizi (SOA), hanno portato alla copresenza all’interno delle realtà aziendali di sorgenti di dati (essenzialmente database) eterogenee, in quanto realizzate con tecnologie differenti, a volte proprietarie, e sicuramente difficilmente integrabili ed accessibili ai processi di data mining.
Infatti bisogna ricordare che il modello relazionale (che è lo standard de facto nei database aziendali) priva le informazioni della loro natura trasformandole semplicemente in dati e li ritrasforma in informazioni solo attraverso opportune query.
Quindi nel momento in cui un’azienda si trova di fronte ad un insieme di database eterogenei avrà si una mole rilevante di dati, ma tali dati saranno privi di informazioni utili e le procedure di integrazione diventano lunghe, costose e soprattutto poco scalabili. Piccole modifiche alle basi di dati (aggiunta di tabelle, modifica del tipo di dati) possono portare ad avere informazioni inconsistenti, che per un’azienda che vuole essere competitiva sono un vero e proprio danno, il cui costo è incalcolabile.
Ho capito! La soluzione non può essere che il Web Semantico!
Esatto! In tale scenario il Web Semantico può venire in aiuto delle aziende.
Come visto in precedenza ( articolo introduttivo al Web Semantico), alla base dell’idea delle tecnologie semantiche c’è la realizzazione di una base di conoscenza che si basa sui linguaggi ontologici (vedi articoli sulle Ontologie e sulla Rappresentazione della Conoscenza). La base di conoscenza, a differenza di una base di dati, è pensata per memorizzare ed estrarre informazioni e non dati, è perfettamente scalabile e la tecnologia utilizzata (linguaggi ontologici, come RDF e OWL) è standardizzata e non proprietaria. Tutte caratteristiche di rilievo nel contesto appena esaminato.
Inoltre, in un contesto di Data Warehousing tradizionale, la fase di estrazione delle informazioni rilevanti (Data Mining) era riservata ad una stretta cerchia di “eletti” (gli esperti del settore), che ovviamente rappresentavano un costo rilevante per l’azienda, specialmente nel momento in cui la base di dati cambiava continuamente.
Con le tecnologie del Web Semantico le interrogazioni possono essere effettuate in linguaggio naturale (o quasi), per cui non è più necessario l’intervento continuo di esperti. Inoltre, alla base di un sistema di rappresentazione della conoscenza vi sono i servizi di reasoning, che permettono di estrarre, tramite semplici interrogazioni in linguaggio naturale, nuova conoscenza a partire dalla conoscenza presente. E questo può rappresentare ancora un beneficio per i management aziendali.
Riassumendo…
C’è un costo notevole in termini di tempo e denaro impiegati per codificare sistemi proprietari e per integrare sorgenti di dati eterogenee che possono essere ridotti notevolmente con le tecnologie del Web Semantico, standard e scalabili.
Per non parlare poi del costo che grava sull’azienda quando l’integrazione e/o la consistenza dei dati non vengono gestiti correttamente, portando alla mancanza di informazioni per il processo decisionale o, peggio, alla presenza di informazioni errate.
Il Web Warehousing: di cosa si tratta?
Qualche anno fa le aziende hanno intuito le enormi potenzialità del web ed hanno pensato che dal web si potessero estrarre dati e informazioni rilevanti per l’azienda. Nasceva così il concetto di Web Warehousing, un “magazzino” di dati raccolti sul web sul quale l’azienda può effettuare Web Mining e ottenere un vantaggio competitivo derivante dall’analisi di trend e pattern che sorgono ed evolvono sul web, quindi l’azienda può venire a conoscenza in maniera rapida dei bisogni dei propri clienti, che sono in continua evoluzione, ed usare tali informazioni per agire oculatamente sulle leve del marketing.
L’idea è semplice e valida, ma la sua implementazione lo è molto meno. La complessità di tale procedura è notevole (l’estrazione di dati consistenti dal web richiede tempo e competenze specifiche), così come il costo che grava sulle spalle dell’azienda.
Qaule potrà mai essere la soluzione a questo problema?
Il Web Semantico sembra sopperire perfettamente le carenze tecnologiche che rendevano il Web Warehousing complesso e costoso. Il Semantic Web, come abbiamo già visto, è un nuovo modo di concepire il web, in cui le informazioni sono comprensibili alle macchine (machine understandable) e tali capacità possono venire in aiuto alle aziende pronte a cogliere le opportunità.
Attraverso l’uso di agenti semantici, reperire le informazioni sul web 3.0 è semplice ed economico, e tali informazioni possono essere facilmente integrate con il Data Warehouse dotato di tecnologie semantiche, che è flessibile ed espandibile. Anche la stessa procedura di Web Mining può essere assorbita da quella di Data Mining in maniera semplice, in quanto, ribadiamolo, le interrogazioni possono essere fatte in linguaggio naturale e non sono più pre-programmate per operare su un set ben definito di dati.
È sottointeso che i processi di Data Warehousing e Web Warehousing possono essere mantenute separate.
Il Web Warehousing con strumenti semantici rappresenta quindi una risorsa a valore aggiunto per l’azienda e l’acquisizione di un vantaggio competitivo attraverso questi strumenti può portare un notevole beneficio economico che, anche in questo caso, non è calcolabile (n.d.r. è incalcolabile anche perché il vantaggio non si ottiene semplicemente avendo le informazioni migliori o più aggiornate, ma il vantaggio è proporzionale alla misura in cui l’azienda si serve di tali informazioni per intervenire sui processi aziendali al fine di migliorare la soddisfazione del cliente).
Antonio Cicirelli
Un super eroe travestito da linguaggio
Chi è XML?
XML è l’acronimo di eXstensible Markup Language, quindi ci troviamo di fronte ad un linguaggio di markup, ovvero basato sui marcatori (tag) che permettono di descrivere il contenuto del documento stesso.
Ho capito, è come l’HTML?
Bravo … a chi ha risposto di no, o almeno non proprio. HTML è si un linguaggio di markup, ma ha come scopo quello di strutturare ipertesti in modo che siano visualizzabili da un browser. Per questo esso ha una serie di tag ben definiti (<html>, <head>, <body>, etc.) che ogni browser è in grado di comprendere – o per lo meno dovrebbe esserne in grado.
E l’XML invece?
L’XML ha scopi molto differenti da quelli dell’HTML. Per questo ora poniamo l’accento sull’eXtensible della definizione.
L’insieme delle marcature utilizzabili per creare un documento XML non è predefinito come succede l’ HTML, ma è l’autore del documento a definire i tag in base alle proprie necessità.
Quindi un documento XML non è vincolato ad una specifica applicazione e non fa supposizioni su come verrà utilizzato. Esso effettua esclusivamente una strutturazione delle informazioni aggiungendo dei “dati sui dati” – meglio noti come metadati –, ovvero i tag creati ad hoc. Praticamente, un documento XML è un semplice file di testo, che possiamo creare con qualunque editor testuale e salvare con estensione .xml.
Esempio:
<?xml version="1.0" encoding="UTF-8"?> <libri> <libro titolo="I soldi fanno la felicità"> <nomeAutore>Alfio</nomeAutore> <cognomeAutore>Bardolla</cognomeAutore> <editore>Sperling & Kupfer</editore> </libro> <libro titolo="O meglio o niente"> <nomeAutore>Jim</nomeAutore> <cognomeAutore>Collins</cognomeAutore> <editore>Modadori</editore> </libro> </libri>
Come possiamo notare nell’esempio, i tag inseriti servono solo a dare un significato all’informazione contenuta, quindi non facciamo altro che descrivere dei dati. <libro>, <titolo>, <nomeAutore> sono i nostri dati sui dati, cioè i nostri metadati.
Quindi HTML usa dei tag per strutturare la visualizzazione di una pagina web, mentre XML si occupa di descrivere il suo contenuto in modo che una qualsiasi applicazione, leggendolo, riesca a capire che tipo di dati sono contenuti nel documento.
Ma io ho sentito dire che XML è un meta-linguaggio. Cosa vuol dire?
Spesso, nelle varie definizioni di XML che si trovano sul web, si parla di XML come meta-linguaggio.
Vuol dire che XML è un linguaggio usato per definire nuovi linguaggi di marcatura.
Davvero?!?
Si, la sintassi di XML è studiata in modo da permettere a chiunque di definire il proprio linguaggio di markup in base alle proprie esigenze di programmazione. Questo in virtù del fatto che XML è stato derivato dal linguaggio SGML (Standard Generalized Markup Language).
Alcuni esempi di linguaggi definiti sulla base di XML sono:
- WML, il linguaggio Wireless Markup Language usato per le connessioni senza cavo;
- CDF, il linguaggio Channel Definition Format;
- MML, il linguaggio Mathematical Markup Language.
Antonio Cicirelli
Finalmente mettiamo un po’ le mani in pasta…
Diamoci da fare e proviamo a mettere in pratica quanto visto fin’ora realizzando la nostra prima ontologia!!
Consideriamo un caso alquanto semplice e esplicativo: vogliamo realizzare una base di conoscenza che contenga le informazioni relative a libri e a prodotti multimediali.
Prima di partire ricordiamo una semplice cosa: non esiste un’unica strada corretta per modellare il nostro dominio, ma ci sono sempre vie alternative. La soluzione migliore dipende sempre dal ruolo che l’ontologia dovrà ricoprire e, soprattutto, dalla capacità di anticipare future espansioni. Inoltre il processo di creazione di una ontologia è un processo iterativo, quindi non pretendiamo che tutto sia perfetto alla prima iterazione…
Come procediamo?
Semplicemente procediamo in ordine, seguendo i passi visti nell’articolo sulle Ontologie.
FASE 1: Definizione del dominio e degli scopi dell’ontologia
Iniziamo chiediamoci:
1. Qual è specificamente il dominio della nostra ontologia?
I libri e i prodotti multimediali.
2. Per quali scopi verrà utilizzata l’ontologia?
Per la realizzazione di un portale di e-commerce di una libreria online.
3. Quali nuove informazioni si vogliono dedurre dall’ontologia?
- Quali sono i generi presenti?
- Quanto costa un prodotto?
- A quale categoria appartiene un prodotto?
- Chi è/sono l’/gli autore/i di un libro o di un prodotto multimediale?
- Quali libri o prodotti multimediali possono essere suggeriti ad un utente in base alle sue preferenze?
4. Chi utilizzerà l’ontologia?
L’amministratore del sito e gli utenti che vogliono acquistare.
FASE 2: Cercare e valutare la possibilità di usare una ontologia esistente.
Sicuramente una delle fasi più interessanti e appetibili, ma in questo caso – e solo in questo caso – la saltiamo per permetterci di realizzare in prima persona questa nostra prima ontologia.
Comunque nel nostro caso, forse, si poteva dare un’occhiatina alla DCMI Dublin Core Metadata Initiative – dublincore.org.
FASE 3: Definizione dei concetti
Si inizia elencando tutti i possibili termini relativi al dominio di conoscenza. Una possibile lista di termini potrebbe essere la seguente:
prodotto – libro – musica – film – autore – titolo – sottotitolo – genere – prezzo – editore – cd – dvd – formato – cartaceo – elettronico – giallo – romanzo – economia – psicologia – informatica – racconto – favola – fiaba – pop – rock – rap – leggera – classica – latino-americana – salsa – merengue – thriller – fantasy – avventura – romantico – durata – descrizione – utente – amministratore – cliente
Iniziamo ad estrapolare i concetti e a realizzare una gerarchia. Gli approcci (come sappiamo) possono essere di tipo top-down, bottom-up o ibrido.
Proviamo a procedere con un approccio ibrido, in modo da utilizzare sia il top-down che il bottom-up.
Innanzitutto possiamo individuare come concetto top-level quello di Prodotto:
Poi, partendo dal basso, individuiamo giallo – romanzo – economia – psicologia – informatica – racconto – favola – fiaba come concetti di bottom-level che possono essere accorpati nel concetto Letterario, che a sua volta afferisce al concetto di Genere.
E così via …
FASE 4: Definizione delle proprietà
Andiamo ora ad individuare le proprietà dei nostri concetti. Ricordiamo che abbiamo due categorie di proprietà: intrinseche ed estrinseche.
Proprietà intrinseche del concetto prodotto potrebbero essere:
- titolo
- sottotitolo
- anno
- lingua
- prezzo
Andiamo ad analizzare le proprietà intrinseche del concetto Libro, che potrebbero essere:
- pagine
- dimensioni
Mentre quelle estrinseche potrebbero essere:
- haAutore
- haGenereLetterario
- haFormato
- haEditore
che sono tutte proprietà che mettono in relazione il concetto di libro con altri concetti definiti nell’ontologia.
Antonio consiglia:
Praticamente si può procedere alla modellazione di un dominio sfruttando un diagramma E-R (entità-relazioni): le entità diventano i concetti, le relazioni diventano gli attributi estrinseci (object properties), le cardinalità delle relazioni si trasformano in vincoli di cardinalità e gli attributi, infine, diventano le proprietà intrinseche (datatype properties).
Convenzioni
Soffermiamoci un attimo sulle convenzioni riguardanti la nomenclatura: i Concetti saranno solitamente dei sostantivi scritti con l’iniziale Maiuscola, mentre le proprietà intrinseche saranno scritte in minuscolo. Per quanto riguarda i ruoli (o proprietà estrinseche) si usa la camelNotation, ovvero prima iniziale minuscole e poi Maiuscole le iniziali delle successive parole, rigorosamente tutte unite.
Al lavoro!
Passiamo ora alla pratica e implementiamo la nostra ontologia con uno degli strumenti migliori sulla piazza: OwlEd2.
Vediamo come procedere:
Inoltre, ovviamente, vi posto il file che ho realizzato (salvatelo e apritelo con Owled2 per vedere ciò che ho realizzato e per editarlo) :
Come potete vedere, questo potente strumento (OwlEd2) ci permette di ottenere un codice OWL già perfettamente strutturato e pronto per l’uso. Cosa è OWL? Beh, lo vedremo presto in uno dei prossimi articoli.
Intanto lascio a voi, come esercizio, il caricamento degli individui nella nostra prima ontologia, sempre tramite Owled2.
Ovviamente sono graditissimi commenti, suggerimenti e miglioramenti della nostra ontologia.
Aspetto impaziente le vostre numerose segnalazioni!!!
Antonio Cicirelli
Citando wikipedia, proviamo a dare una definizione di matchmaking:
Matchmaking is any process of introducing people for the purpose of marriage
Quindi ci occuperemo di matrimoni e della ricerca della dolce metà.
Ma anche no, o forse si….
Beh, sicuramente non ci occuperemo di matrimoni, ma di ricerca della dolce metà forse si… In che senso?
Come un giovane ragazzo che è alla disperata ricerca della sua dolce metà con cui condividere il resto dei suoi giorni e si trova a dover scegliere tra le tante ragazze disponibili che possano appartenere ai suoi ideali, così molti soggetti si ritrovano, negli ambiti più svariati, ad effettuare delle richieste a fronte di un vasto numero di offerte presenti nel medesimo dominio.
Quindi, in breve, il Matchmaking altro non è che un procedimento atto ad individuare le offerte che meglio rispondono, o che meglio combaciano (match-ano), anche solo in parte, con la richiesta effettuata da un soggetto e a fornire una lista di possibili offerte “candidate” ordinate in base al loro grado di match.
Parliamo invece di Matchmaking Semantico nel caso in cui le richieste (query) e le offerte (risorse) sono espresse all’interno di un dominio di conoscenza opportunamente strutturato, come per esempio un’ontologia.
Quindi per ricercare delle risorse all’interno del Web Semantico ricorreremo al processo di Matchmaking Semantico.
Categorie di match
È opportuno, a questo punto, fare delle distinzioni in base al tipo di offerta che viene individuata a fronte di una query. Parliamo di:
- Exact match, se tutte le richieste presenti nella query sono soddisfatte dall’offerta;
- Potential match, se l’offerta soddisfa solo parte delle richieste presenti nella query e non ci sono caratteristiche in conflitto;
- Partial match, se l’offerta soddisfa parte delle richieste della query e ci sono caratteristiche contrastanti tra query e risorsa;
- Full match, se l’insieme delle caratteristiche espresse nella domanda è un sottoinsieme delle caratteristiche espresse nell’offerta.
È ovvio che i match più desiderabili sono gli exact e i full, ma, come è facile intuire, nella realtà quelli più ricorrenti sono proprio i partial e soprattutto i potential.
Facciamo un breve esempio, riconducibile sempre alla nostra Ontologia (usiamo una notazione leggera per motivi di chiarezza espositiva):
R = {libro, Bompiani, Robert_Kyiosaki}
O = {libro, Bompiani, Robert_Kyiosaky, Padre_Ricco_Padre_Povero}
Notiamo che ci troviamo di fronte ad un caso di Full match, se consideriamo la R come richiesta e la O come offerta. Se invece considerassimo O come richiesta e R come offerta ci troveremmo di fronte ad un caso di Partial match.
A questo punto introduciamo una nuova distinzione riguardante i Sistemi di Matchmaking. Parliamo di :
- Sistemi di Matchmaking Simmetrici, se i risultati prodotti sono identici sia se si considera R come richiesta ed O come offerta sia se si considera il viceversa (ovvero O come richiesta ed R come offerta);
- Sistemi di Matchmaking Non-Simmetrici, se i risultati prodotti dal processo sono diversi a seconda che R ed O siano considerate rispettivamente come richiesta/offerta oppure come offerta/richiesta.
I risultati e la funzione penalty
Rimandando ad un altro articolo la trattazione formale in DL del matchmaking, proseguiamo concentrandoci sui risultati del processo.
La classificazione dei risultati ricompre, infatti, un ruolo fondamentale, se non addirittura primario, nell’ambito del matchmaking; per classificare una offerta nei confronti di una richiesta all’interno di una ontologia, definiamo la funzione penalty p(O,R,T).
Presentiamola allora:
- T è una ontologia
- R è una richiesta
- O è una offerta
- P(O,R,T) è la funzione penalty completa
La funzione penalty possiede alcune proprietà:
- Non-simmetria, quando il grado di penalty ha una direzione, per cui
p(O; R; T ) ≠ p(R; O; T ); - Indipendenza Sintattica, quando la penalty dipende esclusivamente dalla semantica di R ed O, ovvero, se all’interno di una ontologia T due risorse O1 e O2 sono identiche, a fronte di una stessa query R, le funzioni penalty sono uguali.
Riassumendo: if T ⊨ O1 ≡ O2 then p(O1; R; T ) = p(O2; R; T ).
Inoltre possiamo definire altre proprietà per la funzione penalty a seconda del tipo di match con cui abbiamo a che fare.
Per il Potential Match, la funzione penalty p⇒(O, R, T) deve essere:
- Monotonica rispetto all’implicazione, ovvero se ho due risorse O1 e O2 che sono match potenziali per la query R, e si verifica che O1 è più specifico di O2, cioè T ⊨ O1 ⊑ O2, deve succedere che p(O1; R; T ) ≤ p(O2; R; T ).
Per quanto riguarda il Partial Match, la funzione penalty p∅(O, R, T) deve essere:
- Antimonotonica rispetto all’implicazione, ovvero se ho due risorse O1 e O2 che sono match parziali per la query R, e si verifica che O1 è più specifico di O2, cioè T ⊨ O1 ⊑ O2, deve succedere che p(O1; R; T ) ≥ p(O2; R; T ).
Ma che significato ha la funzione penalty?
La funzione penalty assume significato a seconda che ci si trovi di fronte ad un partial o ad un potential match.
In particolare, per un potential match la funzione p⇒(O, R, T) valuta quanta informazione manca, non è specificata in O al fine di soddisfare completamente la richiesta R.
Per un partial match la funzione p∅(O, R, T) valuta quanto sia incompatibile la risorsa O rispetto alla query R.
Antonio Cicirelli