Tecniche di gestione delle meta-informazioni nel Semantic

Transcript

UNIONE EUROPEA
FONDO EUROPEO DI SVILUPPO REGIONALE.
REGIONE PUGLIA
AREA POLITICHE PER LO SVILUPPO IL LAVORO E L’INNOVAZIONE
Modello M14 – Allegati RTA
POR PUGLIA 2007-2013 - Asse I Linea 1.1 – Azione 1.1.2
Bando “Aiuti agli Investimenti in Ricerca per le PMI”
BENEFICIARIO
Code Architects S.r.l.
TITOLO DEL PROGETTO
SWOP
Semantic web-service Opened Platform
CODICE DEL PROGETTO
B2SO201
RAPPORTO TECNICO ATTIVITA‟:
A 2.2 (OR2) - Analisi delle tecniche per l’utilizzo delle metainformazioni e delle ontologie esistenti nel Semantic Web
Allegato 2 - D2.2 – Tecniche di gestione delle metainformazioni nel Semantic Web e analisi delle ontologie
esistenti
Indice dei contenuti
1. CONTENUTO DELL’ ALLEGATO ...................................................... 4
2. CORPO DELL’ALLEGATO ................................................................. 5
2.1 Il Semantic Web ......................................................................... 5
2.1.1 Resource Description Framework (RDF) .......................................7
2.1.2 Web Ontology Language (OWL) ................................................ 10
2.1.3 I ragionatori ........................................................................... 14
2.1.3.1 Fact++ ............................................................................ 14
2.1.3.2 Racer ............................................................................... 16
2.1.3.3 Pellet ............................................................................... 17
2.2 La gestione della conoscenza nella piattaforma SWOP ............. 18
2.2.1 Una semplice metodologia di sviluppo di ontologie ...................... 19
2.2.2 Protégé 4 ............................................................................... 21
2.2.3 Il caso d‟uso per la piattaforma SWOP ....................................... 22
2.2.4 Dominio e scopo dell‟ontologia .................................................. 24
2.2.5 I moduli dell‟ontologia ............................................................. 26
2.3 Ontologie esistenti per il dominio Enterprise ............................ 27
2.3.1 Le ontologie e le imprese ......................................................... 27
2.3.2 I processi aziendali e la loro rappresentazione sintattica .............. 28
2.3.3 Le ontologie formali esistenti .................................................... 30
2.3.3.1 Standard per la classificazione di prodotti e servizi ................ 30
2.3.3.2 Standard per la classificazione dei processi aziendali .............. 31
2.3.3.3 NeOn - UBL Invoice Ontology .............................................. 32
2.3.3.4 DIP - Business Data Ontology ............................................. 35
2.3.3.5 SET Harmonized Ontology .................................................. 38
2.3.3.6 GoodRelations ................................................................... 39
2.3.3.7 Le ontologie del progetto SUPER .......................................... 48
2.3.3.8 Business Management Ontology .......................................... 49
2.3.3.9 ONTOMODA-ML ................................................................. 58
2.4 Progettazione dell’ontologia SWOP .......................................... 60
2.4.1 Costruzione dell‟ontologia BusinessObject .................................. 61
2.4.1.1 Enumerazione dei termini e dei concetti ............................... 61
2.4.1.2 Organizzazione dei concetti in una gerarchia ......................... 62
2.4.1.3 Definizione di proprietà e restrizioni ..................................... 63
2.4.2 La classe top-level Business Obejct ........................................... 64
2.4.2.1 La classe BusinessObject estesa per il dominio enterprise ....... 66
2.4.2.2 La classe Concept estesa per il dominio Enterprise ................. 67
2.4.2.3 La classe Attribute estesa per il domino enterprise................. 74
2.4.3 Le Object Property della Business Object Ontology ...................... 79
2.4.4 Le Data Property della Business Object Ontology ........................ 81
2.4.5 Le ontologie per modellare i servizi ........................................... 82
2.4.5.1 Categories Ontology .......................................................... 82
2.4.5.2 Business Process Ontology .................................................. 84
2.4.5.3 Services Ontology............................................................. 87
Beneficiario: Code Architects S.r.l. Progetto: B2SO201
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 2 di 104
2.4.5.4 Swop Integration Ontology ................................................ 94
2.5 Bibliografia............................................................................. 100
3. APPENDICI ................................................................................ 102
3.1 Dati riepilogativi dell‟ontologia SWOP ............................................ 102
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 3 di 104
1.
Contenuto dell’ Allegato
Obiettivo di questo allegato è presentare l‟ontologia modellata per rispondere
alle esigenze di rappresentazione della conoscenza della piattaforma SWOP. Il
caso d‟uso considerato è quello dei processi aziendali legati alla vendita e
all'acquisto di prodotti, al recupero delle informazioni dei clienti e così via.
L'ontologia sviluppata modella sia le caratteristiche funzionali sia le
caratteristiche non funzionali di un web service.
Per prima cosa vengono illustrati i principali formalismi di rappresentazione
della conoscenza per il Semantic Web, con particolare riferimento ad OWL, il
linguaggio utilizzato per lo sviluppo dell'ontologia.
Successivamente viene ripresa l‟architettura di massima della piattaforma
SWOP ed il caso d‟uso scelto, in modo da definire le esigenze semantiche della
piattaforma SWOP e produrre quindi una visione d‟insieme dei requisiti
dell‟ontologia SWOP.
Per facilitare lo sviluppo dell'ontologia, sono stati individuati alcuni esempi di
ontologie esistenti che rappresentano il dominio enterprise e vengono
presentate alcune linee guida utilizzabili per la definizione di un‟ontologia del
dominio enterprise (standard di classificazione e modellazione dei processi).
Infine, vengono descritte le ontologie sviluppate in termini di classi, proprietà
e restrizioni. Le ontologie principali sono le seguenti: un‟ontologia del dominio
enterprise per il caso d‟uso del progetto, un'ontologia delle categorie
tassonomiche, un‟ontologia funzionale ed un‟ontologia dei servizi.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 4 di 104
2. Corpo dell’Allegato
2.1 Il Semantic Web
L‟obiettivo del Semantic Web [1] è lo sviluppo di tecnologie e standard
progettati per rendere le informazioni presenti sul Web comprensibili alle
macchine. Per raggiungere questo obbiettivo sono stati formalizzati i principi
[2] sui quali dovrà poggiare il Semantic Web e la sua architettura.
Figura 1 - L’architettura del Semantic Web
L‟architettura de Semantic Web (Figura 1) è composta da strati sovrapposti
che, partendo dalla base, forniscono:
 un meccanismo per l‟identificazione univoca delle risorse;
 uno strato di mark-up, cosicché le risorse possano auto-descriversi;
 un modello per la rappresentazione della conoscenza;
 lo strato delle ontologie per esprimere concetti;
 lo strato logico in grado di fare inferenze per dedurre le implicazioni
delle definizioni dei termini e le loro relazioni;
 un meccanismo in grado di dimostrare la veridicità delle informazioni
(proof);
 un meccanismo per garantire l‟affidabilità (trust).
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 5 di 104
Il primo strato utilizza standard e tecnologie sviluppate e largamente utilizzate
nel Web. Queste sono utili poiché specificano un meccanismo per identificare
le risorse (URI1) e una codifica non ambigua del contenuto testuale
(UNICODE2). A partire da questo strato sono stati rilasciati alcuni standard che
soddisfano i requisiti emersi per alcuni dei livelli dell‟architettura, in
particolare questi:
 garantiscono interoperabilità sintattica ai dati attraverso XML [3];
 forniscono un framework in grado di rappresentare meta-informazioni
che riguardano tali dati con RDF;
 utilizzano una semantica formale (dapprima con RDF Schema ed in
seguito con OWL), rappresentando mediante ontologie l‟organizzazione
(tassonomica e non) di tali meta-dati.
Attualmente il lavoro della comunità di ricerca è incentrato sul livello logico.
La sua implementazione consentirà di asserire principi logici permettendo alle
macchine di inferire nuova conoscenza applicando questi principi logici ai dati
esistenti. Poiché vi sono molti sistemi d‟inferenza presenti sul Web che non
sono completamente interoperabili, l‟obiettivo è quello di sviluppare un
linguaggio logico universale in grado di rappresentare le dimostrazioni logiche
così da abilitare il loro scambio nel Semantic Web. Il completamento del livello
logico è di fondamentale importanza per la costruzione dei due livelli
superiori. Poiché l‟utilizzo dei meta-dati permetterà di asserire qualsiasi cosa
su qualsiasi altra cosa, si verificheranno situazioni in cui si affermerà qualcosa
da qualche parte e l‟esatto contrario da un‟altra parte. I livelli Proof e Trust
serviranno per risolvere conflitti di questo tipo mediante l‟inserimento di
meccanismi che verificheranno la veridicità delle informazioni presenti nel
Semantic Web (Firma digitale, catene di fiducia, ecc.). La proposta di
linguaggio più accreditata in questo momento a livello logico è Semantic Web
Rule Language (SWRL).
Nel corso dello sviluppo dei vari standard sono nati strumenti (reasoner) in
grado di elaborare l‟informazione, o più propriamente la conoscenza, descritta
attraverso detti linguaggi. L‟obiettivo generale dei reasoner (strumenti per
l‟automazione dell‟inferenza) è quello di esplicitare l‟informazione implicita e
valutare la coerenza delle basi di conoscenza in esame.
Nei prossimi paragrafi esamineremo i livelli fin qui sviluppati per la
modellazione della conoscenza comprensibile dalle macchine (RDF, Ontologico
e Logico) e le relative tecnologie.
1
W3C Architecture Domain, “Naming and Addressing: URIs, URLs, ...”, available at:
http://www.w3.org/Addressing/
2
Unicode Home Page : http://www.unicode.org
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 6 di 104
2.1.1 Resource Description Framework (RDF)
RDF (Resource Description Framework) [4] è uno standard del W3C progettato
per la definizione e il trattamento di meta-dati nel contesto del Semantic Web.
W3C descrive RDF come un linguaggio per la rappresentazione di informazioni
inerenti risorse Web. Una caratteristica importante di RDF è la possibilità di
scambiare meta-dati tra applicazioni preservando il loro il significato [5]. RDF
ha le seguenti caratteristiche:
 un modello dei dati semplice [6];
 una semantica formale [7];
 utilizza un vocabolario (basato sulle URI) estendibile (RDFSchema)
[8];
 è serializzabile in tre modi differenti, ma equivalenti (con XML,
attraverso triple, o come un grafo);
 permette a chiunque di creare asserzioni su qualunque risorsa.
Il modello dei dati RDF
RDF fornisce un modello per descrivere le risorse. Le risorse hanno delle
proprietà (o anche attributi o caratteristiche). RDF definisce una risorsa come
un qualsiasi oggetto che sia identificabile univocamente mediante un Uniform
Resource Identifier (URI). Il modello dei dati di RDF è molto semplice, ed è
basato su tre tipi di oggetti:
 Resource - Qualunque cosa descritta da un‟espressione RDF è detta
risorsa (resource). Una risorsa può essere una pagina Web, o una sua
parte, o un elemento XML all‟interno del documento sorgente. Una
risorsa può anche essere un‟intera collezione di pagine web, o anche
un oggetto non direttamente accessibile via Web (per es. un libro, un
dipinto, etc.). Le risorse sono sempre individuate da una URI.
 Property - Una proprietà (property) è un aspetto specifico, una
caratteristica, un attributo, o una relazione utilizzata per descrivere
una risorsa. Ogni proprietà ha un significato specifico, definisce i valori
ammissibili, i tipi di risorse che possono essere descritte, e le sue
relazioni con altre proprietà. Le proprietà associate alle risorse sono
identificate da un nome, e assumono dei valori.
 Statement - Una risorsa, con una proprietà distinta da un nome, e un
valore della proprietà per la specifica risorsa, costituisce un RDF
statement. Uno statement è quindi una tupla composta da un soggetto
(risorsa), un predicato (proprietà) e un oggetto (valore). L‟oggetto di
uno statement può essere un‟espressione (sequenza di caratteri o
qualche altro tipo primitivo definito da XML) oppure un‟altra risorsa.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 7 di 104
Graficamente, le relazioni tra Resource, Property e Value sono rappresentate
mediante grafi etichettati orientati, in cui le risorse vengono identificate come
nodi (graficamente delle ellissi), le proprietà come archi orientati etichettati, e
i valori (corrispondenti a sequenze di caratteri) come rettangoli. Un insieme di
proprietà che fanno riferimento alla stessa risorsa viene detto descrizione
(description). Un esempio di descrizione RDF rappresentata mediante grafo è
quella di Figura 2.
Figura 2 - Un grafo RDF che descrive Eric Miller
Per evitare la verbosità nelle descrizioni si utilizzano nomi fittizi che
individuano i namespace3, cioè si dichiara un nome fittizio per identificare la
URI.
3
Namespaces
in
XML
1.0
(Second
Edition),
W3C
Recommendation
2006.
http://www.w3.org/TR/REC-xml-names/
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 8 di 104
RDFSchema
RDF consente di definire un semplice modello dei dati per descrivere le
proprietà delle risorse e loro relazioni. In RDF però non esistono livelli
d‟astrazione: ci sono le risorse e le loro relazioni, tutte organizzate in un grafo
piatto. In altri termini non è possibile definire tipi (o classi) di risorse con loro
proprietà specifiche, per questo motivo RDF è stato arricchito con un semplice
sistema di tipi detto RDF Schema. In RDF Schema una risorsa può essere
definita come istanza di una classe (o di più classi) e le classi possono essere
organizzate in modo gerarchico. RDF Schema utilizza il modello RDF stesso
per definire il sistema dei tipi, fornendo un insieme di risorse e proprietà
predefinite che possono essere utilizzate per definire classi e proprietà a livello
utente. L‟insieme delle risorse e delle proprietà di base delle risorse è detto
vocabolario.
Le definizioni di classi in RDF Schema si basano su due classi predefinite
(rdf:Resource e rdf:Class) e due proprietà predefinite (rdf:type e
rdf:subClassOf). La classe rdf:Resource è la classe di base di RDF Schema, in
quanto ogni oggetto definito in RDF è una risorsa. Attraverso la proprietà
rdf:type è possibile specificare che una risorsa è una istanza di una classe. Si
osservi che anche le classi sono risorse. Quando si definisce una nuova classe
si
specifica
come
valore
di
rdf:type
la
risorsa
predefinita
http://www.w3c.org/2000/01/rdf-schema#Class. Una risorsa può essere
istanza di più classi. rdf:subClassOf consente di definire relazioni di
sovra/sotto-insieme fra le classi. La relazione rdf:subClassOf è transitiva.
In generale le classi sono caratterizzate da proprietà. A differenza di quanto
accade in molti linguaggi, in RDF Schema proprietà e classi hanno definizioni
separate e, in particolare, le proprietà sono definite in termini sia delle classi
che costituiscono il loro range sia delle classi a cui tali proprietà si applicano
(e non le classi in termini di proprietà). Le proprietà possono essere definite
utilizzando la risorsa predefinita rdf:Property con le proprietà predefinite:
rdf:domain, rdf:range, rdf:subPropertyOf. Il valore di rdf:range indica la
classe alla quale appartengono le risorse che la proprietà definita può
assumere come valori. rdf:domain specifica che la proprietà si applica a
risorse di una certa classe. Una proprietà può avere diversi rdf:domain
specificati ma se non ne ha nessuno è valida in generale e può essere usata
per tutte le risorse. Quindi di default lo scope di una proprietà è l‟universo; è
poi possibile restringerlo tramite opportune specifiche. Sebbene questa scelta
riduca il controllo sull‟appropriatezza d‟uso delle proprietà, consente di
estendere facilmente l‟uso di proprietà a situazioni non previste da chi le ha
inizialmente definite. In Figura 3 è riportato un esempio di gerarchia di classi
in RDFSchema.
RDF Schema è un linguaggio che consente di definire vocabolari RDF in modo
molto basilare.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 9 di 104
Vi sono alcune capacità espressive necessarie per esprimere vocabolari che si
coniugano con gli obiettivi del Semantic Web. In particolare, RDFSchema non
ha le seguenti capacità espressive:
1. vincoli di cardinalità (es. una persona ha una sola madre e un solo
padre);
2. possibilità di indicare che due classi definite in schemi differenti
rappresentano lo stesso concetto;
3. possibilità di indicare che due istanze, definite separatamente,
rappresentano lo stesso individuo;
4. possibilità di indicare che una proprietà è transitiva;
5. possibilità di definire una nuova classe come combinazione di più classi
esistenti.
La definizione e la realizzazione di queste capacità espressive sono lo scopo
dei gruppi di lavoro sui linguaggi per la definizione di ontologie.
Figura 3 - Un esempio di gerarchia di classi in RDFSchema
2.1.2 Web Ontology Language (OWL)
Il linguaggio standard per la definizione di ontologie è OWL [10]. Il W3C
raccomanda OWL 2 per la creazione di ontologie. OWL, che è un estensione di
RDFS, comprende tre sotto-linguaggi utilizzabili in base alle esigenze
espressive che emergono durante la fase di progettazione dell‟ontologia:
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 10 di 104



OWL Lite è utile quando nella costruzione dell‟ontologia si ha bisogno
soltanto di gerarchie di classificazione e restrizioni semplici sulle
proprietà.
OWL DL è utile quando è necessaria la massima espressività
mantenendo la completezza computazionale e la decidibilità.
L‟acronimo DL sta per Description Logic, il linguaggio logico alla base di
OWL.
OWL Full è utile quando si ha bisogno del massimo potere espressivo
e della libertà sintattica di RDF senza che vi siano garanzie
computazionali (in pratica è utile solo per la rappresentazione dei
contenuti, ma non per il loro utilizzo).
Ognuno di questi sotto-linguaggi è un‟estensione del suo predecessore, sia in
termini di cosa può essere rappresentato, sia in termini di cosa può essere
validamente dedotto dalle informazioni rappresentate. Vale il seguente
insieme di relazioni ma non il loro inverso:
 ogni ontologia OWL-Lite valida è una ontologia OWL-DL valida;
 ogni ontologia OWL-DL valida è una ontologia OWL-FULL valida;
 ogni conclusione valida in OWL-Lite è una conclusione valida in OWLDL;
 ogni conclusione valida in OWL-DL è una conclusione valida in OWLFULL.
Tutti i documenti OWL sono documenti RDF, e tutti i documenti RDF sono
documenti OWL-Full, ma non tutti i documenti RDF possono essere dei
documenti OWL-Lite e OWL-DL validi. Perciò la conversione di documenti RDF
in OWL è da effettuarsi con attenzione.
Anche quando l‟espressività di OWL-DL e OWL-Lite sembra appropriata,
devono essere adottate delle precauzioni per assicurare che il documento RDF
originale soddisfi i vincoli aggiuntivi di questi due sottolinguaggi. Tra tutti
ricordiamo i seguenti:
 ogni URI che è usato come nome di una classe, deve essere dichiarato
esplicitamente come un tipo owl:Class;
 ogni individuo deve appartenere ad almeno una classe;
 gli URI utilizzati per le classi, le proprietà e gli individui devono essere
entità disgiunte.
OWL eredita alcune caratteristiche dell‟RDF-Schema come: Class,
rdfs:subClassOf, rdf:Property, rdfs:subPropertyOf, rdfs:domain, rdfs:range,
Individual.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 11 di 104
Una tipica ontologia OWL comincia con una dichiarazione dello spazio dei nomi
(namespace) che fornisce un modo per l‟interpretazione non ambigua degli
identificatori. I nomi in OWL sono riferimenti a URI mentre i tipi di dato
corrispondono a quelli di XML Schema(4). Inoltre un‟ontologia può importare
informazioni relative ad altre ontologie.
Questi gli elementi base di un‟ontologia:
 classi;
 proprietà;
 istanze delle classi;
 relazioni tra le istanze.
Ogni nuova classe definita dall'utente è una sottoclasse di owl:Thing. Ognuna
delle espressioni che sono contenute all'interno della definizione della classe,
restringe le proprietà che possono essere applicate alle istanze della classe
definita. Le istanze della classe appartengono all'intersezione delle restrizioni
su di essa.
In aggiunta alle classi, OWL permette di descrivere anche i loro membri. Un
individuo è introdotto principalmente dichiarando la sua appartenenza ad una
classe. Gli individui rappresentano gli oggetti del dominio d‟interesse. OWL
permette che due nomi diversi si riferiscano al medesimo individuo. Deve
essere esplicitamente dichiarato se due individui sono equivalenti o diversi tra
loro, altrimenti è valida l‟assunzione che potrebbero essere equivalenti o
potrebbero essere diversi tra loro. Gli individui sono anche detti istanze o
istanze di classi.
OWL-Lite comprende costrutti per esprimere uguaglianza e disuguaglianza:
 equivalentClass: due classi sono equivalenti se condividono le stesse
