Code Architects S.r.l. SWOP Semantic web-service Opened Platform B2SO201

Transcript

1 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 Asse I Linea 1.1 Azione 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

2 Indice dei contenuti 1. CONTENUTO DELL ALLEGATO CORPO DELL ALLEGATO Il Semantic Web Resource Description Framework (RDF) Web Ontology Language (OWL) I ragionatori Fact Racer Pellet La gestione della conoscenza nella piattaforma SWOP Una semplice metodologia di sviluppo di ontologie Protégé Il caso d uso per la piattaforma SWOP Dominio e scopo dell ontologia I moduli dell ontologia Ontologie esistenti per il dominio Enterprise Le ontologie e le imprese I processi aziendali e la loro rappresentazione sintattica Le ontologie formali esistenti Standard per la classificazione di prodotti e servizi Standard per la classificazione dei processi aziendali NeOn - UBL Invoice Ontology DIP - Business Data Ontology SET Harmonized Ontology GoodRelations Le ontologie del progetto SUPER Business Management Ontology ONTOMODA-ML Progettazione dell ontologia SWOP Costruzione dell ontologia BusinessObject Enumerazione dei termini e dei concetti Organizzazione dei concetti in una gerarchia Definizione di proprietà e restrizioni La classe top-level Business Obejct La classe BusinessObject estesa per il dominio enterprise La classe Concept estesa per il dominio Enterprise La classe Attribute estesa per il domino enterprise Le Object Property della Business Object Ontology Le Data Property della Business Object Ontology Le ontologie per modellare i servizi Categories Ontology Business Process Ontology Services Ontology Pag. 2 di 104

3 Swop Integration Ontology Bibliografia APPENDICI Dati riepilogativi dell ontologia SWOP Pag. 3 di 104

4 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. Pag. 4 di 104

5 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). Pag. 5 di 104

6 Il primo strato utilizza standard e tecnologie sviluppate e largamente utilizzate nel Web. Queste sono utili poiché specificano un meccanismo per identificare le risorse (URI 1 ) e una codifica non ambigua del contenuto testuale (UNICODE 2 ). 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: 2 Unicode Home Page : Pag. 6 di 104

7 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. Pag. 7 di 104

8 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 namespace 3, cioè si dichiara un nome fittizio per identificare la URI. 3 Namespaces in XML 1.0 (Second Edition), W3C Recommendation Pag. 8 di 104

9 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 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. Pag. 9 di 104

10 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 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: Pag. 10 di 104

11 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 OWL- DL; ogni conclusione valida in OWL-DL è una conclusione valida in OWL- FULL. 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. Pag. 11 di 104

12 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 Pag. 12 di 104

13 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. Pag. 13 di 104

14 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 I ragionatori 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; Pag. 14 di 104

15 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. Pag. 15 di 104

16 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; Pag. 16 di 104

17 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 Pellet Pellet [15] è un reasoner open-source che soddisfa alcuni requisiti considerati critici 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 Pag. 17 di 104

18 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. Pag. 18 di 104

19 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) 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. Pag. 19 di 104

20 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à. Pag. 20 di 104

21 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 unionof complementof somevaluefrom allvaluesfrom cardinality hasvalue Sintassi in Protegé and or not some only exactly 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. Pag. 21 di 104

22 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 Customer CustomerAddress Location Product ProductCategory ProductInventory ProductModel ProductSubcategory ProductVendor PurchaseOrderHeader SalesOrderHeader Store Vendor VendorAddress WorkOrder Descrizione Elenco di tutti i componenti utilizzati per produrre le biciclette e i rispettivi componenti di assemblaggio. 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 ). 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. 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. Informazioni relative a tutti i prodotti venduti o utilizzati per produrre le biciclette e i rispettivi componenti. Classificazione generale dei prodotti. Ad esempio, bicicletta o accessorio. Il livello di inventario dei prodotti in base alla rispettiva ubicazione. Modelli diversi di un prodotto. Sottocategorie di prodotti. Ad esempio, Mountain, Road e Touring sono sottocategorie della categoria Bike. 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. Informazioni di riepilogo di un'ordine di acquisto, quali il totale e la data. Contiene informazioni generali o di riferimento relative agli ordini di vendita. Contiene dati relativi ai clienti rivenditori dei prodotti. Dettagli relativi ai fornitori, ad esempio il nome e il numero di conto. Contiene gli indirizzi di tutti i fornitori. Può essere presente più di un indirizzo. Contiene dati relativi agli ordini di produzione. Questo tipo di ordini consente di controllare quali prodotti vengono realizzati in quantità Pag. 22 di 104

