1

R. TURCO
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

IP cluster sw

KBFE KBFE

Cluster sw BEA

Viene deployato su WebLogic con una

architettura affidabile e scalabile (cluster
sw BEA).
14
 KBFE STACK SW E PRODOTTI
SOAP-UI
WSDL SOA

Twinkle Log4J KBFE Protegè 4.1

2.0

Jena 2.6.4 Pellet

2.2.2
Cache script query
SPARQL
SPRQL-DL OWL
Cache
Ontologies

Non necessario un Database

15
 WEBSERVICES (HTTP/SOAP)

ontologia

Individual
webservice

output

In input arrivano 2 par:

• il nome dell’ontologia di interesse (corrispondente)
• Il nome dell’individual chiave

Fornisce un output, TXT o XML.

16
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.

Usiamo il Framework KBFE!

24
KNOWLEDGE BASE NotB1
TipoNotifica
Classi:
 SistemaSottoscrittore
 TipoNotifica
 NotificaBilling èSottoscrittoANotifica
 NotificaDelivery

SistemaSottoscrittore ATOM

NBS Notifica
Delivery
NotificaBilling

25
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
• Possibile configurare una Test Suite per testare in modo massivo ogni
ontologia e ottenere subito i risultati di ogni test

31
 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.

KBFE mercato
Deploy a caldo SI NO
Engine one-way SI NO
Sviluppo SI SI-NO
concettuale
Nessun DB SI Richiede DB
Semplicità SI SI-NO
sviluppo
Semplicità SI NO
supporto
Prestazioni buone buone
Traffico Rete minimo Minimo

Restituisce regole SI NO, le applica

34
CONFRONTIAMOLO CON ALTRI PRODOTTI
KBFE mercato
Conoscenza SI SI
tecnologia
Open e Open SI NO
Source
Licenze Solo WLS SI
Impatti Modifiche Nessuna, ogni NO il rilascio è
Sui Test rilascio è dipendente
indipendente
Usa prodotti noti SI (WLS) NO anche altro
Dipendenza del evitare su NO
Charset Protegè caratteri
accentati per
garantire UTF-8
Partizionamento e SI Tramite EAR
memoria minore
35
 FUNCTION POINT

INPUT OUTPUT
KBFE
ILF

Input : gli eventi (notifiche)

ILF : ontologia/WSDL
Output : Info restituite (script)

36
 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