istanze;
 equivalentProperty: due proprietà sono equivalenti se mettono in
relazione tutti gli individui a cui si riferiscono;
 sameAs: due individui sono identici. Il costrutto può essere usato per
creare diversi nomi che si riferiscono allo stesso individuo;
 differentFrom: un individuo è diverso da un altro. Dichiarare ciò in
maniera esplicita è utile con i linguaggi come OWL che non assumono
che gli individui abbiano uno ed un solo nome.
Le proprietà OWL sono relazioni binarie che permettono di asserire fatti
generali riguardo i membri delle classi e di asserire fatti specifici riguardo gli
individui. Si distinguono due tipi di proprietà:
 datatype property: relazioni tra le istanze delle classi ed elementi
letterali o tipi di dati;
 object property: relazioni tra le istanze di due classi.
4
http://www.w3.org/XML/Schema.html
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 12 di 104
Quando si definisce una proprietà si utilizzano alcuni meccanismi per
restringere tale relazione. I più semplici sono:
 specificare il dominio e l'intervallo (range) della proprietà;
 specializzare una proprietà esistente (sotto-proprietà), ma OWL ne
include molti altri che sono più specifici (property restrictions).
OWL-Lite comprende diversi costrutti sulle proprietà:
 inverseOf: una proprietà è l‟inversa di un‟altra .
 TransitiveProperty: due proprietà possono essere transitive. Se una
proprietà è transitiva, allora se la coppia (x,y) è una istanza della
proprietà transitiva P, e la coppia (y,z) è una istanza di P, allora la
coppia (x,z) è una istanza di P. OWL-Lite (e OWL-DL) impone che le
proprietà transitive non possano avere un vincolo di cardinalità
massima pari ad 1, altrimenti essi diverrebbero linguaggi indecidibili.
 SymmetricProperty: le proprietà possono essere simmetriche. Se
una proprietà è simmetrica, se la coppia (x,y) è una istanza della
proprietà simmetrica P, allora la coppia (y,x) è ancora una istanza di P.
 FunctionalProperty: le proprietà possono avere un solo valore. Se
una proprietà è funzionale non può avere più di un valore per
individuo, ma può comunque non avere valore per un individuo. Una
proprietà funzionale è equivalente ad una proprietà con cardinalità
minima pari a 0 e una cardinalità massima pari ad 1.
 InverseFunctionalProperty:
le
proprietà
possono
essere
inversamente funzionali. Se una proprietà è inversamente funzionale,
la sua inversa è funzionale, ovvero contiene al massimo un valore per
ogni individuo.
OWL-Lite permette di applicare restrizioni su come le proprietà possono essere
utilizzate dalle istanze delle classi. Le restrizioni sono specificate nel contesto
di una sezione owl:Restriction e l‟elemento owl:onProperty indica la proprietà
a cui viene applicata la restrizione, che possono essere le seguenti:
 allValuesFrom: si applica su una proprietà in relazione ad una classe.
Indica che la proprietà può essere valorizzata solo con individui
appartenenti alla classe specificata. In questo modo se un individuo A è
collegato ad un individuo B attraverso una proprietà con questa
restrizione, può essere automaticamente inferito che l‟individuo B
appartiene alla classe indicata dalla restrizione.
 someValuesFrom: si applica su una proprietà in relazione ad una
classe. Una classe potrebbe avere una restrizione in modo che una
proprietà abbia almeno un valore di un determinato tipo.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 13 di 104
OWL-Lite include una forma limitata di restrizione di cardinalità, che può
essere applicata solo localmente ad una proprietà in relazione ad una classe
specifica. Le restrizioni di cardinalità OWL-Lite sono limitate perchè
permettono solo valori di cardinalità pari a 0 o ad 1, quindi non permettono
valori di cardinalità arbitrari come in OWL-DL e OWL-Full quali:
 minCardinality: la cardinalità è specificata su una proprietà in
relazione ad una classe specifica. Se minCardinality ha valore pari ad
1, allora qualsiasi istanza di quella classe sarà in relazione tramite la
proprietà, con almeno un individuo. La proprietà richiede di essere
valorizzata per tutte le istanze della classe. In OWL-Lite le sole
cardinalità minime permesse sono 0 ed 1. Una cardinalità minima
uguale a 0 indica che la proprietà è opzionale per una classe.
 maxCardinality: la cardinalità è specificata su una proprietà in
relazione ad una classe specifica. Se maxCardinality ha valore pari ad
1, allora qualsiasi istanza di quella classe sarà in relazione tramite la
proprietà, con al più un individuo. Una cardinalità massima pari ad 1 è
anche chiamata proprietà funzionale o unica. In alcuni casi può essere
utile stabilire che certe classi non possono avere valori rispetto ad una
determinata proprietà, specificando una cardinalità massima pari a 0
alla proprietà applicata a quelle classi.
 cardinality: è presente per comodità nel caso in cui una proprietà di
una classe ha allo stesso tempo lo stesso valore per la cardinalità
minima e massima.
2.1.3 I ragionatori
2.1.3.1 Fact++
FaCT++ [10,11] è un reasoner per la logica descrittiva, basato sugli algoritmi
di ragionamento tableau. Supporta i linguaggi ontologici basati sulla logica
descrittiva ed espressi in OWL e OWL2. Esso incarna l‟evoluzione del
ragionatore FaCT: condivide gli stessi algoritmi testati ed ottimizzati di FaCT,
ma ha una diversa architettura interna ed utilizza il linguaggio C++, allo
scopo di accrescere l‟efficienza, la velocità e la portabilità del software. Nella
fase di preprocessing [12], il reasoner carica la base di conoscenza che viene
normalizzata e trasformata in una rappresentazione interna, alla quale
vengono applicate ottimizzazioni sintattiche. In seguito viene effettuata la
classificazione, selezionando l‟insieme di concetti che minimizza il numero di
test di sussunzione da effettuare. Il classificatore contiene un modulo
altamente ottimizzato che controlla la soddisfacibilità della base di
conoscenza.
FaCT++ offre i seguenti servizi:
 controlli sulla consistenza delle ontologie;
 controlli sulla soddisfacibilità di un singolo concetto/gruppo di concetti;
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 14 di 104


controlli sulle relazioni di sussunzione tra due concetti;
la classificazione dell‟intera ontologia, creando una tassonomia;
FaCT++ è attualmente il reasoner di default presente in Protégé 4. Esso
fornisce un supporto completo per la logica descrittiva SHIF(D). Inoltre, ha le
seguenti caratteristiche:
 interfaccia per la logica di primo ordine: FaCT++ è in grado di creare
problemi in logica del primo ordine, per il controllo della sussunzione e
della soddisfacibilità utilizzando la logica SHOIQ e una sintassi
standard che è supportata dalla maggior parte dei software per la
dimostrazione dei teoremi del primo ordine;
 supporto limitato agli individui: tutti gli individui sono trattati come
concetti, e il ragionamento è effettuato su una ontologia modificata.
Questo approccio elimina la perdita di inferenza nel caso in cui
l‟ontologia non contenga relazioni tra individui, una situazione che si
verifica per molte utili e diffuse ontologie. Anche se sono presenti
relazioni tra individui, è talvolta possibile ottenere risposte corrette a
interrogazioni sulla soddisfacibilità e/o sussunzione. In questo caso
FaCT++ fornisce la risposta assieme ad informazioni sulla sua
correttezza;
 incorporamento di regole di dominio e di range: il software di
ragionamento supporta nativamente i costrutti di dominio e range,
evitando di trattare questi ultimi come assiomi generali. Il processo di
ragionamento risulta più veloce rispetto al precedente FaCT.
FaCT++ è disponibile come:
 software stand-alone da invocare in modalità batch. Gli input, i
comandi e le opzioni per il programma, devono essere contenuti in un
file di configurazione;
 reasoner DIG, implementato come una libreria C++ dinamica. Una
classe Java inoltre, implementa l‟interfaccia DIGReasoner. Attraverso il
linguaggio DIG, uno standard per la descrizione di ontologie, è
possibile il dialogo tra reasoner e i software che gestiscono la
rappresentazione delle ontologie;
 servlet, accessibile via http utilizzando il linguaggio DIG ed utilizzabile
in qualsiasi ambiente server in grado di eseguire servlet, come Apache
Tomcat.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 15 di 104
2.1.3.2 Racer
RACER è l‟acronimo di Renamed Abox and Concept Expression Reasoner.
RacerPro [13] è il nome commerciale del software. RacerPro è nato come
strumento di lavoro nell‟ambito della logica descrittiva ed è basato sul
linguaggio Lisp. Poiché negli standard internazionali del semantic web, la
logica descrittiva costituisce la base per la formalizzazione delle ontologie,
RacerPro può essere utilizzato anche come strumento per la loro gestione.
RacerPro supporta ontologie OWL e può essere usato come reasoner in
ambienti come Protégé. Inoltre è adoperabile anche come base di dati RDF.
Il reasoner è in grado di processare ontologie OWL-Lite, OWL-DL e dati in
formato RDF, fornendo i seguenti servizi:
 controllo di consistenza dell‟ontologia e di un insieme di descrizioni di
dati;
 ricerca di relazioni di sussunzione implicite a partire dalle dichiarazioni
presenti nell‟ontologia;
 ricerca di sinonimi di risorse.
RacerPro è un sistema di rappresentazione della conoscenza che implementa
algoritmi di calcolo tableau altamente ottimizzati. Offre servizi di
ragionamento per T-Box e A-Box multiple. Il sistema implementa la logica
descrittiva ALCQHIR+ anche conosciuta come SHIQ. Tale logica è basata sulla
logica ALC ma è potenziata con restrizioni numeriche qualificate, gerarchia di
ruoli, ruoli inversi e ruoli transitivi.
RacerPro implementa lo standard DIG per l‟accesso via HTTP al reasoner
esponendo interfacce con cui le applicazioni possono dialogare utilizzando un
protocollo basato su XML.
Data una T-box possono essere effettuate query tra cui:
 verifica della sussunzione tra concetti;
 verifica della consistenza tra concetti ed individuazione di eventuali
errori di modellazione;
 individuazione delle relazioni padre-figlio dei concetti.
In una query è possibile specificare concetti come argomento, utilizzando sia
nomi predefiniti, sia parametri ed espressioni che potranno essere completate
anche dopo la fase di progettazione dell‟ontologia.
Su una A-box invece possono essere effettuate query come:
 verifica della consistenza tra A-box e T-box;
 verifica delle istanze nella A-box rispetto alle definizioni della T-box;
 recupero delle istanze nella A-box che corrispondono a dei concetti
della T-box;
 recupero delle istanze che soddisfano determinate condizioni applicate
all‟A-box e alla T-box;
 computazione dei filler di un ruolo in riferimento ad un determinato
individuo;
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 16 di 104

computazione del most specific concept (MSC) di un determinato
individuo.
RacerPro supporta il linguaggio di interrogazione SPARQL [14] ed introduce il
linguaggio di interrogazione nRQL (new Racer Query Language) che supporta
caratteristiche avanzate dell‟OWL come le annotazioni e le datatype property.
Inoltre nRQL è utilizzato come motore base per l‟implementazione di un
grande sottoinsieme del linguaggio di interrogazione OWL-QL(5), uno standard
per l‟interrogazione di documenti OWL, raccomandato dal W3C.
2.1.3.3 Pellet
Pellet
critici





[15] è un reasoner open-source che soddisfa alcuni requisiti considerati
per i reasoner del web semantico. Essi sono:
gestione degli individui e ragionamento sulla A-box;
assenza dell‟assunzione che un nome sia unico;
supporto dell‟implicazione logica (entailment);
supporto per le conjunctive query sull‟A-box;
supporto dei tipi di dato dell‟XML Schema.
Analisi e riparazione delle entità: tutte le basi di conoscenza in OWL sono
codificate in grafi RDF/XML. OWL-DL impone delle restrizioni sui grafi RDF e
assicurare che i documenti RDF/XML le rispettino, è oneroso per gli autori.
Inoltre molti documenti OWL sono OWL-Full, anche quando i loro autori
desideravano produrre documenti OWL-DL. Pellet incorpora delle euristiche
per individuare documenti OWL-Full che è possibile trasformare in OWL-DL e
riesce autonomamente ad effettuarne la conversione.
Ragionamento sui tipi di dato: XML Schema ha un ricco insieme di tipi di
dato semplici e meccanismi, sia standard che inusuali, per creare nuovi tipi di
dato a partire dai tipi base. Pellet è in grado di testare la soddisfacibilità dei
tipi di dato definiti e congiunti.
Pellet è basato sugli algoritmi tableau sviluppati per la logica descrittiva e
supporta tutti i costrutti di OWL-DL, ha performance variabili ma molto
interessanti in alcuni casi, ha un insieme di caratteristiche uniche ed è
estensivamente integrabile poiché è contornato da numerosi middleware.
Inoltre è utilizzato in ambienti di ricerca ed industriali.
Pellet è in grado di verificare la consistenza di entità che usano OWL-DL nella
sua interezza. Oltre alla verifica di consistenza Pellet fornisce l‟insieme
considerato standard di 4 servizi utili e necessari per l‟inferenza per mezzo
della logica descrittiva:
5
http://www.w3.org/TR/owl2-profiles/#OWL_2_QL_2
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 17 di 104




controllo di consistenza: assicura che l‟ontologia non contenga
affermazioni contradditorie. Usando la terminologia della logica
descrittiva, questa operazione consiste nel verificare la consistenza di
una A-box in relazione ad una T-box;
soddisfacibilità dei concetti: controlla se è possibile che una classe
abbia delle istanze. Se una classe è insoddisfacibile, definendone una
istanza, si rende inconsistente l‟intera ontologia;
classificazione: computa le relazioni di sottoclasse e superclasse tra le
classi per creare una gerarchia completa;
realizzazione: individua le classi più specifiche a cui appartiene un
individuo.
Pellet riconduce tutti questi servizi al controllo di consistenza. Si può accedere
ad essi interrogando il reasoner, generalmente tramite una API, ad esempio
quelle delle interfacce DIG. Pellet supporta vari tipi di query e vari servizi di
gestione del reasoner, interfacciandosi a numerosi toolkit come Jena,
WonderWeb OWL API e DIG.
Pellet è un reasoner per la logica descrittiva ed è stato progettato per lavorare
con OWL sin dal principio. Questa scelta progettuale ne ha influenzato
l‟architettura e l‟implementazione del reasoner tableau. Pellet possiede un
piccolo motore di ragionamento facile da estendere e che facilita
l‟interfacciamento con altri software.
Pellet interpreta l‟ontologia OWL in un insieme di triple RDF, le valida e le
converte in assiomi ed asserzioni per la base di conoscenza. A questo livello,
se possibile, avviene la riparazione delle ontologie OWL-Full e la conversione
in OWL-DL. Le funzionalità di Pellet sono esposte da una API scritta in Java,
da riga di comando e da uno script per il web.
Pellet non è efficiente come RacerPro e FaCT++ per la classificazione ma ha
comunque performance accettabili. Inoltre in applicazioni pratiche queste
differenze prestazionali non sono significative. Al contrario, le performance di
Pellet sono superiori a quelle di RacerPro se si effettuano conjunctive query
sulle A-box.
2.2 La gestione della conoscenza nella piattaforma SWOP
I principali servizi della infrastruttura presentata nel deliverable D1.1 sono i
seguenti:
 Annotation Service: strumento con interfaccia grafica necessario
all‟elicitazione delle associazioni semantiche tra componenti del file
WSDL e concetti semantici contenuti all‟interno di ontologie di dominio.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 18 di 104

Discovery Service: strumento con interfaccia grafica necessario alla
formulazione di query complesse da sottoporre al sistema per ottenere
una lista di servizi semanticamente rilevanti rispetto alle query.
Nasce quindi l‟esigenza di individuare un insieme di ontologie con cui l‟intera
infrastruttura possa dialogare al fine di disambiguare il testo descrittivo
inserito dagli sviluppatori/annotatori ed arricchire semanticamente i servizi
web sintatticamente descritti dai rispettivi documenti WSDL. Sono quindi
necessarie delle ontologie di dominio (indispensabili per i concetti propri del
business aziendale) e delle ontologie lessicali (indispensabili per comprendere
la lingua con la quale si inseriscono le descrizioni testuali).
2.2.1 Una semplice metodologia di sviluppo di ontologie
Negli anni novanta è emerso un crescente interesse verso approcci per la
costruzione di ontologie from scratch, per il riuso di altre ontologie e per l‟uso
di metodi semi-automatici in grado di ridurre i tempi ed i costi del processo di
sviluppo di una ontologia.
Fino alla metà degli anni novanta questo processo era più un'arte che una
attività ingegneristica. Ogni gruppo di sviluppo seguiva un proprio insieme di
principi, criteri e fasi per costruire manualmente l‟ontologia. L‟assenza di linee
guida comuni e strutturate rallentava lo sviluppo di ontologie all‟interno dei
gruppi o in cooperazione, la possibilità di estendere o riusare una qualsiasi
ontologia e l‟uso delle ontologie nelle applicazioni finali.
Solo successivamente la comunità di ricerca si pose l‟obiettivo di esplorare
principi, scelte progettuali, regole e buone pratiche di modellazione, da cui
tutti gli ingegneri della conoscenza potessero trarre giovamento. Furono
indagate anche le metodologie di sviluppo e di valutazione delle ontologie, le
differenti attività previste nella loro costruzione e nel loro il ciclo di vita.
Le metodologie non sono state create solo per costruire nuove ontologie.
Quando si usa o si riusa una ontologia esistente, questa può essere
implementata in un linguaggio che utilizza un paradigma di rappresentazione
della conoscenza diverso da quello dell‟ontologia che si vuole riutilizzare. Per
risolvere questi problemi le metodologie possono includere anche metodi di
reingegnerizzazione.
Anche se uno degli scopi principali delle ontologie è velocizzare l‟acquisizione
della conoscenza, questo processo richiede ancora molto tempo e risorse. Di
conseguenza sono stati definiti anche metodi per un apprendimento
automatico delle ontologie, con lo scopo di crearne di nuove, arricchirne i
termini di quelle esistenti, e acquisire conoscenza per compiti specifici.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 19 di 104
Dato che possono esistere più ontologie che modellano in maniera differente
lo stesso tipo di conoscenza o dominio, esistono metodi per l‟allineamento e la
fusione di ontologie. I metodi di allineamento permettono di stabilire vari tipi
di mappatura tra ontologie, preservandole da cambiamenti e ristrutturazioni.
Invece i metodi di fusione portano a generare un‟unica ontologia a partire
dalle ontologie originali.
Anche il processo di fusione prevede la definizione di mappature o
collegamenti tra le ontologie da fondere. In riferimento allo stato attuale della
ricerca e dello sviluppo delle tecnologie, è preferibile effettuare una
mappatura tra ontologie che trattano uno stesso dominio, piuttosto che creare
da zero un modello unificato della conoscenza su tale dominio.
Ci sono delle regole che devono essere sempre tenute in considerazione
durante lo sviluppo di un‟ontologia [16]:
 non esiste una metodologia corretta a priori ma la soluzione migliore
dipende dall‟applicazione prevista e dalle sue estensioni future;
 lo sviluppo dell‟ontologia è necessariamente un processo iterativo;
 l‟ontologia deve riflettere la realtà del mondo da modellare.