23 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 Descrizione Sales GetIndividualCustomers Vengono restituiti il nome e il cognome di tutti i clienti individuati come privati (CustomerType = 'I'). Sales GetIndividualCustomer Restituisce i dati relativi agli indirizzi dei clienti privati. AdressData Sales GetStoreCustomers Viene restituito il nome di tutti i clienti individuati come punti vendita (CustomerType = 'S'). Sales Vengono restituiti i nomi di tutti i punti vendita e i nomi GetStoreContacts e le rispettive qualifiche dei dipendenti del punto ByStore vendita. Sales GetSalesByStore Viene creato un elenco dei punti vendita e degli ordini di vendita a essi associati. Sales GetStoreByLocation Vengono visualizzati nome, città, provincia e paese del punto vendita. Product Visualizzazione dei prodotti per categoria, sottocategoria GetProductDescriptions e modello. Non sono inclusi i prodotti non associati ad ByFilter alcuna categoria. Product GetProductDescriptions Visualizzazione delle descrizioni dei prodotti per modello. Pag. 23 di 104

24 Service Metodo Descrizione ByProductModel Purchasing GetVendorsByLocation Visualizza un elenco dei fornitori con i rispettivi indirizzi. Purchasing Purchasing Purchasing Manufacturing Manufacturing Manufacturing GetProductsSupplied ByVendors GetVendorContacts ByVendor GetPurchasesByVendor GetMultiLevelBillOf MaterialsListForProduct GetWorkOrders ByInventory GetWorkOrders ByProduct Viene visualizzato un elenco dei prodotti acquistati dalla società presso i fornitori. Viene visualizzato un elenco dei dipendenti del fornitore ai quali il reparto acquisti della società si rivolge per ordinare componenti e prodotti. Vengono visualizzati i dati relativi ai fornitori e agli ordini di acquisto ad essi associati. Visualizzazione di un elenco di distinte dei materiali a più livelli relativo a un prodotto di riferimento principale. Viene restituita la quantità disponibile di ogni prodotto in base alla rispettiva ubicazione di inventario. 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) 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. Pag. 24 di 104

25 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. Pag. 25 di 104

26 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 Descrizione Categories unspsc.owl Contiene una tassonomia delle categorie commerciali di prodotti e servizi. Business Vengono classificate le funzionalità e i task del BusinessProcess.owl Processe dominio applicativo. Business Definisce i concetti del dominio che identificano gli BusinessObject.owl Object input e gli output dei web service. Services Services.owl Fornisce lo scheletro per modellare i web service. Swop Questo modulo importa i precedenti e stabilisce le swop-integration.owl Integration relazioni tra le classi delle varie ontologie importate. Tabella 4 SWOP - Le ontologie del progetto Pag. 26 di 104

27 2.3 Ontologie esistenti per il dominio Enterprise 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. Pag. 27 di 104

28 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 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: Pag. 28 di 104

29 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 Pag. 29 di 104

30 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 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 Pag. 30 di 104

31 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: Ontology URI: Autori: Linguaggio: ct.pdf Yalin Yarimagan 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 classi di prodotti e più di proprietà per la descrizione delle caratteristiche dei prodotti. Scheda ecl@ssowl URL progetto: Ontology URI: Autori: Martin Hepp and Andreas Radinger Linguaggio: OWL-DL Versione: del 18/04/2010 Num. Classi: Num. Object 4941 Property: Num. Individui: 4767 Num. Data Property: 2275 Espressività in DL: SHI(D) Queste tassonomie di prodotti possono essere facilmente integrate in altre ontologie Standard per la classificazione dei processi aziendali Per la classificazione dei processi aziendali citiamo alcuni importanti standard basati su XML: 14 Pag. 31 di 104

