Home
|
Possibili errori di traduzione possono essere presenti in questo
documento.
Translation or last correction time: 2006/02/02, Tadas Talaikis,
info@nakagava.com
Solo il documento originale in inglese puo essere considerato
ufficiale: http://www.w3.org/TR/2004/REC-webont-req-20040210/
|
Questo documento specifica scenari d’uso, scopi e requisiti per un linguaggio
ontologico del web. Un’ontologia definisce formalmente un set comune di termini
che si usano per descrivere e rappresentare un dominio. Le ontologie possono
essere usate da strumenti automatizzati per motorizzare servizi avanzati come
ricerche web più accurate, agenti software intelligenti e knowledge
management.
1 Introduzione
La Semantica Web è una visione del futuro della rete nella quale si fornisce
all’informazione un significato esplicito, facendo il processamento più semplice
alle macchine e l’integrazione dell’informazione disponibile nella rete. La
Semantica Web ha come fondamenta l’abilità di XML per definire schemi di
etichettamento personalizzato [XML] e l’approccio
flessibile del RDF alla rappresentazione di dati [RDF
Concepts]. Il seguente requisito di una Semantica Web è un linguaggio
ontologico del web che possa descrivere formalmente la semantica delle classi e
delle proprietà usate nei documenti web. Affinché i computer possano effettuare
lavori di ragionamento utili in questi documenti, il linguaggio deve eccellere
la semantica basica dello Schema RDF [RDF
Vocabulary].
Questo documento è una parte della specificazione dell’OWL, il linguaggio
ontologico del web. La sezione Mappa del
documento del documento Panoramica OWL descrive tutti gli altri documenti.
Questo documento enumera i requisiti di un linguaggio ontologico del web,
secondo l’opinione dei partecipanti del working group. In ogni modo, è da
sperare che futuri linguaggi possano estendere l’OWL, aggiungendo, fra altre
cose, maggiori capacità logiche e l’abilità di stabilire fiducia nella Semantica
Web.
Giustifichiamo la necessità di un linguaggio ontologico del web con la
descrizione di sei casi d’uso. Alcuni
di questi casi si basano su sforzi attualmente in preparazione negli ambiti
industriale e accademico, altri sono possibilità a termine più lungo. I casi
d’uso sono seguiti dagli scopi del progetto che
descrivono obiettivi d’alto livello e linee guida per lo sviluppo del
linguaggio. Questi scopi del progetto saranno considerati quando si valutino le
caratteristiche proposte. La sezione di Requisiti
presenta un set di caratteristiche che il linguaggio deve compiere e fornisce i
motivi. La sezione Obiettivi contiene
un elenco di caratteristiche che potrebbero essere utili in molti casi d’uso,
però il working group potrebbe non svilupparle.
Il Web Ontology Working
Group charter contempla come compito del group la produzione di queste
semantiche più espressive e la specificazione di meccanismi attraverso i quali
il linguaggio possa provvedere "rapporti più complessi tra entità, includendo:
mezzi di limitare le proprietà delle classi rispetto al numero e il tipo, mezzi
che permettano inferire che gli item con molte proprietà sono membri di una
classe particolare, un modello ben definito d’eredità di proprietà, e altre
estensioni semantiche similari ai linguaggi base." La specificazione
circostanziata del linguaggio ontologico del web prenderà in considerazione:
- gli scopi del progetto e i requisiti contenuti in questo documento
- i commenti su questo documento dal contributo pubblico, da esperti
invitati e membri del working group
- le specificazioni o proposte di linguaggi che compiano molti di questi
requisiti
Un’ontologia definisce i termini usati per descrivere e rappresentare un’area
di conoscenza. Le ontologie sono usate da persone, database e applicazioni che
abbiano bisogno di condividere informazione di dominio (un dominio è,
precisamente, un’area tematica specifica o area di conoscenza, come la medicina,
produzione d’attrezzi, beni immobili, riparazione d’automobili, management
finanziario, etc.). Le ontologie includono definizioni, usabili nell’ambito
informatico, di concetti basici del dominio e i rapporti tra loro (qui e in
tutto questo documento, il termine definizione non si usa nel senso tecnico
della logica). Codificano le conoscenze in un dominio e anche le conoscenze che
misurano il dominio. In questo senso, permettono la riutilizzazione di queste
conoscenze.
Il termine ontologia è stato usato per descrivere dispositivi con strutture
di diversi gradi, da semplici tassonomie (come la gerarchia di Yahoo) a schemi
di metadata (come il Dublin Core) e teorie logiche. La Semantica Web ha bisogno
d’ontologie con un grado significativo di struttura. Perciò deve specificare
descrizioni per le seguenti classi di concetti:
- Classi (cose generali) nei domini d’interesse
- I rapporti che possano esistere tra le cose
- Le proprietà (o attributi) che queste cose possano avere
Le ontologie di solito sono espresse in un linguaggio di base logica, per
permettere effettuare distinzioni circostanziate, accurate, coerenti, solide e
significative tra le classi, proprietà e rapporti. Alcuni strumenti di
un’ontologia possono realizzare ragionamenti automatizzati usando le ontologie,
e così provvedere servizi avanzati ad applicazioni intelligenti come: ricerca e
ricupero concettuale/semantico, software agent, supporto di
decisioni,comprensione di discorso e linguaggio naturale, maneggio di
conoscenze, database intelligenti e commercio elettronico.
Le ontologie hanno un ruolo prominente nella Semantica Web emergente come una
maniera di rappresentare la semantica dei documenti e di permettere che le
semantiche possano essere usate da applicazioni web e agenti intelligenti. Le
ontologie possono essere molto utili per una comunità che voglia strutturare e
definire i significati dei termini metadata che si stiano raccogliendo e
standardizzando. Con l’uso delle ontologie, le applicazioni del domani potranno
essere "intelligenti", nel senso che potranno lavorare più accuratamente nel
livello concettuale umano.
Le ontologie sono importantissime per applicazioni che abbiano come scopo la
ricerca o l’incorporazione d’informazione da diverse comunità. Sebbene gli
Schemi XML DTD e XML possano scambiare dati tra parti che si siano messi
d’accordo sulle definizioni in anticipo, la loro mancanza di semantiche
impedisce che le macchine compiano affidabilmente questo compito con nuovi
vocabolari XML. Lo stesso termine può essere usato con (a volte sottili)
significati diversi in contesti diversi, e i termini diversi possono essere
usati per item che abbiano lo stesso significato. Gli Schemi RDF e RDF hanno
avuto un approccio a questo problema permettendo l’associazione di semantiche
semplici con identificatori. Con lo Schema RDF, si possono definire classi con
molteplici sottoclassi e superclassi, e definire proprietà, che possono avere
sottoproprietà, domini ed estensioni. In questo senso, lo Schema RDF è un
linguaggio d’ontologia semplice. Comunque, vi è bisogno di semantiche più ricche
per raggiungere interoperabilità tra schemi numerosi, sviluppati autonomamente e
gestiti. Ad esempio, lo Schema RDF non può specificare che le classi Persone e
Automobili sono disgiunte, oppure che un quartetto d’archi ha esattamente
quattro musicisti come membri.
Uno degli scopi di questo documento è quello di specificare quali cose siano
necessarie in un linguaggio ontologico del web. Questi requisiti avranno come
causa casi d’uso potenziali e obiettivi generali del progetto che tengano conto
delle difficoltà che si trovano all’applicare la nozione standard d’ontologia
all’ambiente unico del Web.
Le ontologie si possono usare per migliorare applicazioni già esistenti
basate nel web e anche possono permettere nuovi usi del Web. In questa sezione
si descrivono sei casi d’uso rappresentativi delle ontologie web. Si deve tenere
in conto che quest’elenco non è esauriente, ma una selezione di casi d’uso
interessanti. Questi casi d’uso servono come orientamento nella selezione dei
requisiti del linguaggio OWL (vedere Sezione 4). I
requisiti sono stati scelti d’accordo agli aspetti dei casi d’uso che il working
group ha considerato come più importanti, secondo lo scopo dello statuto OWL e
altre restrizioni di disegno. Perciò, non si deve assumere che OWL supporterà
direttamente ogni aspetto dei casi d’uso.
Un portale web è un sito web che fornisce contenuto informativo di un tema
comune, ad esempio una città specifica o un dominio d’interesse. Un portale web
permette alle persone interessate nel tema ricevere notizie, trovare altre
persone e parlare con loro, costruire una comunità e trovare link che facciano
collegamento con altre risorse web d’interesse comune.
Un portale che è di successo deve essere un luogo d’inizio per localizzare
contenuto d’interesse. Di solito, questo contenuto è presentato da membri della
comunità, che spesso lo schedano in subtemi. Altri mezzi di raccogliere
contenuti s’affidano ai fornitori di contenuto, che lo etichettano con
informazione che si può usare nella classificazione, frequentemente con semplici
metatag che identificano il tema del contenuto, ecc.
In ogni caso, un indice semplice delle aree considerate non sempre provvede
alla comunità l’abilità sufficiente per cercare il contenuto desiderato dai suoi
membri. I portali web possono definire un’ontologia per la comunità che permetta
una classificazione più intelligente. Quest’ontologia può fornire una
terminologia che descriva contenuti e assiomi che definiscano i termini usando
altri termini dell’ontologia. Ad esempio, un’ontologia potrebbe includere
terminologia come “Giornale", "pubblicazione", "persona" e "autore".
Quest’ontologia può includere definizioni che dichiarino, ad esempio, "tutti i
giornali sono pubblicazioni" oppure "gli autori di tutte le pubblicazioni sono
persone". Quando queste definizioni si combinano con fatti permettono inferire
altri fatti che sono necessariamente veri. Queste inferenze possono, a turno,
permettere agli utenti trovare risultati dal portale che sono impossibili di
ottenere da sistemi convenzionali di ricerca. Con questa tecnica i fornitori di
contenuto usano il linguaggio ontologico del web per catturare rapporti
ontologici d’alta qualità, e uno degli obiettivi dell’OWL è quello di abilitare
contenuti di metadata sufficientemente ricchi e utili per causare lo sforzo
necessario. Un’altra sfida è quella di minimizzare questo sforzo, giacché un
linguaggio ontologico avrà probabilmente un più grande impatto se può facilitare
la cattura di metadata come una parte non intrusiva di qualsiasi processo di
creazione d’informazione.
OntoWeb è un esempio di portale basato
in un’ontologia. Questo portale giova la ricerca ontologica della comunità
accademica ed industriale interessata. Un altro esempio di portale che usa
tecnologie di Semantica Web e potrebbe trarre profitto di un linguaggio
ontologico è The Open Directory Project; un vasto
e comprensivo direttorio del Web redatto con mezzi umani. È stato costruito ed è
mantenuto da una vasta comunità globale d’editori volontari. Il RDF della
database del Open Directory è disponibile per scaricare.
Le ontologie si possono usare per fornire annotazioni semantiche per
collezioni d’immagini, audio o altri oggetti non testuali. È più difficile per
le macchine estrarre una semantica significativa dei multimedia che estrarre una
semantica di un testo in linguaggio naturale. Così, questi tipi di risorse sono
tipicamente indicizzati in sottotitoli o metatag. Comunque, siccome differenti
persone potrebbero descrivere questi oggetti non testuali in diverse forme, è
importante che le facilità di ricerca eccellano la semplice congiunzione di
parole chiave. In forma ideale, le ontologie potrebbero catturare conoscenze
addizionali sul dominio che permetterebbero una migliore ricerca delle
immagini.
Le ontologie multimedia possono essere di due tipi: media-specific e
content-specific. Le ontologie media-specific possono avere tassonomie di
diversi media type e descrivere proprietà di diversi media. Ad esempio, il video
può includere proprietà che identifichino la durata del clip e degli intervalli.
Le ontologie content-specific possono descrivere il tema della risorsa, come i
partecipanti e l’installazione. Siccome queste ontologie non sono specifiche dei
media, possono essere riusate da altri documenti che abbiano lo stesso dominio.
Questa possibilità di riuso aumenterebbe la ricerca che consista semplicemente
in ricavare informazione su un tema in particolare, nonostante il formato della
risorsa. Le ricerche in cui il media type sia importante possono combinare
ontologie media-specific e content-specific.
Prendiamo come esempio di collezione multimedia un archivio d’immagini di
mobili antichi. Un’ontologia dei mobili antichi sarebbe molto utile nella
ricerca di quest’archivio. Si potrebbero classificare i diversi tipi di mobili
usando una tassonomia. Sarebbe anche utile se l’ontologia potesse esprimere
conoscenza definizionale. Per esempio, se la persona che fa l’indice
selezionasse il valore "Tardo Georgiano" per lo stile/periodo di, diciamo,
un’antica cassapanca di cassetti, sarebbe possibile inferire che l’elemento data
"date.created" dovrebbe avere un valore tra 1760 e 1811 A.D. e che l’elemento
data "culture" sarebbe British. La disponibilità di questo tipo di conoscenza di
fondo incrementa significativamente il supporto tanto per l’indicizzare quanto
per la ricerca. Un’altra caratteristica che sarebbe utile è il supporto per la
rappresentazione della conoscenza per default. Un esempio di questa conoscenza
sarebbe che una "cassapanca di cassetti tardo georgiana", senz’altra
informazione, si assume come fatta da mahogany. Questa conoscenza è cruciale per
vere consulte semantiche, ad esempio una consulta d’utente per "mobili antichi
di mahogany in magazzino" potrebbe accoppiarsi con immagini di cassapanche di
cassetti tardo georgiane, sebbene non si dica niente sul tipo di legno
nell’annotazione dell’immagine.
Le aziende importanti di solito hanno numerosi pagine web relative ai
comunicati stampa, offerte di prodotti e studi di caso, procedure aziendali,
informazioni interne su prodotti, informi ufficiali e descrizioni di processi.
Si possono usare ontologie per indicizzare questi documenti e fornire migliori
mezzi di ricerca. Sebbene molti organizzazioni importanti abbiano una tassonomia
per organizzare l’informazione, spesso è insufficiente. Una singola ontologia
spesso sarebbe limitante perché le categorie costituenti sarebbero costrette a
quelle che rappresentino una visione e una granularità del dominio; l’abilità di
lavorare simultaneamente con molte ontologie aumenterebbe la ricchezza della
descrizione. Inoltre, l’abilità di ricercare valori per parametri diversi è
spesso più utile che una ricerca per parole chiave con tassonomie.
Un sito web che lavori con ontologie potrebbe essere usato da:
- Un venditore che cerchi vendite collaterali attinenti ad un obiettivo di
vendita.
- Un tecnico che cerchi competenza tecnica specifica ed esperienza
dettagliata.
- Un leader di progetto che cerchi esperienza per un progetto complesso e di
molti fasi, tanto quanto nella fase di disegno quanto nella fase d’esecuzione.
Un problema tipico di questo tipo d’utenti è che a volte non condividono la
terminologia con gli autori del contenuto desiderato. Il venditore può non
conoscere il nome tecnico della caratteristica desiderata o i tecnici di diversi
campi potrebbero usare termini diversi per lo stesso concetto. Per risolvere
questi problemi sarebbe utile che ogni classe d’utenti avesse una classe diversa
d’ontologia di termini e che tutte le ontologie fossero collegate affinché le
traduzioni se compiano automaticamente.
Un altro problema è quello di porre le consulte nel livello corretto
d’astrazione. Un leader di progetto che cerchi qualcuno con esperienza in
sistemi operativi dovrebbe essere capace di localizzare un impiegato esperto
tanto in Unix quanto in Windows.
Un aspetto di un’organizzazione di molti servizi è che può avere un set di
capacità molto ampio. Ma quando si inseguano contratti grossi queste capacità
spesso devono essere radunate in nuove maniere. Frequentemente non ci sarà un
singolo progetto previo ad accoppiare. La sfida è ragionare su come radunare
modelli e documenti in nuove configurazioni, soddisfacendo una diversità di
precondizioni.
Questo caso d’uso ha un utilizzo ampio nel campo della documentazione di
pianificazione, come si usa nell’industria aerospaziale. Questa documentazione
può essere di molti tipi, includendo documentazione del progetto, documentazione
di fabbricazione e documentazioni di prova. Ognuno di questi set di documenti ha
una struttura gerarchica, ma queste strutture differiscono tra loro secondo i
diversi set. Vi è anche un set d’assi impliciti che collega obliquamente i set
di documentazione; per esempio, nei documenti di disegno aerospaziali un item
come lunghezza d’ali può apparire in ciascuno.
Le ontologie si possono usare per formare un modello d’informazione che
permetta l’esplorazione dello spazio d’informazione con termini degli item
rappresentati, associazione tra item, le proprietà degli item e i link con la
documentazione che li descrive e definisce (ad esempio, la giustificazione
esterna dell’esistenza degli item nel modello). Cioè, l’ontologia e la
tassonomia non sono indipendenti degli item fisici che rappresentano, ma possono
essere sviluppate/esplorate insieme.
Un esempio concreto di questo caso d’uso è la documentazione di progetto per
il dominio aerospaziale, nella qualle gli utenti tipici includono:
- Ingegnere di manutenzione che cerca tutta l’informazione attinente a una
parte in speciale (ad esempio, “lungheza d’ali").
- Ingegnere di progetto che cerca limitazione nel riuso di un sub-montaggio
in particolare.
Per il supporto di questo tipo d’uso è importante definire le limitazioni.
Queste limitazioni possono essere usate per ampliare la ricerca o controllare la
sua consistenza. Questo potrebbe essere un esempio di restrizione:
biplane(X) => CardinalityOf(wing(X)) = 2
wingspar(X) AND wing(Y) AND isComponentOf(X,Y) => length(X) < length(Y)
Un altro uso comune di questo tipo d’ontologia è il supporto della
visualizzazione e edizione di diagrammi che mostrino istantanee dello spazio
dell’informazione centrate su un concetto determinato (ad esempio, una classe).
Questi sono tipicamente diagrammi attività/regole o diagrammi entità-rapporto.
La Semantica Web può fornire agenti che abbiano la capacità di comprendere e
integrare diverse risorse d’informazione. Un esempio specifico è quello di un
pianificatore d’attività sociali, che può ricevere le preferenze di un utente
(come il tipo di film che preferisce, che tipo di cibi mangia, ecc.) e usare
quest’informazione per pianificare le attività dell’utente in una sera. Il
compito di questa pianificazione dipenderà della ricchezza dell’ambiente di
servizi offerti e i bisogni dell’utente. Durante il processo determinazione /
congiunzione dei servizi, si possono anche consultare stimazioni e rassegne di
servizi per trovare congiunzioni più vicine alle preferenze dell’utente (per
esempio, consultare rassegne e stimazioni di film e restaurant per trovare il
“migliore”).
Questo tipo d’agenti richiede ontologie di dominio che rappresentino i
termini per restaurant, alberghi, ecc., e ontologie di servizi che rappresentino
i termini usati nei servizi veri. Queste ontologie saranno capaci di catturare
l’informazione necessaria per applicazioni che discrimino e bilancino le
preferenze dell’utente. Quest’informazione può essere fornita da molte fonti,
come portali, siti di servizi specifici, siti di prenotazione e il Web in
generale.
Agentcities è un esempio
di una iniziativa che esplora l’uso d’agenti in un ambiente di servizi
distribuiti per l’Internet. Questo implica costruire una rete di piattaforme
agenti che rappresentino città vere o virtuali, come San Francisco o la Bay Area, e
popolarle con i servizi di queste città. Inizialmente, questi servizi saranno
orientati verso business per servizi di consumatori, come alberghi, restaurant,
divertimento, ecc., ma eventualmente, si espanderanno fino all’inclusione di
servizi business come payroll e servizi d’impresa.
Per questo si richiede diversi domini e ontologie di servizi, tra i problemi
chiavi vi sono:
- Uso ed integrazione di molte ontologie separate attraverso diversi domini
e servizi
- Locazione distribuita d’ontologie attraverso l’Internet
- Ontologie potenzialmente diverse per ogni dominio o servizio (ontologia di
referenza traduzione/croce)
- Rappresentazione semplice dell’ontologia per fare più facile il lavoro di
definire ed usare le ontologie
Il computer onnipresente è un paradigma emergente nell’ambito del personal
computer, caratterizzato dal cambiamento da meccanismi specificamente
informatici a capacità informatiche incorporate negli ambienti d’ogni giorno.
Sono caratteristiche del computer onnipresente i dispositivi informatici
piccoli, manuali e wireless. I caratteri di questi dispositivi (essere molto
diffuse e senza fili) richiedono architetture network per supportare
configurazioni automatiche ad hoc. Una ragione addizionale per lo sviluppo di
configurazioni automatiche è che questa tecnologia punta sui consumatori
ordinari.
Una chiave tecnologica di una vera rete ad hoc è la scoperta di
servizi, la funzionalità con la quale questi "servizi" (ad esempio, le funzioni
offerte da numerosi dispositivi come telefoni cellulari, sensori, ecc.) si
possano descrive, fare pubblicità ed essere scoperti da altri. Tutti gli attuali
meccanismi di scoperta di servizi e descrizione di capacità (Sun's JINI,
Microsoft's UPnP) si basano su schemi di rappresentazione ad hoc e si affidano
fortemente alla standardizzazione (ad esempio, in un’identificazione a priori di
tutte le cose che si vogliano comunicare o discutere).
Il tema chiave (e la meta) dei computer onnipresenti è "l’interoperabilità
capace di fare felici scoperte", l’interoperabilità in condizioni "non
coreografiche", per esempio: dispositivi che non siano stati necessariamente
disegnati per lavorare insieme (costruiti da diversi fabbricanti, per fini
diversi in tempi diversi) dovrebbero essere capaci di scoprire la funzionalità
altrui e di trarre profitto di questo. È necessaria la capacità di "comprendere"
altri dispositivi e di ragionare su i suoi servizi/funzionalità, giacché i
futuri scenari di computer onnipresenti implicheranno decenne o centinaia di
dispositivi, e standardizzare a priori gli scenari d’uso è un compito
impossibile.
Gli scenari d’interoperazione sono per natura dinamici (ad esempio, i
dispositivi appaiono o scompaiono in qualsiasi momento mentre i possessori li
portano da una stanza all’altra o di un edificio ad altro) e gli umani non sono
coinvolti nel cappio per quanto riguarda alla (re-) configurazione. I compiti
coinvolti nell’utilizzazione di servizi sono scoperta, contrattazione e
composizione. La contrattazione di servizi può implicare tanto la
rappresentazione d’informazione di sicurezza, privacy e confidenza, quanto
particolari relativi a compensazioni (vi potrebbe essere l’obbligazione di
compensare al provveditore di un servizio per i servizi contraccambiati). In
particolare, è una meta che le politiche di sicurezza delle aziende e
organizzazioni si esprimano in moduli d’applicazione neutra permettendo così la
rappresentazione delle restrizioni attraverso la diversità di meccanismi di
rafforzamento (per esempio, firewalls, filters/scanners, traffic monitors,
application-level routers e load-balancers).
Così, un linguaggio ontologico sarà usato per descrivere le caratteristiche
dei dispositivi, i suoi mezzi d’accesso, le politiche stabilite dal proprietario
per il suo uso e altre restrizioni tecniche e requisiti che riguardino
l’incorporazione di un dispositivo in una rete di computer onnipresenti. Le
necessità stabilite da DAML-S
(particolarmente i temi riguardanti all’espressività
del linguaggio) e dagli schemi basati in RDF per rappresentare informazione
sulle caratteristiche di dispositivi (vale a dire, W3C's Composite Capability/Preference
Profile (CC/PP) e WAP Forum's User Agent Profile o UAProf) riguardano
direttamente a questo caso d’uso e l’infrastruttura di risorse che supporterà
applicazioni che amministreranno e faranno la configurazione di reti ad hoc.
Gli scopi di disegno descrivono motivazioni generali del linguaggio che non
risultano necessariamente di un caso d’uso concreto. Insieme ai Casi d’uso, gli
scopi di disegno motivano i Requirements e
gli Obiettivi
delle Sezioni 4 e 5. In questa sezione, descriviamo otto scopi di disegno per il
linguaggio ontologico del web, in particolari quelli che riguardano:
- usare ontologie stabilite
- cambiare ontologie stabilite
- integrare ontologie stabilite
- scoprire incoerenze attraverso le ontologie e gli esempi d’uso
- provvedere un bilancio fra espressività e selezione quando se creano
ontologie
- evitare complessità non necessarie che possano dissuadere un’ampia
adozione
- mantenere la compatibilità con altri standard
- supportare l’internazionalizzazione
Spieghiamo ogni scopo e descriviamo i compiti che supporta. Descriviamo anche
il grado in cui gli Schemi RDF e RDF supportano lo scopo.
3.1 Ontologie
condivise
Le ontologie devono essere disponibili pubblicamente e diverse fonti di dati
devono essere capaci di applicarsi alla stessa ontologia per significati
condivisi. Anche, le ontologie devono essere capaci di estendere altre ontologie
per fornire definizioni addizionali.
Compiti Supportati:
Qualsiasi caso d’uso in cui le fonti di dati
distribuiti usino terminologia condivisa.
Giustificazione:
L’interoperabilità richiede accordi su definizioni
degli identificatori. Le ontologie possono fornire set standard d’identificatori
e descrizioni formali di questi identificatori. Le fonti di dati che applichino
la stessa ontologia sono esplicitamente d’accordo nell’uso degli stessi
identificatori con gli stessi significati.
Le ontologie condivise spesso non sono sufficienti. Un’organizzazione può
scoprire che un’ontologia già esistente fornisce il 90% delle sue necessità, ma
il restante 10% è molto importante. In questi casi l’organizzazione non deve
creare una nuova ontologia improvvisata; deve essere capace di creare
un’ontologia che possa estendere un’ontologia già esistente e aggiungere
qualsiasi identificatore o definizione desiderati.
Supporto RDF(S):
In RDF, ogni schema ha il suo namespace
identificato da un URI. Ogni risorsa dello schema ha un ID, e si può creare un
unico identificatore globale combinando l’ID con l’URI del namespace. Qualsiasi
risorsa che usi questo URI fa riferimento al termine come si define in quello
schema. Comunque, RDF non è chiaro nella definizione di un termine che ha
definizioni parziali in molti schemi. La specificazione assume che la
definizione è l’unione di tutte le descrizioni che usano lo stesso
identificatore, nonostante la fonte. Comunque, questo può creare problemi in un
ambiente distribuito in cui alcuni schemi possano contenere definizioni
scorrette o false. Non è possibile in RDF che una risorsa possa indicare il set
di definizioni con cui concorda.
3.2 Evoluzione
dell’ontologia
Un’ontologia può cambiare, una fonte di dati deve specificare la versione
dell’ontologia corrispondente.
Un tema importante è se i documenti che si riportano ad una versione di
un’ontologia sono compatibili con quelli che riportano ad un’altra. Si devono
permettere tanto le revisioni compatibili quanto quelle incompatibili, ma deve
essere possibile la distinzione tra i due tipi. Siccome le descrizioni formali
provvedono soltanto approssimazioni ai significati della maggioranza degli
identificatori, è possibile che la revisione cambi il significato inteso di un
identificatore senza cambiare la sua descrizione formale. Così, la
determinazione di una semantica compatibile con versione previe richiede più di
una semplice comparazione delle descrizione di termini. Perciò, l’autore
dell’ontologia deve essere capace d’indicare questi cambiamenti
esplicitamente.
Compiti Supportati:
Qualsiasi caso d’uso in cui l’ontologia
potrebbe cambiare potenzialmente, particolarmente quelli in cui il possessore
dell’ontologia è diverso dai fornitori di dati.
Giustificazione:
Il Web è in costante cambiamento e crescita,
perciò dobbiamo aspettare che cambino anche le ontologie. Le ontologie possono
avere bisogno di cambiare perché vi siano errori nelle versioni precedenti,
perché si preferisce una nuova maniera di modellare il dominio o perché una
nuova terminologia è stata creata (per l’invenzione di nuova tecnologia, ad
esempio). Un linguaggio ontologico per il web deve essere capace d’accomodarsi
alle revisioni ontologiche. L’evoluzione dell’ontologia è una cosa diversa della
sua estensione, che non cambia l’ontologia originale.
Supporto RDF(S):
La Specificazione dello Schema RDF raccomanda che
ogni versione dello schema deve essere una risorsa separata con il proprio URI.
Le proprietà rdfs:subClassOf e rdfs:subPropertyOf si possono usare per riferire
nuove versioni di classi e proprietà a versione più vecchie. Comunque, vi è il
problema dell’impossibilità di ritrarre le definizioni sbagliate. Ad esempio,
assumendo che in schema v1, v1:Dolphin è un rdfs:subClassOf v1:Fish. Quando
avvertiamo lo sbaglio la nuova versione dello schema, v2,afferma che v2:Dolphin
è un rdfs:subClassOf v2:Mammal. Comunque, se facciamo v2:Dolphin un
rdfs:subClassOf v1:Dolphin, allora diciamo anche che v2:Dolphin è un
rdfs:subClassOf v1:Fish, e questo perpetua l’errore.
3.3
Interoperabilità dell’ontologia
Le diverse ontologie possono modellare gli stessi concetti in diverse forme.
Il linguaggio deve provvedere primitivi per riferire diverse rappresentazioni,
permettendo così che i dati si convertano a diverse ontologie e facendo
possibile un "web d’ontologie".
Compiti Supportati:
Qualsiasi caso d’uso in cui si devano integrare
dati di diversi fornitori con diverse terminologie.
Giustificazione:
Sebbene la possibilità di condividere ontologie e
l’estensibilità delle ontologie permette un certo grado d’interoperabilità tra
organizzazioni diverse e domini, vi sono spesso casi in cui per modellare la
stessa informazione vi sono molte maniere. Questo può accadere per differenze di
prospettiva tra le organizzazioni, professioni diverse, nazionalità diverse,
ecc. Affinché le macchine possano essere capaci d’integrare informazione che si
riferisce ad ontologie eterogenee, devono esistere primitivi che permettano alle
ontologie progettare concetti negli equivalenti d’altre ontologie.
Supporto RDF(S):
RDF provvede supporto minimo per
l’interoperabilità attraverso le proprietà rdfs:subClassOf e
rdfs:subPropertyOf.
3.4 Scoperta
d’incoerenze
Le diverse ontologie o fonti di dati possono essere contraddittorie. Vi deve
esistere la possibilità di scoprire queste incoerenze.
Compiti Supportati:
Qualsiasi caso d’uso in cui la
decentralizzazione di dati e la mancanza d’autorità di controllo possano portare
a conflitti tra i dati. Qualsiasi compito d’estensione d’ontologia può portare a
descrizione incoerente (possibilmente estendendo un’ontologia in una forma che
generi un concetto molto limitato).
Giustificazione:
Il Web è decentralizzato, permettendo a chiunque
dire qualsiasi cosa. Per questo, diversi ponti di vista potrebbero essere
contradditori, e anche si può fornire informazione falsa. Per evitare che gli
agenti combinino dati incompatibili oppure che prendino dati coerenti e li
trasformino in una dichiarazione incoerente, la scoperta automatica di queste
incoerenze è molto importante.
Supporto RDF(S):
RDF e RDFS non permettono l’espressione
d’incoerenze.
3.5 Bilancio tra espressività e
selezione
Il linguaggio deve essere capace di esprimere un’ampia varietà di conoscenze,
ma deve anche fornire mezzi efficienti di ragionare con queste conoscenze.
Questi due requisiti sono tipicamente dispari, perciò lo scopo del linguaggio
ontologico per il web è cercare un bilancio che supporti l’abilità di esprimere
i più importanti tipi di conoscenze.
Compiti Supportati:
Qualsiasi caso d’uso che usi ontologie vaste o
ampi set di dati e richieda la rappresentazione di conoscenze diverse.
Giustificazione:
Vi sono miliardi di pagine nel Web, e
l’applicazione potenziale della Semantica Web per dispositivi incorporati e
agenti aggiunge addirittura più vaste quantità d’informazione che deve essere
maneggiata. Il linguaggio ontologico per il web deve supportare sistemi
ragionevoli che possano selezionare bene. Comunque, il linguaggio deve essere
anche tanto espressivo quanto sia possibile, affinché gli utenti possano
asserire i tipi di conoscenze che siano importanti per le sue applicazioni.
L’espressività determina che cosa può essere detta in un linguaggio e
determina il suo potere d’inferenza e quali capacità ragionevoli si possano
aspettare in sistemi che l’implementino completamente. Un linguaggio espressivo
contiene un ricco set di primitivi che permette formalizzare un’ampia varietà di
conoscenze. Un linguaggio poco espressivo fornirà troppo poche opportunità di
ragionare che siano utili e può non provvedere nessuna contribuzione ai
linguaggi esistenti.
Supporto RDF(S):
RDF è molto selettivo (con l’eccezione della
sintassi XML, molto verbosa) ma non è molto espressivo.
3.6 Facilità d’uso
Il linguaggio deve fornire una barriera bassa a chi voglia imparare e avere
concetti e significati chiari. I concetti dovrebbero essere indipendenti della
sintassi.
Compiti Supportati:
La marcatura e la consulta di documenti di
semantica web per gli utenti, direttamente o indirettamente.
Giustificazione:
Sebbene idealmente molti utenti saranno isolati
dal linguaggio per strumenti front end, la filosofia basica del linguaggio deve
essere naturale e facile d’imparare. Inoltre, chi l’adotti presto, gli
sviluppatori di strumenti e gli utenti d’importanza possono lavorare
direttamente con la sintassi, essendo desiderabile una sintassi che possa essere
letta (e scritta) da umani.
Supporto RDF(S):
RDF è abbastanza facile d’usare, ma lo Schema RDF
è più complesso. La sintassi sembra di essere un ostacolo per molti utenti.
3.7 Compatibilità con altri
standard
Il linguaggio dovrebbe essere compatibile con altri standard Web e
industriali usati comunemente. Questo include XML e standard correlati (come lo
Schema XML e RDF), e possibilmente altri standard modelli come UML.
Compiti Supportati:
Scambio d’ontologie e dati in un formato
standard.
Giustificazione:
La compatibilità con altri standard facilita lo
sviluppo di strumenti e lo spiegamento del linguaggio.
Supporto RDF(S):
RDF ha una sintassi di serializzazione XML [RDF
Syntax].
3.8
Internazionalizzazione
Il linguaggio dovrebbe supportare lo sviluppo d’ontologie plurilingue, e
potenzialmente fornire diversi vedute delle ontologie che siano appropriate per
culture diverse.
Compiti Supportati:
I compiti in cui la stessa ontologia sia usata
in molti paesi o culture.
Giustificazione:
Il Web è uno strumento internazionale. La
Semantica Web deve giovare allo scambio d’idee e informazione tra culture
diverse, e deve facilitare l’uso delle stesse ontologie a membri di diverse
nazioni.
Supporto RDF(S):
RDF ha lo stesso grado d’internazionalizzazione di
XML.
4 Requisiti
I casi d’uso e gli scopi del progetto motivano una serie di requisiti per il
linguaggio ontologico del web. È il parere attuale del Working Group che i
requisiti descritti sotto sono esenziali per il linguaggio. Ogni requisito
include una breve descrizione e ha come causa uno o più scopi del progetto della
sezione precedente.
- R1. Ontologie come
risorse distinte
-
Le ontologie devono essere risorse che abbiano il proprio identificatore
unico, come una referenza URI.
Motivazione: Ontologie
condivise
- R2. Concetto non-ambiguo
con referenza URI
-
Due concetti in diverse ontologie devono avere identificatori assoluti
diversi (sebbene possano avere identici identificatori relativi). Deve essere
possibile identificare unicamente un concetto in un’ontologia usando una
referenza URI.
Motivazione: Ontologie
condivise, Interoperabilità
dell’ontologia
- R3. Estensione esplicita
dell’ontologia
-
Le ontologie devono essere capace di estendere esplicitamente altre
ontologie per riusare concetti mentre aggiungono nuove classi e proprietà.
L’estensione dell’ontologia deve essere un rapporto transitivo, se
un’ontologia A estende un’ontologia B, e l’ontologia B estende l’ontologia C,
allora l’ontologia A implicitamente estende anche l’ontologia C.
Motivazione: Ontologie
condivise
- R4. Referenza a ontologie
-
Le risorse devono essere capaci di riferirsi esplicitamente a ontologie
specifiche, indicando precisamente il set di definizioni che usano e le
assunzioni fatte.
Motivazione: Ontologie
condivise
- R5. Metadata
dell’ontologia
-
Deve essere possibile fornire meta-data per ogni ontologia, come autore,
data di pubblicazione, ecc. Queste proprietà si possono (o no) mutuare del set
d’elementi del Dublin Core.
Motivazione: Ontologie
condivise
- R6. Informazione sulla
versione
-
Il linguaggio deve provvedere le caratteristiche per comparare e
relazionare le diverse versioni della stessa ontologia, includendo
caratteristiche per relazionare revisioni con versioni anteriori,
dichiarazioni esplicite di compatibilità con versioni anteriori e l’abilità di
disapprovare identificatori (ad esempio, dichiarare che sono disponibili
soltanto per compatibilità con versioni anteriori e non devono usarsi per
nuove applicazioni o documenti).
Motivazione: Evoluzione
dell’ontologia
- R7.
Definizione di classi primitive
-
Il linguaggio deve poter esprimere definizioni complesse di classi,
includendo, per esempio, subclassi e combinazioni boolean di espressioni di
classe (ad esempio, intersezione, unione e complemento).
Motivazione: Bilancio tra espressività e
selezione, Interoperabilità
dell’ontologia, Scoperta
d’incoerenze
- R8.
Definizione di proprietà primitive
-
Il linguaggio deve essere capace di esprimere le definizioni delle
proprietà, includendo, per esempio, sub proprietà, limitazioni di dominio e
serie, transitività e proprietà inverse.
Motivazione: Bilancio tra espressività e
selezione, Interoperabilità
dell’ontologia, Scoperta
d’incoerenze
- R9. Data types
-
Il linguaggio deve fornire un set di data type standard. Questi data type
si possono basare su data type Schema XML [XML-SCHEMA2].
Motivazione: Compatibilità con altri
standard, Facilità d’uso
- R10. Equivalenza di
classe e proprietà
-
Il linguaggio deve includere le caratteristiche che permettano affermare
che due classi o proprietà sono equivalenti.
Motivazione: Interoperabilità
dell’ontologia
- R11. Equivalenza
individuale
-
Il linguaggio deve includere le caratteristiche che permettano affermare
che le coppie d’identificatori rappresentano lo stesso individuo
(coerentemente con la terminologia usata in altri documenti OWL, un individuo
è qualsiasi esempio di una classe OWL, non è necessariamente una persona). Due
identificatori diversi, per la natura distribuita del Web, probabilmente
saranno assegnati allo stesso individuo. L’uso di un URL standard non risolve
questo problema, perché alcuni individui possono avere molteplici URL, come
una persona che ha pagine web o poste elettroniche diverse per il lavoro e per
la casa.
Motivazione: Interoperabilità
dell’ontologia
- R12.
Legare informazione a dichiarazioni
-
Il linguaggio deve provvedere una maniera d’ “etichettare” le dichiarazioni
con informazione addizionale come fonte, timestamp, livello di confidenza,
ecc. Il linguaggio non deve provvedere un set standard di proprietà che si
possano usare così, ma invece deve fornire un meccanismo generale affinché gli
utenti possano legare quest’informazione. La reificazione RDF é una possibile
maniera di portare a termine questo requisito, anche se la reificazione è una
funzione un po’ controversa.
Motivazione: Ontologie
condivise, Interoperabilità
dell’ontologia
- R13. Classi
come esempi
-
Il linguaggio deve supportare l’abilità di trattare le classi come esempi,
perché lo stesso concetto frequentemente può essere veduto come una classe o
come un individuo seconda la prospettiva dell’utente. Ad esempio, in
un’ontologia biologica, la classe Orangutan può avere animali individuali come
esempi. Comunque, la classe Orangutan può essere in se stessa un esempio della
classe Specie. Si prenda nota che Orangutan non è una subclasse di Specie,
perché sarebbe come affermare che ogni esempio di Orangutan (un animale) è un
esempio di Specie.
Motivazione: Interoperabilità
dell’ontologia
- R14. Limitazioni di cardinalità
-
Il linguaggio deve supportare la specificazione delle limitazioni di
cardinalità delle proprietà. Queste restrizioni determinano il numero minimo e
il numero massimo d’individui con cui ogni singolo individuo possa essere
correlato attraverso la proprietà specificata.
Motivazione: Bilancio tra espressività e
selezione, Scoperta
d’incoerenze
- R15. Sintassi XML
-
Il linguaggio dovrebbe avere una sintassi di serializzazione XML.
L’industria ha accettato ampliamente il XML e si sono sviluppati numerosi
strumenti di processamento XML. Se il linguaggio ontologico del web ha una
sintassi XML, questi strumenti potrebbero essere estensi e riusati.
Motivazione: Compatibilità con altri
standard
- R16. Etichette
User-displayable
-
Il linguaggio dovrebbe supportare la specificazione di molte etichette
user-displayable alternative per le risorse specificate dall’ontologia. Si
potrebbero usare, per esempio, per vedere l’ontologia in diversi linguaggi
naturali.
Motivation: Internazionalizzazione,
Facilità d’uso
- R17. Supportare
un modello di carattere
-
Il linguaggio dovrebbe supportare l’uso di set di caratteri
plurilingue.
Motivazione: Internazionalizzazione,
Compatibilità con
altri standard
- R18. Supportare
l’unicità di sequenze Unicode
-
In alcune codificazioni di caratteri, per esempio codificazioni basate su
Unicode, vi sono casi in cui due sequenze diverse di caratteri sembrano uguali
e la maggioranza degli utenti aspetta che siano uguali. Un esempio: una che
usi una forma precomposta (come un carattere c-cediglia) e altra che usi una
forma scomposta (un carattere 'c' seguito di un carattere accento cediglia).
Siccome la W3C I18N WG ha deciso quest’ultima normalizzazione uniforme (a
Unicode Normal Form C) come l’approccio usuale per risolvere questo problema,
qualsiasi altra soluzione dovrebbe essere giustificata.
Motivazione: Internazionalizzazione,
Compatibilità con
altri standard
5 Obiettivi
Insieme al set di caratteristiche che dovrebbe avere il linguaggio (come sono
state definite nella sezione previa), vi sono altre caratteristiche che
potrebbero essere utili in molti casi d’uso. Il working group potrebbe esaminare
queste caratteristiche se fosse possibile, ma il group può decidere che vi sono
buone ragioni per escluderle dal linguaggio o per lasciarle per una posteriore
implementazione da parte di un working group posteriore. Alcuni di questi
obiettivi non sono pienamente definiti, e perciò bisognano una posteriore
chiarificazione se il linguaggio s’indirizzasse in questa direzione. L’ordine
degli obiettivi che s’enunciano sotto non implica priorità relativa o grado di
consenso.
- O1. Margotta delle
caratteristiche del linguaggio
-
Il linguaggio può supportare diversi livelli di complessità per definire
ontologie. Le applicazioni possono essere conformi ad un particolare strato
senza supportare l’intero linguaggio. Una linea guida per identificare strati
può basarsi sulla funzionalità che si trova in diversi tipi di database e
sistema di conoscenza base.
Motivazione: Bilancio tra espressività e
selezione
- O2. Valori per
default delle proprietà
-
Il linguaggio dovrebbe supportare la specificazione dei valori per default
delle proprietà. Questi valori potrebbero essere usati per fare inferenze su
membri tipici delle classi. Comunque, i veri valori per default (come quelli
usati in ragionamenti d’eredità frustrabili) non sono monotonici, e questo può
essere problematico nel Web, nel quale costantemente si scopre o si aggiunge
nuova informazione. Inoltre, non vi è un metodo comunemente accettato di
trattare con default. Un’alternativa è che la specificazione del linguaggio
raccomandi agli utenti su come creare i propri meccanismi di default.
Motivazione: Bilancio tra espressività e
selezione
- O3. Abilità di
creare mondi chiusi
-
Per la dimensione e la velocità del cambio nel Web, le assunzioni di
mondi chiusi (che stipulano che qualsiasi cosa che non possa essere
inferita è assunta come falsa) non è appropriata. In ogni modo, vi sono molti
situazioni nelle quali l’informazione “mondo-chiuso” sarebbe utile. Dunque, il
linguaggio deve essere capace di dichiarare che un’ontologia data deve essere
considerata come completa. Con questo si potrebbero tracciare inferenze
addizionali a quell’ontologia. La semantica precisa d’una tale dichiarazione
(e il corrispondente set d’inferenze) aspetta la sua definizione, ma gli
esempi potrebbero includere l’assunzione d’informazione completa di proprietà
su individui, assumendo la completezza dell’appartenenza ad una classe e
l’esauribilità delle subclassi.
Motivazione: Ontologie
condivise, Scoperta
d’incoerenze
- O4. Serie di
restrizioni in data type
-
Il linguaggio dovrebbe supportare l’abilità di specificare serie di valori
per le proprietà. Questo meccanismo si potrebbe prendere in prestito dai data
type dello Schema XML [XML-SCHEMA2].
Motivazione: Scoperta
d’incoerenze
- O5.
Proprietà incatenate
-
Il linguaggio può supportare la composizione delle proprietà in
dichiarazioni su classi e proprietà. Un esempio di composizione di proprietà
sarebbe l’asserzione: una proprietà chiamata uncleOf è uguale alla
composizione delle proprietà fatherOf e brotherOf.
Motivazione: Bilancio tra espressività e
selezione
- O6. Procedura per decisioni
effettive
-
Il linguaggio deve essere capace di prendere decisioni.
Motivazione: Bilancio tra espressività e
selezione
- O7. Referenza a parti
delle ontologie
-
Il linguaggio deve supporterà l’abilità di riferirsi a parti di
un’ontologia, e riferirsi anche ad un’intera ontologia. Comunque, non è chiaro
il grado di granularità che deva usarsi per questo. Le possibili scelte sono
un subset di concetti con le intere definizioni oppure pezzi individuali di
definizioni. Se si prende in prestito definizioni parziali di concetti si deve
esaminare i potenziali problemi d’interoperabilità che possano risultare
dell’uso di diverse applicazioni con lo stesso identificatore per significare
cose diverse.
Motivazione: Ontologie
condivise
- O8. Meccanismi di vista
-
Il linguaggio dovrebbe supportare l’abilità di creare ontologie di viste,
nelle quali i subset di un’ontologia si possano specificare o si possano
assegnare nomi alternati ai concetti. Questo è particolarmente utile nello
sviluppo di versioni multiculturali di un’ontologia. Questo requisito può
compiersi se vi sono molte ontologie e si usa un meccanismo di formazioni di
mappe in un’ontologia.
Motivazione: Internazionalizzazione,
Interoperabilità
dell’ontologia
- O9.
Integrazione di firme digitali
-
La specificazione W3C su Firma Digitale XML è un importante elemento per la
comunicazione tra proprietà non affidabili, e ciò è importante per molte
applicazioni ontologiche. Il linguaggio ontologico del web dovrebbe disegnarsi
per essere compatibile con l’uso di Firme XML.
Motivazione: Compatibilità con altri
standard
- O10. Primitivi
aritmetici
-
Il linguaggio dovrebbe supportare l’uso di funzioni aritmetiche. Questo si
può usare per traduzioni tra diverse unità di misura.
Motivazione: Interoperabilità
dell’ontologia
- O11.
Manipolazione di sequenze
-
Il linguaggio dovrebbe supportare concatenazioni di sequenze e l’accoppiare
di modelli semplici. Queste caratteristiche si potrebbero usare per stabilire
interoperabilità tra ontologie che trattino informazione complessa come una
sequenza configurata e quelle che abbiano proprietà separate per ogni
componente. Per esempio, un’ontologia può rappresentare un indirizzo e-mail
come una sequenza semplice mentre altra può dividerla in una sequenza per nomi
dell’utente e altra per il nome del server. Per integrare le due ontologie, si
dovrebbe specificare che la concatenazione del nome dell’utente, il carattere
'@', e il nome del server sono equivalenti al valore semplice usato nella
prima ontologi.
Motivazione: Interoperabilità
dell’ontologia
- O12. Aggregazione e
raggruppamento
-
Il linguaggio dovrebbe supportare l’abilità di aggregare informazione in
una maniera simile a quella della clausola SQL's GROUP BY. Dovrebbe permettere
calcoli, addizioni e altre operazioni a calcolarsi per ogni gruppo. Questo
permetterebbe anche l’interoperabilità tra ontologie che rappresentino
informazione a diversi livelli di granularità, e potrebbe riferire cose come i
totali di ogni categoria di un preventivo agli importi dell’item linea di
preventivo, o il numero d’impiegati ai dati individuali degli impiegati.
Motivazione: Interoperabilità
dell’ontologia
- O13.
Procedure di connessione
-
Il linguaggio dovrebbe supportare l’uso di codici eseguibili per valutare
criteri complessi. Le procedure di connessione estendono molto l’espressività
del linguaggio, ma non s’accomodano bene alla semantica formale. Un meccanismo
di procedura di connessione per le ontologie web dovrebbe specificare come
localizzare ed eseguire la procedura. Un linguaggio che potrebbe essere il
candidato potenziale sarebbe Java, che è già adatto a intra-platform sharing
nella Web.
Motivazione: Interoperabilità
dell’ontologia
- O14. Assunzioni di nomi locali
unici
-
In generale, il linguaggio non farà un’assunzione di nomi unici.
Cioè, i diversi identificatori non si presumono come facendo referenza a
diversi individui (si veda il Requisito R11).
In ogni modo, vi sono molte applicazione nelle quali l’assunzione di nomi
unici sarebbe utile. Gli utenti dovrebbero avere l’opzione di specificare che
tutti i nomi in un singolo namespace o documento si riferiscono a individui
diversi.
Motivazione: Scoperta
d’incoerenze
- O15. Data
type complessi
-
Il linguaggio dovrebbe supportare la definizione e l’uso di data type
complessi/ strutturati, per specificare date, coppie coordinate, indirizzi,
ecc.
Motivazione: Compatibilità con altri
standard, Facilità d’uso
Riferimenti
- [DWM]
- Industrial
Strength Ontology Management, Aseem Das, Wei Wu, e Deborah L.
McGuinness. In Isabel Cruz, Stefan Decker, Jerome Euzenat, e Deborah L.
McGuinness, curatori. The Emerging Semantic Web. IOS Press, 2002.
http://www.ksl.stanford.edu/people/dlm/papers/ontologyBuilderVerticalNet-abstract.html
- [Hef]
- Towards
the Semantic Web: Knowledge Representation in a Dynamic, Distributed
Environment, Jeff Heflin. Ph.D. Thesis, University of Maryland,
College Park. 2001. http://www.cse.lehigh.edu/~heflin/pubs/#heflin-thesis
- [RDF Concepts]
- Resource
Description Framework (RDF): Concepts and Abstract Syntax, Graham
Klyne e Jeremy J. Carroll, Curatori, W3C Recommendation, 10 Febbraio 2004,
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ . Ultima versione disponibile
presso http://www.w3.org/TR/rdf-concepts/ .
- [RDF Syntax]
- RDF/XML
Syntax Specification (Revised), Dave Beckett, Curatore, W3C
Recommendation, 10 Febbraio 2004,
http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/ . Ultima versione
disponibile presso http://www.w3.org/TR/rdf-syntax-grammar/ .
- [RDF Vocabulary]
- RDF
Vocabulary Description Language 1.0: RDF Schema, Dan Brickley and
R. V. Guha, Curatori, W3C Recommendation, 10 Febbraio 2004,
http://www.w3.org/TR/2004/REC-rdf-schema-20040210/ . Ultima versione disponibile presso
http://www.w3.org/TR/rdf-schema/ .
- [XML]
- Extensible
Markup Language (XML) 1.0 (Second Edition), Tim Bray, Jean Paoli,
C. M. Sperberg-McQueen, Eve Maler, Curatori, W3C Recommendation, 6 Ottobre
2000, http://www.w3.org/TR/2000/REC-xml-20001006. Ultima versione disponibile presso
http://www.w3.org/TR/REC-xml .
- [XML-SCHEMA2]
- XML
Schema Part 2: Datatypes, Paul V. Biron e Ashok Malhotra, Curatori,
W3C Recommendation, 2 Maggio 2001.
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ . Ultima versione disponibile
presso http://www.w3.org/TR/xmlschema-2/ .
Appendix A: Change Log
I cambiamenti effettuati fin dalla Raccomandazione Proposta sono elencati in
ordine cronologico inverso.
- Sezione referenze riformattate.
Riconoscimenti
Raphael Volz e Jonathan Dale hanno effettuato contributi autoriali
significativi a questo documento, e insieme all’attuale curatore, sono stati
curatori dei progetti iniziali di lavoro. Lo sforzo iniziale per identificare
gli scopi del progetto e i requisiti è stato co-diretto tra il curatore e
Deborah McGuinness. Il Dr. McGuiness [DWM] ha contribuito
direttamente con alcuni dei requisiti, sulla base di un decennio di lavoro nella
costruzione di sistemi basati in ontologie. Altri requisiti sono stati
identificati come parte della tesi di laurea del curatore, che consisteva in
costruire un prototipo di sistema di Semantica Web [Hef]. Un progetto della
sezione Management Aziendale di Siti Web è stato scritto da Michael Smith.
Il contenuto di questo documento è il risultato di larghe discussioni fra
tutti i partecipanti del Web
Ontology Working Group . Alcuni partecipanti furono: Yasser alSafadi,
Jean-François Baget, James Barnette, Sean Bechhofer, Jonathan Borden, 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, Ruediger
Klein, Natasha Kravtsova, Ora Lassila, Deborah McGuinness, Enrico Motta, Leo
Obrst, Mehrdad Omidvari, Martin Pike, Marwan Sabbouh, Guus Schreiber, Noboru
Shimizu, 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, Frederik Brysse, Francesco Iannuzzelli,
Massimo Marchiori, Michael Sintek e John Yanosy.
Associating Style Sheets with XML
documents
XML-Signature XPath Filter 2.0
XPointer element() Scheme
XPointer Framework
XPointer xmlns() Scheme
XML Inclusions (XInclude) Version
1.0
XML-binary Optimized
Packaging
xml:id Version 1.0
XML Information Set (Second
Edition)
OWL Web Ontology Language - Use Cases
and Requirements
Ruby Annotation in Spanish
Ruby Annotation in Italian
SOAP Introduction