Lo sviluppo di un‟ontologia può cominciare con la definizione del dominio e
dello scopo [17]:
1. Qual è il dominio che l‟ontologia deve coprire?
2. Quale utilizzo dobbiamo fare dell‟ontologia?
3. Per quali tipi di domande l‟informazione presente nell‟ontologia deve
fornire una risposta?
4. Chi utilizzerà e chi manterrà l‟ontologia?
5. Esistono ontologie disponibili che possono essere adottate, estese,
raffinate nel nostro dominio e obiettivo particolare?
Uno dei metodi per determinare lo scopo di un‟ontologia è quello di
individuare una lista di domande a cui la base di conoscenza, su cui si basa
l‟ontologia, deve sapere rispondere (competency questions) [18].
1. Lo sviluppo di un‟ontologia continua poi con questi semplici passi:
2. enumerare i termini importanti per l‟ontologia;
3. definire i concetti del dominio (classi);
4. organizzare i concetti in una gerarchia (sottoclassi e superclassi);
5. definire quali attributi e proprieta‟ hanno le classi e le restrizioni sui
valori;
6. definire gli individui e i valori che assumono le loro proprietà.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 20 di 104
2.2.2 Protégé 4
Tra i tool per lo sviluppo di ontologie in linguaggio OWL, il più famoso è
Protégé [19]. Protégé è uno strumento sviluppato dalla Stanford Medical
Informatics alla Stanford University School of Medicine. Consiste in una suite
Java multipiattaforma, gratuita ed open-source che offre strumenti per la
costruzione di modelli di dominio e di applicazioni basate sulla conoscenza
attraverso le ontologie. Protégé implementa un nutrito insieme di strutture e
di azioni per la modellazione della conoscenza, a supporto della creazione,
visualizzazione e manipolazione di ontology in diversi formati di
rappresentazione. La
Tabella 1 compara i principali costruttori di OWL con la sintassi di Protegé
(Manchester Syntax [20]):
Costruttori in OWL
intersectionOf
Sintassi in Protegé
and
unionOf
or
complementOf
not
someValueFrom
some
allValuesFrom
only
cardinality
exactly
hasValue
has
Tabella 1 – Protegè - La sintassi
Inoltre sono disponibili numerosi plug-in che arricchiscono le funzionalità di
Protegé. Protegé supporta OWL 2 DL e permette di integrare numerosi
ragionatori tra cui Pellet.
Protégé supporta due metodi per la modellazione delle ontologie. L‟editor
Protégé-Frames permette di costruire e popolare ontologie basate sui frame.
L‟editor Protégé-OWL permette di costruire ontologie per il web semantico in
linguaggio OWL. La semantica formale di OWL specifica come derivare
conseguenze logiche e dedurre fatti non presenti esplicitamente nell‟ontologia,
ma implicati dalla semantica. Le implicazioni possono essere basate sulle
proposizioni contenute in un singolo documento o in più documenti distribuiti
e combinati con i costrutti di OWL.
Protégé è il tool utilizzato per la realizzazione della base di conoscenza della
piattaforma SWOP, la versione di riferimento è la 4.02, mentre la versione del
ragionatore integrato in Protegè 4.02 è Pellet-Plugin 1.1.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 21 di 104
2.2.3 Il caso d’uso per la piattaforma SWOP
Come caso d‟uso per la piattaforma SWOP è stato selezionato un progetto di
esempio fornito da Microsoft©, Adventure Works [21] rappresentato da una
società fittizia che produce e vende biciclette. I servizi forniti alla società sono
quelli necessari ad interrogare una base dati relazionale contenente le
informazioni aziendali. Quelle elencate nella Tabella 2 sono le principali
tabelle presenti nel database Adventure Works ed utilizzate per recuperare i
dati di interesse:
Tabelle di Ad.Works
BillOfMaterials
Descrizione
Elenco di tutti i componenti utilizzati per produrre le biciclette e i
rispettivi componenti di assemblaggio.
Customer
Contiene informazioni relative alla clientela attuale. I clienti sono
classificati in base al tipo, ovvero cliente individuale (CustomerType
= „I‟) o punto vendita al dettaglio (CustomerType = „S‟).
CustomerAddress
Contiene gli indirizzi di tutti i clienti. Può essere presente più di un
indirizzo. Ad esempio, a un cliente possono essere associati un
indirizzo per la fatturazione e uno per le spedizioni.
Location
Elenco di ubicazioni di stoccaggio nelle quali prodotti e componenti
sono immagazzinati a fini di inventario. Ad esempio, la vernice è
presente nell'ubicazione Paint Storage nel magazzino e nel centro
di produzione Paint Shop dove avviene la verniciatura dei telai delle
biciclette.
Product
Informazioni relative a tutti i prodotti venduti o utilizzati per
produrre le biciclette e i rispettivi componenti.
ProductCategory
Classificazione generale dei prodotti. Ad esempio, bicicletta o
accessorio.
ProductInventory
Il livello di inventario dei prodotti in base alla rispettiva ubicazione.
ProductModel
Modelli diversi di un prodotto.
ProductSubcategory
Sottocategorie di prodotti. Ad esempio, Mountain, Road e Touring
sono sottocategorie della categoria Bike.
ProductVendor
Definisce il mapping tra i fornitori e i rispettivi prodotti. È possibile
che un prodotto sia disponibile presso più fornitori o che diversi
prodotti possano essere acquistati da uno stesso fornitore.
PurchaseOrderHeader
Informazioni di riepilogo di un'ordine di acquisto, quali il totale e la
data.
SalesOrderHeader
Contiene informazioni generali o di riferimento relative agli ordini di
vendita.
Store
Contiene dati relativi ai clienti rivenditori dei prodotti.
Vendor
Dettagli relativi ai fornitori, ad esempio il nome e il numero di
conto.
VendorAddress
Contiene gli indirizzi di tutti i fornitori. Può essere presente più di
un indirizzo.
WorkOrder
Contiene dati relativi agli ordini di produzione. Questo tipo di ordini
consente di controllare quali prodotti vengono realizzati in quantità
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 22 di 104
Tabelle di Ad.Works
Descrizione
appropriata e nei tempi necessari per soddisfare le richieste di
vendita e inventario.
Tabella 2 – Adventure Works (Le principali Tabelle)
I servizi del caso d‟uso Adventure Works sono realizzati dai seguenti 4 web
service:
 SalesService: questo servizio permette di reperire le informazioni
dettagliate relative ai clienti e alle vendite memorizzate nel database di
esempio.
 ProductService: questo servizio permette di reperire le informazioni
dettagliate sui dati relativi ai prodotti rappresentati nel database.
 PurchasingService: il reparto acquisti della società si occupa
dell'approvvigionamento di materie prime utilizzate per la realizzazione
delle biciclette. La società acquista inoltre prodotti a scopo di rivendita,
ad esempio abbigliamento per ciclisti e accessori. Le informazioni
relative a questi prodotti e ai relativi fornitori, sono archiviate nel
database di esempio. Questo servizio permette di reperire le
informazioni dettagliate sui dati relativi ai fornitori.
 ManufacturingService: questo servizio permette di reperire le
informazioni dettagliate sui dati relativi alle attività produttive della
società.
Nella Tabella 3 si descrivono brevemente i metodi definiti per ciascun web
service:
Service
Metodo
Sales
GetIndividualCustomers
Sales
Sales
Sales
GetIndividualCustomer
individuati come privati (CustomerType = 'I').
Restituisce i dati relativi agli indirizzi dei clienti privati.
Viene restituito il nome di tutti i clienti individuati come
GetStoreCustomers
punti vendita (CustomerType = 'S').
Vengono restituiti i nomi di tutti i punti vendita e i nomi
GetStoreContacts
e le rispettive qualifiche dei dipendenti del punto
ByStore
GetSalesByStore
Sales
GetStoreByLocation
Product
Vengono restituiti il nome e il cognome di tutti i clienti
AdressData
Sales
Product
Descrizione
vendita.
Viene creato un elenco dei punti vendita e degli ordini di
vendita a essi associati.
Vengono visualizzati nome, città, provincia e paese del
punto vendita.
GetProductDescriptions
ByFilter
e modello. Non sono inclusi i prodotti non associati ad
alcuna categoria.
GetProductDescriptions
Attività: 2.2
Visualizzazione dei prodotti per categoria, sottocategoria
Visualizzazione delle descrizioni dei prodotti per modello.
Versione:1
Data: 16/07/2010
Pag. 23 di 104
Service
Metodo
Descrizione
ByProductModel
Purchasing
Purchasing
Purchasing
Purchasing
Manufacturing
Manufacturing
Manufacturing
GetVendorsByLocation
Visualizza un elenco dei fornitori con i rispettivi indirizzi.
GetProductsSupplied
Viene visualizzato un elenco dei prodotti acquistati dalla
ByVendors
società presso i fornitori.
Viene visualizzato un elenco dei dipendenti del fornitore
GetVendorContacts
ai quali il reparto acquisti della società si rivolge per
ByVendor
ordinare componenti e prodotti.
GetPurchasesByVendor
Vengono visualizzati i dati relativi ai fornitori e agli ordini
di acquisto ad essi associati.
GetMultiLevelBillOf
Visualizzazione di un elenco di distinte dei materiali a più
MaterialsListForProduct
livelli relativo a un prodotto di riferimento principale.
GetWorkOrders
Viene restituita la quantità disponibile di ogni prodotto in
ByInventory
base alla rispettiva ubicazione di inventario.
GetWorkOrders
ByProduct
Visualizzazione di tutte le commesse relative ai prodotti
inclusi nelle sottocategorie Mountain Bike (1), Road Bike
(2) e Touring Bike (3).
Tabella 3 – Adventure Works (I Web Service)
2.2.4 Dominio e scopo dell’ontologia
Qual è il dominio che l’ontologia deve coprire? Qual’è il suo utilizzo?
Obiettivo di questa attività (Attività A2.3) è realizzare una o più ontologie che
soddisfino tutte le esigenze semantiche della piattaforma SWOP, nel dominio
applicativo del business aziendale. Per il modulo Service Annotation sono
necessarie:
 un‟ontologia del dominio business da utilizzare nel confronto semantico
tra i dati di input/output dei servizi e quelli di input/output delle
richieste degli utenti (semantica dei dati)
 un‟ontologia funzionale nella quale ogni concetto/classe rappresenta