32 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 NeOn - UBL Invoice Ontology Scheda NEON UBL Invoice URL progetto: Ontology URI: Autori: Linguaggio: wl isoco S.A. ( OWL DL Versione: 18/02/2010 finale Num. Classi: 106 Num. Object Property: 111 Num. Individui: 0 Num. Data Property: 3 Espressività in DL: ALUN(D) Pag. 32 di 104

33 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: Pag. 33 di 104

34 Figura 6 UBL Invoice Ontology (Transaction Entity) Pag. 34 di 104

35 DIP - Business Data Ontology Scheda BDO URL progetto: Ontology URI: Autori: Gabor Nagypal ( Linguaggio: OWL FULL Versione: 24/01/2005 finale Num. Classi: 385 Num. Object Property: 519 Num. Individui: 0 Num. Data Property: 97 Espressività in DL: ALHI+(D) 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: Ontology URI: Autori: Linguaggio: OntoText Lab ( OWL-DL Versione: 0.1 del 2005 finale Num. Classi: 266 Num. Object Property: 77 Num. Individui: 0 Num. Data Property: 36 Espressività DL: in ALHI+(D) 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 Pag. 35 di 104

36 Figura 7 Processo ordine-fattura in UBL Quella visualizzata in Figura 8 è una visione d insieme dell ontologia BDO. Pag. 36 di 104

37 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. Order b. Order Response Simple c. Order Response (detailed) d. Order Change e. Order Cancellation f. Despatch Advice g. Receipt Advice h. Invoice Pag. 37 di 104

38 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 SET Harmonized Ontology Scheda SET Harmonized Ontology URL progetto: Ontology URI: TC/ontology/ HarmonizedOntology.owl Autori: Oasis Committees Linguaggio: OWL-Lite Versione: 13/05/2009 finale Num. Classi: 3351 Num. Object Property: 9 Num. Individui: 0 Num. Data Property: 0 Espressività in DL: AL 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 Pag. 38 di 104

39 Figura 9 Set Harmonized Ontology GoodRelations Scheda GoodRelations URL progetto: Ontology URI: Autori: Martin Hepp Linguaggio: OWL DL Versione: Release 1.0 del 12/04/2010 Num. Classi: 28 Num. Object Property: 43 Num. Individui: 47 Num. Data Property: 37 Espressività in DL: 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. Pag. 39 di 104

40 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. Pag. 40 di 104

41 Figura 11 Good Relations Ontology Nella Tabella 6 è riportata una descrizione delle principali classi di GoodRelations: Classi di GoodRelations BusinessEntity 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 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 Pag. 41 di 104

42 Classi di GoodRelations BusinessEntityType BusinessFunction DayOfWeek DeliverMethod LocationsOfSalesOrS erviceprovisioning 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ò 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, 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 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 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 consegna. In questo caso il luogo principale dell ufficio della 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 Pag. 42 di 104

43 Classi di GoodRelations N-Ary-Relations Offering PaymentMethod PriceSpecification ProductOrService 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 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 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 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. 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 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). Pag. 43 di 104

44 Classi di GoodRelations QualitativeValue QuantitativeValue WarrantyScope 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 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 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 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 Pag. 44 di 104

45 Figura 12 Good Relation Annotator - Step 1 Figura 13 Good Relation Annotator - Step 1b Pag. 45 di 104

46 Figura 14 Good Relation Annotator - Step 2 Figura 15 Good Relation Annotator - Step 3 Pag. 46 di 104

47 Figura 16 Good Relation Annotator - Step 4 Figura 17 Good Relation Annotator - Step 5 Figura 18 Good Relation Annotator - Step 6 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. Pag. 47 di 104

48 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) Le ontologie del progetto SUPER Scheda Ontologie progetto SUPER URL progetto: Ontology URI: Autori: Linguaggio: Super Consortium WSMO Versione: 2009 Num. Classi: N.D. Num. Object Property: Num. Individui: N.D. Num. Data Espressività in DL: N.D. Property: N.D. N.D. 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 Pag. 48 di 104

49 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) Business Management Ontology Scheda BMO URL progetto: Ontology URI: Autori: Jenz & Partner Linguaggio: OWL Full Versione: 1.0 del 2004 finale Num. Classi: 518 Num. Object Property: 481 Num. Individui: 180 Num. Data Property: 557 Espressività in DL: ALCIN (D) 31 Pag. 49 di 104

50 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 Pag. 50 di 104

