Post on 01-Jul-2015
transcript
R. TURCO 1
NUOVE METODOLOGIE
La Knowledge Base e le Ontologie possono rappresentare una efficace
metodologia di progettazione , che può sfruttare facili componenti
ontologici da implementare oppure implementati e disponibili come
palette sugli editor (esempio su Eclipse).
Disporre di strumenti di tal genere consente una facile progettazione,
soprattutto concettuale, rendendo lo sviluppo light e con pochi errori e
anomalie
E’ una metodologia da vedersi collocata nell’ambito della progettazione a
componenti e dei framework.
2
ONTOLOGIE E KNOWLEDGE BASE Definizione
Quella più pratica è che una ontologia permette di classificare/raggruppare oggetti di
un dominio ed ottenere inferenze su essi, attraverso un «reasoner» (un engine di
inferenza)
Una Ontologia è costituita da:
Classi
Individuals (Istanze di Classi, la valorizzazione della Classe)
Object Property (relazioni binarie tra Individui)
Data Property (relazioni binarie tra Individuo e dato)
Una definizione pratica di Knowledge Base, è, invece, quella che la indica come un
insieme di ontologie; dietro ci sono i concetti del filosofo Russel e degli assiomi della
Matematica, gli insiemi di insiemi etc, ricordate Peano etc?
Anche il DB relazionale è un concetto matematico. La Knowledge base punta agli stessi
concetti del Prolog e del RDF: Soggetto, Predicato ed Oggetto.
3
ONTOLOGIE
Non sono esclusiva del Semantic Web 2.0.
Sono un paradigma di programmazione potente quanto l’Object Oriented e
permette la realizzazione di componenti e framework intelligenti, palette
sotto Eclipse per componenti Ontologici.
Sono già diffuse ed esistono molti strumenti tecnologici standard e stabili:
RDF, OWL2 , SPARQL-DL, protocollo SPARQL su http/https SOAP etc
Permettono ad esempio creazione di:
dynamic registry (fornire la lista degli IP di un web service, di abitanti di un
palazzo, di dipendenti di una unità di azienda, mappe geografiche etc)
rules engine o mapper dinamici (fornire la lista di regole di business a fronte di
un evento o di mapping XSLT),
Information Retrieval: Dati/Image/Video/Voce (accoppiabile anche a Lucene)
Crawler per Social Network (per FOAF etc)
Servizi domotici per creare una interfaccia sw che mette d’accordo vari
dispositivi su rete
Regole ontologiche per fare deduzioni (SWRL con Jena e plug-in) nell’ambito di
applicazioni
4
ONTOLOGIE
5
ONTOLOGIE
6
ONTOLOGIE
7
KNOWLEDGE BASE VS DATA BASE
Quand’è che la Knowledge base è superiore ad un Data base?
Se si fa leva sulla generalizzazione e si riesce con uno stesso «engine» a
trattare una stessa «Classe di Problemi». Una Knowledge Base è in
grado di trattare N ontologie, indipendentemente da nomi di schema
DB, tabelle, colonne e indipendentemente dalla lunghezza delle
colonne, riuscendo a interrogarle simultaneamente, anche
condividendone i dati.
Le Ontologie inoltre sono utili a creare metadati e annotations anche
collaborative.
8
CLASSE DI PROBLEMI - ENGINE ONE WAY
Spesso in un’azienda ciò che serve al cliente è progettabile con una sola astrazione concettuale.
In molte aziende, piccole o grandi, indipendentemente dal processo di management, spesso serve una sola cosa:
«Dato un argomento e una informazione chiave, determinare una lista di informazioni correlate anche non omogenee, di qualsiasi tipo (voce, video, e-mail, immagine, fax, numero di telefono etc) e dove ha importanza la relazione».
Questa classe di problemi se si progettano correttamente le ontologie sono trattabili con un solo engine di Knowledge Base.
La lista delle persone che abitano nel palazzo e che sono dipendenti che lavorano a via Depretis e che sono abbonati a Sky e al Napoli calcio sono ricerche su almeno 4 ontologie incrociate da un solo engine.
9
PARTIZIONAMENTO DI UNA ONTOLOGIA
Una ontologia può essere realizzata anche con m file, ognuno dei quali costituisce una partizione, ordinata secondo la informazione chiave di ricerca o più informazioni, rendendo possibile a monte dell’engine di Information Retrieval, una pre-ricerca B-tree, sui nomi dei file, con un algoritmo che dipende dal logaritmo.
Ad esempio un elenco pagine bianche ordina per tipo di lavoro e per ordine alfabetico del cognome
Il partizionamento di un’ontologia è un fenomeno concettuale, ed è un errore demandarlo al partizionamento fisico del software ovvero a suddivisioni di engine successivi: basta un solo engine con pre-ricerca dei file (un index sostanzialmente) ed un partizionamento della ontologia.
E’ un aspetto importante quando occorre lavorare con grandi numeri; rispetto a più engine c’è risparmio di memoria.
Si possono realizzare Regole di Partizionamento (con altre ontologie ed uso di SWRL SweetRules)
10
RULES ENGINE
Un rules engine di business è un framework ontologico, ad esempio, che
lavora su una ontologia definita come «Sistemi sottoscritti a notifiche»,
«Notifiche», «Regole di applicazione». Il problema che affrontano è:
«Un sistema BPM o un ESB, fornita la notifica vuole sapere la lista dei
sistemi interessati alle notifiche e le regole, per ogni sistema
interessato, per inoltrare o meno la notifica al sistema sottoscritto»
Un rules engine in generale è un framework anche con regole ontologiche
per dedurre una serie di fatti e restituire l’azione da compiere.
11
FRAMEWORK KBFE
KBFE è un piccolo framework Java, un engine di «knowledge base» che
si poggia su tecnologie note e stabili:
Jena 2.6.4,
Pellet 2.2.2 (reasoner),
SPARQL,
Log4J
Twickle (editor SPARQL) 2-0,
Protegè 4.1 per la modellazione della Ontologia in RDF/OWL2/XML, WSDL
SOA
Scritto con Oracle Workspace Studio e gira su BEA WebLogic 10.3.x,
Sfrutta lo standard RDF/OWL/XML del www.w3.org
KBFE è un componente, si può rendere jar o paletta di Eclipse
12
ORACLE WORKSPACE STUDIO
13
ARCHITETTURA KBFE
14
Cluster sw BEA
KBFE KBFE
IP cluster sw
Viene deployato su WebLogic con una
architettura affidabile e scalabile (cluster
sw BEA).
KBFE STACK SW E PRODOTTI
15
KBFE
SPRQL-DL
Jena 2.6.4 Pellet
2.2.2
OWL
Cache script query
SPARQL
Cache
Ontologies
Twinkle
2.0 Protegè 4.1
WSDL SOA
Non necessario un Database
Log4J
SOAP-UI
WEBSERVICES (HTTP/SOAP)
16
webservice
ontologia
Individual
output
In input arrivano 2 par:
• il nome dell’ontologia di interesse (corrispondente)
• Il nome dell’individual chiave
Fornisce un output, TXT o XML.
CONFIGURAZIONE
E’ semplice
• Per il logging con Log4J.properties (sotto il dominio BEA)
• Per molti parametri con KBFE.properties (sotto il dominio BEA)
• Per l’ontologia (sotto il dominio BEA)
• Per gli script SPARQL (sotto il dominio BEA in directory dbquery)
17
PROTEGÈ – CLASSI E ISTANZE
18
PROTEGÈ – OBJECT PROPERTY, DOMAIN E
RANGE
19
PROTEGÈ – REASONER E DL QUERY
20
PROTEGÈ
Con Protegè si progetta in OWL2 il modello ontologico:
Classi
Object Property
Data Property
Individuals
Col reasoner (Fact++) si può:
verificare la consistenza tra la Asserted Class Gerarchy e la Inferred Class
Gerarchy
verificare il modello con il DL-query TAB
Si salva l’ontologia, come OWL di tipo RDF/XML; l’ontologia è il motore di
ragionamento e inferenza per KBFE, la base di conoscenza (Knowledge Base).
Un reasoner può dedurre cose non esplicitate: l’ontologia può auto-imparare!
21
TWINKLE
22
TWINKLE
Con Twinkle si può:
Progettare le query SPARQL
Testare le query SPARQL
Salvare gli script SPARQL per la cache
23
ESEMPIO RULES ENGINE
Si vuole che un ESB a fronte di un evento di notifica chieda al Rules Engine
quali sono i sistemi sottoscritti a tale notifica.
24
Usiamo il Framework KBFE!
KNOWLEDGE BASE
Classi:
SistemaSottoscrittore
TipoNotifica
NotificaBilling
NotificaDelivery
25
SistemaSottoscrittore ATOM
NBS
TipoNotifica
NotificaBilling
Notifica
Delivery
NotB1
èSottoscrittoANotifica
RDF/OWL
26
SPARQL-DL
Cercare i sistemi sottoscritti alla notifica NotDel1
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX table: <http://www.semanticweb.org/UniversityOntologies/2011/2/23/Ontology1300891609561.owl#>
SELECT ?x
FROM <file:/C:/Users/37509490/Desktop/OWL/Rules/Notifiche.owl>
WHERE
{
?x table:èSottoscrittoANotifica table:NotDel2
}
27
SPARQL-DL
28
SPARQL-DL
Cercare tutti i sistemi sottoscritti alle notifiche
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX table: <http://www.semanticweb.org/UniversityOntologies/2011/2/23/Ontology1300891609561.owl#>
SELECT ?x ?y
FROM <file:/C:/Users/37509490/Desktop/OWL/Rules/Notifiche.owl>
WHERE
{
?x table:èSottoscrittoANotifica ?y
}
29
SPARQL-DL
30
SOAPUI 3.6.1 - TEST MASSIVO
31
• Possibile configurare una Test Suite per testare in modo massivo ogni
ontologia e ottenere subito i risultati di ogni test
VANTAGGI 1 Sviluppo solo concettuale con minori anomalie:
Protegè per il modello delle Ontologie necessarie
Twinkle per la progettazione degli script SPARQL-DL
Deploy a caldo di:
modello ontologico e script
Engine identico per la stessa «classe di problemi» ontologici
• cambia solo l’Ontologia e gli script
Prestazioni:
• tipiche di http/SOAP
32
VANTAGGI 2
• Può restituire REGOLE usando i dataProperty
• Possibilità di aggiungere nuovi engine per altre «classi di
problemi» (è raro)
• Manutenzione ridotta allo sviluppo concettuale e al test
• Non esclude utilizzo di DB
• Cache su files e non SPARQL su https con traffico di rete
• Lascia aperta, in caso di emergenza (rarissimo) a soluzioni di
Workflow con Workshop e di utilizzo di un DB. Ma Il DB NON è
necessario, si usano le cache su filesystem.
• Uso di RDF/XML porta ad avere script SPARQL più simili al SQL
• Maggiore facilità di sviluppo e di comprensione del sistema.
33
CONFRONTIAMOLO CON ALTRI PRODOTTI
Per avere un termine di paragone serio e importante di valutazione per
KBFE si può confrontare con prodotti di mercato.
34
KBFE mercato
Deploy a caldo SI NO
Engine one-way SI NO
Sviluppo
concettuale
SI SI-NO
Nessun DB SI Richiede DB
Semplicità
sviluppo
SI SI-NO
Semplicità
supporto
SI NO
Prestazioni buone buone
Traffico Rete minimo Minimo
Restituisce regole SI NO, le applica
CONFRONTIAMOLO CON ALTRI PRODOTTI
35
KBFE mercato
Conoscenza
tecnologia
SI SI
Open e Open
Source
SI NO
Licenze Solo WLS SI
Impatti Modifiche
Sui Test
Nessuna, ogni
rilascio è
indipendente
NO il rilascio è
dipendente
Usa prodotti noti SI (WLS) NO anche altro
Dipendenza del
Charset
evitare su
Protegè caratteri
accentati per
garantire UTF-8
NO
Partizionamento e
memoria minore
SI Tramite EAR
FUNCTION POINT
36
KBFE
INPUT
Input : gli eventi (notifiche)
ILF : ontologia/WSDL
Output : Info restituite (script)
ILF
OUTPUT
PASSIAMO AI FATTI …
Una DEMO è meglio delle chiacchiere e del fumo …
Cosa c’è dietro la nuvola? Vediamo …
37
CASE STUDY
1 - Aggiungiamo una notifica
2 - Aggiungiamo un sistema
3 - Lavoriamo con più ontologie e lo stesso engine
38
CONCLUSIONI
Che ne pensate ora?
39