una funzionalità del dominio scelto, in modo che ogni funzionalità dei
Web Service siamo messa in relazione con uno o più concetti
dell‟ontologia di riferimento (semantica funzionale
Inoltre per il corretto funzionamento del tool di elaborazione del linguaggio
naturale, è necessario che:
 per tutti i concetti sia correttamente valorizzato l‟attributo OWL
comment;
 la lingua da utilizzare per i commenti e i nomi dei concetti sia l‟inglese.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 24 di 104
Per quali tipi di domande l’informazione presente nell’ontologia deve
fornire una risposta?
Per il modulo Discovery Service è necessaria un‟ontologia dei servizi (ontology
service) che modelli i web service, in funzione del loro ritrovamento. Le query
possono coinvolgere:
1. caratteristiche non funzionali come la categoria del servizio;
2. caratteristiche funzionali come l‟input, l‟output, le caratteristiche di
un'operazione;
3. conoscenza di dominio che definisce, ad esempio, la tipologia dell‟input
di un servizio.
4. informazioni correlate al task o al goal del servizio;
5. il nome del servizio.
Esistono ontologie disponibili che possono essere adottate, estese,
raffinate nel nostro dominio e obiettivo particolare?
Nel paragrafo 2.3 Ontologie esistenti per il dominio Enterprise si analizzerà il
ruolo delle ontologie nell‟impresa e verranno analizzate alcune ontologie
esistenti per il dominio del business, al fine di valutare possibili riusi.
Formalismo
Il linguaggio utilizzato è OWL-DL con l'aggiunta delle restrizioni esistenziali
qualificate (logica SHOIQ) che assicura ancora la decidibilità del linguaggio. Le
caratteristiche di OWL utilizzate sono le seguenti: relazione di sottoclasse,
definizione di dominio e range e restrizioni quali exact cardinality,
allValueFrom e someValuesFrom. L‟ontologia è stata sviluppata con Protegé
Versione 4.02 (Build 115) e Pellet-Plugin 1.1.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 25 di 104
2.2.5 I moduli dell’ontologia
La Figura 4 sintetizza l‟architettura modulare dell‟ontologia progettata per la
paittaforma SWOP:
Figura 4 – Architettura dell’ontologia per Swop
I principi di progettazione seguiti per lo sviluppo dell‟ontologia sono stati i
seguenti:
 Modularizzazione - La conoscenza di dominio, che definisce le proprietà
funzionali e non funzionali dei web service, è stata suddivisa in
ontologie, che poi sono state integrate tra di loro.
 Estendibilità - L‟ontologia sviluppata è facilmente adattabile a differenti
domini applicativi semplicemente estendendo i concetti base presenti
oppure importanto ontologie di dominio differenti.
 Riuso di ontologie di classificazione esistenti.
Nella
Tabella 4 è stata riportata una breve descrizione delle ontologie
coinvolte:
Ontologie
Nome file
Categories
unspsc.owl
Business
Processe
Business
Object
Services
Swop
Integration
BusinessProcess.owl
BusinessObject.owl
Services.owl
swop-integration.owl
Descrizione
Contiene una tassonomia delle categorie commerciali
di prodotti e servizi.
Vengono classificate le funzionalità e i task del
dominio applicativo.
Definisce i concetti del dominio che identificano gli
input e gli output dei web service.
Fornisce lo scheletro per modellare i web service.
Questo modulo importa i precedenti e stabilisce le
relazioni tra le classi delle varie ontologie importate.
Tabella 4 – SWOP - Le ontologie del progetto
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 26 di 104
2.3 Ontologie esistenti per il dominio Enterprise
2.3.1 Le ontologie e le imprese
Se due parti vogliono effettuare un affare, uno dei principali requisiti è la
condivisione di una comune comprensione del mondo. Se il venditore e
l‟acquirente non si capiscono, chiaramente la transazione non può avvenire.
Questo principio è anche vero per il commercio elettronico con la differenza
che in questo caso gli agenti software fanno più difficoltà a comunicare tra di
loro. Mentre gli uomini hanno una conoscenza del senso comune del mondo e
possono risolvere l‟ambiguità dei termini utilizzati nella comunicazione
commerciale, molti programmi, al giorni d‟oggi, non hanno questa capacità.
In un‟economia dove la rete dei fornitori, distributori, partner e clienti di
un‟azienda commerciale è sempre più un‟importante fonte di vantaggio
competitivo, l‟interoperabilità semantica – l‟abilità di agenti umani e
automatizzati di coordinarsi basandosi su l‟apprendimento condiviso di dati
che fluiscono tra di loro – è la maggior abilità economica [23].
Inoltre, l‟informazione è elemento essenziale all‟interno di un‟azienda nel
determinare lo svolgimento corretto dei processi e dei flussi fisici, a livello
logistico, nei servizi, nella gestione finanziaria e nel supporto alle decisioni.
Condividere l‟informazione permette di controllare e coordinare lo svolgimento
di attività diverse, superando il limite della razionalità individuale.
Gli utenti di un‟azienda hanno bisogno di analizzare i cambiamenti di
informazioni per poter supportare efficacemente le attività lavorative. A causa
della complessità dei sistemi aziendali e degli strumenti disponibili, gli utenti,
soprattutto quelli con meno competenze tecniche, affrontano considerevoli
sfide quando cercano di recuperare in maniera flessibile i dati necessari con un
metodo ad-hoc.
In realtà col tempo è emerso che il compito più importante per l‟ontologia dei
nuovi sistemi informativi, si rapporta più che al progetto dell‟intelligenza
artificiale al mondo delle basi di dati (database management) – e riguarda
quello che potremmo chiamare il problema della torre di Babele delle basi di
dati (integrazione semantica) [24].
Gradualmente ha preso corpo l‟idea che arrivare ad una comune tassonomia di
riferimento potrebbe procurare vantaggi significativi rispetto a soluzioni
sviluppate ad-hoc. Una tale visione è supportata dal fatto che molti grandi
rivenditori adottano attualmente delle tecnologie semantiche: Hewlet Packard,
IBM, Microsoft, Oracle, SAP.
Le ontologie possono aiutare i programmi ad essere più intelligenti, ad essere
capaci di automatizzare le transazioni commerciali e l‟analisi dei flussi. Lo
scopo di una “Enterprise Ontology” è quello di essere un valido riferimento per
il dominio dell‟e-business. Una Enterprise Ontology dovrebbe fornire ad un
livello più alto i concetti più importanti del business e poi dovrebbe fornire
delle definizioni ontologiche di concetti di più basso livello come il tempo, il
luogo e il denaro.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 27 di 104
Nei sistemi informativi e nelle applicazioni aziendali, le categorie generali ed
universali, solitamente rappresentate dalle ontologie top-level, non sono
molto diffuse. Le imprese trovano eccessivamente costoso, in termini di tempo
e di risorse impiegate, creare e gestire una concettualizzazione completa,
piuttosto è di loro interesse che i sistemi basati su ontologie siano più efficaci
dei sistemi preesistenti.
Inoltre gli individui interpretano e rappresentano il “mondo” in modo diverso,
in base a personali prospettive. Ad esempio due utenti (o comunità di utenti)
possono osservare lo stesso fenomeno e vedere diversi problemi, opportunità
e occasioni di sviluppo. Ne deriva che una ontologia non risulta essere una
organizzazione di significati neutra, ma piuttosto risulta essere uno schema
interpretativo, attraverso il qualche ha senso (per una persona o una
comunità) organizzare e definire oggetti.
Seppure
i
ragionamenti
induttivi,
la
disambiguazione
semantica,
l‟interoperabilità tra ontologie possono non essere efficacemente supportate
dai sistemi esperti e di knowledge management delle imprese, la presenza di
ontologie diverse deve diventare una fonte di arricchimento conoscitivo, che
conduce a combinazioni inattese di conoscenze e innovazione.
2.3.2 I processi aziendali e la loro rappresentazione sintattica
Il Business Process (o Processo Aziendale) è il flusso di un insieme di attività
interrelate, svolte all'interno dell'azienda, da una persona, da un sistema
interno, che creano valore trasformando delle risorse (input del processo) in
un prodotto (output del processo) destinato ad un soggetto interno o esterno
all'azienda (cliente). Il processo è teso al raggiungimento di un obiettivo
aziendale, determinato in sede di pianificazione se questa è presente.
Fondamentale per un‟azienda non è soltanto la gestione in sé per sé delle sue
risorse (persone, prodotti, clienti, fornitori) ma anche la possibilità di
analizzare i suoi processi.
Il Business Process Management (BPM) [25] è l‟insieme di attività necessarie
per definire, monitorare, ottimizzare ed integrare i processi aziendali, al fine di
rendere efficiente ed efficace il business dell‟azienda. Il Business Process
Modeling indica quelle tecniche e quegli standard utilizzati per rappresentare i
processi di un‟azienda.
Le attività connesse al BPM possono essere raggruppate in cinque categorie:
disegno, modellazione, esecuzione - tramite le regole di business (business
rules) - monitoraggio e ottimizzazione. Gli analisti e/o i manager analizzano il
processo corrente e lo migliorano, in efficienza e qualità.
Una tecnica standard molto diffusa per la rappresentazione grafica del BPM, è
il BPMN (Business Process Modelling Notation) [26], una rappresentazione
molto flessibile che permette di specificare i processi di business in un
workflow. Citiamo anche altre tecniche:
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 28 di 104

EPC (Event-driven Process Chain) che identifica un particolare tipo di
flowchart che può essere utilizzato per configurare un‟implementazione
di un ERP (Enterprise Resource Planning - ossia quei prodotti gestionali
che permettono di pianificare le risorse di un‟azienda);

UML2 (Unified Modeling Language) Activity Diagram [27];

UMM (UN/CEFACT's Modeling Methodology) [28].
Il Business Process Definition Metamodel (BPDM) indica un metamodello
esplicito per rappresentare gli elementi del BPMN, e fornisce un meccanismo
per la serializzazione di questi elementi basato su XML. Mentre L‟XML Process
Definition Language (XPDL) [29] è un formato standard per lo scambio delle
definizioni dei processi di business tra differenti prodotti di workflow.
Una Business Process Management Suite (BPMS) è generalmente un insieme
di tool finalizzati al BPM (Es. IBM BPM Suite(6), Oracle BPM Suite(7),
raggruppabili in quattro principali gruppi:
 Process Engine - indica una robusta piattaforma per modellare ed
eseguire applicazioni basate sui processi, incluse le business rules;

Business Analytics - sono tecniche che permettono di identificare i
problemi di business o i trend;

Content
Management
-
fornisce
un
sistema
per
memorizzare
documenti elettronici, ed altri file;

Collaboration Tools - attraverso forums, o bacheche è possibile
abbattere le barriere di comunicazione tra i vari dipartimenti di
un‟azienda.
Il principale approccio architetturale per il BPM è SOA (Service-Oriented
Architecture) già illustrato nel deliverable D1.1. In un‟architettura orientata ai
servizi l‟azienda stessa è vista come un insieme di servizi, che sono forniti o
consumati dai processi. Questo tipo di architettura si dimostra molto flessibile
soprattutto quando devono essere apportate delle modifiche.
Il cuore della sfida del BPM è riuscire a dare una vista d‟insieme
dell‟andamento di un‟azienda attraverso l‟integrazione delle molteplicità di
sistemi IT in essa presenti. Il Semantic Business Process Management (SBPM)
è il nuovo approccio per automatizzare questa integrazione mediante l‟utilizzo
delle tecnologie semantiche. Questa nuova ottica è seguita dai maggiori
produttori di sistemi di ERP e BPM. SAP(8) ad esempio è pienamente coinvolta
nel progetto SUPER di cui parleremo nel seguito.
6
http:/www-01.ibm.com/software/info/bpm/offerings.html
7
http://www.oracle.com/us/technologies/bpm/index.html
http://www.sap.com
8
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 29 di 104
2.3.3 Le ontologie formali esistenti
Nell‟affrontare il problema di implementare una Enterprise Ontology un
approccio potrebbe essere quello di riusare le ontologie formali disponibili sul
Web, contenenti informazioni rilevanti per la realizzazione di una Enterprise
Ontology. Ad esempio ci sono varie upper ontology che definiscono concetti
come il tempo, i luoghi, le quantità fisiche e le strutture aziendali. Esse
comunque potrebbero risultare troppo generiche e contenere numerosi
concetti "lontani" dal dominio del business che si vuole modellare. Inoltre
spesso sono pubblicate con poca documentazione.
Un altro approccio potrebbe essere quello di non basarsi su alcuna delle
ontologie esistenti, ma scegliere di basare la concettualizzazione su alcuni
importanti standard per l‟e-business.
Il successo di una rappresentazione sta nel suo utilizzo condiviso. Sebbene
esistano vari standard per lo scambio dei dati che condividono uno stesso
dizionario, questi non condividono la semantica. Questo implica che il
significato dei termini deve essere codificato direttamente nelle procedure,
rendendo così il loro riuso complicato e costoso.
Il mondo economico/finanziario ha già visto la nascita di alcuni standard
sintattici di successo per lo scambio e la rappresentazione delle informazioni e
numerose sono le organizzazioni che lavorano per realizzare degli standard
comuni. Questi alcuni degli organismi internazionali coinvolti:
 W3C(9) - World Wide Web Consortium

UN/CEFACT(10) - United Nations / Centre for Trade Facilitation and
Electronic Business

OASIS(11)
-
Organization
for
the
Advancement
of
Structured
Information Standards

OMG(12) - Object Management Group
Ci sono standard per la classificazione dei prodotti e standard per la
descrizione dei processi aziendali.
2.3.3.1 Standard per la classificazione di prodotti e servizi
Tra gli standard di classificazione dei prodotti i più importanti sono i seguenti:
 UNSPSC [30] è una semplice tassonomia di concetti. Esiste un
progetto denominato unspscOWL(13) nato con l‟obiettivo di fornire una
versione semantica di questo standard ma ad oggi non esistono
9
http://www.w3.org/
10
http://www.unece.org/cefact
11
http://www.oasis-open.org
12
http://ontology.omg.org/
13
http://www.heppnetz.de/projects/unspscowl/
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 30 di 104
prototipi ufficiali [31,32]. Una versione ontologica di questo standard è
stata realizzata da uno studente della Middle East Technical University
(METU):
Scheda unspscOWL
URL progetto:
http://www.srdc.metu.edu.tr/ubl/translation/src/Thesis%20Extra
ct.pdf

Ontology URI:
http://www.srdc.metu.edu.tr/ubl/contextOntology/unspsc.owl
Autori:
Yalin Yarimagan
Linguaggio:
OWL
Versione:
2006
Num. Classi:
2548
Num. Object Property:
0
Num. Individui:
0
Num. Data Property:
0
Espressività in DL:
AL
Ecl@ss2(14), a differenza del primo standard, contiene anche le
proprietà e quindi è più interessante da punto di vista ontologico tanto
che ne esiste una completa versione in OWL Lite, denominata
eCl@ssOWL [33], che rappresenta la prima ontologia per prodotti e
servizi. L‟ultima versione di eClassOWL fornisce più di 60.000 classi di
prodotti e più di 5.000 proprietà per la descrizione delle caratteristiche
dei prodotti.
Scheda eCl@ssOWL
URL progetto:
http://www.heppnetz.de/projects/eclassowl/
Ontology URI:
http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/
Autori:
Martin Hepp and Andreas Radinger
Linguaggio:
OWL-DL
Versione:
5.1.4 del 18/04/2010
Num. Classi:
60687
Num. Individui:
4767
SHI(D)
Num.
Object
4941
Property:
Num. Data Property:
2275
Queste tassonomie di prodotti possono essere facilmente integrate in altre
ontologie.
2.3.3.2 Standard per la classificazione dei processi aziendali
Per la classificazione dei processi aziendali citiamo alcuni importanti standard
basati su XML:
14
http://www.eclass-online.com
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 31 di 104

ebXML (Electronic Business eXtensible Markup Language)(15) un
insieme di specifiche che permettono di modellare le transazioni
commerciali elettroniche. ebXML definisce il Core Components
Technical Specification (CCTS)(16) sviluppato da UN/CEFACT. CCTS
definisce i più importanti blocchi dei tipici documenti di business e può
essere riutilizzato in altri standard.

RosettaNet(17). Il dizionario dei dati di RosettaNet (quello tecnico e
quello di business) definisce una lista di termini che possono essere
utilizzati nei documenti di business. Questa lista non è strutturata in
alcuna forma, inoltre, le convenzioni per i nomi degli elementi sono
piuttosto ad-hoc.

UBL 2.0 [34]. E‟ un linguaggio basato su XML per la rappresentazione
elettronica di documenti commerciali (Ordine, Avviso spedizione,
Richiesta di offerta, ecc.) realizzato in collaborazione con varie
organizzazioni di standardizzazione, tra cui UN/CEFACT. UBL
rappresenta la prima implementazione in XML della metodologia
CCTS. In Danimarca dal Febbraio 2005 la fattura UBL è stata adottata
per legge da tutte le aziende del settore pubblico e diversi sono gli
esempi di effettivo utilizzo di questo linguaggio (analogo vincolo vige,
per esempio, in Turchia da Marzo 2010).
Varie sono le iniziative(18) che hanno provato ad aggiungere semantica allo
standard UBL, a dimostrazione del fatto che è uno standard importante per il
mondo del business, ma questi progetti in realtà non hanno mai visto dei
risultati concreti.
2.3.3.3 NeOn - UBL Invoice Ontology
Scheda NEON UBL Invoice
URL progetto:
http://www.neon-project.org
Ontology URI:
http://www.isoco.com/ontologies/neon/UBLInvoiceOntology.o
wl
Autori:
iSOCO S.A. (www.isoco.com)
Linguaggio:
OWL DL
Versione:
18/02/2010
Num. Classi:
106
111
Num. Individui:
0
Num. Data Property:
3
ALUN(D)
finale
15
http://www.ebxml.org/
16
http://www.unece.org/cefact/codesfortrade/CCTS/CCTS-Version3.pdf
17
http://www.rosettanet.org/
18
http://ontolog.cim3.net/cgi-bin/wiki.pl?UblOntology
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 32 di 104
NeOn (Networked Ontologies) [35] è un progetto finanziato dal “Sesto
programma quadro di ricerca dell’Unione europea” il cui scopo è fornire un
supporto per lo sviluppo e la gestione delle applicazioni semantiche di nuova
generazione. Il cuore di questo progetto è Neon Toolkit, un ambiente per la
progettazione di ontologie, multi-piattaforma e open source, basato sulla
piattaforma di Eclipse, che fornisce un supporto globale durante tutto il ciclo
di vita di un‟ontologia: acquisizione della conoscenza, sviluppo,
modularizzazione, integrazione con le basi di dati relazionali, valutazione, ecc.
I2Ont (Invoices to Ontologies) (19) un prototipo che utilizza le tecnologie e i
metodi di NeOn Toolkit per ridurre significativamente il problema
dell‟interoperabilità delle fatture nell‟industria farmaceutica spagnola. Uno dei
modelli di fattura utilizzati in questo prototipo, denominato UBLIO (UBL
Invoice Ontology), implementa lo standard UBL ed è stato sviluppato
utilizzando la Ontolog UBL ontology(20). Le classi principali della UBL Invoice
Ontology sono visualizzate in
Figura 5.
Figura 5 – UBL Invoice Ontology
In Figura 6 sono illustrate le sottoclassi della classe UBLTransactionEntity:
19
http://neon-toolkit.org/wiki/I2Ont
20
http://ontolog.cim3.net/cgi-bin/wiki.pl?UblOntology
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 33 di 104
Figura 6 – UBL Invoice Ontology (Transaction Entity)
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 34 di 104
2.3.3.4 DIP - Business Data Ontology
Scheda BDO
URL progetto:
http://dip.semanticweb.org
Ontology URI:
http://dip.semanticweb.org/documents/D3.3-Business-dataontology.pdf
Autori:
Gabor Nagypal (www.fzi.de)
Linguaggio:
OWL FULL
Versione:
24/01/2005
Num. Classi:
385
519
Num. Individui:
0
Num. Data Property:
97
ALHI+(D)
finale
Nell‟ambito del progetto DIP (Data, Information, and Process Integration with
Semantic Web Services) [36] finanziato dal “Sesto programma quadro di
ricerca dell’Unione europea”, è stata realizzata la Business Data Ontology
(BDO).
La BDO utilizza ed estende la upper-ontology PROTON (in precedenza
denominata BULO) [37], un‟ontologia realizzata come supporto per il progetto
Semantic Knowledge Technologies (SEKT) (21) che rappresenta una semplice
struttura di alto livello.
Scheda PROTON
URL progetto:
http://proton.semanticweb.org/
Ontology URI:
http://proton.semanticweb.org/2005/04/protonu
Autori:
OntoText Lab (http://wwww.ontotext.com)
Linguaggio:
OWL-DL
Versione:
0.1 del 2005
Num. Classi:
266
77
Num. Individui:
0
Num. Data Property:
36
Espressività
ALHI+(D)
in
finale
DL:
Tabella 5 – PROTON – Scheda Riepilogativa
BDO è un‟ontologia basata sullo standard UBL 1.0, nata per essere un
riferimento per l‟e-business. La BDO pone particolare attenzione al ciclo
ordine-fattura di UBL, rappresentato in Figura 7.
21
http://www.sekt-project.com/
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 35 di 104
Figura 7 – Processo ordine-fattura in UBL
Quella visualizzata in
Figura 8 è una visione d‟insieme dell‟ontologia BDO.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 36 di 104
Figura 8 – Business Data Ontology
Lo standard UBL consiste di tre parti principali:
1. la prima parte è lo standard UN/CEFACT CCTS che fornisce i blocchi
primitivi (CCTS e i tipi di dati) che sono riutilizzati nello standard. Gli
elementi CCTS sono tutti sottoconcetti del nuovo concetto BASETYPE.
2. all‟altro estremo ci sono le tipologie di documenti necessari per il ciclo
ordine-fattura:
a.
b.
c.
d.
e.
f.
g.
h.
Order
Order Response Simple
Order Response (detailed)
Order Change
Order Cancellation
Despatch Advice
Receipt Advice
Invoice
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 37 di 104
Queste tipologie di documenti descrivono una complicata struttura di
documento che usa elementi dalla terza parte di UBL. I concetti che
definiscono le tipologie di documenti UBL sono aggiunti come
sottoconcetti del nuovo concetto BUSINESSDOCUMENT (a sua volta
sottoconcetto di DOCUMENT e di BUSINESSOBJECT).
3. la terza parte è chiamata “riusabile”. Questa definisce delle utili
astrazioni che hanno già una semantica di business (in contrasto con
gli elementi CCTS). Ad esempio appartengono a questa parte concetti
generali del business come Address oppure Item.
2.3.3.5 SET Harmonized Ontology
Scheda SET Harmonized Ontology
URL progetto:
http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=set
Ontology URI:
http://www.srdc.metu.edu.tr/iSURF/OASIS-SETTC/ontology/ HarmonizedOntology.owl
Autori:
Oasis Committees
Linguaggio:
OWL-Lite
Versione:
13/05/2009
Num. Classi:
3351
9
Num. Individui:
0
Num. Data Property:
0
AL
finale
La SET Harmonized Ontology [38] rappresenta uno dei numerosi tentativi di
aggiungere semantica allo standard UBL. Essa è il risultato del progetto OASIS
SET TC (Semantic Support for Electronic Business Document Interoperability)
che mira a sviluppare le specifiche per una rappresentazione dei documenti
commerciali elettronici semanticamente processabili dalle macchine.
La SET Harmonized Ontology esprime le relazioni tra gli artefatti documentali
dei seguenti standard: UN/CEFACT CCL (Core Component Library)22, UBL 2.0,
OAGIS 9.1(23) and GS1 XML (24), come illustrato in Figura 9.
22
http://www.unece.org/cefact/codesfortrade/unccl/CCL_index.htm
23
http://www.oagi.org
24
http://www.gs1.org/ecom/xml/overview
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 38 di 104
Figura 9 – Set Harmonized Ontology
2.3.3.6 GoodRelations
Scheda GoodRelations
URL progetto:
http://purl.org/goodrelations/
Ontology URI:
http://purl.org/goodrelations/v1
Autori:
Martin Hepp
Linguaggio:
OWL DL
Versione:
Release 1.0 del 12/04/2010
Num. Classi:
28
43
Num. Individui:
47
Num. Data Property:
37
SHI(D)
GoodRelations [39] è un‟ontologia che può essere utilizzata per descrivere
con molta precisione cosa un‟azienda offre (prodotti, prezzi ed altri dati
aziendali). Questo “vocabolario standardizzato” può essere incastrato in
pagine web statiche e dinamiche e può essere processato da altri computer,
incrementando così la visibilità dei prodotti e dei servizi nei motori di ricerca
semantici, nei sistemi di raccomandazione e in altre nuove applicazioni,
rendendo cosi disponibili i dati, esclusivamente alle persone che stanno
cercando tali prodotti e servizi.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 39 di 104
Figura 10 – GoodRelations Goal
GoodRelations può essere utilizzato per creare un piccolo pacchetto di dati che
descrive i prodotti, le loro caratteristiche, i prezzi, gli orari di apertura e
chiusura, le condizioni di pagamento e informazioni simili (vedere la Figura
10). E‟ poi sufficiente incollare questo pacchetto dati nella propria pagina Web
usando il formato RDF. Utilizzando il tool gratuito GoodRelations Annotator è
possibile descrivere con molta semplicità la propria azienda ed i suoi prodotti.
Vengono così generate poche linee di codice extra da incollare nella pagina
principale del sito aziendale.
Inoltre, GoodRelations rende facile lo scambio dei dettagli di un modello di
prodotto tra produttori e operatori di vendita, in modo che tali dati possano
essere molto facilmente riutilizzati attraverso la catena del valore.
Il lavoro sull‟ontologia GoodRelations è supportato dalla Commissione Europea
nell‟ambito del progetto SUPER (Semantics Utilised for Process management
within and between EnteRprises) [40,41]– che combina i Semantic Web
Service (SWS) e le tecnologie di modellazione del processo aziendale per
supportare la gestione del processo aziendale.
GoodRelations utilizza l‟ontologia eCl@ssOWL. La relazione tra eCl@ssOWL e
GoodRelations è lineare:
 eClassOWL fornisce classi, attributi e valori per descrivere un prodotto o
un servizio.
 GoodRelations fornisce tutto il necessario per descrivere l‟offerta attuale e i
suoi dettagli, ad esempio, la relazione tra una Business Entity ed un
prodotto oppure un servizio. Tale caratteristica è anche l‟origine del nome:
è un‟ontologia per le relazioni tra beni e business entity.
GoodRelations è molto flessibile, infatti è possibile referenziare qualsiasi altra
ontologia che descriva beni e servizi purché risponda a determinate linee
guida.
La Figura 11 illustra la gerarchia delle classi di GoodRelations.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 40 di 104
Figura 11 – Good Relations Ontology
Nella Tabella 6
GoodRelations:
è riportata
Classi di
GoodRelations
una
descrizione delle principali
classi
di
Descrizione
Un‟istanza di questa classe rappresenta l‟agente legale che fa
una particolare offerta (vedi la classe Offerings). Una Business
Entity ha almeno un indirizzo di posta e dei dettagli di
contatto. Gli standard tipicamente usati per gli indirizzi (come
BusinessEntity
vCard) e i dati sulla posizione possono essere aggiunti. La
posizione potrebbe essere importante per trovare un fornitore
con una data distanza dalla propria sede.
Esempi: Siemens Austria AG, Volkswagen Ltd., Peter Miller's
Cell phone Shop
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 41 di 104
Classi di
GoodRelations
Descrizione
E‟ una entità concettuale che rappresenta la forma legale, la
dimensione, la posizione nella catena dei valori di una
Business Entity. Dal punto di vista ontologico, le tipologie di
Business Entity identificano i principali ruoli che un‟entità può
BusinessEntityType
assumere nel mercato. Questi tipi sono importanti quando si
vogliono individuare i clienti idonei per una data offerta,
poiché le offerte spesso hanno un senso solo per entità di una
certa dimensione, con una certa struttura legale, o con un
determinato ruolo nella catena dei valori.
Esempi: EndUser, Retailers, Wholesalers, or Public Institutions
Specifica il tipo di attività o di accesso offerto da una Business
Entity su un prodotto o servizio messo tra le offerte. L‟idea di
standardizzare le funzioni di business è nata per allinearsi con
gli “UNSPSC Business Functions Identifiers” (UNSPSC BFI).
Tipicamente queste funzioni sono sell, rental oppure lease,
BusinessFunction
maintenance
oppure
repair,
manufacture/produce,
recycle/dispose, engineering/construction, o installation.
Esempi: Una particolare offerta fatta dalla Miller Rentals Ltd
potrebbe dire che quest‟azienda sell (vende) decappottabili
della Volkswagen Golf, lease out (loca) un particolare tipo di
camioncino della Ford, e dispose (dispone di) rottami di
macchine di ogni tipo e modello.
Il giorno della settimana utilizzato per specificare a quale
DayOfWeek
giorno si riferiscono gli orari di apertura.
Esempi: Monday, Tuesday, Wednesday,...
I metodi di spedizione sono le procedure standardizzare per il
trasferimento di prodotti e servizi alla destinazione finale
DeliverMethod
scelta dal cliente. Essi sono caratterizzati dai mezzi di
trasporto
utilizzati,
e
dall‟organizzazione
o
gruppo
che
rappresenta la parte contrattuale incaricata della spedizione.
Esempi: spedizione con Mail, con Direct Download, con UPS
Location of Sales o Service Provisioning è un luogo in cui una
determinata Business Function, applicata ad un'istanza di un
particolare prodotto o servizio, può essere offerta da una
Business Entity.
Le grandi imprese spesso hanno più filiali per le spedizioni di
LocationsOfSalesOrS
consegna. In questo caso il luogo principale dell‟ufficio della
erviceProvisioning
Business Entity non coincide con il posto dove il cliente può
attualmente fare l‟offerta. Nel caso di una catena di negozi,
coincide con tutti i negozi attuali.
Location of Sales o Service Provisioning sono caratterizzati da
un indirizzo o da una posizione geografica e da un insieme di
indicazioni sugli orari di apertura per i diversi giorni della
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 42 di 104
Classi di
GoodRelations
Descrizione
settimana.
Esempi: un‟azienda di noleggio di auto può offrire la Business
Function, Lease Out per le auto, da due luoghi, uno in Fort
Myers,
Florida,
e
un
altro
in
Boston,
Massachussetts.
Entrambe le stazioni sono aperte 7:00 - 23:00 dal lunedì al
sabato.
Questa è la superclasse per tutte le classi che rappresentano
N-Ary-Relations
le relazioni n-arie, che non possono essere rappresentate con
OWL.
Un‟offerta rappresenta l‟annuncio pubblico di una Business
Entity di fornire una certa BusinessFunction per alcune istanze
di Product o Service ad un determinato target di clienti.
Un‟offerta è caratterizzata dal tipo di prodotto o servizio a cui
si riferisce, dalla BusinessFunction offerta (sales, rental, …) e
Offering
da un insieme di proprietà commerciali. Un'offerta può essere
espressa in termini di tipi ammissibili di business partner,
città, quantità ed altre proprietà commerciali.
Esempi: Peter Miller offre la riparazione di TV fatti di marca
Siemens, Volkswagen Innsbruck vende una particolare serie
della Volkswagen Golf a $10,000.
Un metodo di pagamento è una procedura standardizzata per
trasferire l‟ammontare monetario di un acquisto. I metodi di
pagamento sono caratterizzati dalle strutture legali e tecniche
PaymentMethod
utilizzate, e dall‟organizzazione o gruppo che esegue la
transazione. Questo elemento è principalmente utilizzato per
specificare i tipi di pagamento accettati da una Business
Entity.
Esempi: Visa, Mastercard, Diners, Cash.
PriceSpecification
La superclasse di tutte le specifiche di pagamento.
La superclasse di tutte le classi che descrivono tipi di prodotti
o servizi, ad esempio TV o aspirapolvere. Un‟istanza di questa
classe può essere sia un prodotto o un servizio attuale oppure
un'istanza per appresentare le istanze sconosciute di materie
prime prodotte in serie.
Da quando eClassOWL e altre ontologie di prodotti e servizi
ProductOrService
sono usate per descrivere sia le istanze sia la marca e modello
di prodotti e servizi, questo concetto di alto-livello è l‟unione
di (1) istanze di prodotti o servizi attuali, (2) modelli di
prodotti o servizi, e (3) "segnaposto" per alcune istanze di
prodotti e servizi. Quest‟ultima classe contiene le istanze
"fittizie" che rappresentano le istanze di prodotti o servizi
anonimi (ossia che esistono ma che non sono attualmente
esposti sul web).
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 43 di 104
Classi di
GoodRelations
Descrizione
E‟ un'entità che rappresenta lo stato di alcune proprietà
qualitative di un prodotto o servizio. I valori qualitativi sono
sia valori letterali che enumerativi. Un‟istanza di questa classe
QualitativeValue
rappresenta un valore qualitativo per una proprietà di un
oggetto.
Esempi: il colore "green", il cavo di alimentazione di tipo "US".
Nota: Attualmente, né gli insiemi di valori e né le relazioni
ordinali tra valori sono supportate.
E‟ un intervallo numerico che rappresenta il range di alcune
proprietà quantitative di un prodotto o servizio in termine di
limite inferiore e superiore. Viene interpretato in combinazione
con la rispettiva unità di misura. La maggior parte dei valori
quantitativi sono intervalli anche se essi in pratica sono
QuantitativeValue
spesso trattati come singoli.
Questa classe è un work-around dovuto al fatto che i dati di
tipo range non possono essere facilmente rappresentati in
OWL.
Esempi: un peso tra 10 e 25 kg, una lunghezza tra 10 e 15
mm.
Rappresenta i tipi di servizi che vengono forniti gratuitamente
dal
venditore
o
dal
produttore
in
casi
di
difetti
(es.
Manodopera e componenti, solo componenti), come garanzia
WarrantyScope
inclusa in un'offerta. I servizi attuali possono essere forniti da
una Business Entity che fa un‟offerta, dal produttore del
prodotto, o da una terza parte.
Esempi: Componenti e manodopera, componenti.
Tabella 6 – GoodRelations Ontology – Descrizione delle classi
Tra i siti che hanno integrato GoodRelations citiamo Yahoo! Search Monkey(25)
e BestBuy(26).
GoodRelations Annotator(27) guida l‟utente alla creazione di un‟istanza della
ontologia descritta in precedenza, contenente i dati della propria azienda
come indicato nelle figure seguenti.
25
http://siteexplorer.search.yahoo.com/submit
26
http://www.bestbuy.com/
27
http://www.ebusiness-unibw.org/tools/goodrelations-annotator/
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 44 di 104
Figura 12 – Good Relation Annotator - Step 1
Figura 13 – Good Relation Annotator - Step 1b
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 45 di 104
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 46 di 104
Dopo aver compilato i dati è possibile scaricare l'istanza consistente con
l‟ontologia GoodRelations relativa alla propria azienda in formato RDF.
Successivamente è necessario pubblicarla sul Web, caricando il file RDF sul
proprio portale e aggiungendo gli opportuni riferimenti nella propria pagina
web principale.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 47 di 104
A questo punto il portale è semanticamente pronto, manca solo la notifica del
proprio link ai principali motori di ricerca semantici: Sindice(28), Yahoo! Search
Monkey(29), URIBurner(30).
2.3.3.7 Le ontologie del progetto SUPER
Scheda Ontologie progetto SUPER
URL progetto:
http://www.ip-super.org/
Ontology URI:
http://www.ip-super.org/content/view/129/136/
Autori:
Super Consortium
Linguaggio:
WSMO
Versione:
2009
Num. Classi:
N.D.
Num. Object
N.D.
Property:
Num. Individui:
N.D.
N.D.
Num.
Data
N.D.
Property:
SUPER (Semantics Utilised for Process management within and between
EnteRprises) è un progetto finanziato dal “Sesto programma quadro di ricerca
dell’Unione europea” il cui scopo è portare il BPM a livello semantico. Il
Semantic Web, in particolare, la tecnologia dei Semantic Web Services (SWS)
offre la promessa di integrare le applicazioni semantiche. Combinando SWS e
BPM, SUPER vuol creare delle ontologie orizzontali che descrivano i processi di
business ed ontologie verticali orientate che supportino le annotazioni
specifiche del dominio.
SBPM (Semantic Business Process Management) è un nuovo approccio alla
gestione dei processi aziendali. In SUPER sono state utilizzate un insieme di
ontologie per rappresentare gli aspetti principali del SBPM. Le ontologie
coinvolte sono illustrate in Figura 19.
28
http://sindice.com/main/submit
29
http://siteexplorer.search.yahoo.com/submit
30
http://linkeddata.uriburner.com
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 48 di 104
Figura 19 – Process Modeling Ontology in SUPER
Il progetto è tuttora in fase di realizzazione e ha visto come caso d‟uso
l‟applicazione al mondo della fatturazione nel settore delle telecomunicazioni
coinvolgendo alcune delle principali compagnie telefoniche (31).
2.3.3.8 Business Management Ontology
Scheda BMO
URL progetto:
http://www.bpiresearch.com/Resources/RE_OSSOnt/re_ossont
.htm
Ontology URI:
http://www.bpiresearch.com/BMO/2004/11/01//BMO
Autori:
Jenz & Partner
Linguaggio:
OWL Full
Versione:
1.0 del 2004
Num. Classi:
518
481
Num. Individui:
180
Num. Data Property:
557
ALCIN (D)
31
finale
http://www.ip-super.org/res/Deliverables/M6/D2.1.pdf
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 49 di 104
BMO (Business Management Ontology) [42] è un‟ontologia open source che
vuole coprire tutti gli aspetti del business management, allineandolo con l‟IT e
arricchendolo di semantica. Sviluppata da “Jenz & Partner”(32), essa si ispira a
standard pubblici come BPMN, ebXML e UBL.
BMO porta con sé varie entità: disegno del processo di business, gestione dei
progetti, gestione dei requisiti, e gestione delle prestazioni di business. Inoltre
forma le basi per una base di conoscenza della gestione del business che sia
integrata e neutrale rispetto al venditore, e da cui vari artefatti possono
essere generati. Mentre gli analisti del business saranno gli utenti primari
della BMO, gli esperti di IT lo useranno per stabilire relazioni tra definizioni
correlate al software, come gli oggetti del business e le descrizioni dei Web
Service.
Molte grandi organizzazioni utilizzando più di un BPMS. Appurato che i
processi di business si svolgono in ambienti eterogenei, il bisogno di una
correlazione diventa evidente. BMO cerca proprio di rispondere a questo
bisogno. BMO permette all‟analista del business di:
 definire processi di business privati

definire le entità gli oggetti del business

definire i servizi che implementano le attività del processo

seguire lo standard UMM per il processo di business e per la
modellazione delle informazioni
La Figura 20 sintetizza l‟architettura di BMO.
Figura 20 – L’architettura di BMO
32
http://www.jenzundpartner.de/
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 50 di 104
Ci sono quindi vari strati di ontologie, che poi vengono integrate tra di loro
attraverso gli strati di integrazione. BMO (ver.1) contiene 40 ontologie che
verranno descritte brevemente nelle tabelle di seguito, suddivise per area di
interesse.
Code Lists
Nome Ontologia
Countries
Descrizione
Ontologia delle tipologie di nazioni, stati e territori. C‟è
anche un riferimento alla codifica ISO 3166.
Currencies
Ontologia delle valute secondo lo standard ISO 4217.
Language
Ontologia delle lingue secondo lo standard ISO 639.
Importa
le
seguenti
ontologie
(necessarie
in
ogni
organizzazione):
Code Lists
Artifact Definition
States
-
Countries Ontology
-
Currencies Ontology
-
Language Ontology
Definisce la ArtifactDefinitionState Class (le cui
istanze sono descrizioni dei possibili stati: definito, in
fase di sviluppo o indefinito).
Definisce la DocumentPublicationState Class (le cui
Document Publication
istanze
sono
descrizioni
dei
possibili
stati
di
States
pubblicazione di un documento: rilasciato, in test, in
revisione).
Release Quality States
Definisce la ReleaseQualityState Class (le cui istanze
sono le possibili release: alfa1, beta1, ecc.).
Importa le seguenti ontologie:
Code Lists - States
-
Artifact Definition States Ontology
-
Document Publication States Ontology
-
Release Quality States
Definsice la TimeIntervalUnit Class (le cui istanze
Time Interval Units
sono i possibili intervalli: giornalmente, mensilmente,
annualmente).
Time Duration Units
Definsice la DurationUnit Class (le cui istanze sono le
possibili unità: giorno, mese, anno, minuto).
Importa le le seguenti ontologie:
Code Lists - Units
-
Time Interval Units
-
Time Duration Units Ontology
Tabella 7 - BMO – Code Lists
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 51 di 104
Business Context
Nome Ontologia
Descrizione
Definisce la UniverseOfDiscourse Class (tramite le
Business Context
classi sostantivo, simbolo, verbo, vocabolario)
e la
classe comunità (semantica o linguistica).
Tabella 8 - BMO – Business Context
Business Context Integration
Nome Ontologia
Descrizione
Definisce le seguenti classi: Document (un oggetto che
descrive dei requisiti), DocumentFormat (le cui istanze
Documents
possono essere HTML, MSWORD, PDF), DocumentType
(le cui istanze possono essere: immagine, software,
suono, testo,ecc.).
Forma lo strato base di integrazione. Importa le seguenti
ontologie:
Business Context
Integration
-
Business Context Ontology
-
Code Lists Ontology
-
Code Lists States Ontology
-
Code Lists Units Ontology
-
Documents Ontology
Tabella 9 - BMO – Business Context Integration
Generic Business Domain Ontologies
Nome Ontologia
Business Rules
Descrizione
Importa la Business Context Integration Ontology.
Definisce la Business Rule Class che rappresenta la
conoscenza che un‟azienda ha del suo business.
Business Rules Process
Importa la Business Rules Ontology e la estende.
Basata sulle specifiche ebXML/UBL. Tra le principali
classi che definisce individuamo: BusinessContext
Class (raggruppa i contesti possibili: di processo,
Core Components
geopolitico, di classificazione industriale),
BusinessInformationEntity Class (un gruppo di dati
di business con un‟unica definizione), CoreComponent
Class (tassello che permette la costruzione di pacchetti
di informazioni di scambio, che rispecchia la definizione
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 52 di 104
Nome Ontologia
Descrizione
UN/CEFACT CCTS), MetaDataItem Class.
Business Documents
-
-
Core Components Ontology
e definisce la classe BusinessDocument (es. ordine o
una fattura).
Definisce i concetti di Organization, Organizational
Organization
Unit, Person. Inoltre è definita la classe DIRECTEDBINARY-RELATION.
Roles
Definice la Role Class. Un ruolo è una entità funzionale:
una persona, un partner o un sistema.
E' utilizzata per descrivere i compiti che precedono la
definizione di un processo aziendale. Gli analisti possono
Tasks
catturare tali compiti in un modo informale. Definisce la
Task Class e importa le seguenti ontologie:
-
Organization Ontologyc
-
Roles Ontology
Durable Information
Entity
-
-
Definisce la Durable Information Entity Class: l‟entità
informativa di cui ha bisogno un task per eseguire la sua
funzione, che può essere rappresentata in un
meccanicismo di memorizzazione persistente, e il cui
stato deve esistere al di là del tempo d vita del servizio
(applicazione) che implementa il task.
Resources
Definisce la Resource Class (se umana o fisica).
Definisce la generica Product Class. Può essere
Products Ontology
sviluppata ulteriormente nella Industry-Specific Ontology
che tipicamente la importa.
Importa la Organization Ontology.
Requirements
Definisce il concetto di requisito, se funzionale o meno, il
Ontology
suo livello (le cui istanze sono del tipo “deve”, “nondeve”,”potrebbe”, “non-potrebbe”).
Partner
Privileges
Usergroup
Definisce la BusinessPartner Class (se è un individuo o
se è un‟organizzazione).
Definisce la Privilege Class (ossia il diritto di effettuare
una determinata azione).
Definisce la UserGroup Class, ossia una comunità di
persone che hanno caratteristiche comuni.
Privilege Assignments
Attività: 2.2
-
Partner Ontology
-
Privileges Ontology
Versione:1
Data: 16/07/2010
Pag. 53 di 104
Nome Ontologia
Descrizione
-
Roles Ontology
-
Usergroup Ontology
Definisce inoltre le classi relazioni tra queste entità.
Tabella 10 - BMO – Generic Business Domain Ontologies
Organization Specific
Nome Ontologia
Descrizione
Questa ontologia integra i concetti generici del business.
OrganizationSpecific Ontology
-
Business Context Integration Ontology
-
Business Documents Ontology
-
Durable Information Entities Ontology
-
Organization Ontology
-
Resources Ontology
-
Roles Ontology
In fase di utilizzo a questi concetti possono poi essere
aggiunti quelli specifici dell‟organizzazione che deve essere
trattata.
Tabella 11 - BMO – Organization Specific
IT
Nome Ontologia
Descrizione
Definisce la BusinessObject Class.
Business Objects
Definisce il lato IT (Information Technology) del BPM.
Ontology
Attualmente questa ontologia definisce solo pochi oggetti di
business, giusto per presentare i principi di fondo.
IT Integration
Importa le altre ontologie orientate all‟IT (la Business
Ontology
Objects Ontology).
Tabella 12 - BMO – IT
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 54 di 104
BPM Core
Nome Ontologia
Descrizione
Tra le altre definisce le seguenti classi:
- Service, intesa come un modulo applicativo che esegue un
compito.
- ServiceGrounding, per differenziare le applicazioni JAVA
Services
da un WebService.
- ServiceParameter, per elencare i parametri in input e in
output
- WSDLMessage, un oggetto contenente la definizione
dell‟URI del messaggio WSDL che identifica il servizio.
Tra le altre definisce le seguenti classi:
Task
Implementations
- Action, un‟azione è associata con una implementazione di
un servizio
- TaskInteraction, definisce l‟interazione tra un utente e un
sistema
-
Business Documents Ontology
-
Durable Information Entities Ontology
-
Resource Ontology
-
Services Ontology
-
Task Implementations Ontology
-
Tasks Ontology
L‟analista di business può descrivere i tipi di contesto di
Process Task
Context Type
esecuzione dei processi. Viene definita la classe
ProcessTaskContextType Class che fornisce una
descrizione semantica di un process task.
Un processo è associato a un istanza della Rule Class, a uno
o più Business Document, a uno o più Durable
Information Entity Class, a uno o più Physical Resource
Class.
Viene inoltre fatta una distinzione tra processo collaborativo
e processo privato. In quest‟ultimo caso si può parlare di
processo manuale o automatico (questo implica che ogni
processo deve essere associato a un elemento della
ServiceImplementation Class) o semi-automatico.
Necessaria per la generazione dei modelli UML, definisce la
Entity Types
EntityType Class (le cui istanze possono ad esempio essere
Ontology
BusinessDocument, BusinessEntity, BusinessObject,
BusinessRule).
Business Modeling
Ontology
Importa la Organization Ontology.
Basato su UN/CEFACT UMM, definisce i concetti di
BusinessArea,
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 55 di 104
Nome Ontologia
Descrizione
BusinessDomainView,BusinessGoal,BusinessObjective.
Importa la Business Context Integration Ontology.
BPM Core Ontology
Definisce le classi che individuano i concetti specifici del
Business Process richiesti per modellare i flussi di business
interni (privati), pubblici o collaborativi.
Tabella 13 - BMO – BPM Core
BPM Integration
Nome Ontologia
Descrizione
Importa le seguenti ontologie e le mette in relazione:
-
BPM-Core Ontology
-
Business Modeling Ontology
-
Business Rules Process Ontology
-
-
Entity Types Ontology
BPM Integration
-
Privilege Assignments Ontology
Ontology
-
Process Task Context Types Ontology
-
Requirements Ontology
-
Services Ontology Ontology
-
Task Implementation Ontology
Questo strato fornisce una vista integrata sugli aspetti
relativi al business process: viene fatta un‟associazione tra i
concetti propri del business process e i concetti generali del
dominio di un‟azienda.
Tabella 14 - BMO – BPM Integration
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 56 di 104
Business Integration
Nome Ontologia
Descrizione
Questa ontologia rappresenta lo strato di integrazione di
business di più alto livello. Essa importa le seguenti
ontologie:
Ontology
1) BPM Integration Ontology
2) IT Integration Ontology
3) Organization-Specific Ontology
Inoltre in fase di utilizzo può importare zero o più
ontologie specifiche industriali che possono esistere
parallelamente.
Tabella 15 - BMO – Business Integration
BMO
Nome Ontologia
Descrizione
Importa la Business Integration Ontology.
Business Management Ontology
Rappresenta lo strato dell'ontologia top-
(BMO)
level. In questa ontologia possono essere
create le istanze.
Tabella 16 - BMO – Main Ontology
Istanziare la BMO
Per utilizzare la BMO è sufficiente istanziare il modello, opportunamente
arricchito delle ontologie del settore specifico a cui appartiene l‟azienda a cui
deve essere applicata la BMO. Queste ontologie specifiche possono integrare
ed estendere le Generic Business Domain Ontologies.
Ora riepiloghiamo le ontologie che devono essere create e/o istanziate in fase
di utilizzo:
Nome Ontologia
Business Context
Integration
Descrizione
La struttura è identica a quella della Business Context
Integration Ontology, in più ci sono le istanze. Le istanze
definiscono le informazioni relative alla lingua in uso,
all‟universo del discorso, ai termini adottati, alla valuta,
ecc.
Industry-Specific
Ontology
Attività: 2.2
Eventualmente aggiungere le ontologie industriali
specifiche che possono esistere parallelamente a BMO.
Tipicamente un‟ontologia specifica può importare altre
Versione:1
Data: 16/07/2010
Pag. 57 di 104
Nome Ontologia
Descrizione
ontologie BMO ed estenderne le classi. Ad esempio può
estendere la Product Class in modo da definire le
specificità del settore.
Ontology
La struttura è quella della Business Integration Ontology,
in più importa eventuali ontologie di settore (IndustrySpecific Ontology).
La
Business Management
Ontology (BMO)
struttura
è
identica
a
quella
della
Business
Management Ontology (BMO). In più contiene le istanze
che dimostrano come può essere utilizzata. Gli analisti
del business potrebbero anche partire con una BMO
vuota e poi creare le istanze.
Tabella 17 - BMO – Le Istanze
Ad oggi non ci sono strumenti open-source che permettono di modellare dei
processi con BMO. Ma Protégé è dotato di un plug-in, Graph Widget(33), che
permette la rappresentazione grafica delle relazioni tra entità. Manca
ovviamente un tool per la validazione dei processi.
2.3.3.9 ONTOMODA-ML
Scheda Ontomoda-ML
URL
http://spring.bologna.enea.it/LeapfrogWiki/index.php?title=OntoMOD
progetto:
A
Ontology
http://winter.bologna.enea.it/Ontologies/OntoModa/OntoModaML-
URI:
DMO.owl
Autori:
Enea (Agenzia nazionale per le nuove tecnologie)
Linguaggio:
OWL Full
Versione:
0.8.0
Num.
282
Classi:
Num.
finale
Num.
Object
36
Property:
47
Num. Data Property:
23
Individui:
Espressività
ALCOIF(D)
in DL:
33
http://protege.stanford.edu/doc/tutorial/graph_widget/
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 58 di 104
OntoMODA-ML [43] è un ontologia di dominio modulare multi-livello
orientata alla modellazione dei dati ed allo scambio delle informazioni di ebusiness. Il suo scopo primario è modellare una parte della conoscenza del
settore tessile e vestiario attraverso la descrizione semantica di molti aspetti,
come i processi industriali, i trattamenti, le descrizioni dei prodotti (es. il
tessuto, il filato, le fibre) ed altre informazioni. L‟ontologia è orientata allo
scambio dei dati nel senso che è stata realizzata un'architettura che non solo
permette la descrizione del dominio, ma permette anche di descrivere ogni
concetto del dominio che può eventualmente essere collegato ad una
particolare rappresentazione o ad un particolare formato digitale elaborabile
dai sistemi automatici come gli ERP.
La stessa ontologia statica è modulare e perciò composta da diverse sottoontologie (vedere la Figura 21), ognuna delle quali afferisce a diversi aspetti
di modellazione e meta-modellazione (es. lo standard ISO11179, XML Schema
Meta Modeling e la reale conoscenza del settore).
Figura 21 – L’architettura di OntoModa-ML
Segue una breve descrizione delle ontologie:
 CMO (Concept Model Ontology) è l‟ontologia più generica ed è usata
come modello per costruire un‟ontologia che modelli i formati di
scambio delle informazioni partendo da concetti astratti. In questa
ontologia sono definiti l‟idea di concetto o rappresentazione di un
concetto.
 XS (XML Schema Ontology) è l‟ontologia che modella un modo
particolare di rappresentare le informazioni, il linguaggio XML . Essa
descrive i concetti della sintassi XML: Type (simple, complex),
Elements, Attributes e altre relazioni.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 59 di 104




Domain Ontology (OntoMODA) è il cuore di tutta l‟architettura: essa
contiene i concetti specifici del settore privati della loro particolare
rappresentazione. Questa ontologia è il punto di congiunzione tra
l‟insieme delle informazioni reali e la conoscenza di settore, con
l‟insieme dei dati scambiati. Nel caso del settore tessile
questa
ontologia descrive concetti come Fabric e le sue proprietà oppure il
concetto di Meta Model per la modellazione dei dati.
ebXML (ebXML Concept Ontology) descrive il metamodello e i concetti
ebXML.
ebBP (ebBP Concept Ontology) specializza la ebXML Concept Ontology
e introduce i concetti e i termini usati nella definizione dei processi di
Business in ebXML (es.. Business Collaboration, Business Transaction
Activity oppure Business Transaction).
Moda-ML Model introduce i concetti di Moda-ML e i termini che li
collegano alla ebXML Concept ontology. Ad esempio entrambi i
framework, ebXML Concept e Moda-ML, definiscono il concetto di
Business Activity: in questo modo i due concetti vengono fortemente
interconnessi nel senso che un elemento Moda-ML Business Activity è
un ebXML Business Activity.
2.4 Progettazione dell’ontologia SWOP
Dopo aver investigato l'architettura di massima dell‟ontologia per la
piattaforma SWOP, definendone scopo e obiettivi e dopo aver analizzato alcuni
esempi di ontologie per il mondo enterprise, in questa sezione del documento
descriveremo le ontologie del dominio enterprise sviluppate per il progetto
SWOP.
Dominio e scopo dell’ontologia SWOP
Si vuole concettualizzare e implementare un‟ontologia nel dominio enterprise
da utilizzare nel confronto semantico tra i dati di input/output dei web service
e quelli di input/output delle richieste degli utenti (semantica dei dati).
Questa ontologia deve contenere i principali termini del business, con
particolare riferimento al ciclo acquisto-produzione-vendita. Il suo uso è
strettamente legato agli obiettivi della piattaforma SWOP, quindi l‟esigenza
principale è quella di presentare una tassonomia di concetti facilmente
referenziabili all‟interno dei documenti WSDL che devono essere annotati
semanticamente.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 60 di 104
L'ontologia SWOP non contiene individui, intesi come istanze di una classe
dell'ontologia, in quanto un individuo, nel caso di studio affrontato, serve per
descrivere (annotare) un servizio in modo che possa essere recuperato in
maniera efficiente. In questa ottica, non è stato necessario creare, per
esempio, un individuo per definire un metodo implementato dal nome
getAllProducts, poichè servizi diversi potevano condividere delle operazioni
comuni, ognuna implementata con un metodo proprietario (quindi
probabilmente con un nome diverso ma rappresentabile con una stessa
descrizione semantica). L'informazione che è necessario annotare e che risulta
funzionale anche alla fase di Service Discovery, è l'interfaccia funzionale e non
funzionale del web service evidenziando proprietà quali una categoria di
classificazione, il contesto in cui si colloca il servizio, le caratteristiche delle
operazioni che espone lo stesso. Tutto ciò può essere rappresentato da un
assioma che descrive il servizio e che deve, pertanto, rispettare i vincoli
modellati nell'ontologia.
2.4.1 Costruzione dell’ontologia BusinessObject
2.4.1.1 Enumerazione dei termini e dei concetti
Possiamo considerare importanti per l‟ontologia i concetti rappresentati dalle
principali tabelle presenti nel database di esempio Adventure Works Cycles, il
nostro caso d‟uso. Un elenco completo del dizionario di dati è reperibile al
seguente indirizzo Web:
http://technet.microsoft.com/it-it/library/ms124438(SQL.90).aspx
I termini sono stati distinti principalmente in:
 Attributi: nozioni atomiche, non ulteriormente scomponibili;
 (macro) Concetti: nozioni un po‟ più complesse che possono essere
espresse come composizione di attributi semplici.
La maggior parte dei concetti è stata desunta dai nomi delle tabelle, mentre
gli attributi coincidono con i campi principali di ciascuna tabella. Tutti questi
elementi sono stati espressi come classi dell‟ontologia conservando però la
distinzione tra macro-concetti e attributi. Inizialmente si era pensato di
trasformare gli attributi in data property legate ai concetti, ma poi è emersa
l‟esigenza di presentare principalmente una tassonomia di concetti e quindi
tutti i termini sono diventati classi.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 61 di 104
2.4.1.2 Organizzazione dei concetti in una gerarchia
Namespace
E‟ stato definito per l‟ontologia il seguente namespace:
http://www.di.uniba.it/~swap/ontologies/BusObj/BusinessObject.owl
Seguono alcune delle linee guida adottate nello sviluppo dell‟ontologia.
Composizione al posto dell’ereditarietà
Come vedremo nell‟ontologia è stata definita una proprietà di composizione
abbastanza generica hasSimpleAttribute, che rappresenta la possibilità che un
Concept possa avere uno più attributi semplici. Non tutte le relazioni di
appartenenza specifiche sono state definite, perché non necessarie per gli
scopi di questa ontologia (ad esempio un CustomerAddress potrebbe avere un
CustomerAddressStreet e un CustomerAddressCity, ecc., ma questi legami
attualmente nell‟ontologia, non sono dichiarati); sono state definite solo le
relazioni verso gli attributi di maggiore rilevanza (ad esempio gli ID e pochi
altri elementi).
In molti casi è stata utilizzata la composizione di oggetti piuttosto che
l‟ereditarietà (i.e. sotto-concetti). E‟ noto che per alcuni elementi possano
esistere dei sotto-concetti, legati a proprietà qualitative che specializzano il
concetto padre. Ad esempio se consideriamo l‟oggetto SalesOrder (ordine di
acquisto), possiamo pensare ai vari stati in cui questo può trovarsi (in
lavorazione, approvato, rifiutato, spedito, cancellato). In questa versione
dell‟ontologia non si è ritenuto necessario definire altrettanti sotto-concetti,
uno per ciascuno stato possibile, poiché tali concetti non sono referenziati
negli input/output dei web service definiti nel caso d‟uso per SWOP.
Sottolineiamo che alcuni di questi sotto-concetti possano comunque essere
espressi con delle restrizioni sulle classi già esistenti. Ad esempio per definire
un ordine di vendita approvato (il valore 1 è la codifica per lo stato approvato
definito nelle specifiche del dizionario dati di Adventure Works) possiamo
ricorrere alla seguente definizione OWL:
SalesOrder and hasSimpleAttribute exactly 1
(SalesOrderStatus and hasSalesOrderStatusValue value 1)
Sviluppi futuri dell‟ontologia potrebbero richiedere la creazione di questi sottoconcetti.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 62 di 104
Classi Ridondanti
In alcuni casi concetti con la stessa semantica sono stati introdotti molte
volte. Ad esempio troviamo CustomerAddress, VendorAddress oppure
CustomerName, VendorName. Questa scelta è legata al fatto che dovendo
annotare semanticamente documenti WSDL, si è reso necessario disporre di
concetti che avessero un significato ben preciso piuttosto che di concetti più
generali legati tra di loro quali potevano essere Customer e Address.
2.4.1.3 Definizione di proprietà e restrizioni
Proprietà obbligatorie
Per ogni concetto individuato analizzando il dizionario di Adventure Work
Cycles, sarebbe stato possibile definire tutte le sue proprietà obbligatorie,
individuando ad esempio i campi “Not null” nel database, ma non si è ritenuto
di inserire tali informazioni nell‟ontologia (ad esclusione dell‟identificativo
univoco che ogni elemento possiede).
Si è cercato inoltre di stabilire dei legami (object property) tra i macroconcetti sfruttando l‟analisi delle foreign key di ciascuna tabella (ad esempio
un SalesOrder si riferisce a un cliente, a un prodotto; la proprietà inversa
invece non è stata espressa).
Diversamente sono state trattate le cosidette tabelle di relazione presenti nel
database. Ad esempio, consideriamo la relazione tra un prodotto e le sue foto:
un prodotto può avere più fotografie (per semplicità non consideriamo la
relazione inversa). Questa relazione in un database diventa una tabella,
mentre ontologicamente viene rappresentata con una object-property che lega
due concetti (ricordiamo che la nostra ontologia non contiene individui ma
assiomi per definire i servizi). Il confronto è mostrato nella Figura 22.
Figura 22 – Relazioni tra concetti vs/ Relazioni tra tabelle
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 63 di 104
Ontologicamente questa relazione viene espressa con una restrizione sul
concetto Product:
hasProductPhoto some ProductPhoto
IDs nella modellazione dell’ontologia
Gli ID sono elementi importanti di una qualsiasi rappresentazione informatica
che voglia identificare univocamente i suoi oggetti, soprattutto nelle soluzioni
per l‟e-business. Gli attributi di tipo ID sono referenziati come output in alcuni
Web Service del nostro caso d‟uso, pertanto in questa prima versione della
nostra ontologia si è ritenuto importante esprimere il vincolo per cui ogni
concetto distinto ha esattamente 1 IDentificativo. Ad esempio per la classe
Customer troviamo la seguente restrizione OWL:
hasID exactly 1 CustomerID
2.4.2 La classe top-level Business Obejct
Le premesse appena fatte ci portano alla struttura top-level dell'ontologia
BusinessObject relativa alla modellazione dei dati di input/output dei processi,
illustrata nella Figura 23.
Figura 23 – Business Object (top-level)
In questa ontologia sono state definite le seguenti object property:
hasSimpleAttribute
Domain:
Concept
Range:
Attribute
Esprime la possibilità che un Concept possa avere uno più attributi
semplici.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 64 di 104
hasID
Domain:
Concept
Range:
Identifier
Esprime la possibilità che un Concept possa avere un identificativo.
hasConcept
Range:
Concept
Questa super-property raggrupperà tutte le object-property che
esprimeranno i legami tra i vari Concept della gerarchia.
Inoltre sono state definite le seguenti data property:
hasSimpleAttributeValue
Domain:
SimpleAttribute
Identifica l’insieme dei possibili valori che può assumere un
SimpleAttribute. Non è definito un esatto Range, in quanto per
alcuni concetti il valore potrebbe essere un numero, per altri una
stringa, o una data.
hasIDValue
Domain:
Identifier
Identifica l’insieme dei possibili valori che può assumere un
Identifier. Non è definito un esatto Range, in quanto per alcuni
concetti l’identificativo potrebbe essere un numero, per altri un
codice alfanumerico.
Come vedremo questa data property è stata referenziata nella
descrizione (assioma) di alcuni Web Service del caso d’uso di
SWOP (per ulteriori dettagli si rimanda al deliverable D2.3) in
particolare nei metodi in cui c’era da esprimere un filtro su alcuni
valori degli identificativi.
Nella Tabella 18 è riportata una descrizione delle classi illustrate nella Figura
23.
Class
BusinessObject
Description
Questa classe identifica un generico oggetto del dominio di
business.
Questa classe identifica gli
attributi, ossia le entità
atomiche. In particolare distinguiamo tra:
Attribute

SimpleAttribute: è un attributo semplice, come lo
può essere
un nome, una descrizione o gli
attributi qualitativi o quantitativi.

Attività: 2.2
Identifier: è l‟attributo che permette di distinguere
Versione:1
Data: 16/07/2010
Pag. 65 di 104
Class
Description
un oggetto dagli altri appartenenti alla stessa
classe. La possibilità che un Concept possa avere
un Identifier è espressa dalla relazione hasID.
Inoltre le classi Attribute e Concept sono disgiunte tra di
loro.
Appartengono a questa classe tutti i macro-concetti del
dominio, ossia quei concetti che possono essere espressi
come composizione di attributi.
Concept
Restrizioni
hasSimpleAttribute
Some
SimpleAttribute
Questa restrizione sta ad indicare che un Concept può
avere uno più attributi semplici.
Tabella 18 – Business Object (top-level) - Descrizione delle classi.
L‟ontologia top-level così definita può essere estesa per contenere i concetti
specifici del dominio scelto per questo caso d‟uso (ossia la gestione
acquisti/vendite di una azienda) o in generale per qualsiasi altra ontologia
specifica (per futuri casi d‟uso) garantendo alla nostra architettura le
caratteristiche dell‟estendibilità e del riuso.
2.4.2.1 La classe BusinessObject estesa per il dominio enterprise
Tutti i macro-concetti relativi alla gestione vendite/prodotti di un‟impresa
derivano dalla classe Concept come illustrato in Figura 24.
Figura 24 – Business Object (estesa per il dominio Enterprise)
Nella Tabella 19 viene riportata una descrizione per le sotto-classi di Concept
illustrate in Figura 24.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 66 di 104
Class
Description
Enterprise Concept raggruppa tutti i concetti tipici della
gestione vendite/prodotti di un‟impresa. Essa estende la
EnterpriseConcept
generica Business Obejct. I concetti sono raggruppate in
3
macroaree:
CLIENTI-VENDITE,
PRODOTTI,
FORNITORI-ACQUISTI
CustomerAndSales
E‟ la classe che raggruppa tutti i concetti relativi al
Concept
processo di vendita ai clienti.
Product
E‟ la classe che raggruppa tutti i concetti relativi ai
Concept
prodotti e alla loro produzione.
VendorAndPurchaising
E‟ la classe che raggruppa tutti i concetti relativi al
Concept
processo di acquisto dai fornitori.
Generic Contept
E‟ la classe che raggruppa i concetti più generici.
Tabella 19 – Business Object estesa per il mondo Enterprise. Descrizione delle classi.
2.4.2.2 La classe Concept estesa per il dominio Enterprise
La classe GenericConcept
E‟ la classe che raggruppa i concetti più generici, dalle nozioni di regione ed
unità di misura a quelle relative alle risorse umane di un‟azienda come
illustrato in Figura 25.
Figura 25 – Business Object (Generic Concept)
Nella Tabella 20 riportiamo i commenti e le eventuali restrizioni definiti per
ciascuna classe illustrata in Figura 25 (i commenti sono in inglese, la lingua
scelta per descrivere i concetti ontologici e formulare le interrogazioni nel
progetto SWOP).
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 67 di 104
Class
Description
“Types of addresses. For example, billing, home, or shipping.”
AddressType
Restrizioni
Exactly 1
hasID
AddressTypeID
“ISO standard codes for countries and regions.”
Restrizioni
CountryRegion
hasCurrency
hasID
some
Currency
Exactly 1
CountryRegionCode
“Standard ISO currencies.”
Currency
Restrizioni
Exactly 1
hasID
CurrencyCode
“Currency exchange rates.”
Restrizioni
CurrencyRate
hasFromCurrency
Exactly 1
Currency
hasToCurrency
Exactly 1
Currency
hasID
Exactly 1
CurrencyRateID
“Employee information such as salary, department, and title.”
Restrizioni:
Employee
hasEmployeeAddress
Some
EmployeeAddress
hasID
Exactly 1
EmployeeID
hasEnterpriseDepartment
Max 1
hasManager
Max 1
EnterpriseDepartment
Employee
“Street address information for employees.”
Restrizioni
EmployeeAddress
hasAddressType
Exactly 1
AddressType
hasStateProvince
Exactly 1
StateProvince
Exactly 1
hasID
EmployeeAddressID
“Departments of Enterprise”.
EnterpriseDepartment
Restrizioni
Exactly 1
hasID
EnterpriseDepartmentID
“Shipping methods.”
ShipMethod
Restrizioni
Exactly 1
hasID
ShipMethodID
“States and provinces”.
Restrizioni
hasCountryRegion
StateProvince
hasSalesTerritory
hasID
Exactly 1
CountryRegion
Exactly 1
SalesTerritory
Exactly 1
StateProvinceID
“Unit of measure”.
UnitMeasure
Restrizioni
Exactly 1
hasID
UnitMeasureCode
Tabella 20 – Business Object (Generic Concept). Descrizione delle sotto classi.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 68 di 104
La classe CustomerAndSalesConcept
Come sotto classi di CustomerAndSalesConcept ritroviamo i concetti relativi al
processo di vendita ai clienti come illustrato in Figura 26.
Figura 26 – Business Object (Cusrtomer and Sales Concept)
progetto SWOP).
Class
Description
“Current Customer individual information”.
Restrizioni
Customer
hasID
exactly 1
CustomerID
hasSimpleAttribute
exactly 1
CustomerType
hasCustomerAddress
Some
CustomerAddress
hasCustomerCreditCard
Some
CustomerCreditCard
hasSalesTerritory
Max 1
SalesTerritory
“Street address information for customers”.
Restrizioni
CustomerAddress
exactly 1
hasID
CustomerAddressID
hasAddressType
exactly 1
AddressType
hasStateProvince
exactly 1
StateProvince
“Customer credit card information.”
CustomerCreditCard
Restrizioni
exactly 1
hasID
CustomerCreditCartID
“Stores of our Company (customer and resellers).”
CustomerStore
Restrizioni
exactly 1
hasID
Attività: 2.2
Versione:1
Data: 16/07/2010
CustomerStoreID
Pag. 69 di 104
Class
Description
hasSaleRepresentativePerson
Max 1
SalesRepresentativePerson
isOwnedBy
exactly 1
Customer
“General sales order information (header)”
Restrizioni
SalesOrder
hasID
exactly 1
hasBillToCustomerAddress
exactly 1
CustomerAddress
hasShipToCustomerAddress
exactly 1
CustomerAddress
hasCurrencyRate
exactly 1
CurrencyRate
hasCustomerCreditCard
Max 1
CustomerCreditCard
hasCustomer
exactly 1
Customer
hasSalesOrderDetail
some
SalesOrderDetail
exactly 1
SalesOrderStatus
hasSalesReason
some
SalesReason
hasSaleRepresentativePerson
Max 1
SalesRepresentativePerson
hasSalesTerritory
Max 1
SalesTerritory
hasShipMethod
exactly 1
ShipMethod
hasSimpleAttribute
SalesOrderID
“Product details associated with a specific sales order.”
Restrizioni
SalesOrderDetail
hasProduct
exactly 1
Product
hasID
exactly 1
SalesOrderDetailID
exactly 1
SalesSpecialOffer
hasSalesSpecialOffer
“Reasons why a customer may purchase a particular product.”
SalesReason
Restrizioni
exactly 1
hasID
SalesReasonID
“Contains current sales information for the sales representative persons.”
Restrizioni
SalesRepresentative
Person
exactly 1
SalesRepresentativePersonID
hasSalesTerritory
exactly 1
SalesTerritory
isAnEmployee
exactly 1
Employee
hasID
“Contains shopping cart items until the order is submitted or cancelled.”
SalesShopping
CartItem
Restrizioni
hasID
exactly 1
hasProduct
exactly 1
SalesShoppingCartItemID
Product
“Special Offer (discounts)”
SalesSpecialOffer
Restrizioni
exactly 1
SalesSpecialOfferID
hasID
exactly 1
SalesTaxRateID
hasStateProvince
some
StateProvince
hasID
“Sales Tax rate.”
Restrizioni
SalesTaxRate
SalesTerritory
“Sales territory.”
Restrizioni
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 70 di 104
Class
Description
hasID
exactly 1
hasCountryRegion
some
SalesTerritoryID
CountryRegion
Tabella 21 – Business Object (Customer and Sales Concept). Descrizione delle classi.
La classe ProductConcept
Come sotto classi di ProductConcept ritroviamo tutti i concetti relativi ai
prodotti ed alla loro produzione come illustrato in Figura 27.
Figura 27 – Business Object (Product Concept)
progetto SWOP).
Class
Description
“Products sold or used in the manfacturing of sold products.”
Restrizioni
Exactly 1
ProductID
hasProductDocument
Some
ProductDocument
hasProductModel
Exactly 1
ProductModel
hasProductPhoto
Some
ProductPhoto
hasProductSubCategory
Exactly 1
ProductSubCategory
hasID
Product
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 71 di 104
Class
Description
hasSizeUnitMeasure
Exactly 1
hasWeighrUnitMeasure
Exactly 1
hasProductCostHistory
some
ProductCostHistory
Some
ProductListPriceHistory
hasProductListPriceHistory
UnitMeasure
UnitMeasure
“Cross-reference class mapping vendors with the products they supply.”
Restrizioni
exactly 1
Vendor
hasUnitMeasure
exactly 1
UnitMeasure
hasSimpleAttribute
exactly
hasVendor
ProductSupplied
ByVendor
ProductSuppliedByVendor
MaxOrderQty
“Bill
Of
Materials
are
items
required
to
make
products
and
product
subassemblies. It identifies the heirarchical relationship between a parent
product and its components.”
Restrizioni
ProductBillOfMaterials
Exactly 1
ProducBillOfMaterialsID
hasProductAssembly
Exactly 1
Product
hasComponent
Exactly 1
hasUnitMeasure
Exactly 1
hasID
Product
UnitMeasure
“High-level product categorization.”
ProductCategory
Restrizioni
Exactly 1
hasID
ProductCategoryID
“Changes in the cost of a product over time.”
Restrizioni
ProductCostHistory
Exactly 1
ProductCostHistoryStartDate
hasSimpleAttribute
Exactly 1
ProductCostHistoryEndtDate
hasSimpleAttribute
Exactly 1
ProductCostHistoryStandardCost
hasSimpleAttribute
“Product maintenance documents.”
ProductDocument
Restrizioni
Exactly 1
ProductDocumentID
hasProduct
Exactly 1
Product
hasProductLocation
Exactly 1
ProductLocation
hasSimpleAttribute
Exactly 1
ProductInventoryBin
hasSimpleAttribute
Exactly 1
ProductInventoryQuantity
hasSimpleAttribute
Exactly 1
ProductInventoryShelf
hasID
“Product inventory information.”
Restrizioni
ProductInventory
“Changes in the list price of a product over time.”
Restrizioni
ProductListPriceHistory
ProductLocation
hasSimpleAttribute
Exactly 1
hasSimpleAttribute
Exactly 1
ProductListPriceHistoryEndDate
hasSimpleAttribute
Exactly 1
ProductListPriceHistoryPrice
ProductListPriceHistoryStartDate
“Product manufacturing locations”
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 72 di 104
Class
Description
Restrizioni
hasID
Exactly 1
ProductLocationID
Exactly 1
ProductModelID
Exactly 1
ProductPhotoID
“Product model classification”
ProductModel
Restrizioni
hasID
“Product photo”
ProductPhoto
Restrizioni
hasID
“Customer reviews of products they have purchased.”
Restrizioni
ProductReview
Exactly 1
ProductReviewID
Exactly 1
Product
hasID
Exactly 1
ProductSubCategoryID
hasProductCategory
Exactly 1
ProductCategory
hasID
hasProduct
“Product subcategories.”
Restrizioni
ProductSubCategory
“Manufacturing work orders.”
Restrizioni
Exactly 1
ProductWorkOrderID
hasProduct
Exactly 1
Product
hasSimpleAttribute
Exactly 1
ProductWorkOrderQty
hasProductWorkOrderRouting
Some
ProductWorkOrderRouting
hasID
WorkOrder
“Work order routing details. This includes the sequence of work centers the
product travels through in the manufacturing or assembly process.”
Restrizioni
WorkOrderRouting
hasSimpleAttribute
Exactly 1
ProductWorkOrderRouting
OperationSequence
hasProduct
Exactly 1
Product
hasProductLocation
Exactly 1
ProductLocation
Tabella 22 – Business Object (Product Concept) - Descrizione delle sotto classi
La classe PurchasingAndVendorConcept
E‟ la classe che raggruppa tutti i concetti relativi al processo di acquisto delle
materie prime dai fornitori (vendor), come illustrato in Figura 28.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 73 di 104
Figura 28 – Business Object (Vendor and Purchaising Concept)
progetto SWOP).
Class
Description
“General purchase order information (header).”
Restrizioni
PurchaseOrder
hasID
exactly 1
PurchaseOrderID
hasPurchaseOrderDetail
some
PurchaseOrderDetail
hasShipMethod
exactly 1
ShipMethod
hasVendor
exactly 1
Vendor
hasProductsSupplied
some
ProductSuppliedByVendor
ByVendor
exactly 1
hasEmployee
Employee
“Products details associated with a specific purchase order.”
PurchaseOrderDetail
Restrizioni
hasID
exactly 1
PurchaseOrderDetailID
hasProduct
exactly 1
Product
“Details about vendors, such as the vendor name and account
number.”
Vendor
Restrizioni
hasID
VendorAddress
exactly 1
VendorID
some
VendorAddress
“Street address information for vendors.”
Restrizioni
VendorAddress
hasID
Exactly 1
hasAddressType
Exactly 1
AddressType
hasStateProvince
Exactly 1
StateProvince
VendorAddressID
Tabella 23 – Business Object (VendorAndPurchaising Concept)-Descrizione delle classi
2.4.2.3 La classe Attribute estesa per il domino enterprise
La classe IDentifier
Nella Figura 29 sono riportate tutte le sotto classi di tipo Identifier
nell‟ontologia Business Object estesa per il dominio enterprise.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 74 di 104
Figura 29 – Business Object – (Identifier)
A ciascuna sotto-classe della classe Concept, dotata di un Identifier, verrà
applicata una restrizione che esprima questo vincolo. Ad esempio nella
definizione della classe Customer troviamo la seguente restrizione:
hasID exactly 1 CustomerID
La classe SimpleAttribute
In Figura 30 sono riportate le principali categorie in cui sono stati raggruppati
gli attribti semplici dell‟ontologia Business Object estesa per il domonio
enterprise:
Figura 30 – Business Object – (SimpleAttribute)
In Figura 31 sono riportate le sotto classi di tipo CustomerAttribute.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 75 di 104
Figura 31 - Business Object – (CustomerAttribute)
In Figura 32 sono riportate le sotto classi di tipo ProductAttribute.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 76 di 104
Figura 32 - Business Object – (ProductAttribute)
In Figura 33 sono riportate le sotto classi di tipo GenericConceptAttribute.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 77 di 104
Figura 33 - Business Object – (GenericConceptAttribute)
In Figura 34 sono riportate le sotto classi di tipo PurchaseOrderAttribute.
Figura 34 - Business Object – (PurchaseOrderAttribute)
In Figura 35 sono riportate le sotto classi di tipo SalesAttribute.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 78 di 104
Figura 35 - Business Object – (SalesAttribute)
In Figura 36 sono riportate le sotto classi di tipo VendorAttribute.
Figura 36 - Business Object – (VendorAttribute)
2.4.3 Le Object Property della Business Object Ontology
In Figura 37 e Figura 38 sono riportate tutte le object property definite
nell‟ontologia Business Object.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 79 di 104
Figura 37 - Business Object – (Object Property 1/2)
Figura 38 - Business Object – (Object Property 2/2)
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 80 di 104
La seguente object-property è referenziata nella descrizione (assioma) di
alcuni Web Service per il caso d‟uso di SWOP;
hasProductSubCategory
Domain:
Product
Range:
ProductSubCategory
hasConcept
SuperProperty:
Indica che un prodotto può avere una sotto-categoria.
2.4.4 Le Data Property della Business Object Ontology
In Figura 39 sono riportate tutte le data property definite nell‟ontologia
Business Object per il dominio enterprise.
Figura 39 - Business Object – (Data Property)
Segue una descrizione delle principali data-property per il dominio Enterprise.
hasCustormerTypeValue
Domain:
CustomerType
Range:
{"I", "S"}
SuperProperty:
hasSimpleAttributeValue
Indica i possibili valori che può assumere la tipologia di un cliente.
Questa data property è stata referenziata nella descrizione
(assioma) dei Web Service per il caso d’uso di SWOP.
hasSalesOrdersStatusValue
Domain:
Range:
SalesOrderStatus
{"1"^înteger,
"2"^înteger,
"3"^înteger,
"4"^înteger, "5"^înteger, "6"^înteger}
Indica i possibili valori che può assumere lo stato di un ordine.
Attualmente il suo uso è limitato a verificare le capacità espressive
dell’ontologia.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 81 di 104
2.4.5 Le ontologie per modellare i servizi
2.4.5.1 Categories Ontology
Dominio e Scopo dell’ontologia
Si vuole concettualizzare ed implementare un‟ontologia che sia una
tassonomia delle principali categorie commerciali di prodotti e servizi. L‟uso di
quest‟ontologia è strettamente legato al modulo Service Annotation della
piattaforma SWOP, quindi l‟esigenza principale è quella di presentare una
tassonomia di categorie di alto livello facilmente referenziabili all‟interno dei
documenti WSDL che devono essere annotati semanticamente.
Riuso di un’ontologia di classificazione esistente
Per questa ontologia si è scelto di utilizzare la classificazione UNSPSC. Come
punto di partenza è stata scelta l‟implementazione realizzata da Yalin
Yarimagan. Questa versione pur non riportando tutti i livelli della
classificazione UNSPSC, consta di circa 2600 classi. Considerando il dominio di
interesse si è provveduto a ridurre il numero delle categorie lasciando quelle
classi (e relative sotto-classi) che potevano risultare utili per descrivere un
servizio della piattaforma SWOP.
All‟ontologia sono poi state applicate delle modifiche affinché per ciascuna
classe fossero valide le seguenti caratteristiche:
 ridenominazione della classe con il solo nome della categoria (ES.
“Coffee_and_tea”);