51 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 Descrizione Ontologia delle tipologie di nazioni, stati e territori. C è Countries anche un riferimento alla codifica ISO Currencies Ontologia delle valute secondo lo standard ISO Language Ontologia delle lingue secondo lo standard ISO 639. Importa le seguenti ontologie (necessarie in ogni organizzazione): Code Lists - Countries Ontology - Currencies Ontology - Language Ontology Definisce la ArtifactDefinitionState Class (le cui Artifact Definition istanze sono descrizioni dei possibili stati: definito, in States 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). Definisce la ReleaseQualityState Class (le cui istanze Release Quality States sono le possibili release: alfa1, beta1, ecc.). Importa le seguenti ontologie: - Artifact Definition States Ontology Code Lists - States - Document Publication States Ontology - Release Quality States Definsice la TimeIntervalUnit Class (le cui istanze Time Interval Units sono i possibili intervalli: giornalmente, mensilmente, annualmente). Definsice la DurationUnit Class (le cui istanze sono le Time Duration Units 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 Pag. 51 di 104

52 Business Context Nome Ontologia Business Context Descrizione Definisce la UniverseOfDiscourse Class (tramite le classi sostantivo, simbolo, verbo, vocabolario) e la classe comunità (semantica o linguistica). Tabella 8 - BMO Business Context Business Context Integration Nome Ontologia Documents Business Context Integration Descrizione Definisce le seguenti classi: Document (un oggetto che descrive dei requisiti), DocumentFormat (le cui istanze 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 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 Business Rules Process Core Components Descrizione Importa la Business Context Integration Ontology. Definisce la Business Rule Class che rappresenta la conoscenza che un azienda ha del suo business. 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, 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 Pag. 52 di 104

53 Nome Ontologia Business Documents Organization Roles Tasks Durable Information Entity Resources Products Ontology Requirements Ontology Partner Privileges Usergroup Privilege Assignments Descrizione UN/CEFACT CCTS), MetaDataItem Class. Importa le seguenti ontologie: - Code Lists States Ontology - Core Components Ontology e definisce la classe BusinessDocument (es. ordine o una fattura). Definisce i concetti di Organization, Organizational Unit, Person. Inoltre è definita la classe DIRECTED- BINARY-RELATION. 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 catturare tali compiti in un modo informale. Definisce la Task Class e importa le seguenti ontologie: - Organization Ontologyc - Roles Ontology Importa le seguenti ontologie: - Code Lists States Ontology - Core Components Ontology 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. Definisce la Resource Class (se umana o fisica). Definisce la generica Product Class. Può essere sviluppata ulteriormente nella Industry-Specific Ontology che tipicamente la importa. Importa la Organization Ontology. Definisce il concetto di requisito, se funzionale o meno, il suo livello (le cui istanze sono del tipo deve, nondeve, potrebbe, non-potrebbe ). 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. Importa le seguenti ontologie: - Partner Ontology - Privileges Ontology Pag. 53 di 104

54 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 Organization- Specific Ontology Descrizione Questa ontologia integra i concetti generici del business. Importa le seguenti ontologie: - 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 Business Objects Ontology IT Integration Ontology Descrizione Definisce la BusinessObject Class. Definisce il lato IT (Information Technology) del BPM. Attualmente questa ontologia definisce solo pochi oggetti di business, giusto per presentare i principi di fondo. Importa le altre ontologie orientate all IT (la Business Objects Ontology). Tabella 12 - BMO IT Pag. 54 di 104

55 BPM Core Nome Ontologia Services Task Implementations Process Task Context Type Entity Types Ontology Business Modeling Ontology Descrizione Tra le altre definisce le seguenti classi: - Service, intesa come un modulo applicativo che esegue un compito. - ServiceGrounding, per differenziare le applicazioni JAVA 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: - Action, un azione è associata con una implementazione di un servizio - TaskInteraction, definisce l interazione tra un utente e un sistema Importa le seguenti ontologie: - 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 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 EntityType Class (le cui istanze possono ad esempio essere BusinessDocument, BusinessEntity, BusinessObject, BusinessRule). Importa la Organization Ontology. Basato su UN/CEFACT UMM, definisce i concetti di BusinessArea, Pag. 55 di 104

56 Nome Ontologia BPM Core Ontology Descrizione BusinessDomainView,BusinessGoal,BusinessObjective. Importa la Business Context Integration 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 BPM Integration Ontology Descrizione Importa le seguenti ontologie e le mette in relazione: - BPM-Core Ontology - Business Modeling Ontology - Business Rules Process Ontology - Core Components Ontology - Entity Types Ontology - Privilege Assignments 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 Pag. 56 di 104

57 Business Integration Nome Ontologia Business Integration Ontology Descrizione Questa ontologia rappresenta lo strato di integrazione di business di più alto livello. Essa importa le seguenti ontologie: 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 Business Management Ontology (BMO) Descrizione Importa la Business Integration Ontology. Rappresenta lo strato dell'ontologia toplevel. 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 Industry-Specific Ontology 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. Eventualmente aggiungere le ontologie industriali specifiche che possono esistere parallelamente a BMO. Tipicamente un ontologia specifica può importare altre Pag. 57 di 104

58 Nome Ontologia Business Integration Ontology Business Management Ontology (BMO) Descrizione ontologie BMO ed estenderne le classi. Ad esempio può estendere la Product Class in modo da definire le specificità del settore. La struttura è quella della Business Integration Ontology, Specific Ontology). La 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 ONTOMODA-ML in più importa eventuali ontologie di settore (Industry- Scheda Ontomoda-ML URL progetto: A Ontology URI: DMO.owl Autori: Enea (Agenzia nazionale per le nuove tecnologie) Linguaggio: OWL Full Versione: finale Num. 282 Num. Object 36 Classi: Property: Num. 47 Num. Data Property: 23 Individui: Espressività in DL: ALCOIF(D) 33 Pag. 58 di 104

59 OntoMODA-ML [43] è un ontologia di dominio modulare multi-livello orientata alla modellazione dei dati ed allo scambio delle informazioni di e- business. 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. Pag. 59 di 104

60 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. Pag. 60 di 104

61 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 Costruzione dell ontologia BusinessObject 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: 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. Pag. 61 di 104

62 Organizzazione dei concetti in una gerarchia Namespace E stato definito per l ontologia il seguente namespace: 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. Pag. 62 di 104

63 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 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 Pag. 63 di 104

64 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 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. Pag. 64 di 104

65 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 Attribute Description Questa classe identifica un generico oggetto del dominio di business. Questa classe identifica gli attributi, ossia le entità atomiche. In particolare distinguiamo tra: SimpleAttribute: è un attributo semplice, come lo può essere un nome, una descrizione o gli attributi qualitativi o quantitativi. Identifier: è l attributo che permette di distinguere Pag. 65 di 104

66 Class Concept 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. 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 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. Pag. 66 di 104

67 Class EnterpriseConcept CustomerAndSales Concept Product Concept VendorAndPurchaising Concept Generic Contept Description Enterprise Concept raggruppa tutti i concetti tipici della gestione vendite/prodotti di un impresa. Essa estende la generica Business Obejct. I concetti sono raggruppate in 3 macroaree: CLIENTI-VENDITE, PRODOTTI, FORNITORI-ACQUISTI E la classe che raggruppa tutti i concetti relativi al processo di vendita ai clienti. E la classe che raggruppa tutti i concetti relativi ai prodotti e alla loro produzione. E la classe che raggruppa tutti i concetti relativi al processo di acquisto dai fornitori. E la classe che raggruppa i concetti più generici. Tabella 19 Business Object estesa per il mondo Enterprise. Descrizione delle classi 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). Pag. 67 di 104

