Il World Wide Web per come è costituito attualmente, rappresenta una
struttura scarsamente organizzata. Le nostre analisi dei documenti e delle
capacità disponibili sono basate sulla ricerca di parole chiave e sono spronate
da un uso intelligente della connettività dei documenti e dall'utilizzo di
modelli opportuni. L'intera massa di queste informazioni è ingestibile senza
potenti strumenti di supporto. In modo da mappare questo terreno in maniera più
precisa, gli agenti computazionali richiedono descrizioni dei contenuti
interpretabili dalle macchine e nuove capacità per le risorse accessibili sul
web. Queste descrizioni devono essere date in aggiunta alle versioni delle
informazioni interpretabili dall'uomo.
Il Linguaggio ontologico per il web OWL è stato progettato per fornire un
linguaggio che può essere usato per descrivere le classi e le relazioni che le
collegano e che sono inerenti ai documenti e alle applicazioni web.
Questo documento dimostra l'uso del linguaggio OWL per:
formalizzare un dominio definendo le classi e le proprietà di quelle
classi;
definire individui e asserire delle proprietà su di essi;
ragionare su queste classi e sugli individui fino al grado permesso dalla
semantica formale del linguaggio OWL.
Le sezioni sono organizzate per presentare una definizione incrementale di un
insieme di classi, proprietà e individui, cominciando dai fondamenti e andando
avanti con i componenti più complessi del linguaggio.
Stato del documento
Questo documento è stato rivisto dai Membri del W3C e da altre parti
interessate, ed è stato approvato dal Direttore come Raccomandazione
del W3C. Il ruolo del W3C nel redigere la Raccomandazione è quello di
richiamare l'attenzione sulla specifica e di promuoverne un'ampia diffusione.
Questo favorisce la funzionalità e l'interoperabilità del Web.
Il Progetto di OWL rappresentato nelle precedenti versioni di questi
documenti è stato ampiamente rivisto e soddisfa i Requisiti Tecnici del Gruppo di
Lavoro. Il Gruppo di Lavoro ha esaminato tutti i
commenti pervenuti, effettuando le modifiche come necessario. Le modifiche a
questo documento a partire dalla versione della Raccomandazione
Proposta sono elencati nel registro
dei cambiamenti.
Questa sezione descrive lo stato del Documento al momento della sua
pubblicazione. Altri documenti possono sostituire il presente documento. Una
lista delle attuali pubblicazioni del W3C e l'ultima revisione di questa
Relazione Tecnica possono essere trovate nell'Indice delle Relazioni Tecniche del W3C
all'indirizzo http://www.w3.org/TR/.
"Dimmi quali vini dovrei comprare da servire con ogni portata del
seguente menù. E comunque ricorda che non mi piace il Sauternes."
Sarebbe difficile oggigiorno costruire un Agente Web che sia in grado di
effettuare una ricerca di vini sul web che soddisfi questa richiesta. Allo
stesso modo si consideri anche la difficoltà di assegnare ad un agente software
il compito di trovare un insieme coerente di sistemazioni per un viaggio. (Per
altri casi d'uso, vedere il Documento
dei Requisiti per il Linguaggio OWL.)
Per supportare questo tipo di calcolo, è necessario andare oltre le parole
chiave e specificare il significato delle risorse descritto sul Web. Questo
strato addizionale di interpretazione cattura la semantica delle
informazioni.
Il Linguaggio per le Ontologe Web
OWL è un linguaggio per definire e istanziare Ontologie Web.
Ontologia è un termine preso in prestito dalla Filosofia che si
riferisce alla Scienza della descrizione del tipo di Entità del Mondo e di come
sono correlate tra loro. Una ontologia OWL può includere le
descrizioni delle classi, proprietà e delle loro istanze. Una
volta dato questo tipo di Ontologia, la semantica formale
di OWL specifica come derivare le sue conseguenze logiche, ovvero i fatti
che non sono presenti letteralmente nell'ontologia, ma derivati logicamente dalla semantica. Queste
derivazioni logiche possono essere basate su un singolo documento o su più
documenti distribuiti che sono stati combinati fra loro usando dei predefiniti
meccanismi
OWL.
Questo documento è un componente della descrizione dell'OWL, il Linguaggio
Ontologico del Web, che è stato prodotto dal Gruppo di Lavoro per le Ontologie
del Web della W3C (WebOnt). La Roadmap del
Documento nella sezione relativa alla Panoramica di OWL ([Overview],
1.1) descrive ognuna delle differenti parti e come queste si collegano le une
alle altre.
Una domanda che nasce spontanea quando si descrive ancora un altro standard
Web XML è "Cosa mi offre questo che non mi offrono XML e XML Schema?" Ci
sono sue risposte a questa domanda.
Una Ontologia differisce da un XML Schema nel senso che essa è una
rappresentazione della conoscenza, non un formato per i messaggi. La maggior
parte degli standard Web prodotti, consiste nella combinazione di vari formati
del messaggio e delle specifiche dei protocolli di comunicazione. Questi
formati sono stati dotati di una semantica operazionale, del tipo: "Al
ricevimento di un messaggio di OrdinediAcquisto, trasferisci
l'Ammontare in dollari dal ContodiPartenza al
ContodiDestinazione e spedisci il Prodotto." Ma le
specifiche non sono progettate per supportare alcun tipo di ragionamento al di
fuori del contesto della transazione. Per esempio non avremmo in generale un
meccanismo che sia in grado di concludere che, poichè il Prodotto è
un tipo di Chardonnay, deve anche essere necessariamente un vino bianco.
Un vantaggio delle ontologie OWL è la disponibilità di strumenti che sono
in grado di ragionare su di esse. Gli Strumenti devono fornire un
generico supporto che non deve essere specifico del particolare
dominio considerato, che dovrebbe essere invece il caso in cui una persona
dovrebbe costruire un sistema per effettuare dei ragionamenti su uno specifico
standard di uno XML Schema. Costruire un efficiente ed utile sistema di
ragionamento non è uno sforzo semplice. Costruire una ontologia è invece più
facilmente trattabile. E' una nostra aspettativa che molti gruppi si
imbarchino nella costruzione di ontologie. Essi beneficeranno di Strumenti
costruiti da terze parti, basati sulle proprietà formali del Linguaggio OWL;
strumenti che consegneranno un assortimento di caratteristiche che la maggior
parte delle organizzazioni difficilmente sarà in grado di replicare.
OWL fornisce tre sottolinguaggi di espressività crescente che sono stati
progettati per essere utilizzati da determinate comunità di sviluppatori e
utenti.
OWL Lite aiuta quegli
utenti che hanno soprattutto bisogno di una gerarchia di classificazione e
semplici restrizioni. Per esempio, benchè sostenga limitazioni della
cardinalità, esso permette soltanto valori di cardinalità di 0 o 1. Sarebbe
più semplice fornire uno strumento di supporto per OWL Lite che per i suoi
parenti più espressivi e OWL Lite fornisce un percorso di migrazione più
rapido per i thesaurus e le altre tassonomie.
OWL DL supporta quegli utenti
che vogliono il massimo dell'espressività senza perdere la completezza
computazionale (tutte le conclusioni hanno la garanzia di essere calcolabili)
e la decidibilità (tutte le computazioni finiscono in un tempo definito) dei
sistemi di ragionamento. OWL DL comprende tutti i costrutti del linguaggio OWL
con delle restrizioni come quelle sulla separazione del tipo (una classe non
può essere un individuo o una proprietà, così come una proprietà non può
essere un individuo o una classe). OWL DL si chiama così a causa della sua
corrispondenza con la logica descrittiva[Description
Logics], un campo di ricerca che ha studiato un particolare frammento
decidibile della Logica del Primo Ordine. OWL DL è stato progettato per
supportare la parte relativa alla Logica Descrittiva ed ha auspicabili
propriètà computazionali per i sistemi di ragionamento.
OWL Full è destinato agli
utenti che vogliono la massima espressività e libertà sintattica di RDF senza
le garanzie computazionali. Per esempio, in OWL Full una classe può essere
trattata contemporaneamente come una collezione di individui e come un
individuo a pieno titolo. Un'altra differenza notevole dall'OWL DL è che una
owl:DatatypeProperty può essere considerata come una
owl:InverseFunctionalProperty. OWL Full permette ad un'ontologia di
aumentare il significato di un vocabolario predefinito (RDF o OWL). E'
improbabile che qualsiasi software di ragionamento possa sostenere un
ragionamento completo per ciascuna caratteristica di OWL Full.
Ciascuno di questi sottolinguaggi è un'estensione del suo modello più
semplice, sia in ciò che può essere legalmente espresso sia in ciò che può
essere validamente concluso. Le seguenti affermazioni sono vere. Il loro opposto
no.
Ogni ontologia OWL Lite legale è un'ontologia OWL DL legale.
Ogni ontologia OWL DL legale è un'ontologia OWL Full legale.
Ogni conclusione OWL Lite valida è una conclusione OWL DL valida.
Ogni conclusione OWL DL è una conclusione OWL Full valida.
Gli sviluppatori di ontologie che adottano OWL, dovrebbero considerare quale
sottolinguaggio si addice meglio ai loro bisogni. La scelta tra OWL Lite e OWL
DL dipende dal grado di necessità degli utenti di aver bisogno delle strutture
più espressive fornite da OWL DL. I software di Ragionamento per OWL Lite
dovrebbero avere preferibilmente delle proprietà computazionali. I software di
Ragionamento per OWL DL, poichè hanno a che fare con un sottolinguaggio
decidibile, sono soggetti ad una complessità più alta nel caso pessimo. La
scelta tra OWL DL e OWL Full dipende soprattutto dal grado di necessità degli
utenti di aver bisogno degli strumenti di meta-modeling dello Schema RDF (per
es. definizione di classi di classi). In confronto ad OWL DL, quando si usa OWL
Full, il supporto di ragionamento è meno predicibile. Per maggiori informazioni
riguardo questo argomento consultare il Documento
della Semantica di OWL.
Gli utenti che passano dall'utilizzo di RDF a quello di OWL DL o di OWL Lite
devono prestare particolare attenzione, assicurandosi che il documento originale
in RDF, soddisfi le limitazioni imposte dall'OWL DL e dall'OWL Lite. I dettagli
di queste limitazioni sono descritte nell'Appendice
E delle Fonti OWL.
Quando nel seguito di questo
documento introdurremo dei costrutti che sono permessi solo in OWL DL o in OWL
FULL, li contrassegneremo con una etichetta del tipo "[OWL DL]".
In modo da fornire un consistente insieme di esempi lungo tutta la guida,
abbiamo creato un'ontologia dei vini (wine) e
dei cibi (food).
Questa è una ontologia in OWL DL. Alcune delle nostre discussioni riguarderanno
delle peculiarità di OWL Full e saranno contrassegnate distintamente.
L'ontologia dei vini e dei cibi (Wine and Food), rappresenta una modifica
sostanziale di un elemento
della libreria ontologica del DAML e ha alle spalle una lunga storia. E' stata
originariamente sviluppata da McGuinnes come un esempio
CLASSICO di Logica Descrittiva, esteso poi ad un tutorial di
Logica Descrittiva, ed esteso successivamente ad un tutorial di
ontologie.
In questo documento presentiamo gli esempi usando la sintassi RDF/XML ([RDF], 5),
assumendo che XML sia abbastanza familiare per la maggior parte dei lettori. La
sintassi delle regole di OWL è del tipo RDF/XML. Si noti che OWL è stato
progettato per ottenere la massima compatibilità con RDF e RDF Schema. I formati
XML ed RDF sono parte integrante dello standard OWL.
Tutti gli esempi presentati in questo documento sono presi dalle ontologie
contenute nella wine.rdf e
nella food.rdf,
fatta eccezione per quelle contrassegnate con il simbolo ¬ nella parte in basso a destra.
Il linguaggio OWL è un componente dell'Attivita del W3C per il Semantic Web. Questa attività si
propone lo scopo di rendere le risorse sul Web più prontamente accessibili ai
processi automatizzati, mediante l'aggiunta di informazioni riguardanti le
risorse che descrivono e forniscono i contenuti del Web. Poichè il Web Semantico
è distribuito, OWL deve permettere la raccolta di informazioni da risorse
distribuite. Questo obiettivo è parzialmente raggiunto in quanto si permette
alle ontologie di essere correlate tra loro, includendo la possibilità di
effettuare una importazione esplicita delle informazioni da altre ontologie.
Inoltre OWL effettua una assunzione di mondo aperto (OWA - Open World Assumption) cioè
assume che la descrizione delle risorse non sia confinata ad un unico file o ad
un unico obiettivo. Sebbene la classe C1 sia definita originariamente
in una ontologia O1, questa può essere estesa anche in altre ontologie. Le
conseguenze di queste nuove asserzioni circa la classe C1 sono monotone (monotonic). Le
nuove informazioni infatti non possono ritrattare le informazioni precedenti;
possono essere però contraddittorie, ma possono solo aggiungere fatti e
conseguenze e mai cancellarli.
La possibilità di queste contraddizioni è un qualcosa che il progettista di
ontologie deve bene tenere in considerazione. Ci si aspetta inoltre che gli
strumenti di supporto aiutino a rilevare questi casi.
Nell'intento di scrivere una ontologia che possa essere interpretata in
maniera non ambigua e usata da agenti software, abbiamo bisogno di una sintassi
e di una semantica formale per il linguaggio OWL. OWL può essere considerato
come una estensione semantica del vocabolario di RDF [RDF Semantics] . La semantica del
linguaggio OWL è definita nel documento OWL Web
Ontology Language Semantics and Abstract Syntax.
Prima di poter usare un insieme di termini, abbiamo bisogno di una precisa
indicazione di quali saranno i vocabolari specifici che saranno utilizzati. Un
componente iniziale standard di una ontologia include un insieme di
dichiarazioni dello spazio dei
nomi XML (XML Namespace) racchiuse in una etichetta iniziale del tipo
rdf:RDF. Questo fornisce un mezzo per interpretare in maniera non
ambigua gli identificatori e rendere il resto della presentazione dell'ontologia
molto più leggibile. Una tipica ontologia OWL comincia con una dichiarazione
dello spazio dei nomi molto simile alla seguente. Naturalmente, gli
identificatori (URIs) dell'ontologia che viene definita non saranno solitamente
riferiti all'indirizzo w3.org.
Le prime due dichiarazioni identificano lo spazio dei nomi associati con
questa ontologia. La prima indica lo spazio dei nomi di default,
specificando che i nomi utilizzati senza prefisso, si riferiranno all'ontologia
corrente. La seconda identifica lo spazio dei nomi dell'ontologia corrente con
il prefisso vin:. La terza indica l'identificatore di base (base URI)
per questo documento (vedere più avanti
). La quarta indica lo spazio dei nomi dell'ontologia di supporto dei cibi
con il prefisso food:.
La quinta dichiarazione dello spazio dei nomi indica che, in questo
documento, gli elementi che presentano un prefisso owl: devono essere
interpretati con riferimento agli oggetti derivanti dallo spazio dei nomi
all'indirizzo http://www.w3.org/2002/07/owl#. Questa è una
dichiarazione convenzionale di OWL, usata per introdurre il vocabolario
specifico del linguaggio.
OWL dipende da costrutti definiti mediante RDF, RDFS e tipi di dato di XML
Schema. In questo documento il prefisso rdf:, si riferisce alle cose
che appartengono allo spazio dei nomi all'indirizzo
http://www.w3.org/1999/02/22-rdf-syntax-ns#. Le due successive
dichiarazioni dello spazio dei nomi, indicano affermazioni simili alla
precedente e riguardanti lo spazio dei nomi dello Schema RDF (rdfs:) e
dei tipi di dato dello Schema XML (xsd:).
Come aiuto per la scrittura di indirizzi web troppo lunghi, può essere utile
fornire un insieme di definizioni di entità in una dichiarazione del tipo di
documento (DOCTYPE) che precede le definizioni dell'ontologia. I nomi definiti
dalle dichiarazioni dello spazio dei nomi hanno significato valido solo se sono
parte integrante di etichette XML (XML tags). I valori degli attributi
non sono influenzati dallo spazio dei nomi, ma in OWL facciamo
riferimento in maniera frequente agli identificatori dell'ontologia usando
proprio i suddetti valori. Possono essere scritti nella loro forma completa
espansa, per esempio
"http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#merlot". Oppure,
alternativamente, possono essere definite delle abbreviazioni mediante una
definizione con il costrutto ENTITY, ad esempio:
Dopo questa coppia di dichiarazioni di ENTITY, possiamo scrivere il valore
"&vin;merlot" e questo verrà considerato automaticamente con la sua
estensione "http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#merlot".
Per questo motivo, in modo più elegante, le dichiarazioni rdf:RDF
dello spazio dei nomi possono essere semplificate in maniera che i cambiamenti
effettuati alle dichiarazioni delle entità si propaghino consistentemente a
tutta l'ontologia.
Una volta che gli spazi dei nomi
sono stati dichiarati, normalmente includiamo una collezione di affermazioni
riguardanti l'ontologie e raggruppate sotto una etichetta owl:Ontology.
Queste etichette svolgono compiti critici molto comuni quali i commenti, il
controllo della versione e l'inclusione di altre ontologie.
Da notare che usiamo '...' per indicare che c'è del testo addizionale che è
stato omesso perchè non inerente a questo specifico esempio.
L'elemento owl:Ontology è il posto dove è possibile conservare la
maggior parte delle meta-informazioni OWL per il documento. Esso non garantisce
però che il documento descriva una ontologia nel senso tradizionale della
parola. In alcune comunità infatti le ontologie non sono composte da individui,
ma solo da classi e proprietà che definiscono un dominio. Quando si usa OWL per
descrivere una collezione di istanze di informazioni, l'etichetta
owl:Ontology può essere ncessaria per registrare la versione delle
informazioni disponibili e per importare le definizioni sulle quali è basato il
documento. Tuttavia in OWL il termine ontologia è stato ampliato per
includere anche istanze di informazioni (vedere
più avanti).
L'attributo rdf:about fornisce invece un nome o
un riferimento per l'ontologia. Quando il valore di questo attributo e nullo
(""), ovvero il caso standard, il nome dell'ontologia è l'identificatore di base
dell'elemento owl:Ontology. Tipicamente esso rappressenta
l'identificatore (URI) del documento contenente l'ontologia. Una eccezione è il
caso in cui si fa uso del costrutto xml:base che può impostare
l'identificatore di base (base URI) per un elemento, a qualcosa che sia
differente dall'identificatore del documento corrente.
rdfs:comment fornisce l'ovvia capacità di cui si ha bisogno per
commentare una ontologia.
owl:priorVersion è una etichetta standard che può essere usata per
fornire un collegamento per il sistema di controllo di versione che viene
utilizzato con le ontologie. La definizione della Versione dell'Ontologia
(Ontology versioning) sarà discussa più avanti.
owl:imports fornisce un meccanismo di stile di
inclusione. owl:imports prende un singolo argomento, identificato
dall'attributo rdf:resource.
Importare un'altra ontologia implica l'importazione dell'intero insieme di
asserzioni fornito da quella ontologia, all'interno dell'ontologia corrente. Per
permettere l'uso ottimo dell'ontologia importata, normalmente questo meccanismo
sarà accompagnato e coordinato da una dichiarazione dello spazio dei nomi. Da
notare la distinzione tra questi due meccanismi. Le dichiarazioni dello spazio
dei nomi forniscono un mezzo conveniente per riferirsi ai nomi definiti
in altre ontologie OWL. Concettualmente, owl:imports è inserito per
indicare l'intenzione di includere le asserzioni riguardanti
l'ontologia indicata. Importare un'altra ontologia O2, significa anche
importare tutte le ontologie che O2 importa.
Da notare che owl:imports non sempre può avere successo. Come ci si
potrebbe aspettare avendo a che fare con il Web Semantico, l'accesso a risorse
distribuite sul Web non può essere sempre possibile. Gli strumenti
risponderebbero infatti a questa situazione in una maniera predefinita secondo
la loro implementazione.
Da notare inoltre che per usare il vocabolario OWL non è necessario importare
l'ontologia owl.rdf. Infatti una
importazione di questo tipo non è assolutamente raccomandata.
Un insieme comune di marcatori aggiuntivi che possono essere inseriti
ragionevolmente, sono alcuni marcatori dei metadati del Dublin
Core. Il sottoinsieme include quelle che riescono a gestire tipi semplici o
stringhe come valori. Esempi includono il Titolo, l'Autore, la Descrizione,
l'Editore e la Data (vedere inoltre le dichiarazioni RDF).
Le proprietà che sono usate come annotazioni devono essere dichiarate
utilizzando la owl:AnnotationProperty. Per esempio
L'abilità dell'OWL di esprimere informazioni ontologiche riguardanti istanze
che compaiono in documenti diversi, supporta il collegamento di informazioni
provenienti da diverse fonti in una maniera schietta. La semantica sottesa
fornisce un supporto per i meccanismi di inferenza riguardo queste informazioni,
che può portare a risultati inattesi. In particolare, l'abilità di esprimere le
equivalenze mediante il costrutto owl:sameAs può essere utilizzata per
indicare il fatto che individui apparentemente differenti sono invece proprio
gli stessi. Owl:InverseFunctionalProperty può anche essere usata per
collegare gli individui tra di loro. Ad esempio, se una proprietà come
"SocialSecurityNumber" è una owl:InverseFunctionalProperty, allora due
individui separati possono essere considerati come se fossero uguali sulla base
del fatto che hanno lo stesso valore di quella proprietà. Quando gli individui
sono dichiarati identici sulla base di questi mezzi, le informazioni su di loro
provenienti da diverse fonti possono essere fuse tra loro. Questa
aggregazione può essere utilizzata per determinare dei fatti che non sono
direttamente rappresentati in nessuna delle fonti a cui fanno
riferimento.
L'Abilità del Web Semantico di collegare informazioni provenienti da fonti
multiple è una caratteristica auspicabile e potente che può essere utilizzata in
molte applicazioni.
Tuttavia, la capacità di fondere insieme informazioni provenienti da fonti
multiple, combinata con il potere inferenziale dell'OWL, può permettere un
potenziale abuso di potere. Gli utenti del linguaggio OWL dovrebbero essere
avvertiti delle potenziali implicazioni riguardanti la privacy. Dettagliate
soluzioni riguardanti la sicurezza sono state considerate al di fuori degli
obiettivi del Gruppo di Lavoro. Diverse organizzazioni stanno dotando questo
progetto di una varietà di soluzioni e di caratteristiche di sicurezza. Si
consultino ad esempio i progetti SAML e P3P.
La maggior parte degli elementi che compongono una ontologia OWL riguardano
classi, proprietà, istanze di classi e le relazioni tra queste istanze. Questa
sezione presenta i componenti essenziali del linguaggio per introdurre questi
elementi.
Molti usi di una ontologia dipendono dall'abilità di ragionare sugli
individui. Per fare ciò in modo utile ed efficiente, abbiamo bisogno di avere un
meccanismo per descrivere le classi a cui gli individui appartengono e le
proprietà che essi ereditano in virtù dell'appartenenza alle classi stesse. Noi
possiamo sempre affermare delle specifiche proprietà riguardo gli individui ma
molto della forza delle ontologie proviene dalla capacità di ragionamento basato
sulle classi.
A volte vogliamo enfatizzare la distinzione tra una classe vista come oggetto
e una classe intesa come un contenitore di elementi. Chiamiamo l'insieme degli
individui che sono membri di una classe come l'estensione di quella classe.
Il
concetto fondamentale in un dominio deve corrispondere alle classi che sono alla
radice delle varie strutture ad albero che ne rappresentano la tassonomia. Ogni
individuo nel mondo di OWL è un membro della classe owl:Thing. Per
questo motivo ogni nuova classe definita dall'utente sarà implicitamente una
sottoclasse della owl:Thing. Le classi radice di uno specifico dominio,
possono essere definite semplicemente dichiarandone il nome. OWL permette anche
la definizione della classe vuota, owl:Nothing.
Per il nostro esempio del dominio dei
vini, abbiamo creato tre classi radice: Winery(Azienda Vinicola),
Region(Regione), e ConsumableThing(Bene consumabile).
Da notare che per ora abbiamo solo detto che esistono classi a cui sono stati
dati questi nomi, mediante la sintassi 'rdf:ID='. Formalmente noi non
sappiamo niente altro di queste classi se non il fatto che esistono, grazie
all'uso di etichette che le definiscono mediante i termini comuni in lingua
Inglese. E fino a che le classi esistono solamente, potrebbero non avere nessun
membro. Per quello che sappiamo fino a questo punto, le classi potrebbero essere
anche state chiamate Thing1, Thing2, e Thing3.
E' importante ricordare che le definizioni possono essere incrementali e
distribuite. In particolare avremo molto da dire successivamente riguardo la
classe Winery.
La sintassi rdf:ID="Region" è usata per introdurre un nome come
parte della sua definizione. Questo è il costrutto rdf:ID attribute ([RDF], 7.2.22)
che risulta del tutto simile al più familiare attributo ID definito dall'XML.
All'interno di questo documento, potremmo ora riferirci alla classe
Region usando il termine #Region, ad esempio scrivendo
rdf:resource="#Region". Altre ontologie possono invece riferirvisi
usando la sua forma completa,
"http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#Region".
Un'altra forma di riferimento usa la sintassi rdf:about="#Region"
per estendere
la definizione di una risorsa. Questo è l'esempio dell'uso della sintassi
rdf:about="&ont;#x" che risulta essere un elemento critico nella
creazione di ontologie distribuite. Esso permette l'estensione delle definizioni
importate di x senza modificare il documento originale e supporta la
costruzione incrementale di una ontologia più ampia.
E' ora possibile riferirsi alle classi che abbiamo definito mediante altri
costrutti OWL usando i loro identificatori corrispondenti. Per la prima classe
all'interno di questo documento, possiamo utilizzare l'identificatore relativo,
#Winery. Anche altri documenti però, potrebbero avere bisogno di
indirizzare questa classe in maniera opportuna. Il modo più ragionevole per
farlo è quello di fornire lo spazio dei nomi e le definizioni delle entità che
includono il documento come fonte di informazioni:
Una volta date queste definizioni possiamo riferirci alla classe winery sia
usando l'etichetta XML vin:Winery sia il valore dell'attributo
&vin;Winery. Letteralmente è sempre possibile riferirsi ad una
risorsa usando il suo identificatore (URI) completo che in questo caso sarebbe
http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#Winery.
Il costruttore fondamentale per definire la tassonomia delle classi è
rdfs:subClassOf. Esso mette in relazione una classe specifica con una
più generica. Se X è una sottoclasse di Y, allora ogni istanza di X è anche una
istanza di Y. La relazione rdfs:subClassOf è inoltre una relazione
transitiva. Se X è una sottoclasse di Y e Y è una sottoclasse di Z, allora X è
anche una sottoclasse di Z.
Definiamo PotableLiquid (liquido potabile) come una sottoclasse di
ConsumableThing.
Nel mondo delle ontologie orientate al Web, entrambe queste classi possono
essere definite in una ontologia separata, che può fornire le basi per una ampia
varietà di ontologie di cibi e bevande ed in effetti è quello che è stato fatto
con l'ontologia food che
viene importata
nella ontologia dei vini (wine ontology). L'ontologia food include una serie di
classi come ad esempio Food, EdibleThing, MealCourse
e Shellfish, che non appartengono a tutti gli effetti ad una collezione
di vini, ma devono poter essere collegate alla terminologia adottata se vogliamo
effettuare dei ragionamenti utili. Cibi e vini sono infatti mutualmente
dipendenti in quanto devono soddisfare il nostro bisogno di accoppiare cibi e
vini insieme.
La definizione di una classe è suddivisa in due parti:un nome introduttivo od
un riferimento ed una serie di restrizioni. Ognuna delle espressioni che sono
contenute all'interno della definizione della classe, restringono le proprietà
che possono essere applicate alle istanze della classe definita. Le Istanze
della Classe appartengono all'intersezione delle restrizioni su di essa.
(Consultare ulteriori dettagli su owl:equivalentClass.)
Fino ad ora, abbiamo visto solo esempi in cui una nuova classe era una
sottoclasse di un'altra classe precedentemente definita.
A questo punto, è possibile creare una semplice (e
incompleta) definizione per la classe Wine. Wine è un
PotableLiquid (Il Vino è un LiquidoPotabile). Possiamo inoltre definire
la Pasta come un EdibleThing (una cosa commestibile).
L'etichetta rdfs:label fornisce un nome opzionale leggibile da parte
dell'utente umano per le classi appena definite. Strumenti di presentazione
possono farne uso. L'attributo "lang" fornisce il supporto per diverse lingue.
Una etichetta è in realtà come un commento e non contribuisce
all'interpretazione logica dell'ontologia.
La nostra definizione del vino è ancora molto incompleta. Noi non sappiamo
niente dei vini, fatta eccezione per il fatto che sono cose e liquidi potabili,
ma abbiamo comunque già abbastanza informazioni per creare e ragionare su alcuni
degli individui che appartengono alla classe.
In aggiunta alle classi, noi vogliamo essere in grado di descrivere anche i
loro membri. Normalmente pensiamo ai membri come degli individui nel nostro
universo delle cose. Un individuo è introdotto principalmente dichiarando la sua
appartenenza ad una classe.
<Region rdf:ID="CentralCoastRegion" />
Da notare che il seguente esempio ha esattamente lo stesso significato del
precedente.
rdf:type è una proprietà RDF che lega un individuo ad una classe a
cui appartiene.
Ci sono due punti principali che ora necessitano di essere chiariti. Per
prima cosa, abbiamo deciso che CentralCoastRegion (un'area specifica)
sia una membro della classe Region, la quale contiene tutte le regioni
geografiche. Come seconda cosa, non c'è nessun prerequisito nelle due parti
dell'esempio che indichi che i due elementi debbano essere necessariamente
adiacenti l'uno all'altro o anche che si trovino nello stesso file (sebbene i
nomi necessitano di essere estesi mediante un URI in questo caso). Progettiamo
le ontologie web con l'intento che esse siano distribuite. Esse possono essere
quindi importate e aumentate, creando delle ontologie derivate.
In modo da avere a disposizione altre poche classi per discutere le proprietà
introdotte nelle successive sezioni, definiamo un nuovo ramo della tassonomia,
Grape, con un individuo che denota la varietà di uva del tipo Cabernet
Sauvignon. I tipi d'uva (Grapes) sono definiti nell'ontologia food:
Ci sono importanti discussioni riguardanti la
distinzione tra una classe(Class) ed un individuo (Individual) in
OWL. Una classe è da considerarsi semplicemente come un nome e una collezione di
proprietà che descrivono un insieme di individui. Gli Individui sono i membri di
questi insiemi. Per questo motivo le classi devono corrispondere ad insiemi di
cose che naturalmente compaiono nel dominio di un discorso e gli individui
devono invece corrispondere proprio a quelle entità che possono essere
raggruppate in queste classi.
Nel costruire le ontologie, la distinzione è frequentemente vista in due
modi:
Livelli di rappresentazione: In alcuni contesti, qualcosa che può
essere considerata ovviamente come una classe, può invece essere considerata
come una istanza di qualche altra cosa. Per esempio nell'ontologia dei vini,
abbiamo la nozione di Grape, che viene considerata come l'insieme di
tutte le qualità di uva (grape varietals).
CabernetSauvingonGrape è un esempio di istanza di questa classe,
poichè denota la varietà di uva conosciuta con il nome di Cabernet Sauvignon.
Tuttavia, CabernetSauvignonGrape può essere essa stessa considerata
come una classe, cioè l'insieme di tutte le uve di tipo Cabernet Sauvignon.
Sottoclassi vs. istanze: E' veramente facile
confondere la relazione istanza-di (instance-of) con quella di sottoclasse.
Per esempio può sembrare arbitraria la scelta di rappresentare
CabernetSauvignonGrape come un individuo di una istanza di
Grape, piuttosto che una sottoclasse di Grape. Questa non è
del tutto una scelta arbitraria. La classe Grape denota l'insieme di
tutte le varietà di uva (grape varietals), e tuttavia ogni sottoclasse
di Grape deve rappresentare un sottoinsieme di queste varietà. Per
questo motivo quindi, CabernetSauvignonGrape deve essere considerato una istanza di (istance of) Grape
(Uva) e non una sua sottoclasse. Esso infatti non descrive un sottoinsieme
delle varietà di Grape (Uva) bensì è una varietà di uva.
Da notare che la stessa dimensione sorge con il trattamento della classe
Wine. La classe Wine attualmente denota l'insieme di tutte le
varietà di vino, non l'insieme delle bottiglie che qualcuno può
acquistare. In una ontologia alternativa, ogni istanza di Wine che
viene considerata nella corrente ontologia, può invece rappresentare una classe
formata da tutte le bottiglie di un vino di un determinato tipo. E' facile
immaginare un sistema informativo, come un sistema per la gestione
dell'inventario di un mercante di vini, che ha invece bisogno di considerare
bottiglie singole di vino. L'ontologia dei vini, come è stata definita fino a
questo punto, avrebbe bisogno dell'abilità aggiuntiva di trattare le classi come
istanze in modo da poter supportare questa interpretazione. Da notare che OWL
Full permette questa espressività fornendoci la possibilità di trattare una
istanza di una varietà di vino anche come una classe le quali istanze sono
bottiglie di vino.
Allo stesso modo, i vini prodotti dalle aziende vinicole in anni specifici
sono considerati d'annata (vintages). Per riuscire a rappresentare il concetto
di annata (vintage), dobbiamo determinare dove, nella corrente ontologia, il
termine può essere inserito correttamente. Una istanza della classe
Wine, come discusso precedentemente, rappresenta una singola varietà di
vino prodotto da una particolare azienda vinicola, per esempio la
FormanChardonnay.
Aggiungendo il fatto che il vino prodotto nell'anno 2000 può essere
considerato d'annata (vintage)
incontriamo un ostacolo poichè non abbiamo la possibilità di rappresentare un
sottoinsieme di un predefinito individuo della classe wine. Annata (vintage) non
è una nuova varietà di vino, è uno speciale sottoinsieme del vino - quello
prodotto nell'anno 2000. Una possibile soluzione potrebbe essere quella di usare
OWL Full e trattare le istanze del vino come classi aventi delle sottoclassi ( o
sottoinsiemi) che denotano le caratteristiche dell'annata. Un'altra opzione è
quella di aggirare l'ostacolo e di considerare la classe Vintage
(annata) come una classe separata, le cui istanze hanno una relazione con i vini
che sono d'annata. Per esempio, FormanChardonnay2000 è un individuo
d'annata(vintage) con una proprietà annatadel(vintageof) il
quale valore è il Wine,FormanChardonnay. Definiremo
successivamente la classe Vintage.
Il punto della discussione è dunque che lo sviluppo di una ontologia deve
essere fermamente guidato dall'uso che se ne intende fare. Questa annotazione
inoltre sottolinea una delle maggiori differenze che sussistono tra OwL Full e
OWL DL. OWL Full permette l'uso delle classi come istanze e OWL DL non lo
permette. L'ontologia dei vini (wine ontology) è stata progettata per funzionare
in OWL DL e come risultato gli individui come FormanChardonnay non sono
simultaneamente trattati come classi.
Questo mondo di Classi e Individui potrebbe risultare abbastanza noioso se
potessimo definire solo delle tassonomie. Le Proprietà ci permettono di asserire fatti
generali riguardo i membri delle classi e di asserire fatti specifici riguardo
gli individui.
Una proprietà è una relazione binaria. Possono essere distinti due tipi di
proprietà:
datatype properties, relazioni tra
le istanze appartenenti alle classi e elementi RDF literals o tipi di dati XML
Schema
object
properties, relazioni tra istanze di due classi. Da sottolineare che il
nome object property (proprietà dell'oggetto) non è da intendersi con
riferimento al termine RDF detto rdf:object ([RDF],
5.3.4).
Quando definiamo una
proprietà, ci sono molti modi di restringere una relazione. Possono essere
specificati il dominio e l'intervallo (range). La proprietà può essere definita
come una specializzazione di una proprietà esistente (sottoproprietà). Altre
restrizioni molto più elaborate sono possibili e sono descritte più avanti.
In OWL, una sequenza di
elementi senza un esplicito operatore rappresenta una congiunzione implicita. La
proprietà madeFromGrape ha il dominio della classe Winee
un intervallo riferito a WineGrape. Ciò significa che crea una
relazione tra istanze della classe Wine e istanze della classe
WineGrape. Domini multipli indicano invece che il dominio della
proprietà è dato dall'intersezione delle classi identificate ( e la stessa cosa
vale anche per l'intervallo).
Allo stesso modo, la proprietà course(portata) lega un
Meal(pasto) ad un MealCourse (tipo di portata).
Notare che l'uso dell'intervallo e del dominio in OWL è differente dall'uso
dei tipi in un linguaggio di programmazione classico. Tra le altre cose, i tipi
sono usati per controllare la consistenza in un liguaggio di programmazione. In
OWL, un intervallo può essere usato per ricavare un tipo di dato. Per esempio,
se viene detto:
La proprietà WineDescriptor collega i vini con il loro colore e i
componenti del loro gusto, compresi la dolcezza(sweetness), la rotondità(body) e
il gusto(flavor). hasColor è una sottoproprietà della proprietà
hasWineDescriptor, con il suo intervallo circoscritto al
WineColor. La relazione rdfs:subPropertyOf in questo caso
indica che ogni cosa con una proprietà del tipo hasColor avente valore
X ha anche una proprietà hasWineDescriptor che assume il valore X.
Successivamente introdurremo la proprietà locatedIn, che collega le
cose con le regioni in cui si trovano.
Notare bene come sono definiti il dominio e l'intervallo della
locatedIn. Il dominio permette ogni cosa che può essere locata in una
regione, includendo anche le stesse regioni. Da qui si vede come la composizione
transitiva
in questa relazione essenzialmente crea una rete geografica di sottoregioni e
cose. Le cose che non possono contenere niente possono essere di qualsiasi
classe mentre quelle che contengono qualcosa devono necessariamente essere di
tipo regione.
E' ora possibile espandere la definizione di Wine per includere la
nozione che un vino è fatto da almeno una WineGrape. Come per la
definizione delle proprietà, le definizioni della classe hanno molte sottoparti
che sono implicitamente connesse tra loro.
definisce una classe senza nome che rappresenta l'insieme delle cose con
almeno una proprietà madeFromGrape. Chiamiamo questo tipo classi
anonime. Includere questa restrizione nel
corpo della definizione della classe Wine vuol dire che le cose che
sono vini, sono anche membri della classe anonima. Ciò significa che ogni
individuo della classe Wine deve partecipare almeno ad una relazione di tipo
madeFromGrape.
Noi distinguiamo le proprietà a seconda che esse mettano in relazione
individui con individui (object properties) o individui con tipi di dati
(datatype properties). Le proprietà sui tipi di dati, possono essere applicate a
semplici letterali RDF o a tipi semplici in accordo con XML Schema datatypes.
OWL usa la maggior
parte degli XML Schema datatypes predefiniti. I riferimenti a questi tipi di
dato sono da intendersi come il riferimento all'identificatore (URI) per quel
tipo di dato, http://www.w3.org/2001/XMLSchema. I seguenti tipi di dato
sono raccomandati per l'utilizzo con il linguaggio OWL:
xsd:string
xsd:normalizedString
xsd:boolean
xsd:decimal
xsd:float
xsd:double
xsd:integer
xsd:nonNegativeInteger
xsd:positiveInteger
xsd:nonPositiveInteger
xsd:negativeInteger
xsd:long
xsd:int
xsd:short
xsd:byte
xsd:unsignedLong
xsd:unsignedInt
xsd:unsignedShort
xsd:unsignedByte
xsd:hexBinary
xsd:base64Binary
xsd:dateTime
xsd:time
xsd:date
xsd:gYearMonth
xsd:gYear
xsd:gMonthDay
xsd:gDay
xsd:gMonth
xsd:anyURI
xsd:token
xsd:language
xsd:NMTOKEN
xsd:Name
xsd:NCName
I tipi di dato sopra elencati, unitamente agli rdfs:Literal, formano
i tipi di dato predefiniti del linguaggio OWL. Tutti i reasoner per il
linguaggio OWL hanno come requisito fondamentale quello si supportare i tipi di
dato xsd:integer e xsd:string.
Altri tipi di dato predefiniti possono essere usati in OWL Full ma con alcuni
accorgimenti descritti nella documentazione OWL
Semantics and Abstract Syntax.
La proprietà yearValue relaziona il VintageYear ad un
valore positivo intero. Descriveremo la proprietà hasVintageYear, che
relaziona un Vintage con un VintageYearsotto.
La OWL
Reference ([Reference], 6.2) descrive l'uso dei costrutti
owl:oneOf, rdf:List e rdf:rest per definire i tipi di
dato enumerati. L'esempio mostra come costruire la
owl:DatatypeProperty, tennisGameScore, con un intervallo
uguale agli elementi della lista dei valori interi {0, 15, 30, 40}.
Questa definizione è ancora incompleta. Ci sono altri aspetti del gusto del
vino che sono definiti nell'ontologia completa. Ma i pezzi cominciano a
combaciare tra di loro. Potremmo ad esempio cominciare a ragionare riguardo
quale oggetto del menù della nostra ontologia dei cibi può essere accompagnato
da questo vino. Sappiamo dalla descrizione precedentemente mostrata che
l'azienda vinicola della Santa Cruz Mountain produce questa qualità. Poichè è un
CabernetSauvignon (Vedere anche wine.rdf),
sappiamo che è un vino rosso, asciutto.
Le proprietà dei tipi di dato possono essere aggiunte agli individui in
maniera molto simile. Sotto viene riportata una istanza di VintageYear
che viene collegata ad uno specifico valore di tipo
&xsd:positiveInteger.
Le seguenti sezioni descrivono i meccanismi usati per specificare
ulteriormente le proprietà. E' possibile specificare le caratteristiche
di una proprietà, che forniscono un meccanismo molto potente per agevolare dei
ragionamenti su una proprietà.
3.3.1. Proprietà
Transitiva (TransitiveProperty)
Se una proprietà P è specificata come proprietà transitiva, allora per ogni
X,Y e Z si ha logicamente:
Poichè la SantaCruzMountainsRegion è locatedIn(contenuta
nella) CaliforniaRegion, allora deve anche essere
locatedIn(contenuta nella) USRegion, poichè locatedIn
è una proprietà transitiva.
3.3.2. Proprietà
Simmetrica (SymmetricProperty)
Se una proprietà P viene definita simmetrica, allora per ogni x e y abbiamo:
P(x,y) se e solo se P(y,x)
La proprietà adjacentRegion(regione adiacente) è simmetrica, mentre
la locatedIn non lo è. Per essere più precisi, la proprietà
locatedIn non viene intesa come simmetrica. Niente nella ontologia dei
vini, al momento, impedisce che essa sia da considerarsi come simmetrica.
La MendocinoRegion è adiacente alla SonomaRegion e
viceversa. La MendocinoRegion è contenuta all'interno della
CaliforniaRegion ma non è vero il contrario.
3.3.3. Proprietà
Funzionale (FunctionalProperty)
Se una proprietà P viene definita come funzionale, allora per tutte le x, y e
z:
P(x,y) e P(x,z) implicano che y = z
Nella nostra ontologia dei vini, la proprietà hasVintageYear è una
proprietà funzionale. Un vino ha un unico anno di invecchiamento. Ciò significa
che un singolo indidividuo della classe Vintage(annata) può essere
associato solamente ad un singolo anno usando la proprietà
hasVintageYear. Non è però un requisito della proprietà
owl:FunctionalProperty che tutti gli elementi del dominio abbiamo un
valore. Per ulteriori approfondimenti controllare la discussione riguardo la
cardinalità della proprietà Vintage.
Se una proprietà P1, viene definita come la proprietà owl:inverseOf
(inversa di) P2, allora per tutte le x e y abbiamo:
P1(x,y) se e solo se P2(y,x)
Da notare che la sintassi della proprietà owl:inverseOf prende un
nome di una proprietà come argomento. A se e solo se B significa (A
implica B) e (B implica A).
Gli individui appartenenti alla classe Wine hanno dei produttori,
che nella definizione della classe Wine sono ristretti agli individui
della classe Winery(Azienda Vinicola). Allora ogni
Winery(Azienda Vinicola) produce l'insieme dei vini che la identificano
come un'azienda produttrice.
3.3.5.
Proprietà Funzionale Inversa (InverseFunctionalProperty)
Se una proprietà P, viene definita come una Proprietà Funzionale Inversa,
allora per tutte le x, y e z abbiamo:
P(y,x) e P(z,x) implica y = z
Da notare che la proprietà producesWine(produce vino) nella sezione
precedente è una funzionale inversa. La ragione di questa decisione è che
l'inversa di una proprietà funzionale deve necessariamente essere una proprietà
funzionale inversa. Potremmo aver definito la proprietà hasMaker(ha un
produttore) e la proprietà producesWine(produce vino) come specificato
di seguito ed ottenere lo stesso risultato dell'esempio precedente.
Si pensi agli elementi nell'intervallo di riferimento della proprietà
funzionale inversa come se definissero una chiave primaria secondo l'idea delle
basi di dati. owl:InverseFunctional implica che gli elementi
dell'intervallo di riferimento forniscano un identificatore unico per ogni
elemento del dominio.
In OWL Full, possiamo definire una
DatatypeProperty come una proprietà funzionale inversa. Questo ci
permette di identificare una stringa come una chiave primaria. In OWL DL i
letterali sono disgiunti dalla classe owl:Thing e questo è il motivo per cui in
OWL DL non è possibile definire come proprietà
InverseFunctional(funzionaleInversa) una DatatypeProperty.
3.4. Restrizioni sulle proprietà
In aggiunta alle caratteristiche specificate sulle
proprietà, è possibile limitare ulteriormente l'intervallo dei valori che può
assumere una proprietà in specifici contesti, in differenti maniere. Otteniamo
questo mediante le property restrictions (restrizioni sulle proprietà).
Le differenti forme descritte di seguito, possono essere usate solo all'interno
del contesto di un costrutto definito owl:Restriction. Il costrutto
owl:onProperty indica la proprietà restrittiva.
3.4.1. allValuesFrom,
someValuesFrom
Abbiamo già visto un modo per restringere i tipi di elementi che
costituiscono una proprietà. I meccanismi applicati erano di tipo
globale, nel senso che essi si applicavano a tutte le istanze della
proprietà. Questi due prossimi meccanismi invece, allValuesFrom e
someValuesFrom, sono locali ovvero si applicano solo alla
classe in cui sono definiti.
La
restrizione owl:allValuesFrom richiede che per ogni istanza della
classe che ha delle istanze della specifica proprietà, i valori della proprietà
devono essere tutti membri appartenenti alla classe indicata nella clausola
della owl:allValuesFrom.
Il produttore di un Wine(vino) deve essere una
Winery(Azienda Vinicola). La restrizione allValuesFrom è
imposta solo sulla proprietà hasMaker(ha un produttore) di
questa classe Wine(vino). I produttori di Cheese(formaggi) non
sono infatti limitati da questa restrizione locale.
La proprietà
owl:someValuesFrom è simile. Se rimpiazzassimo la proprietà
owl:allValuesFrom con la owl:someValuesFrom nell'esempio
sopra, significherebbe che almeno uno individuo delle proprietà
hasMaker(ha un produttore) di un Wine deve indicare un
individuo che deve appartenere alla classe Winery(Azienda Vinicola).
La differenza tra queste due formulazioni è la differenza che sussite tra i
due quantificatori universale ed esistenziale.
Relazione
Implicazioni
allValuesFrom
Per tutti i vini, se hanno delle aziende produttrici, tutti i
produttori sono delle aziende vinicole.
someValuesFrom
Per tutti i vini, essi hanno almeno un produttore che è un'azienda
vinicola.
La prima formulazione non richiede che un vino debba avere un produttore;
dice solo che se ne ha uno o più, devono essere tutti delle aziende vinicole. La
seconda formulazione invece richiede che ci sia almeno un produttore che sia una
azienda vinicola ma possono anche esserci altri produttori che non siano aziende
vinicole.
Abbiamo già visto alcuni esempi di restrizione della
cardinalità. Per essere più specifici, sono state tutte delle asserzioni fatte
riguardo la cardinalità minima. Ancora più preciso e ampio è l'elemento
owl:cardinality, che permette di specificare esattamente il
numero di elementi in una relazione. Per esempio, specifichiamo la classe
Vintage(annata) come una classe che ha esattamente un
VintageYear (Anno di invecchiamento).
Abbiamo specificato la hasVintageYear(ha un anno di invecchiamento)
come una proprietà funzionale, che corrisponde anche a dire che ogni
Vintage(annata) ha al massimo un solo VintageYear(anno di invecchiamento).
Questo tipo di applicazione sulla proprietà Vintage(annata) usando le
restrizioni sulla cardinalità, asserisce qualcosa di più forte, ovvero che
ogniVintage ha esattamente uno ed un solo
VintageYear.
Espressioni della cardinalità con valori limitati a
0 o 1, fanno parte delle definizioni in OWL Lite. Questo permette all'utente di
definire 'almeno uno', 'non più di uno', ed 'esattamente uno'. Valori interi
positivi che non siano 0 o 1 sono permessi invece in OWL DL. Il costrutto
owl:maxCardinality può essere usato per specificare un limite
superiore. Il costrutto owl:minCardinality può essere invece
usato per specificare un limite inferiore. Se combinati fra loro,
possono essere usati per specificare il limite dell'intervallo numerico di
valori che rappresentano la cardinalità della proprietà.
Il costrutto hasValue ci
permette di specificare delle classi sulla base dell'esistenza di
particolari valori della proprietà. Tuttavia, un individuo sarà un
membro di tale classe se almeno uno dei valori della sua proprietà è
uguale a quello assunto dalla clausola hasValue.
Qui dichiariamo che tutti i vini di tipo Burgundy sono secchi. Ciò
significa che le loro proprietà hasSugar(hanno grado zucchero) devono
avere almeno un valore che è uguale a Dry(Secco).
Come per la allValuesFrom e la someValuesFrom, questa è una
restrizione locale. Essa è valida solo per la proprietà hasSugar
applicata alla classe Burgundy.
Affinchè le ontologie abbiano il massimo impatto, esse hanno bisogno di
essere ampiamente condivise. In modo da minimizzare lo sforzo intellettuale
impiegato nello sviluppo di una ontologia, esse hanno bisogno di poter essere
riutilizzate. Nel migliore di tutti i mondi possibili devono essere costituite
dalla composizione di più ontologie. Per esempio, si può adottare una ontologia
che identifica il concetto di data da una sorgente e il concetto di locazione
fisica da un'altra e poi si può estendere la nozione di locazione includendo il
periodo di tempo durante il quale viene mantenuta.
E' importante realizzare che la maggior parte dello sforzo dello sviluppo di
una ontologia è rivolto all'aggancio tra le classi e le proprietà in un modo che
deve massimizzare le implicazioni ottenibili. Vogliamo dunque che delle semplici
asserzioni sull'appartenenza ad una classe abbiano ampie ed utili implicazioni.
Questa è la parte più difficile dello sviluppo di una ontologia. Se si riesce a
trovare una ontologia che è stata già sottoposta ad un ampio uso e differenti
revisioni, ha senso il fatto di adottarla.
Sarebbe una sfida molto ardua quella di combinare tra loro un insieme di
ontologie. Uno strumento di supporto dovrebbe quindi fornire un valido aiuto per
mantenerne la consistenza.
Per legare tra loro un insieme di ontologie predefinite in modo da comporne
una terza, è frequentemente utile il fatto di essere in grado di indicare che
una particolare classe o una proprietà in una ontologia sia equivalente ad una
classe o ad una proprietà in una seconda ontologia. Questa capacità deve essere
usata con molta attenzione. Se le ontologie una volta combinate tra loro sono
contraddittorie, ("Tutte le A sono B" contro "Tutte le A NON sono B") non ci
sarà nessuna estensione (nessun individuo nè relazione utile) che soddisferà la
combinazione risultante.
Nell'ontologia dei cibi vogliamo fare in modo di
collegare le caratteristiche dei vini presenti nelle descrizioni delle portate
dei pasti, con l'ontologia dei vini. Una maniera di ottenere questa cosa, può
essere il definire una classe nell'ontologia dei cibi (&food;Wine) e poi
dichiararla equivalente alla classe esistente nei vini, presente nell'ontologia
specifica.
La proprietà owl:equivalentClass è usata per indicare che due classi
hanno precisamente le stesse istanze. Da notare che in OWL DL, le classi
denotano semplicemente insiemi di individui e non sono individui esse stesse. In
OWL Full tuttavia, possiamo usare la proprietà owl:sameAs
tra due classi per indicare che esse sono identiche sotto tutti gli aspetti.
Naturalmente l'esempio sopra è qualcosa di ridondante, poichè noi possiamo
sempre usare la &vin;Wine ogni volta in cui vogliamo usare la
classe #Wine ed ottenere lo stesso risultato senza effettuare nessuna
ridefinizione. Un caso più interessante potrebbe essere quello in cui dipendiamo
dall'uso di due ontologie sviluppate separatamente e in cui si nota che esse
usano gli identificatori URI O1:foo e O2:bar per riferirsi
alla stessa classe. La proprietà owl:equivalentClass può essere usata
per far collassare queste definizioni tra loro in modo che le derivazioni
ottenute dalle due ontologie siano effettivamente combinate fra loro.
Abbiamo già visto che le espressioni delle classi possono essere il bersaglio
dei costrutti rdfs:subClassOf. Esse possono però anche essere bersaglio
di un altro costrutto cioè di owl:equivalentClass. Di nuovo, questo
evita il bisogno di ripetere i nomi dell'espressione per ogni classe e fornisce
una potente capacità di definizione basata sul soddisfacimento di una proprietà.
Le TexasThings(oggetti Texani) sono esattamente quelle cose
che si trovano nella regione del Texas. In questo caso, la differenza tra l'uso
della owl:equivalentClass e della rdfs:subClassOf consiste
nella differenza tra una condizione necessaria e una condizione necessaria e
sufficiente. Con il subClassOf, le cose che si trovano in Texas non
sono necessariamente TexasThings(oggetti Texani). Ma, usando invece
owl:equivalentClass, se qualcosa si trova in Texas, allora deve
necessariamente essere inclusa all'interno della classe di
TexasThings(oggetti Texani).
Relazioni
Implicazioni
subClassOf
TexasThings(x) implica locatedIn(x,y) e TexasRegion(y)
equivalentClass
TexasThings(x) implica locatedIn(x,y) e
TexasRegion(y) locatedIn(x,y) e TexasRegion(y) implica
TexasThings(x)
Per collegare fra loro le
proprietà in maniera simile usiamo invece la proprietà
owl:equivalentProperty.
Questo meccanismo è simile a quello usato per le classi, ma dichiara invece
che sono identici i due individui a cui fa riferimento. Un esempio potrebbe
essere:
Questo esempio non ha una grande utilità. Da quello che abbiamo scritto
infatti, impariamo solamente che Mike apprezza dei vini locali che non sono
costosi. Un uso più tipico della proprietà sameAs potrebbe invece
essere quello di uguagliare tra loro individui definiti in differenti documenti,
durante la parte di unificazione delle due ontologie.
Questo mette in risalto un punto importante. OWL non ha una assunzione di
nome unico (unique name
assumption). Significa quindi che se due nomi sono differenti, non è detto che
debbano riferirsi a differenti individui.
Nell'esempio precedente, abbiamo asserito l'identità tra due nomi
distinti. Ma è anche possibile riuscire a ricavare questo tipo di identità senza
doverla specificare precedentemente. Si ricordino le implicazioni che possono
essere derivate da una proprietà funzionale. Detto infatti che la proprietà
hasMaker è funzionale, le seguenti affermazioni non necessariamente
portano ad un conflitto.
Se queste non portano ad un conflitto con altre informazioni nella nostra
ontologia, semplicemente significa che Bancroft = Beringer.
Da sottolineare che usando la sameAs per uguagliare due classi
non è lo stesso che uguagliarle con il costrutto
equivalentClass; questo porta ad interpretare le classi come individui
ed è dunque sufficiente classificare una ontologia mediante OWL Full. In OWL
Full la proprietà sameAs può essere usata per uguagliare ogni cosa: una
classe ed un individuo, una proprietà ed una classe, etc., e fa in modo da
considerare entrambi gli argomenti come individui.
Questo è uno dei modi per asserire che questi tre valori sono mutuamente
distinti tra loro. Ci saranno dei casi in cui sarà importante assicurare la
distinzione di queste identità. Senza queste distinzioni infatti, noi potremmo
descrivere un vino che sia contemporaneamente Dry(secco) e
Sweet(dolce). Abbiamo stabilito che la proprietà hasSugar
applicata ad un vino, non abbia più di un valore. Se commettiamo un errore e
affermiamo che un vino è sia Dry(secco) sia Sweet(dolce),
senza definire l'elemento differentFrom come sopra, questo
implicherebbe che Dry(secco) e Sweet(dolce) siano la stessa
cosa. Imponendo invece l'uso degli elementi come nell'esempio precedente,
otterremo invece una contraddizione.
Esiste un altro meccanismo più conveniente per la
definizione di un insieme di individui mutuamente distinti. Il seguente esempio
afferma che Red(rosso), White(bianco) e Rose(rosato)
sono distinti a coppie.
Da notare che il costrutto owl:distinctMembers può essere usato
solamente in combinazione con il costrutto owl:AllDifferent.
Nell'ontologia dei vini noi forniamo una asserzione del tipo
owl:AllDifferent per ognuno dei WineDescriptor(descrittori dei
vini). Affermiamo inoltre che tutte le Winery(Aziende Vinicole) sono
differenti fra di loro. Se vogliamo aggiungere un'altra Azienda Vinicola in
un'altra ontologia e affermare che è disgiunta da tutte quelle che sono state
già definite, noi dovremmo effettuare una operazione di taglia e incolla sulla
asserzione originale owl:AllDifferent e aggiungere il nuovo produttore
nella lista. Non c'è una maniera più semplice di estendere una collezione del
tipo owl:AllDifferent in OWL DL. In OWL Full, usando le triple RDF e i
costrutti rdf:List, sono possibili anche altri approcci.
OWL fornisce altri costruttori addizionali per formare le classi. Questi
costruttori possono essere usati per creare le cosiddette class
expressions(espressioni sulle classi). OWL supporta l'insieme di base delle
operazioni sugli insiemi conosciute come unione, intersezione e complemento.
Esse sono chiamate rispettivamente owl:unionOf,
owl:intersectionOf e owl:complementOf. Inoltre le classi
possono anche essere enumerate. Le estensioni di una classe possono
essere date esplicitamente mediante il costruttore oneOf. Ed è anche
possibile affermare che le estensioni delle classi devono essere disgiunte.
Da notare che le espressioni di classe possono essere annidate tra di loro
senza che ci sia bisogno di creare un nome per ogni classe intermedia. Questo
permette l'uso di operatori di insieme per la costruzione di classi complesse da
classi anonime o da classi con eventuali valori di restrizione.
Da ricordare che le estensioni di una classe OWL class sono degli insiemi
composti dagli individui che sono membri di quella classe. OWL fornisce i mezzi
per manipolare le estensioni di una classe usando gli operatori base di insieme.
Le classi costruite usando le operazioni di insieme sono piuttosto uguali
alle definizioni che abbiamo visto fino a questo momento. I membri della classe
sono completamente specificati dall'operatore di insieme. La costruzione
effettuata nell'esempio precedente stabilisce che il WhiteWine(Vino
Bianco) è esattamente l'intersezione della classe Wine(Vino)
con l'insieme delle cose che sono di colore bianco. Ciò significa che se
qualcosa è bianco ed è un vino, allora è necessariamente una istanza della
classe WhiteWine(Vino Bianco). Senza questo tipo di definizione noi
possiamo sapere solo che i vini bianchi sono vini e bianchi, ma non il
viceversa. Questo è uno strumento importante per classificare gli individui. (Si
noti che 'rdf:parseType="Collection"' è un elemento sintattico necessario.)
Qui definiamo il Burgundy per includere esattamente quei vini che
hanno almeno una relazione di tipo locatedIn(contenuto in) con la
regione della Bourgogne. Noi avremmo potuto dichiarare una nuova classe
ThingsFromBourgogneRegion(cose provenienti dalla regione della
Bourgogne) e avremmo potuto usarla come una classe nel costrutto
owl:intersectionOf. Dato che non usiamo da nessuna altra parte la
ThingsFromBourgogneRegion, la dichiarazione che abbiamo definito sopra
è più corta, più chiara e non richiede la creazione di un nome apposito.
Infine, la classe WhiteBurgundy è esattamente l'intersezione dei
vini e dei Burgundies. I Burgundies al contrario, possono essere considerati
come quelli che sono cresciuti in Francia e che sono vini secchi. In accordo con
quanto stabilito, tutti gli individui che sono vini e che incontrano questi
criteri, sono parte dell'estensione della classe detta WhiteBurgundy.
Questo stabilisce che le istanze di Fruit(Frutta) sono un
sottoinsieme dell'intersezione di frutta dolce e non dolce, che ci
aspettiamo sia in effetti l'insieme vuoto.
Il costrutto
complementOf seleziona tutti gli individui del dominio di interesse che
non appartengono ad una certa classe. Solitamente questo si riferisce ad un
insieme veramente grande di individui:
La classe delle NonConsumableThing(cose non commestibili) include
tra i suoi membri tutti gli individui che non appartengono all'estensione delle
ConsumableThing(cose commestibili). Questo insieme include tutti i
Wine(Vini),le Region(Regioni), etc. E' letteralmente l'insieme
di differenza tra la classe owl:Thing e la classe
ConsumableThing. Tuttavia, un tipico modo di uso del
complementOf è in combinazione con altri operatori di insieme:
OWL fornisce i mezzi per specificare una classe mediante l'enumerazione
diretta dei suoi membri. Questo si ottiene mediante il costrutto oneOf.
Da notare che questa definizione specifica completamente l'estensione della
classe in modo che nessun altro individuo possa essere dichiarato come
appartenente alla classe.
Il seguente esempio definisce una classe
WineColor(Colore del Vino) i cui membri sono gli individui
White(Bianco), Rose(Rosato) e Red(Rosso).
La prima cosa che deve essere messa in evidenza a questo punto, è che nessun
altro individuo può essere un valido WineColor poichè la classe è stata
definita mediante l'enumerazione.
Ogni elemento del costrutto oneOf deve essere un individuo
dichiarato validamente. Un individuo deve appartenere a qualche classe.
Nell'esempio precedente ogni individuo è riferito mediante il suo nome. Noi
usiamo la classe owl:Thing come un semplice espediente per introdurre
il riferimento. Alternativamente noi potremmo aver fatto riferimento agli
elementi dell'insieme in accordo al loro tipo specifico, WineColor,
come di seguito:
La disgiunzione di un
insieme di classi può essere espressa usando il costrutto
owl:disjointWith. Esso garantisce che un individuo che è membro di una
classe non può essere contemporaneamente una istanza di un'altra specifica
classe:
L'esempio precedente della Pasta, dimostra l'uso di classi disgiunte
multiple. Da notare che in questo caso si afferma che la Pasta è
disgiunta da tutte queste altre classi. Non afferma, ad esempio, che la
Meat(Carne) e la Fruit(Frutta) sono disgiunte. Per riuscire ad
asserire che un insieme di classi è mutuamente disgiunto, deve essere dichiarata
una asserzione owl:disjointWith per ogni coppia di classi.
Un requisito comune è quello di definire una classe come l'unione di un
insieme di sottoclassi mutuamente disgiunte.
In questo esempio definiamo la classe Fruit(Frutta) esattamente come
l'unione della SweetFruit(Frutta Dolce) e della
NonSweetFruit(Frutta non dolce). E sappiamo inoltre che queste
sottoclassi partizionano esattamente la classe Fruit in due distinte
sottoclassi in quanto sono tra di loro disgiunte. Non appena il numero di classi
mutuamente disgiunte cresce, il numero delle asserzioni sulle disgiunzioni
cresce proporzionalmente secondo n2. Tuttavia nei casi d'uso che
abbiamo visto sino ad ora, n è tipicamente piccolo.
Quando n tende a diventare elevato, approcci alternativi possono essere usati
per evitare la crescita quadratica del numero di asserzioni. Un metodo di questo
tipo è illustrato nella OWL
test suite
Il metodo illustrato funziona in questo modo. Descriviamo una classe genitore
i quali elementi hanno una proprietà con cardinalità uguale a uno. Ciò significa
che ogni istanza deve avere uno ed un solo valore per questa proprietà.
Successivamente, per ogni sottoclasse della classe genitore, richiediamo che le
sue istanze debbano avere necessariamente un unico valore particolare per la
proprietà. In questo modo quindi, nessuna delle sottoclassi distinte può avere
dei membri in comune con le altre.
6. Definizione della Versione dell'Ontologia
Le Ontologie sono come il
software; esse vengono mantenute di continuo e quindi possono cambiare nel
tempo. All'interno di un elemento owl:Ontology (come discusso sopra),
è possibile collegarsi ad una precedente versione dell'ontologia che si sta
definendo. La proprietà owl:priorVersion è usata per fornire questo
tipo di collegamento e può essere anche usata per tracciare cronologicamente le
diverse versioni di una ontologia.
L'ontologia indicata è una versione precedente dell'ontologia che si sta
definendo.
Le diverse versioni di una
ontologia possono non essere compatibili tra di loro. Per esempio, una
precedente versione di una ontologia, può contenere delle affermazioni che
contraddicono la versione corrente. All'interno dell'elemento
owl:Ontology, noi usiamo delle marcature come
owl:backwardCompatibleWith e owl:incompatibleWith per indicare
la compatibilità o la mancanza di compatibilità con le precedenti versioni
dell'ontologia. Se il marcatore owl:backwardCompatibleWith non è
dichiarato, allora la compatibilità non deve essere assunta implicitamente. In aggiunta il marcatore
owl:versionInfo fornisce un aggancio adatto ai sistemi che effettuano
il controllo delle versioni. In opposizione ai tre precedenti marcatori,
l'oggetto owl:versionInfo è un letterale e può essere usato per fornire
delle annotazioni sulle classi e sulle proprietà in aggiunta alle ontologie.
Per differenti motivi,
effettuare la traccia delle versioni in maniera altamente granulare su una
intera ontologia non è abbastanza. I manutentori possono voler mantenere
informazioni sulla versione per le classi, le proprietà e gli individui e anche
questo potrebbe non essere sufficiente. La natura incrementale delle espressioni
delle classi in OWL, implica che una ontologia può aggiungere delle restrizioni
su una classe definita in un'altra ontologia e anche le stesse restrizioni
possono aver bisogno di informazioni relative alla versione.
OWL Full fornisce la potenza espressiva per effettuare ogni sorta di
asserzione su una classe ad esempio, significa che una istanza di un'altra
classe o la classe stessa (e non le sue istanze), può avere una proprietà e un
valore per quella proprietà. Questo ambiente può essere utilizzato per costruire
una ontologia di classi e di proprietà per il tracciamento delle informazioni
sulla versione. Lo spazio dei nomi in OWL include due classi predefinite che
possono essere usate per questo scopo: owl:DeprecatedClass e
owl:DeprecatedProperty. Esse sono utilizzate per indicare che la classe
o la proprietà probabilmente cambieranno in maniera incompatibile nelle versioni
future:
E' importante notare che la owl:DeprecatedClass e la
owl:DeprecatedProperty non sono dotate di una semantica aggiuntiva e
spetta agli sviluppatori di strumenti e agli utenti di OWL di assicurarsi che
siano effettivamente utilizzate nella maniera che corretta.
Una volta che una ontologia di dominio sia diventata disponibile, un largo
numero di applicazioni possono essere sviluppate per sfruttarla. In questa
sezione descriviamo alcuni esempi di uso nel dominio dei vini.
Oggigiorno esistono numerosi siti che si definiscono portali dei vini. Google
ad esempio, fornisce 152,000 riferimenti per la richiesta "wine portal"(Portali
del Vino). Uno dei primi risultati della ricerca, un sito chiamato "Wine-Portal.com", fornisce l'accesso a
diversi siti. Molti siti che pretendono di essere definiti come Portali del Vino
sono più che altro siti informativi. Per esempio il primo sito consigliato dal
wine-portal.com, chiamato 'cork cuisine' (www.corkcuisine.com/), fornisce
informazioni riguardo l'accoppiamento dei vini e dei cibi, dei vini da regalare,
etc.
Continuando a controllare le diverse aree divise per argomento, si possono
trovare collezioni di pagine contenenti informazioni e, qualche volta, alcuni
servizi correlati con quell'argomento. Per esempio, 'accessori e regali'
contiene informazioni su cosa cercare quando si comprano dei vini particolari e
contiene inoltre un numero cospicuo di rivenditori online. Un'altra delle
macroaree chiamata "shopping" (acquisti) ha una sottoarea chiamata 'wine
shopping'(acquisto di vini) nella quale gli utenti possono trovare dei negozi
online (o indirizzi di 'street shopping' - negozi classici) classificati e
organizzati per regione. Questi due siti sono solo due dei molti esempi che oggi
sono rappresentativi della nozione generale di Portale del Vino che forniscono
una collezione di informazioni e di servizi collegati con la particolare area di
riferimento.
Guardando questi siti più nel dettaglio, non è chiaro fino a che punto essi
dipendano oggi dalle ontologie. Per esempio, guardando il codice html delle
pagine, non si rivela l'evidenza di un uso di tipo ontologico. Tuttavia è anche
chiaro che i siti che sono in grado di sfruttare le ontologie hanno alcune
ontologie dei vini a disposizione.
Un semplice uso che si può fare delle ontologie nei portali è quello realtivo
all'organizzazione e alla navigazione. L'elenco delle categorie sopra nominate,
potrebbe essere generato dai pochi livelli alti delle classi relative ai vini.
Le richieste possono sfruttare le ontologie dei vini per ricavare
informazioni sul vino di interesse rilevante. Se si effettua la ricerca di un
termine contenuto all'interno dell'ontologia, la richiesta può essere espansa
con le informazioni relative alle sottoclassi per trovare delle risposte
rilevanti. I portali potrebbero essere fatti per aggiornarsi automaticamente con
le informazioni (candidate) relative all'area di interesse. Con delle capacità
altamente potenti di ragionamento potrebbero persino identificare dei siti di
vendita dei vini e negoziare con loro per includerli come parte integrante del
portale.
Abbiamo cominciato a costituire un wine agent
(Agente dei vini) per scopo puramente dimostrativo. Nel nostro progetto iniziale
l'obiettivo dell'agente dei vini è quello di raccomandare i vini che possono
essere accompagnati alle differenti portate di un pasto. Questa applicazione
sfutta l'ontologia usata come base per questa guida. Questa ontologia dei vini è
disponibile nella libreria ontologica DAML ed intitolata originariamente con wines.
Un agente personalizzato dei vini può offrire diversi servizi ad una persona.
L'agente può essere usato per raccomandare dei vini una volta dato un
insieme di restrizioni (come le portate che devono essere servite), può trovare
informazioni riguardo un vino particolare o una classe di vini e può cercare
accessori appropriati per quel particolare vino (per esempio un tipo particolare
di bicchiere adatto alla varietà del vino, etc.).
Sotto, descriviamo un esempio di prototipo che è stato scritto come progetto
da uno studente.
Si consideri il seguente scenario:
Qualcuno sta programmando una cena
e almeno uno degli invitati ha conoscenze sui vini. Il padrone di casa vorrebbe
servire dei vini che si accompagnino bene alle portate del menù. Il padrone di
casa vorrebbe inoltre apparire colto riguardo i vini che verranno serviti
all'evento. Il padrone di casa vorrebbe avere accessori appropriati per la cena.
Il padrone di casa potrebbe aver deciso di servire una speciale pasta fresca a
base di sugo come portata principale.
Per servire vini appropriati al pasto, il padrone di casa ha bisogno di
informazioni riguardo i vini e gli eventuali accoppiamenti con i cibi. Inoltre
per apparire colto sui vini, avrebbe beneficio mediante l'accesso a informazioni
rilevanti sui vini che potrebbero essere serviti. Per avere accessori
appropriati. dovrebbe avere informazioni sugli accessori che potrebbero servire
in quella occasione (e che siano all'interno della sua portata economica).
Con una ontologia dei vini a disposizione, una volta fornita la descrizione
del pasto, un agente dei vini può suggerire il tipo di vino da servire con il
pasto. L'agente può suggerire uno zinfandel come varietà di scelta da abbinare
al pasto e in aggiunta, controllando l'ontologia di riferimento, può suggerire
un particolare zinfandel, un Marietta Zinfandel. Una volta detto che il vino
deve essere uno zinfandel, un agente potrebbe cercare un posto dove acquistare
una selezione di zinfandel o potrebbe cercare ulteriormente per un particolare
zinfandel come il Marietta. Una volta fornita una ontologia contenente le
risorse appropriate per l'acquisto di vini (possibilmente filtrate sul luogo di
provenienza del padrone di casa e dei rivenditori) l'agente potrebbe andare su
un sito come wine.com ed effettuare una
ricerca per lo 'zinfandels' e ritornare una lista di tutti i vini zinfandel in
vendita su quel sito. L'agente dei vini potrebbe tentare di trovare un MariettaZinfandel sia dalla
stessa azienda vinicola, sia da altri rivenditori. Esso potrebbe ad esempio
trovare (tramite una ricerca su Google o una ricerca strutturata su una
selezione particolare di siti) che il sito winelibrary.com ha in vendita un
Marietta zinfandel del 1999 ad un prezzo di sconto di $13.99. L'agente dei vini
potrebbe a questo punto utilizzare un filtro aggiunivo, come gli intervalli di
prezzo, fornito dall'utente o come suggerimento di prezzo basato sulla qualità
del vino.
L'agente dei vini può ora cercare di fornire informazioni riguardanti lo
zinfandel in generale o il Marietta Zinfandel in particolare. Potrebbe usare una
ontologia di riferimento per trovare informazioni riguardanti vini particolari.
Per esempio la descrizione delle aziende
vinicole e dei loro recenti zinfandel prodotti può essere utile. Alre
informazioni aggiuntive da fonti convalidate come ad esempio il Wine Spectator possono anche
essere utili. Se non viene trovata nessuna recensione disponibile sul Marietta
Zinfandel, può essere utile cercare informazioni correlate come recensioni su
zinfandel della stessa regione ovvero, in questo caso, zinfandel provenienti
dalla Contea di Sonoma in California.
Anche altre nozioni generali possono essere utili. Il padrone di casa
potrebbe avere voglia di leggere alcuni libri sui vini in generale o sullo
zinfandel in particolare. Ad esempio il padrone di casa potrebbe essere
interessato nei libri che la Amazon.com ha in vendita
sullo zinfandel. Il padrone di casa potrebbe inoltre essere interessato ad
informazioni riguardanti vini provenienti dalla stessa regione e quindi potrebbe
essere interessato anche al Sonoma zinfandel. Un agente dei vini può avere
informazioni tipiche di base che sono collegate con le sue aree maggiori di
conoscenza. Per esempio questo agente dei vini deve trattare l'accoppiamento di
cibi e di vini quindi dovrebbe avere delle informazioni gratuite e/o a pagamento
su questo argomento, così come viene descritto nell'articolo del Wine Spectator
su Come
accoppiare il cibo e il vino..
Il padrone di casa potrebbe inoltre voler acquistare degli accessori
appropriati prima dell'evento. Il vino viene servito in bicchieri di vino e
differenti varietà di vini sono servite meglio in differenti tipi di bicchieri.
Per esempio se il padrone di casa ha scelto delle portate per cui lo zinfandel è
appropriato, potrebbe voler sapere che il Riedel è un noto produttore di
bicchieri per il vino. Potrebbe inoltre voler essere messo in contatto con il
Wine Enthusiast (un ottimo fornitore di prodotti per il vino) ed essere
avvertito del fatto che il Wine Enthusiast vende un insieme di 4 bicchieri di
tipo Riedel
Vinum Zinfandel al prezzo di $63.95 (con un prezzo scontato di $59.95 se si
comprano due confezioni da 4 bicchieri). Il padrone di casa potrebbe inoltre
essere interessato al fatto che Amazon.com ha dei bicchieri di tipo Reidel's
Sommelier Zinfandel single stem glass a disposizione a $49.99 (rispetto un
prezzo di listino di $65.00). Amazon ha inoltre gli stessi bicchieri da vino in
gruppi da 6 (invece dei 4 della wine enthusiast) a $79.99 (rispetto ad un prezzo
di listino di $119.40). Un agente dei vini potrebbe fornire una lista
comparativa dei diversi bicchieri che si adattano al pasto (per esempio quelli
che sono appropriati per essere usati con lo zinfandel) e che siano ordinati in
relazione al prezzo o ad altri criteri scelti da una lista di proprietà
nell'ontologia.
Il padrone di casa potrebbe volere anche altri accessori per il vino.
Dall'ontologia sappiamo che anche i cavatappi sono accessori per il vino.
L'ontologia potrebbe codificare delle sottoclassi di cavatappi o queste
informazioni potrebbero essere ricavate anche dai siti di vini. Il Wine
Enthusiast ha un set di cavatappi
che sono da loro raccomandati
(con la descrizione dei tipi e degli intervalli di prezzo). Essi distinguono
inoltre i cavatappi in base al tipo (a livello, da cameriere, stazionario,
ruotante e a pompa) e il padrone di casa potrebbe volere informazioni riguardo i
differenti tipi.
L'agente dei vini può essere implementato a diversi livelli di precisione in
base alla conoscenza delle ontologie del dominio, delle informazioni e dei siti
di riferimento. In questo esempio abbiamo esplorato solo le informazioni
riguardanti i vini, le diverse varietà, la combinazione e l'accopiamento con i
cibi, alcuni accessori per i vini e le loro proprietà correlate. Potremmo
naturalmente espandere il tutto includendo informazioni e restrizioni imposte
dall'utente.
Un esempio di questo agente dei vini in continua evoluzione è disponibile al
seguente indirizzo.
Riconoscimenti
Questo documento è il risultato delle discussioni di approfondimento
all'interno di tutto il Web Ontology
Working Group. I partecipanti a questo Gruppo di Lavoro includono: Yasser
alSafadi, Jean-François Baget, James Barnette, Sean Bechhofer, Jonathan Borden,
Frederik Brysse, Stephen Buswell, Jeremy Carroll, Dan Connolly, Peter Crowther,
Jonathan Dale, Jos De Roo, David De Roure, Mike Dean, Larry Eshelman, Jérôme
Euzenat, Tim Finin, Nicholas Gibbins, Sandro Hawke, Patrick Hayes, Jeff Heflin,
Ziv Hellman, James Hendler, Bernard Horan, Masahiro Hori, Ian Horrocks, Jane
Hunter, Francesco Iannuzzelli, Rüdiger Klein, Natasha Kravtsova, Ora Lassila,
Massimo Marchiori, Deborah McGuinness, Enrico Motta, Leo Obrst, Mehrdad
Omidvari, Martin Pike, Marwan Sabbouh, Guus Schreiber, Noboru Shimizu, Michael
Sintek, Michael K. Smith, John Stanton, Lynn Andrea Stein, Herman ter Horst,
David Trastour, Frank van Harmelen, Bernard Vatant, Raphael Volz, Evan Wallace,
Christopher Welty, Charles White, and John Yanosy.
Alcuni testi importanti iniziali sulle restrizioni complesse sono stati
scritti da Raphael Volz,
Forschungszentrum Informatik (FZI). Approfondimenti sostanziali sono stati
forniti dal DAML+OIL
Walkthru. Jeremy Carroll, Jerome Euzenat, Jeff Heflin, Kevin Page and
Peter F. Patel-Schneider hanno fornito delle correzioni fondamentali. Al WG Face
to Face, 8 October 2002, Stephen Buswell, Ruediger Klein, Enrico Motta, e Evan
Wallace hanno fornito una revisione dettagliata dell'ontologia con il risultato
di cambiamenti sostanziali. Al WG Face to Face, 10 January 2003, Jonathan Dale,
Bernard Horan, Guus Schreiber, e Jeff Heflin hanno fornito delle revisioni
dettagliate della Guida con dei notevoli cambiamenti. La revisione
pubblica ha fornito numerosi e utilissimi suggerimenti e correzioni.
OWL
Web Ontology Language Semantics and Abstract Syntax , Peter F.
Patel-Schneider, Patrick Hayes, and Ian Horrocks, Editors. W3C Recommendation,
10 February
2004, http://www.w3.org/TR/2004/REC-owl-semantics-20040210/. Latest version available at
http://www.w3.org/TR/owl-semantics/.
OWL
Web Ontology Language Overview , Deborah L. McGuinness and Frank
van Harmelen, Editors. W3C Recommendation, 10 February
2004, http://www.w3.org/TR/2004/REC-owl-features-20040210/. Latest version available at
http://www.w3.org/TR/owl-features/.
OWL Web
Ontology Language Reference , Mike Dean and Guus Schreiber,
Editors. W3C Recommendation, 10 February
2004, http://www.w3.org/TR/2004/REC-owl-ref-20040210/. Latest version available at
http://www.w3.org/TR/owl-ref/.
OWL Web
Ontology Language Test Cases , Jeremy J. Carroll and Jos De Roo,
Editors. W3C Recommendation, 10 February
2004, http://www.w3.org/TR/2004/REC-owl-test-20040210/. Latest version available at
http://www.w3.org/TR/owl-test/.
RDF
Semantics , Patrick Hayes, Editor. W3C Recommendation, 10 February
2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/. Latest version available at
http://www.w3.org/TR/rdf-mt/.
RDF/XML
Syntax Specification (Revised) , Dave Beckett, Editor. W3C
Recommendation, 10 February
2004, http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/. Latest version available
at http://www.w3.org/TR/rdf-syntax-grammar.
XML Base, Jonathan Marsh,
Editor. W3C Recommendation, 27 June
2001, http://www.w3.org/TR/2001/REC-xmlbase-20010627/. Latest version available at
http://www.w3.org/TR/xmlbase/.
Namespaces in
XML , Tim Bray, Dave Hollander, Andrew Layman, Editors. W3C
Recommendation, Jan 1999,
http://www.w3.org/TR/1999/REC-xml-names-19990114/. Latest version available at
http://www.w3.org/TR/REC-xml-names.
Extensible
Markup Language (XML) 1.0 , Tim Bray, Jean Paoli, C. M.
Sperberg-McQueen, Editors. W3C Recommendation, 10 February
1998, http://www.w3.org/TR/1998/REC-xml-19980210. Latest version available at
http://www.w3.org/TR/REC-xml.
XML Schema Part 1:
Structures, Henry S. Thompson, David Beech, Murray Maloney, and
Noah Mendelsohn, Editors. W3C Recommendation, 2 May 2001,
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/. Latest version available at
http://www.w3.org/TR/xmlschema-1/.
XML Schema Part 2:
Datatypes, Paul V. Biron, Ashok Malhotra, Editors. W3C
Recommendation, 2 May 2001,
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/. Latest version available at
http://www.w3.org/TR/xmlschema-2/.
Integrating Applications
on the Semantic Web , James Hendler, Tim Berners-Lee, and Eric
Miller. Journal of the Institute of Electrical Engineers of Japan,
Vol 122(10), October, 2002, p. 676-680.
Industrial
Strength Ontology Management , Aseem Das, Wei Wu, and Deborah L.
McGuinness. Stanford Knowledge Systems Laboratory Technical Report KSL-01-09
2001. In the Proceedings of the International Semantic Web Working
Symposium, Stanford, CA, July 2001.
Classic
Knowledge Representation System Tutorial , Deborah L. McGuinness,
Peter F. Patel-Schneider, Richmond H. Thomason, Merryll K. Abrahams, Lori
Alperin Resnick, Violetta Cavalli-Sforza, and Cristina Conati. AT&T Bell
Laboratories and University of Pittsburgh, 1994.
Living
with CLASSIC: When and How to Use a KL-ONE-Like Language , Ronald
J. Brachman, Deborah L. McGuinness , Peter F. Patel-Schneider , Lori Alperin
Resnick , and Alex Borgida. In Principles of Semantic Networks:
Explorations in the representation of knowledge, John Sowa, Editor.
Morgan-Kaufmann, San Mateo, California, 1991, pages 401--456.
DAML+OIL W3C Submission,
Includes reference description, both model theoretic and axiomatic semantics,
annotated walkthrough and examples.
Annotated DAML+OIL
Ontology Markup , Dan Connolly, Frank van Harmelen, Ian Horrocks,
Deborah McGuinness, Peter F. Patel-Schneider, Lynn Andrea Stein. December
2001.
Partial
DAML-ONT axiomatization at
http://www.daml.org/2000/10/DAML-Ont-kif-axioms-001107.html. Defined in KIF
(http://logic.stanford.edu/kif/kif.html).
XOL: An XML-Based
Ontology Exchange Language, Peter D. Karp, Vinay K. Chaudhri, and Jerome
F. Thomere. Technical Report 559. AI Center, SRI International, 333 Ravenswood
Ave., Menlo Park, CA 94025, Jul 1999.
Expressing
Dublin Core in RDF/XML, Dave Beckett, Eric Brickley, and Dan
Brickley. Dublin Core Metadata Initiative. July 31, 2002,
http://dublincore.org/documents/2001/11/28/dcmes-xml/.