valorizzazione del campo rdfs:label in modo che contenga sia il codice
UNSPSC che il nome della categoria (Es. “_502017__Coffee_and_tea”);

valorizzazione del campo rdfs:comment in modo che riporti solo il
nome della categoria senza caratteri di sottolineatura (Es. “Coffee and
tea”).
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 82 di 104
Sviluppo di un applicazione per modificare i commenti e label di
un’ontologia
Considerato l‟elevato numero delle classi dell‟ontologia delle categorie
commerciali UNSPSC, al fine di attuare in maniera consistente le suddette
modifiche è stata realizzata un‟applicazione Java ontology-based, che utilizza
un framework open source, Jena [44] sviluppato dal Semantic Web Research
Group di HP Labs. Jena permette di gestire le ontologie con un modello ad
oggetti indipendente dal linguaggio ontologico utilizzato, la cui classe
principale è OntModel che espone metodi per la lettura e per la serializzazione
delle ontologie. Inoltre tramite opportuni iteratori è possibile navigare tra i
vari elementi dell‟ontologia (classi, proprietà, individui e così via). La
piattaforma di sviluppo di riferimento è Eclipse. Per i nostri scopi è stata
creata una semplice classe denominata OWLFile che, incapsulando le
funzionalità della libreria Jena, implementa dei metodi pubblici per accedere
ad un‟ontologia (readFromFile), cambiare i commenti delle classi
(changeAllComments), cambiare le label delle classi (changeAllLabels),
cambiare gli URI delle classi (changeAllURI) ed infine per salvare le modifiche
effettuate (write e close).
Namespace
Definiamo per l‟ontologia il seguente namespace:
http://www.di.uniba.it/~swap/ontologies/Cat/unspsc.owl
Organizzazione dei concetti in una gerarchia
La tassonomia di prodotti risultante è stata integrata, sotto il concetto toplevel CommercialCategory come illustrato in Figura 40. Nessuna proprietà è
stata definita in questa ontologia.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 83 di 104
Figura 40 – Commercial Categories Ontology
2.4.5.2 Business Process Ontology
Si vuole concettualizzare ed implementare un‟ontologia del dominio funzionale
nella quale ogni concetto/classe rappresenti una funzionalità del dominio
scelto, in modo che ogni funzionalità dei Web Service sia messa in relazione
con uno o più concetti dell‟ontologia funzionale (semantica funzionale).
Lo sviluppo di questa ontologia è strettamente legato al modulo Service
Annotation della piattaforma SWOP, quindi l‟esigenza principale è quella di
presentare una tassonomia di funzioni utili ad annotare semanticamente le
operazioni offerte da ciascun servizio.
Inoltre è necessaria una tassonomia di task generici che sia associabile a
ciascuna funzione di business in modo che il modulo Service Discovery della
piattaforma SWOP possa ricercare i web service in base ai task compiuti da
questi ultimi.
Enumerazione di termini e concetti
Le funzioni da individuare devono sempre da riferirsi al ciclo acquistoproduzione-vendita di un‟azienda. Per semplicità ci limiteremo ad esaminare
le funzioni associabili ai web service definiti per il nostro caso d‟uso
L‟analisi delle descrizioni dei Web Service ci porta ad individuare le seguenti
associazioni (Tabella 24):
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 84 di 104
Service
Sales
Service Method
GetIndividualCustomers
Business Process
SearchCustomerInformation
Sales
GetIndividualCustomerAdressData
Sales
GetStoreCustomers
SearchCustomerStores
Sales
GetStoreContactsByStore
Sales
GetSalesByStore
SearchCustomerSales
Sales
GetStoreByLocation
Product
GetProductDescriptionsByFilter
SearchProductDescription
Product
GetProductDescriptionsByProductModel
Purchasing
GetVendorsByLocation
SearchVendorInformation
Purchasing
GetProductsSuppliedByVendors
SearchVendorProducts
Purchasing
GetVendorContactsByVendor
Purchasing
GetPurchasesByVendor
SearchVendorPurchases
Manufacturing
GetMultiLevelBillOfMaterialsListForProduct
SearchProductBillOfMaterials
Manufacturing
GetWorkOrdersByInventory
SearchProductWorkOrders
Manufacturing
GetWorkOrdersByProduct
Tabella 24 – SWOP - Associazione tra i metodi dei web service e i business process
Inoltre, sono stati individuati i seguenti task generici: insert, modify, search e
delete. I processi legati ai Web Service del caso d‟uso effettuano
esclusivamente interrogazioni sul database (quindi task di tipo search).
Organizzazione della gerarchia di concetti e proprietà
Namespace
http://www.di.uniba.it/~swap/ontologies/BusPro/BusinessProcess.owl
Le classi top-level
L‟ontologia BusinessProcess contiene due classi top-level (Figura 41):
Figura 41 – Business Process (top-level)
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 85 di 104
E‟ stata definita la seguente object-property:
hasTask
Domain:
BusinessProcess
Range:
BusinessTask
Esprime la possibilità che un BusinessProcess possa avere uno o
più task.
Sono state definite le seguenti data-property:
hasBusinessProcessName
Domain:
BusinessProcess
Range:
Literal
E’ il nome di un processo di business.
hasBusinessProcessDescription
Domain:
BusinessProcess
Range:
Literal
E’ la descrizione di un processo di business.
Nella Tabella 25 è riportata una descrizione delle classi illustrate in Figura 41.
Class
BusinessTask
Description
Questa classe identifica un generico task. Sono poi state definite le
seguenti sotto-classi: delete, insert, modify e search.
E‟ il nodo che raggruppa tutte le funzioni di business tipiche del
dominio applicativo coinvolto nell‟attività di annotazione semantica
dei web serivces.
Restrizioni:
BusinessProcess
hasTask
Some
BusinessTask
hasBusinessProcessName
Exactly 1
Literal
hasBusinessProcessDescription
Exactly 1
Literal
BusinessTask e BusinessProcess sono disgiunti tra di loro.
Tabella 25 – Business Process (top-level) - Descrizione delle classi
L‟ontologia top-level così definita può essere estesa per contenere i concetti
specifici del dominio scelto per questo caso d‟uso (ossia la gestione
acquisti/vendite di un‟azienda) o in generale per qualsiasi altra ontologia
specifica (per futuri casi d‟uso) garantendo alla nostra architettura le
caratteristiche di estendibilità e riuso.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 86 di 104
La classe top-level Business Process estesa per il dominio Enterprise
Per il caso d‟uso Adventure Works è stata estesa la classe BUSINESSPROCESS in
modo da considerare i possibili scenari di business: manufacturing, product,
purchasing e sales come illustrato in Figura 42.
Figura 42 – Business Process (estesa per il dominio enterprise)
Per
ogni
funzione
sono
state
specializzate
le
proprietà
hasBusinessProcessName e hasBusinessProcessDescription.
Come vedremo, nell‟ontologia che integrerà i BusinessProcess con i
BusinessObject sarà possibile stabilire delle relazioni tra i concetti delle due
ontologie.
2.4.5.3 Services Ontology
Namespace
http://www.di.uniba.it/~swap/ontologies/Srv/services.owl
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 87 di 104
Per il modulo Discovery Service del progetto SWOP è necessaria un‟ontologia
dei servizi (ontology service) che modelli i web service, in funzione del loro
ritrovamento. Allo stato attuale non è emerso il livello di dettaglio con cui
questa ontologia deve poter descrivere un Web Service, se ad esempio deve
solo limitarsi ad esprimere i suoi legami con le ontologie di riferimento
(categorie commerciali, operazioni, task, dati di input/output), oppure se deve
anche contenere informazioni sul suo grounding (consentire la trasformazione
dell‟input e dell‟output di un processo atomico in concetti di
rappresentazione).
Nell‟ipotesi che debba servire anche una struttura per descrivere le
informazioni funzionali e non funzionali di un Web Service, è stata arricchita la
classe top-level Service. In realtà, per le classi e le relazioni che verranno
descritte in questo paragrafo attualmente non è stato definito alcun ruolo
nella fase di discovery. Quindi negli sviluppi futuri alcune classi potrebbero
anche essere rimosse in modo da lasciare la sola classe top-level Service con
le sue data-property di base (nome e descrizione) nell‟ontologia Services. A
questo punto sarebbe possibile aggiungere nuove classi e proprietà a seconda
dei nuovi obiettivi e “scope” definiti.
E‟ opportuno precisare che le relazioni con le altre ontologie vengono definite
nell‟ontologia di integrazione e le estensioni della classe Service in essa
presenti restano valide in ogni caso.
Riuso di un’ontologia di servizi esistente
E‟ stato preso come punto di riferimento, l‟ontologia dei servizi vista per il
progetto BMO che modella un‟ontologia di servizi usando OWL-S come
linguaggio di riferimento. Le classi dell‟ontologia dei servizi di BMO sono state
raggruppate sotto il macro-concetto ServiceConcept, escludendo la classe
ServiceModel, che sicuramente non è necessaria, e conservando la classe
ServiceGrounding.
Le classi presenti nell‟ontologia Services sono indicate in Figura 43.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 88 di 104
Figura 43 – Services Ontlogy
Come si evince dai nomi della classi, l‟ontologia permette di strutturare un
Web Service, in funzione degli elementi del formalismo WSDL.
Definizione delle Object Property
Sono state definite le seguenti object-property:
hasServiceGrounding
Domain:
Service
Range:
ServiceGrounding
Ad ogni Service può essere associato un ServiceGrounding. Questa
proprietà potrebbe essere rimossa.
isAssociatedToAService
Domain:
ServiceGrounding
Range:
Service
Un ServiceGrounding è associato ad un Service. Questa proprietà
potrebbe essere rimossa.
hasServiceInputParameter
Domain:
Service or WSDLMessageMapInput
Range:
ServiceInputParameter
Un service può avere dei parametri di input e questi possono
essere referenziati da un WSDLMessageMapInput. Questa proprietà
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 89 di 104
hasServiceOutputParameter
Domain:
WSDLMessageMapOutput or Service
Range:
ServiceOutputParameter
Un service può avere dei parametri di output e questi possono
essere referenziati da un WSDLMessageMapInput. Questa proprietà
hasWSDLMessageMapInput
Domain:
ServiceGrounding or WSDLMessagePartInput
Range:
WSDLMessageMapInput
Ci deve essere un’istanza di questa proprietà per ogni message
part del WSDL input message. Questa proprietà potrebbe essere
rimossa.
hasWSDLMessageMapOutput
Domain:
ServiceGrounding or WSDLMessagePartOutput
Range:
WSDLMessageMapOutput
Ci deve essere un’istanza di questa proprietà per ogni output del
servizio. Questa proprietà potrebbe essere rimossa.
hasWSDLMessagePartInput
Domain:
WSDLInputMessage
Range:
WSDLMessagePartInput
Esprime la relazione tra i due oggetti. Questa proprietà potrebbe
essere rimossa.
hasWSDLMessagePartOutput
Domain:
WSDLOutputMessage
Range:
WSDLMessagePartOutput
Esprime la relazione tra i due oggetti. Questa proprietà potrebbe
essere rimossa.
hasWSDLOperation
Domain:
ServiceGrounding
Range:
WSDLOperationRef
Un ServiceGrounding specifica delle operazioni. Questa proprietà
Definizione delle Data Property
Sono state definite le seguenti data-property relative alla classe Service:
hasServiceName
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 90 di 104
Domain:
Service
Range:
Literal
Individua il nome del servizio. Nella fase di discovery (a cui lo
sviluppo dell'ontologia è funzionale) si individuerà un modello dei
dati
che
combini
informazioni
strutturate
ad
informazioni
semantiche. Questo probabilmente comporterà l'eliminazione della
proprietà che diventerà il campo di una tabella relazionale.
hasServiceDescription
Domain:
Service
Range:
Literal
Individua una descrizione del servizio. Nella fase di discovery (a cui
lo sviluppo dell'ontologia è funzionale) si individuerà un modello dei
dati
che
combini
informazioni
strutturate
ad
informazioni
semantiche. Questo probabilmente comporterà l'eliminazione della
proprietà che diventerà il campo di una tabella relazionale.
hasServiceProviderInformation
Domain:
Service
Range:
Literal
Individua il nome del provider. Questa proprietà potrebbe essere
rimossa.
Sono state definite le seguenti data-property relative alle altre classi (da
rimuovere qualora l‟ontologia non debba essere utilizzata per rappresentare il
grounding del web service):
hasParameterName
Domain:
ServiceParameter
Range:
Literal
E’ il nome del parametro. Questa proprietà potrebbe essere
rimossa.
hasParameterUsageType
Domain:
ServiceInputParameter, ServiceOutputParameter
Range:
{"IN", "OUT"}
E’ il tipo di parametro se di input o output. Questa proprietà
hasOperation
Domain:
Attività: 2.2
WSDLOperationRef
Versione:1
Data: 16/07/2010
Pag. 91 di 104
Range:
anyURI
E’ un URI di un metodo del web service. Questa proprietà potrebbe
essere rimossa.
hasPortType
Domain:
WSDLOperationRef
Range:
anyURI
Rappresenta il port-type di un web service. Questa proprietà
hasWSDLDocument
Domain:
ServiceGrounding
Range:
anyURI
ServiceGrounding:E’ un URI che indica il documento WSDL a cui il
grounding si riferisce. Non è un’informazione essenziale ma è solo
per documentazione. Questa proprietà potrebbe essere rimossa.
hasWSDLInputMessage
Domain:
ServiceGrounding
Range:
anyURI
E’ un URI per l’elemento WSDL input message. Questa proprietà
hasWSDLMessagePart
Domain:
WSDLMessageMap
Range:
Literal
Questa proprietà potrebbe essere rimossa.
hasWSDLOututMessage
Domain:
ServiceGrounding
Range:
anyURI
E’ un URI per l’elemento WSDL message corrispondente all’output
del service. Questa proprietà potrebbe essere rimossa.
hasWSDLPort
Domain:
ServiceGrounding
Range:
anyURI
Un URI per un WSDL Port che fornisce l’operazione a cui il servizio
is legato. Questa proprietà potrebbe essere rimossa.
hasWSDLVersion
Domain:
Attività: 2.2
ServiceGrounding
Versione:1
Data: 16/07/2010
Pag. 92 di 104
Range:
anyURI
Un URI indicante la versione di WSDL che viene usata. Questa
proprietà potrebbe essere rimossa.
Definizione delle Classi
Segue una descrizione delle classi illustrate in Figura 43.
Classe
Descrizione
Identifica un web service, che soddisfa uno specifico task o insieme
di tasks. Ogni istanza supporta una descrizione ServiceGrounding.
Restrizioni
Service
hasServiceName
Exactly 1
Literal
hasServiceDescription
some
Literal
Max 1
Literal
hasServiceProviderInformation
Descrive come accedere al servizio in termini di protocollo, formato
dei messaggi, serializzazione, ecc. Inoltre, il grounding deve
specificare per ogni tipo semantico di input o output, una maniera
ServiceGrounding
non ambigua di scambiare dati di quel tipo con il servizio. Questa
classe potrebbe essere rimossa.
Restrizioni
Exactly 1
isAssociatedToAService
ServiceParameter
Service
Sono i parametri del servizio. Questa classe potrebbe essere
rimossa.
WSDLInputMessage: un oggetto contenente l‟URI della definizione
del messaggio WSDL che contiene l‟input di un dato service.
WSDLMessage
WSDLOutputMessage: un oggetto contenente l‟URI della definizione
del messaggio WSDL che contiene l‟output di un dato service.
Questa classe potrebbe essere rimossa.
WSDL Message Map (Questa classe potrebbe essere rimossa).
Restrizioni
Some
hasWSDLMessagePart
WSDLMessageMAPInput:
Literal
mappa
gli
input
ad
una
specifica
grounding
WSDLMessageMap
Restrizioni
hasServiceInputParameter
Some
ServiceParameter
WSDLMessageMAPOutput: mappa gli output ad una specifica
grounding
Restrizioni
hasServiceOutputParameter
Attività: 2.2
Versione:1
Data: 16/07/2010
Some
ServiceParameter
Pag. 93 di 104
Classe
Descrizione
WSDLMessagePartInput
referenzia
Un
WSDLMessagePart
un
o
più
WSDLMessageMAPInput. Un WSDLMessagePartOutput referenzia
uno o più WSDLMessageMAPOutput. Questa classe potrebbe essere
rimossa.
Questa classe fornisce una specifica univoca di una operazione
WSDL.
WSDL 1.1, su cui questa versione di grounding è basata, non ha un
modo univoco di riferirsi ad un‟operazione con un singolo URI.
WSDLOperationRef
L‟unicità è data dalla coppia (portType, operation). Questa classe
Restrizioni
hasOperation
Exactly 1
Literal
hasPortType
Exactly 1
Literal
Tabella 26 – SWOP - Services Ontology – Descrizione delle classi
2.4.5.4 Swop Integration Ontology
In questo paragrafo descriviamo come integrare tra di loro le ontologie sin qui
descritte, in modo da definire le relazioni tra i concetti in esse definiti.
Per il modulo Service Discovery è necessaria un‟ontologia dei servizi (ontology
services) che modelli i web service, in funzione del loro ritrovamento. Le query
possono coinvolgere, tra l‟altro, i seguenti elementi:
1. caratteristiche non funzionali come la categoria del servizio;
2. caratteristiche funzionali come l‟input, l‟output ed il tipo di funzionalità
offerte;
3. conoscenza di dominio che definisce, ad esempio, la tipologia dell‟input
di un servizio (contesto).
Quindi obiettivo di questa ontologia è caratterizzare ulteriormente la classe
Service in modo che risponda ai requisiti elencati (stiamo definendo il suo
profilo).
Namespace
Definiamo per l‟ontologia di integrazione il seguente namespace:
http://www.di.uniba.it/~swap/ontologies/SwopInt/swop-integration.owl
Questa ontologia importa quelle di più basso livello, relative ai seguenti
concetti:
 Business Object;

Business Process e Business Task;

Commercial Category;
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 94 di 104

Services.
In Figura 44 è riportata la sezione “Imported Ontologies” così come appare
nell‟environment di Protegé 4.
Figura 44 – Swop Integration (Imported Ontologie)
Gerarchia delle classi dell’ontologia di integrazione
In Figura 45 viene illustrata la gerarchia delle classi dell‟ontologia di
integrazione. Riconosciamo le cinque classi top-level presenti nelle ontologie
importate. In questa ontologia si è definito che le cinque super-classi siano
disgiunte tra di loro.
Figura 45 – Swop Integration Ontlogy(top-level)
Questa ontologia non contiene la definizione di alcuna nuova classe e nessuna
nuova data-property.
Definizione delle object-property dell’ontologia di integrazione
Proprietà del dominio Service
A) E‟ stata definita una proprietà che permette di associare ad un Service una
categoria commerciale:
hasCommercialCategory
Domain:
Service
Range:
CommercialCategory
Indica che un Service può avere una o più categorie commerciali.
E‟ stata poi definita la seguente restrizione sulla classe Service:
hasCommercialCategory exactly 1 CommercialCategory
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 95 di 104
B) E‟ stata definita una proprietà che permette di associare ad un Service
delle funzioni.
hasBusinessProcess
Domain:
Service
Range:
BusinessProcess
Indica che un Service può avere una o più funzioni di business di
riferimento.
E‟ stata poi aggiunta la seguente restrizione sulla classe Service:
hasBusinessProcess some BusinessProcess
C) E‟ stata definita una proprietà che permette di associare ad un Service un
contesto.
hasContext
Domain:
Service
Range:
Concept or BusinessProcess
Indica che un Service può avere un contesto, ossia un ambito che
può essere sia un macro-concetto del dominio applicativo sia una
funzione.
E‟ stata poi definita la seguente restrizione sulla classe Service:
hasContext some (Concept or BusinessProcess)
Proprietà del dominio ServiceParameter
B) Sono state definite delle proprietà che permettono il mapping con i dati di
input/output di un ServiceParameter.
hasBusinessObject
Domain:
ServiceParameter
Range:
BusinessObject
Indica che un ServiceParameter può riferirsi ad un concetto del
dominio. Questa proprietà potrebbe essere rimossa.
Per ora non c‟è alcuna restrizione su questa relazione, in quanto tale proprietà
attualmente non viene utilizzata nella modellazione dei Web Service dei caso
d‟uso, pertanto rappresenta soltanto un placeholder per sviluppi futuri.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 96 di 104
Proprietà del dominio BusinessProcess
Una funzione di business, può essere vista come una black box, che lavora su
degli input e fornisce degli output. Sono state definite delle proprietà che
permettono di associare alla classe BusinessProcess uno o più concetti in input
e in output:
hasInput
Domain:
BusinessProcess
Range:
BusinessObject
Indica che un BusinessProcess può avere uno o più concetti di
business in input.
hasOutput
Domain:
BusinessProcess
Range:
BusinessObject
Indica che un BusinessProcess può avere uno o più concetti di
business in output.
A questo livello dell‟ontologia non possiamo porre ulteriori vincoli sul numero
degli input in quanto una funzione potrebbe anche non avere un input.
Potremo aggiungere delle restrizioni solo analizzando nel dettaglio le funzioni
definite per il dominio applicativo del nostro caso d‟uso (Figura 42).
Riepilogando brevemente, possiamo affermare che le seguenti object property
fanno sì che l‟ontologia raggiunga gli scopi fissati:
1. hasCommercialCategory
2. hasBusinessProcess
3. hasInput
4. hasOutput
5. hasContext
Le restrizioni sulle proprietà nel dominio Enterprise
Nella Tabella 27 sono stati individuati i possibili macro-concetti di input/output
associabili alle funzioni definite per il caso d‟uso AdventureWorks.
SWOP Business
Process
EndProductWorkOrder
SearchProductBillOfMaterial
Concetti
Concetti
in Input
in Output
ProductWorkOrder,
ProductWorkOrderEndDate
Product
s
Attività: 2.2
Product
Versione:1
Data: 16/07/2010
ProductBillOfMaterials
ProductWorkOrder
Pag. 97 di 104
StartProductWorkOrder
Product, ProductWorkOrderStartDate
AddProduct
Product
-
Product
ProductConcept
AddNewVendor
Vendor
-
Vendor
VendorAddress
SearchVendorProducts
Vendor
Product
SearchVendorPurchases
Vendor
PurchaseOrder
AddNewCustomer
Customer
-
Customer
CustomerAddress
Customer
SalesOrder
SearchCustomerSales
Customer
CustomerStore
Tabella 27 – BusinessProcess (associazione input/output)
Queste associazioni si concretizzano nelle seguenti restrizioni applicate sulle
classi di seguito elencate:
- Class EndProductWorkOrder
hasInput exactly 1 ProductWorkOrder
ProductWorkOrderEndDate
and
hasInput
exactly
1
- Class SearchProductBillOfMaterials
hasInput some Product and hasOutput some ProductBillOfMaterials
- Class SearchProductWorkOrders
hasInput some Product and hasOutput some ProductWorkOrder
- Class StartProductWorkOrder
hasInput
exactly
1
Product
ProductWorkOrderStartDate
and
hasInput
exactly
1
- Class AddProduct
hasInput some Product
- Class SearchProductDescription
hasInput some Product and hasOutput some ProductConcept
- Class AddNewVendor
hasInput some Vendor
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 98 di 104
- Class SearchVendorInformation
hasInput some Vendor and hasOutput some VendorAddress
- Class SearchVendorProducts
hasInput some Vendor and hasOutput some Product
- Class SearchVendorPurchases
hasInput some Vendor and hasOutput some PurchaseOrder
- Class AddNewCustomer
hasInput some Customer
- Class SearchCustomerInformation
hasInput some Customer and hasOutput some CustomerAddress
- Class SearchCustomerStores
hasInput some Customer and hasOutput some SalesOrder
- Class SearchCustomerSales
hasInput some Customer and hasOutput some CustomerStore
In fase di modellazione di un web service, dovendo esprimere il servizio in
funzione di uno o più
processi di business, potremmo specializzare
ulteriormente queste restrizioni, richiamando concetti più specifici (come ad
esempio gli attributi). Tale modellazione sarà oggetto dell'attività A2.3.
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 99 di 104
2.5 Bibliografia
[1] T. Berners-Lee. Weaving the Web. Harper, San Francisco, 1999.
[2]
M.-R.
Koivunen
and
E.
Miller,
2001.
Semantic
Web
Main
Principles,
http://www.w3.org/2001/12/semweb-fin/w3csw
[3]
Extensible
Markup
Language
(XML)
1.0,
W3C
Recommendation,
2006.
http://www.w3.org/TR/REC-xml/
[4] W3C Recommendation, 10 February 2004. RDF Primer. http://www.w3.org/TR/rdfprimer/
[5] S. Decker, F. van Harmelen, J. Broekstra, M. Erdmann, D. Fensel, I. Horrocks, M.
Klein, and S. Melnik. The semantic web - on the respective roles of XML and RDF. IEEE
Internet Computing, 2000.
[6] Resource Description Framework (RDF): Concepts and Abstract Syntax, W3C
Recommendation, 2004. http://www.w3.org/TR/rdf-concepts/
[7] RDF Semantics, W3C Recommendation, 2004.http://www.w3.org/TR/rdf-mt/
[8] RDF Vocabulary Description Language 1.0: RDF Schema, W3C Recommendation,
2004. http://www.w3.org/TR/rdf-schema/
[9] OWL 2, “Web Ontology Language”. W3C (2009). URL:
http://www.w3.org/TR/owl2-syntax/
[10] D. Tsarkov, I. Horrocks, “Reasoner Demonstrator, Implementing new reasoner
with datatypes support”. University of Manchester, Tech. Rep. (2004).
[11] FACT++, URL: http://owl.man.ac.uk/factplusplus/
[12]
D.
Tsarkov,
I.
Horrocks,
“FaCT++
Description
Logic
Reasoner:
System
Description.” In Proc. of the Int. Joint Conf. on Automated Reasoning (IJCAR 2006),
volume 4130 of Lecture Notes in Artificial Intelligence, pages 292-297. Springer, 2006.
[13] RACER PRO©, Reaoner, http://www.racer-systems.com/
[14] SPARQL
Query Language for RDF. W3C Recommendation (2008). URL:
http://www.w3.org/TR/rdf-sparql-query/
[15] E. Sirin, B. Parsia, B. Grau, A. Kalyanpur, Y. Katz. Pellet, “A practical OWL-DL
Reasoner”. Journal of Web Semantics (2006).
[16] A. Gómez-Pérez, M. Fernandez-Lopez, O. Corcho. “Ontological engineering”.
Springer, 2003
[17] Natalya F. Noy e Deborah McGuiness (2000). “Ontology Development 101: A
Guide to Create Your First Ontology”. URL:
http://protege.stanford.edu/publications/ontology_development/ontology101.pdf
[18] M. Gruninger, M. Fox. “The Role of Competency Questions in Enterprise
Engineering”. (1994). URL:
http://www.eil.utoronto.ca/enterprise-modelling/papers/benchIFIP94.pdf
[19]
Protegé,
Ontology
Editor,
Stanford
University
(2010).
URL:
http://protege.stanford.edu/
[20] Manchester Syntax, URL:
http://www.co-ode.org/resources/reference/manchester_syntax/
[21]
Adventure
Works,
Uno
scenario
di
business.
Microsoft ©
(2008).
URL:
http://technet.microsoft.com/it-it/library/ms124825(SQL.100).aspx
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 100 di 104
[22]
BPEL,
Business
Process
Execution
Language
for
Web
Services.
URL:
http://www.oasis-open.org/committees/wsbpel
[23]
Leo
Obrst
(2003), “Ontologies for Semantically Interoperable
Systems”.
Proceedings of the 12th International Conference on Information and Knowledge
Management
[24] D. Frankel. “Industrial Convergence and Semantic Interoperability”. MDA Journal
(2007). URL:
http://www.bptrends.com/publicationfiles/TEN%20MDA%20Journal%20200707%20Industrial%20Convergence%20v01-00.pdf
[25] M. Weske. “Business Process Management: Concepts, Languages, Architectures”.
Springer (2007).
[26] BPMN, Business Process Modelling Notation. URL: http://www.bpmn.org/
[27] UML, Unified Modeling Language. URL: http://www.uml.org/
[28] UMM, UN/CEFACT's Modeling Methodology. URL:
http://www.untmg.org/umm/spec/foundation/1_0/
[29] XPDL, XML Process Definition Language. URL: http://www.wfmc.org/xpdl.html
[30] UNSPSC, Categories Classification, URL: http://www.unspsc.org/
[31] UNSPSC OWL, Middle East Technical University. URL:
http://www.srdc.metu.edu.tr/ubl/translation/src/Thesis%20Extract.pdf
[32] UNSPSC OWL, Heppnetz. URL: http://www.heppnetz.de/projects/unspscowl/
[33] ECLASS OWL, URL: http://www.heppnetz.de/projects/eclassowl/
[34] UBL, language. URL:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl
[35] NEON Project. URL: http://www.neon-project.org
[36] DIP Business Data Ontology. URL: http://dip.semanticweb.org/documents/D3.3Business-data-ontology.pdf
[37] PROTON Ontology. URL: http://proton.semanticweb.org/
[38] OASIS SET Harmonized Ontology. URL:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=set
[39] GoodRelations Ontology. URL: http://purl.org/goodrelations/
[40] SUPER PROJECT, URL: http://www.ip-super.org/
[41] SUPER PROJECT Ontologies. URL:
http://www.ip-super.org/res/Deliverables/M6/D2.1.pdf
[42] SINDICE, semantic search. URL: http://sindice.com/main/submit
[43] BMO, Business Management Ontology. URL:
http://www.bpiresearch.com/Resources/RE_OSSOnt/re_ossont.htm
[44] ONTO MODA-ML. URL:
http://spring.bologna.enea.it/LeapfrogWiki/index.php?title=OntoMODA
[45] JENA Framework. URL: http://jena.sourceforge.net/
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 101 di 104
3. Appendici
3.1 Dati riepilogativi dell’ontologia SWOP
Scheda Ontologia SWOP BUSINESS OBJECT
Ontology URI:
http://www.di.uniba.it/~swap/ontologies/BusObj/BusinessObject.owl
Linguaggio:
OWL DL
Versione:
1.0
Num. Classi:
317
57
Num.
0
Num. Data Property:
5
Individui:
Espressività in
ALCHQ(D)
DL:
Scheda Ontologia SWOP BUSINESS PROCESS
Ontology
http://www.di.uniba.it/~swap/ontologies/busPro/BusinessProcess.owl
URI:
Linguaggio:
OWL DL
Versione:
1.0
Num. Classi:
25
2
Num.
0
Num. Data Property:
3
Individui:
Espressività
ALCHN(D)
in DL:
Scheda Ontologia SWOP COMMERCIAL CATEGORIES
Ontology URI:
http://www.di.uniba.it/~swap/ontologies/cat/unspsc.owl
Linguaggio:
OWL DL
Versione:
1.0
Num. Classi:
702
0
Num. Individui:
0
Num. Data Property:
0
AL
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 102 di 104
Scheda Ontologia SWOP SERVICES
Ontology URI:
http://www.di.uniba.it/~swap/ontologies/srvc/Services.owl
Linguaggio:
OWL DL
Versione:
1.0
Num. Classi:
16
10
Num. Individui:
0
Num. Data Property:
14
ALCHIQ(D)
Scheda Ontologia SWOP INTEGRATION (escludendo le ontologie che importa)
Ontology URI:
http://www.di.uniba.it/~swap/ontologies/swopint/swopintegration.owl
Linguaggio:
OWL DL
Versione:
1.0
Num. Classi:
35
8
0
Num. Data Property:
0
Num. Individui:
Espressività
in
ALCHQ
DL:
Importando le SWOP BUSINESS OBJECT, PROCESS, CATEGORIES e SERVICES
Num. Classi:
Num. Individui:
Espressività
in
1059
75
0
Num. Data Property:
22
ALCHIQ(D)
DL:
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 103 di 104
FIRMA DIGITALE CERTIFICATA
Apporre la Firma digitale certificata del Legale rappresentante del soggetto
Beneficiario
Attività: 2.2
Versione:1
Data: 16/07/2010
Pag. 104 di 104

Tecniche di gestione delle meta-informazioni nel Semantic

Transcript

Documenti analoghi

standard di documentazione cluster - SWOP

Brad Pitt presenta case ecologiche per New Orleans

curcuma alismatifolia

SeaClub insotel Cala Mandia 55 BaLeari

No all`uniforme scolastica Vincerà “Cars” o “Gang

UserID e password sono quelle che ti sono state communicate dal

COMPITI PER LE VACANZE ESTIVE

Illegittimo impedimento

composed upon westminster bridge william wordsworth

La polizia canadese difende la taser gun