68 Class AddressType CountryRegion Currency CurrencyRate Employee EmployeeAddress EnterpriseDepartment ShipMethod StateProvince UnitMeasure Description Types of addresses. For example, billing, home, or shipping. Restrizioni hasid Exactly 1 AddressTypeID ISO standard codes for countries and regions. Restrizioni hascurrency some Currency hasid Exactly 1 CountryRegionCode Standard ISO currencies. Restrizioni hasid Exactly 1 CurrencyCode Currency exchange rates. Restrizioni hasfromcurrency Exactly 1 Currency hastocurrency Exactly 1 Currency hasid Exactly 1 CurrencyRateID Employee information such as salary, department, and title. Restrizioni: hasemployeeaddress Some EmployeeAddress hasid Exactly 1 EmployeeID hasenterprisedepartment Max 1 EnterpriseDepartment hasmanager Max 1 Employee Street address information for employees. Restrizioni hasaddresstype Exactly 1 AddressType hasstateprovince Exactly 1 StateProvince hasid Exactly 1 EmployeeAddressID Departments of Enterprise. Restrizioni hasid Exactly 1 EnterpriseDepartmentID Shipping methods. Restrizioni hasid Exactly 1 ShipMethodID States and provinces. Restrizioni hascountryregion Exactly 1 CountryRegion hassalesterritory Exactly 1 SalesTerritory hasid Exactly 1 StateProvinceID Unit of measure. Restrizioni hasid Exactly 1 UnitMeasureCode Tabella 20 Business Object (Generic Concept). Descrizione delle sotto classi. Pag. 68 di 104

