Il Semantic Web si candida ad essere una architettura universale dello scambio di informazione e conoscenza. Questa enorme struttura dovrà organizzarsi in maniera complessa. Quali scelte abbiamo a disposizione, quali scenari si
imporranno, quali saranno vantaggiosi? Tutte queste domande sono di grande importanza. È banale osservare che questo tipo di organizzazione non sarà stabilita in modo 'autoritario' ma si costruirà nel tempo in base alla evoluzione che il Web avrà spontameamente.
La gerarchia della semantica dovrà tenere conto di questo fatto. Ogni applicazzione, ogni intenzione di scopo applicata ad un dominio, utilizzerà una sua propria ontologia. Nasce quindi la difficoltà di collegare fra loro le varie ontologie, conciliando le diverse semantiche utilizzate. L'operazione di collegare ontologie che definiscono stessi oggetti con una semantica differente è chiamata Mapping.
Una posizione ingenua potrebbe pensare di risolvere il problema attraverso la definizione di una Ontologia Globale, questa soluzione richiederebbe un unico mapping: ogni diverso schema dovrebbe mapparsi all'ontologia globale che funzionerebbe così come una lingua universale, traduzione universale dei vari linguaggi usati. Questo tipo di soluzione, si baserebbe su transazioni di comunicazione punto a punto e comporterebbe un accordo totale, ad ogni livello, del significato della semantica usata.
Ovviamente questa visione è improponibile. L'accordo su tutto non è pensabile e qualora fosse anche raggiunto sarebbe incapace di dare risposta a quei naturali mutamenti del dominio descritto, che inevitabilmente sorgono nel tempo. La via che si seguirà sarà perciò diversa. L'idea diffusa è quella che si lavorerà su una architettura federativa.
Per capire come pssa funzionare una organizzazione federativa dobbiamo focalizzare alcuni punti. Dobbiamo chiederci:
1. Che tipo di mapping realizzeremo
2. Che tipo di transazioni
3. Che accordo deve esserci a priori (standard)
Il mapping potrà essere di due tipi automatico o manuale. Osservando lo scenario attuale con realismo possiamo dire che la soluzione che dovrebbe diffondersi mischierà queste due alternative. In una prima fase dei
tool leggeranno grosse quantità di dati e realizzeranno dei cluster, un esperto poi dovrà validare le scelte dei tool.
Per quanto riguarda le transizioni sono possibili due strade. Il problema è quando sceglere come mappare le diverse ontologie che definiscono i dati d'interscambio.
Il servizio che si occuperà delle transizioni potrebbe conoscere a priori come mapparle oppure potrebbe calcolarlo al momento. Conoscere a priori quali ontologie usare è un vantaggio per la computazione. Tuttavia permettere di eseguire dei calcoli al momento lascai spazio a computazioni sfumate. Cioè alla capacità di riportare ad una stessa struttura strutture non idendice ma che presentano un sufficiente grado di vicinanza.
Riguardo al problema degli standard, il modello è quello dell'interlingua. Alcuni gruppi di ontologie relative a domini e a scopi simili o collegati tra loro parzialmente, condividono una stessa ontologia, dette appunto interlingua. Questa soluzione permetterebbe di ridurre drasticamente il numero di mappature perché un gruppo di n di ontologie non dovrebbe essere mappate (n * n-1)/k volte ma solo una volta per ogni singola ontologia (n volte). Ogni
ontologia si mapperebbe con l'interlingua, la quale fornirebbe l'aggancio con tutte le altre. Questo tipo di soluzione possiede anche il vantaggio di essere in buon accordo con la prassi con la quale si costruisce la collaborazione tra organizzazioni. Inizialmente alcuni gruppi di organizzazioni si accordano per creare un standard condiviso, quando questo standard si consolida e afferma altre realtà si associano allo standard.
Questo modello di organizzazione dell'architettura deve esser immaginato replicato in modo iterato. Nel senso che un gruppo di interlingue possono a loro volta collegarsi ad una interlingua in grado di accordare la loro semantica.
In uno scenario come quello descritto si può capire facilemente l'importanza che avranno i Web Services. È infatti indispensabile possedere un livello che sia in grado di gestire la scelta dell'ontologia giusta a seconda dell'operazione da eseguire, del dominio da esplorare. L'uso dei Web Services per organizzare la modularità apre anche la strada ad un nuovo importantissimo problema.
È possibile avere viste di diversa profondità sulle ontologie?.
Se a certi livelli abbiamo applicazioni che debbono mappare ontologie diverse, e quindi operare delle computazioni, non sarà sempre utile considerare l'intera ontologia. Potremmo voler trattare unicamente con il livello più superficiale di questa ontologia. In pratica la definizione, la profondità con cui considerare l'albero dell'ontologia potrebbe variare in base alle necessità di computazione.
Come si calcola il livello di profondità? Bella domanda, io per ora non ho risposta.