69 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) Nella Tabella 21 riportiamo i commenti e le eventuali restrizioni definiti per ciascuna classe illustrata in Figura 26 (i commenti sono in inglese, la lingua scelta per descrivere i concetti ontologici e formulare le interrogazioni nel progetto SWOP). Class Customer CustomerAddress CustomerCreditCard CustomerStore Description Current Customer individual information. Restrizioni hasid exactly 1 CustomerID hassimpleattribute exactly 1 CustomerType hascustomeraddress Some CustomerAddress hascustomercreditcard Some CustomerCreditCard hassalesterritory Max 1 SalesTerritory Street address information for customers. Restrizioni hasid exactly 1 CustomerAddressID hasaddresstype exactly 1 AddressType hasstateprovince exactly 1 StateProvince Customer credit card information. Restrizioni hasid exactly 1 CustomerCreditCartID Stores of our Company (customer and resellers). Restrizioni hasid exactly 1 CustomerStoreID Pag. 69 di 104

70 Class SalesOrder SalesOrderDetail SalesReason SalesRepresentative Person SalesShopping CartItem SalesSpecialOffer SalesTaxRate SalesTerritory Description hassalerepresentativeperson Max 1 SalesRepresentativePerson isownedby exactly 1 Customer General sales order information (header) Restrizioni hasid exactly 1 SalesOrderID hasbilltocustomeraddress exactly 1 CustomerAddress hasshiptocustomeraddress exactly 1 CustomerAddress hascurrencyrate exactly 1 CurrencyRate hascustomercreditcard Max 1 CustomerCreditCard hascustomer exactly 1 Customer hassalesorderdetail some SalesOrderDetail hassimpleattribute exactly 1 SalesOrderStatus hassalesreason some SalesReason hassalerepresentativeperson Max 1 SalesRepresentativePerson hassalesterritory Max 1 SalesTerritory hasshipmethod exactly 1 ShipMethod Product details associated with a specific sales order. Restrizioni hasproduct exactly 1 Product hasid exactly 1 SalesOrderDetailID hassalesspecialoffer exactly 1 SalesSpecialOffer Reasons why a customer may purchase a particular product. Restrizioni hasid exactly 1 SalesReasonID Contains current sales information for the sales representative persons. Restrizioni hasid exactly 1 SalesRepresentativePersonID hassalesterritory exactly 1 SalesTerritory isanemployee exactly 1 Employee Contains shopping cart items until the order is submitted or cancelled. Restrizioni hasid exactly 1 SalesShoppingCartItemID hasproduct exactly 1 Product Special Offer (discounts) Restrizioni hasid exactly 1 SalesSpecialOfferID Sales Tax rate. Restrizioni hasid exactly 1 SalesTaxRateID hasstateprovince some StateProvince Sales territory. Restrizioni Pag. 70 di 104

71 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) Nella Tabella 22 riportiamo i commenti e le eventuali restrizioni definiti per ciascuna classe illustrata in Figura 27 (i commenti sono in inglese, la lingua scelta per descrivere i concetti ontologici e formulare le interrogazioni nel progetto SWOP). Product Class Description Products sold or used in the manfacturing of sold products. Restrizioni hasid Exactly 1 ProductID hasproductdocument Some ProductDocument hasproductmodel Exactly 1 ProductModel hasproductphoto Some ProductPhoto hasproductsubcategory Exactly 1 ProductSubCategory Pag. 71 di 104

72 Class ProductSupplied ByVendor ProductBillOfMaterials ProductCategory ProductCostHistory ProductDocument ProductInventory ProductListPriceHistory ProductLocation Description hassizeunitmeasure Exactly 1 UnitMeasure hasweighrunitmeasure Exactly 1 UnitMeasure hasproductcosthistory some ProductCostHistory hasproductlistpricehistory Some ProductListPriceHistory Cross-reference class mapping vendors with the products they supply. Restrizioni hasvendor exactly 1 Vendor hasunitmeasure exactly 1 UnitMeasure hassimpleattribute exactly 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 hasid Exactly 1 ProducBillOfMaterialsID hasproductassembly Exactly 1 Product hascomponent Exactly 1 Product hasunitmeasure Exactly 1 UnitMeasure High-level product categorization. Restrizioni hasid Exactly 1 ProductCategoryID Changes in the cost of a product over time. Restrizioni hassimpleattribute Exactly 1 ProductCostHistoryStartDate hassimpleattribute Exactly 1 ProductCostHistoryEndtDate hassimpleattribute Exactly 1 ProductCostHistoryStandardCost Product maintenance documents. Restrizioni hasid Exactly 1 ProductDocumentID Product inventory information. Restrizioni hasproduct Exactly 1 Product hasproductlocation Exactly 1 ProductLocation hassimpleattribute Exactly 1 ProductInventoryBin hassimpleattribute Exactly 1 ProductInventoryQuantity hassimpleattribute Exactly 1 ProductInventoryShelf Changes in the list price of a product over time. Restrizioni hassimpleattribute Exactly 1 ProductListPriceHistoryStartDate hassimpleattribute Exactly 1 ProductListPriceHistoryEndDate hassimpleattribute Exactly 1 ProductListPriceHistoryPrice Product manufacturing locations Pag. 72 di 104

73 Class ProductModel ProductPhoto ProductReview ProductSubCategory WorkOrder WorkOrderRouting Description Restrizioni hasid Exactly 1 Product model classification Restrizioni hasid Exactly 1 Product photo Restrizioni hasid Exactly 1 Customer reviews of products they have purchased. Restrizioni hasid Exactly 1 hasproduct Exactly 1 Product subcategories. Restrizioni hasid Exactly 1 hasproductcategory Exactly 1 Manufacturing work orders. Restrizioni hasid Exactly 1 hasproduct Exactly 1 hassimpleattribute Exactly 1 hasproductworkorderrouting Some ProductLocationID ProductModelID ProductPhotoID ProductReviewID Product ProductSubCategoryID ProductCategory ProductWorkOrderID Product ProductWorkOrderQty ProductWorkOrderRouting Work order routing details. This includes the sequence of work centers the product travels through in the manufacturing or assembly process. Restrizioni hassimpleattribute Exactly 1 hasproduct Exactly 1 hasproductlocation Exactly 1 ProductWorkOrderRouting OperationSequence Product 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. Pag. 73 di 104

74 Figura 28 Business Object (Vendor and Purchaising Concept) Nella Tabella 23 riportiamo i commenti e le eventuali restrizioni definiti per ciascuna classe illustrata in Figura 28 (i commenti sono in inglese, la lingua scelta per descrivere i concetti ontologici e formulare le interrogazioni nel progetto SWOP). Class PurchaseOrder PurchaseOrderDetail Vendor VendorAddress Description General purchase order information (header). Restrizioni hasid exactly 1 PurchaseOrderID haspurchaseorderdetail some PurchaseOrderDetail hasshipmethod exactly 1 ShipMethod hasvendor exactly 1 Vendor hasproductssupplied some ProductSuppliedByVendor ByVendor hasemployee exactly 1 Employee Products details associated with a specific purchase order. Restrizioni hasid exactly 1 PurchaseOrderDetailID hasproduct exactly 1 Product Details about vendors, such as the vendor name and account number. Restrizioni hasid exactly 1 VendorID VendorAddress some VendorAddress Street address information for vendors. Restrizioni hasid Exactly 1 VendorAddressID hasaddresstype Exactly 1 AddressType hasstateprovince Exactly 1 StateProvince Tabella 23 Business Object (VendorAndPurchaising Concept)-Descrizione delle classi 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. Pag. 74 di 104

75 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. Pag. 75 di 104

76 Figura 31 - Business Object (CustomerAttribute) In Figura 32 sono riportate le sotto classi di tipo ProductAttribute. Pag. 76 di 104

77 Figura 32 - Business Object (ProductAttribute) In Figura 33 sono riportate le sotto classi di tipo GenericConceptAttribute. Pag. 77 di 104

78 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. Pag. 78 di 104

79 Figura 35 - Business Object (SalesAttribute) In Figura 36 sono riportate le sotto classi di tipo VendorAttribute. Figura 36 - Business Object (VendorAttribute) Le Object Property della Business Object Ontology In Figura 37 e Figura 38 sono riportate tutte le object property definite nell ontologia Business Object. Pag. 79 di 104

80 Figura 37 - Business Object (Object Property 1/2) Figura 38 - Business Object (Object Property 2/2) Pag. 80 di 104

81 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 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: SalesOrderStatus {"1"^^integer, "2"^^integer, "3"^^integer, Range: "4"^^integer, "5"^^integer, "6"^^integer} Indica i possibili valori che può assumere lo stato di un ordine. Attualmente il suo uso è limitato a verificare le capacità espressive dell ontologia. Pag. 81 di 104

82 2.4.5 Le ontologie per modellare i servizi 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. _ 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 ). Pag. 82 di 104

83 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: 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. Pag. 83 di 104

84 Figura 40 Commercial Categories Ontology Business Process Ontology Dominio e Scopo dell ontologia 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): Pag. 84 di 104

85 Service Service Method Business Process Sales GetIndividualCustomers SearchCustomerInformation Sales GetIndividualCustomerAdressData SearchCustomerInformation Sales GetStoreCustomers SearchCustomerStores Sales GetStoreContactsByStore SearchCustomerStores Sales GetSalesByStore SearchCustomerSales Sales GetStoreByLocation SearchCustomerStores Product GetProductDescriptionsByFilter SearchProductDescription Product GetProductDescriptionsByProductModel SearchProductDescription Purchasing GetVendorsByLocation SearchVendorInformation Purchasing GetProductsSuppliedByVendors SearchVendorProducts Purchasing GetVendorContactsByVendor SearchVendorInformation Purchasing GetPurchasesByVendor SearchVendorPurchases Manufacturing GetMultiLevelBillOfMaterialsListForProduct SearchProductBillOfMaterials Manufacturing GetWorkOrdersByInventory SearchProductWorkOrders Manufacturing GetWorkOrdersByProduct SearchProductWorkOrders 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 Definiamo per l ontologia il seguente namespace: Le classi top-level L ontologia BusinessProcess contiene due classi top-level (Figura 41): Figura 41 Business Process (top-level) Pag. 85 di 104

86 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 BusinessProcess 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: 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. Pag. 86 di 104

87 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 Services Ontology Namespace Definiamo per l ontologia il seguente namespace: Pag. 87 di 104

88 Dominio e Scopo dell ontologia 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. Pag. 88 di 104

89 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à potrebbe essere rimossa. Pag. 89 di 104

90 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à potrebbe essere rimossa. 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à potrebbe essere rimossa. Definizione delle Data Property Sono state definite le seguenti data-property relative alla classe Service: hasservicename Pag. 90 di 104

91 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à potrebbe essere rimossa. hasoperation Domain: WSDLOperationRef Pag. 91 di 104

92 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à potrebbe essere rimossa. 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à potrebbe essere rimossa. 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: ServiceGrounding Pag. 92 di 104

93 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 Service ServiceGrounding ServiceParameter WSDLMessage Descrizione Identifica un web service, che soddisfa uno specifico task o insieme di tasks. Ogni istanza supporta una descrizione ServiceGrounding. Restrizioni hasservicename Exactly 1 Literal hasservicedescription some Literal hasserviceproviderinformation Max 1 Literal 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 non ambigua di scambiare dati di quel tipo con il servizio. Questa classe potrebbe essere rimossa. Restrizioni isassociatedtoaservice Exactly 1 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. 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 haswsdlmessagepart Some Literal WSDLMessageMap WSDLMessageMAPInput: mappa gli input ad una specifica grounding Restrizioni hasserviceinputparameter Some ServiceParameter WSDLMessageMAPOutput: mappa gli output ad una specifica grounding Restrizioni hasserviceoutputparameter Some ServiceParameter Pag. 93 di 104

94 Classe WSDLMessagePart WSDLOperationRef Descrizione Un WSDLMessagePartInput referenzia 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. L unicità è data dalla coppia (porttype, operation). Questa classe potrebbe essere rimossa. Restrizioni hasoperation Exactly 1 Literal hasporttype Exactly 1 Literal Tabella 26 SWOP - Services Ontology Descrizione delle classi 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: Questa ontologia importa quelle di più basso livello, relative ai seguenti concetti: Business Object; Business Process e Business Task; Commercial Category; Pag. 94 di 104

95 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 Pag. 95 di 104