WSMO Restricted
Upcoming SlideShare
Loading in...5
×
 

WSMO Restricted

on

  • 1,001 views

Riassunto e traduzione della reference ufficiale del framework WSMO per la descrizione di Web Service e la definizione di ontologie.

Riassunto e traduzione della reference ufficiale del framework WSMO per la descrizione di Web Service e la definizione di ontologie.

Statistics

Views

Total Views
1,001
Views on SlideShare
998
Embed Views
3

Actions

Likes
0
Downloads
12
Comments
0

3 Embeds 3

file:// 1
http://www.linkedin.com 1
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

WSMO Restricted WSMO Restricted Document Transcript

  • WSMO // Restricted ! Liberamente estratto e sintetizzato da Web Service Modeling Ontology (http://www.wsmo.org/TR/d2/v1.3/) Il linguaggio per definire Web Service Modeling Ontology (WSMO) I livelli del meta-modello per la definizioni di WSMO WSMO è un meta-modello per aspetti collegati ai Web Service Semantici ed è specificato usando il Meta-Object Facility (MOF). Il MOF definisce un linguaggio astratto e un framework per la specificazione, la costruzione ed il mantenimento di meta-modelli indipendenti dalla tecnologia. Sono definiti quattro livelli: • Information layer comprende i dati da descrivere • Model layer comprende i meta-dati che descrivono i dati nel infomation layer • Meta-model layer comprende le descrizioni che definiscono la struttura e la semantica dei metadati. • Meta-meta-model layer comprende le descrizioni che definiscono la struttura e la semantica dei meta-metadati. In questa classificazione, il linguaggio per definire WSMO è il livello meta-meta-model, WSMO in sé è il livello meta-model, ontologie, Web Service, Goal e mediator costituiscono il livello Model mentre i dati di un'ontologia o quelli scambiati tra web service costituiscono il livello information. Una nota sulla terminologia: un web service è un'entità computazionale capace tramite invocazione di soddisfare i goal degli utenti mentre il servizio è il valore attuale fornito da questa invocazione. Identificatori URI: Sono l'opzione di default. Possono essere completi oppure qualified name(QName) che sono risolti usando le dichiarazioni di namespace. ID Anonimi: Un id anonimo può essere numerato (#_1,#_2) oppure non numerato (#_). Ad esempio, se qualcuno vuole dire che una persona John ha un indirizzo _ # che a sua volta ha un nome della via quot;hitchhikerstreetquot; e un numero civico quot;42quot;, quindi l'oggetto indirizzo di per sé non ha bisogno di un particolare URI, ma dal momento che deve esistere come un oggetto di collegamento tra John e quot;hitchhikersstreetquot; e quot;42quot; si può indicare con un id anonimo. Valori e tipi di dato In WSMO, i literal sono utilizzati per identificare i valori come numeri per mezzo di una rappresentazione lessicale. Literal possono essere semplici o tipizzati (vengono tipizzati tramite i tipi di dati XML). Formalmente un tipo è definito da 3 elementi: • un insieme non vuoto i stringhe chiamato spazio lessicale. E.G.{quot;truequot;, quot;1quot;, quot;falsequot;, quot;0quot;} • un insieme non vuoto chiamato spazio dei valori. E.G. {true, false} • una mappatura dello spazio lessicale sullo spazio dei valori. E.G.{quot;truequot;, quot;1quot;}->{true}; {quot;falsequot;, quot;0quot;}->{false}. Annotazioni Le annotazioni sono usate nella definizione di elementi WSMO; nella lista seguente troviamo un insieme di annotazioni che possono essere applicate a qualsiasi tipo elemento. Class annotation hasContributor type dc:contributor hasCoverage type dc:coverage hasCreator type dc:creator hasDate type dc:date hasDescription type dc:description hasFormat type dc:format hasIdentifier type dc:identifier
  • hasLanguage type dc:language hasOwner type owner hasPublisher type dc:publisher hasRelation type dc:relation hasRights type dc:rights hasSource type dc:source hasSubject type dc:subject hasTitle type dc:title hasType type dc:type hasVersion type version Contributor: un'entità che ha dato un contributo al contenuto dell'elemento. Esempi di dc:contributor sono persone, organizzazioni o anche web service. Coverage: l'estensione o la portata del contenuto dell'elemento. Tipicamente dc:coverage include locazioni spaziali, periodi temporali o giurisdizioni. Creator: un'entità primaria responsabile della creazione del contenuto dell'elemento. Esempio di dc:creator sono persone,organizzazioni o anche web service. Date: la data di un evento associato al ciclo di vita dell'elemento (generalmente si tratta della creazione) Description: un descrizione del contenuto dell'elemento. Esempi di dc:description sono una indice astratto dei contenuti, descrizioni in testo libero oppure riferimenti a rappresentazioni grafiche. Format: una manifestazione, fisica o digitale, dell'elemento. Tipicamente dc:format include il media-type e le dimensioni di un elemento. Format è usato per identificare il software, l'hardware o altro equipaggiamento necessario per operare con l'elemento. Identifier: Un riferimento non ambiguo all'elemento in un dato contesto. E' buona pratica identificare l'elemento per mezzo di una stringa o di un numero conformandosi però ad sistemi di identificazione formale(ad esempio URI). Language: la lingua usata per il contenuto intellettuale dell'elemento. Owner: la persona o l'organizzazione a cui appartiene un particolare elemento WSMO. Publisher: un'entità che rende disponibile l'elemento. Reference: un riferimento ad un elemento collegato. E' buona pratica identificare l'elemento per mezzo di una stringa o di un numero conformandosi però ad sistemi di identificazione formale(ad esempio URI). Rights: informazioni sui diritti collegati all'elemento. Tipicamente dc:rights una dichiarazione di gestione dei diritto oppure in riferimento ad un web service che fornisce tale informazioni. Esempio di diritto sono il Copyright o l'Intellectual Property Righs(IPR). Se non viene specificato nessun diritto non si possono fare assunzioni su quale siano effettivamente i diritti collegati all'elemento. Source: un riferimento ad un elemento da cui il presente è derivato. E' buona pratica identificare l'elemento per mezzo di una stringa o di un numero conformandosi però ad sistemi di identificazione formale(ad esempio URI). Subject: un argomento del contenuto dell'elemento. Generalmente dc:subject sono parole chiave, frasi chiave o codici di classificazione per gli argomenti. Si raccomanda di usare valori presi da un vocabolario controllato o da uno schema di classificazione formale. Title: un nome dato a questo elemento. Il dc:title è il nome con il quale l'elemento è formalmente conosciuto. Type: La natura o il genere del contenuto dell'elemento. Version: visto che molte proprietà dell'elemento possono cambiare nel tempo, si rende necessario un identificatore dell'elemento in un certo periodo di tempo. Elementi WSMO di alto livello WSMO si riferisce ai concetti che definisce come “elementi”. Il listato seguente mostra la definizione generale di un qualsiasi elemento WSMO; questa definizione viene poi raffinata da ogni singolo elemento.
  • Class wsmoElement hasAnnotation type annotation Ogni elemento WSMO ha un insieme di annotazioni associate. WSMO identifica quattro elementi di altro livello come i concetti principali che devono essere specificati per descrivere un Web Service semantico. Le Ontologie forniscono la terminologia usata dagli altri elementi WSMO per descrivere aspetti rilevanti del dominio del discorso. I Web Service descrivono l'entità computazionale che fornisce l'accesso ad un servizio che fornisce un qualche valore nel dominio. Questa descrizione comprende le capacità, le interfacce e il funzionamento interno del Web Service. I Goal rappresentano i desideri degli utenti che possono essere soddisfatti con l'esecuzione di un Web Service. Il modello dei Goal rappresenta la visione dell'utente all'interno del processo d'uso di Web Service. I Mediator descrivono gli elementi che superano i problemi di interoperabilità tra diversi elementi WSMO. I mediator sono il concetto chiave per risolvere le incompatibilità sui dati, sui processi o sui protocolli. Ontologie Un'ontologia è una specifica esplicita e formale di una concettualizzazione condivisa: l'ontologia quindi definisce una terminologia condivisa fornendo dei concetti e relazioni tra i concetti. Al fine di descrivere le proprietà semantiche delle relazioni e dei concetti, un ontologia fornisce generalmente un'insieme di assiomi (che sono espressioni in qualche linguaggio logico). Class ontology sub-Class wsmoElement importsOntology type ontology usesMediator type ooMediator hasConcept type concept hasRelation type relation hasFunction type function hasInstance type instance hasRelationInstance type relationInstance hasAxiom type axiom Importazione di Ontologie L'importazione di ontologie ci permette di utilizzare la modularità per superare le difficoltà collegate alla definizione di ontologie complesse. Un'ontologia può essere usata solo nei casi in cui non ci sono conflitti altrimenti si deve usare un ooMediator. Usare i Mediator Nel caso in cui sia necessario l'allineamento di ontologie importate è di gran lunga preferibile usare un ooMediator. Il mediator saranno descritti meglio in seguito. Concetti Da una prospettiva di alto livello un concetto( descritte da una definizione di concetto) è provvisto di attributo (ognuno con nome e tipo) e può essere un sotto-concetto di alcuni (possibilmente nessuno) super-concetti. Class concept sub-Class wsmoElement hasSuperConcept type concept hasAttribute type attribute hasDefinition type logicalExpression multiplicity = single-valued Supercontept: vi è un numero finito di concetti che possono servire come super-concetti di un
  • determinato concetto. Essere il sotto-concetto di un un altro concetto significa ereditare la signature e i vincoli del super-concetto e inoltre ogni istanza del sotto-concetto è anche un'istanza del super- concetto. Attribute: ogni concetto fornisce un insieme di attributi che rappresentano degli slot (forniti di nome) per i dati delle istanze: tali slot saranno riempiti a livello di istanza. Class attribute sub-Class wsmoElement hasRange type concept multiplicity = single-valued Ad un attributo viene associato, tramite un Range, un vincolo logico sui possibili valori che possono essere contenuti in questo slot dati. Definition: la definizione è un'espressione logica che può essere usata per descrivere formalmente la semantica del concetto; più precisamente, l'espressione logica definisce (oppure restringe) l'estensione del concetto(ad esempio l'insieme delle istanze). Se C è l'identificatore di un concetto allora l'espressione logica può prendere una delle seguenti forme: forAll ?x ( ?x memberOf C implies l-expr(?x)) • forAll ?x ( ?x memberOf C impliedBy l-expr(?x)) • forAll ?x ( ?x memberOf C equivalent l-expr(?x)) • dove l-expr(?x) è un'espressione logica con una sola variabile ?x libera. Il primo esempio esprime una condizione necessaria per l'appartenenza all'estensione del concetto, il secondo esprime una condizione sufficiente mentre la terza espressione indica che c'è una condizione necessari e sufficiente affinché un oggetto sia un elemento dell'estensione del concetto. Relazioni Le relazioni sono usate per modellare l'interdipendenza tra alcuni concetti (e quindi anche tra le sue istanze). Class relation sub-Class wsmoElement hasSuperRelation type relation hasParameter type parameter hasDefinition type logicalExpression multiplicity = single-valued Superrelation: Un insieme finito di relazioni delle quale la relazione può essere considerata una sotto-relazione. Essere la sotto-relazione significa ereditare la signature e i vincoli della super- relazione e inoltre l'insieme delle tuple che appartengono alla relazione (cioè l'estensione della relazione) deve essere un sottoinsieme di ognuna delle estensioni delle super-relazioni. Parameter: La lista dei parametri. Class parameter sub-Class wsmoElement hasDomain type concept multiplicity = single-valued Il domain è il concetto che vincola i possibili valori che il parametro può avere. Definition: Un espressione logica che definisce un insieme di istanze (una tupla di n elementi) della relazione. Se i parametri sono specificati, la relazione è rappresentata da un simbolo di predicato n- ario con argomenti nominati e l'identificatore della relazione è usato come nome del simbolo del predicato. Se R è l'identificatore di una relazione e i parametri sono specificati allora le espressioni logiche possono avere queste forme: • forAll ?v1,...,?vn ( R[p1 hasValue ?v1,...,pn hasValue ?vn] implies l-expr(?v1,...,?vn) ) • forAll ?v1,...,?vn ( R[p1 hasValue ?v1,...,pn hasValue ?vn] impliedBy l-expr(?v1,...,? vn) ) • forAll ?v1,...,?vn ( R[p1 hasValue ?v1,...,pn hasValue ?vn] equivalent l-expr(?v1,...,?vn) ) Se i parametri non sono specificati la relazione è rappresentata come un simbolo di predicato dove l'identificatore della relazione è il nome del simbolo di predicato. Se R è l'identificatore di una
  • relazione e i parametri non sono specificati allora le espressioni logiche che si possono avere sono: • forAll ?v1,...,?vn ( R(?v1,...,?vn) implies l-expr(?v1,...,?vn) ) • forAll ?v1,...,?vn ( R(?v1,...,?vn) impliedBy l-expr(?v1,...,?vn) ) • forAll ?v1,...,?vn ( R(?v1,...,?vn) equivalent l-expr(?v1,...,?vn) ) Il simbolo l-expr(?v1,...,?vn) indica un'espressione logica con ?v1,...,?vn come variabili libere e p1,...,pn sono i nomi dei parametri della relazione. Funzioni Una funzione è un tipo speciale di relazione che ha un range unario e un dominio n-ario dove i valori del range è funzionalmente dipendenti dai valori del dominio. Il seguente vincolo deve essere soddisfatto (F è il nome della funzione). forAll ?x1,...,?xn,?r1,?r2 (false impliedBy F(?x1,...,?xn,?r1) and F(?x1,...,?xn,?r2) and ?r1 != ?r2) A differenza del simbolo di funzione, una funzione non è solo una entità sintattica ma ha una semantica definita che permette di valutare effettivamente la funzione se vengono passati dei valori di input concreti per i parametri. Class function sub-Class relation hasRange type concept multiplicity = single-valued Il range di una funzione è un concetto che vincola i possibili valori di ritorno. La rappresentazione logica di una funzione è praticamente identica a quella delle relazioni tranne che il valore del risultato della funzione ( il valore del termine della funzione) deve essere rappresentato esplicitamente. La funzione è quindi un simbolo di predicato (n+1)-ario dove n è il numero degli argomenti della funzione; se i parametri non sono specificati si adotta la convenzione che il primo argomento del simbolo di predicato rappresenti il termine della funzione. Se F è l'identificatore di un funzione la rappresentazione logica della funzione avrà una forma simile a questa: forAll ?v1,...,?vn,?range ( F[p1 hasValue ?v1,...,pn hasValue ?vn, range hasValue ?range] equivalent l-expr(?v1,...,?vn,?range) ) Istanze Le istanze possono essere definite esplicitamente oppure attraverso un link ad un “instance store”. Class instance sub-Class wsmoElement hasType type concept hasAttributeValues type attributeValue Type: il concetto di cui è istanza la presente istanza. Attribute Value: il valore di un singolo attributo definito nel concetto. Class attributeValue sub-Class wsmoElement hasAttribute type attribute multiplicity = single-valued hasValue type {instance, literal, anonymousId} Attribute è l'attributo a cui questo valore fa riferimento mentre value può essere un istanza, un literal o un ID anonimo che rappresenta il valore attuale dell'istanza di uno specifico attributo. Istanze di Relazioni Le istanze di relazioni possono essere viste come tuple a n valori di istanze dei concetti specificati come parametri della relazione. Class relationInstance sub-Class wsmoElement hasType type relation hasParameterValue type parameterValue Type: la relazione a cui appartiene questa istanza.
  • ParameterValue: un insieme di valori dei parametri che specificano le singole istanze che sono collegate in accordo con l'istanza di relazione. Class parameterValue sub-Class wsmoElement hasParameter type parameter multiplicity = single-valued hasValue type {instance, literal, anonymousId} multiplicity = single-valued Parameter indica il parametro a cui si fa riferimento mentre value può essere un'istanza, un liteal o un ID anonimo rappresentante il valore attuale di un'istanza per uno specifico parametro. Assiomi Un assioma è un'espressione logica accompagnata da un'annotazione. Class axiom sub-Class wsmoElement hasDefinition type logicalExpression Definition: la dichiarazione effettiva catturata dall'assioma è definita da una formula in un linguaggio logico. Descrizioni di Web Service Le descrizioni WSMO di Web Service comprendono aspetti funzionali, non funzionali e comportamentali del Web Service. Un Web Service è un'entità computazionale che è capace tramite invocazione di raggiungere un traguardo (goal) definito dall'utente. Un servizio, invece, è il valore attuale fornito da tale invocazione. Un Web Service deve anche fornire un insieme di servizi differenti. Class webService sub-Class wsmoElement importsOntology type ontology usesMediator type {ooMediator, wwMediator} hasNonFunctionalProperties type nonFunctionalProperty hasCapability type capability multiplicity = single-valued hasInterface type interface Importing Ontology: usato per importare ontologie fino a quando non si generano conflitti. Using Mediator: un Web Service può importare ontologie usando un mediatore di ontologie (ooMediator) quando servono allineamenti o trasformazioni delle ontologie. Un Web Service può usare un wwMediator per la mediazione di protocolli e processi. Proprietà non funzionali Esempi di proprietà non funzionali sono il costo, la precisione, QoS della rete, performance etc. A differenza delle semplici annotazioni le proprietà non funzionali non sono rappresentate solo come una coppia chiave-valore ma possono essere espresse usando delle espressioni logiche. Class nonFunctionalProperty sub-Class wsmoElement hasDefinition type logicalExpression Definition: l'espressione logica che specifica le informazioni non funzionali. WSMO non impone nessuna restrizione sulla codifica delle informazioni in espressioni logiche. Si raccomanda di usare delle terminologie standard dove è possibile per facilitare l'interoperabilità. WSMO raccomanda: accuracy, financial, networkRelatedQoS, performance, reliability, robustness, scalability, security, transactional, trust. Capacità Una capacità descrive un Web Service attraverso le sue funzionalità. Class capability sub-Class wsmoElement importsOntology type ontology
  • usesMediator type {ooMediator, wgMediator} hasNonFunctionalProperties type nonFunctionalProperty hasSharedVariables type sharedVariables hasPrecondition type axiom hasAssumption type axiom hasPostcondition type axiom hasEffect type axiom Importing Ontology: usato per importare ontologie fino a quando non si generano conflitti. Using Mediator: un Web Service può importare ontologie usando un mediatore di ontologie (ooMediator) quando servono allineamenti o trasformazioni delle ontologie. Può essere collegato ad un goal tramite un wgMediator. Non-funcional Properties: un insieme di proprietà non funzionali strettamente collegate alla capacità. Shared Variables: rappresentano le variabili condivise dalle precondizioni, postcondizioni, assunzioni ed effetti. Precondition: le precondizioni specificano lo spazio delle informazioni del Web Service prima della sua esecuzione Assumption: le assunzioni descrivono lo stato del mondo prima dell'esecuzione del Web Service Postcondition: le postcondizioni specificano lo spazio delle informazioni del Web Service dopo la sua esecuzione. Effect: gli effetti descrivono lo stato del mondo dopo l'esecuzione del Web Service. Interfacce Un interfaccia descrive come la funzionalità di un Web Service può essere ottenuta fornendo due punti di vista sulle competenze operazionali del Web Service: • la coreografia decompone una capacità in termini di interazioni con il Web Service • l'orchestrazione decompone una capacità in termini di funzionalità richieste da altri Web Service Questa distinzione riflette la distinzione tra comunicazione e cooperazione. La coreografia definisce il modo per comunicare con il web service al fine di “consumare” una sua funzionalità. L'orchestrazione definisce come una funzionalità complessiva può essere ottenuta tramite la cooperazione tra più Web Service elementari. Class interface sub-Class wsmoElement importsOntology type ontology usesMediator type ooMediator hasNonFunctionalProperties type nonFunctionalProperty hasChoreography type choreography hasOrchestration type orchestration Importing Ontology: usato per importare ontologie fino a quando non si generano conflitti. Using Mediator: un Web Service può importare ontologie usando un mediatore di ontologie (ooMediator) quando servono allineamenti o trasformazioni delle ontologie. Non-functional Properties: un insieme di proprietà strettamente collegate all'interfaccia. Choreography: fornisce le informazioni necessarie, dal punto di vista del cliente, per permettere la comunicazione con il servizio. Orchestration: descrive come il servizio fa uso di altri servizi al fine di realizzare la sua capacità. Goal I goal sono rappresentazioni di obiettivi il cui soddisfacimento è visto attraverso l'esecuzione di un Web Service. Un goal può essere la descrizione di un Web Service che potrebbe potenzialmente soddisfare i desideri dell'utente.
  • Class goal sub-Class wsmoElement importsOntology type ontology usesMediator type {ooMediator, ggMediator} hasNonFunctionalProperties type nonFunctionalProperty requestsCapability type capability multiplicity = single-valued requestsInterface type interface Importing Ontology: usato per importare ontologie fino a quando non si generano conflitti. Using Mediator: un Web Service può importare ontologie usando un mediatore di ontologie (ooMediator) quando servono allineamenti o trasformazioni delle ontologie. Un goal può essere definito a partire da uno o più goal preesistenti e per ottenere questo effetto si usano i ggMediator. Non-functional Properties: un insieme di funzionalità strettamente collegate al goal. Capabilty: le capacità che il Web Service voluto dall'utente dovrebbe avere. Interface: le interfacce che il Web Service voluto dall'utente dovrebbe avere e con cui l'utente vorrebbe interagire. Mediator Si distinguono 4 tipi di Mediator: • ggMediator: mediator tra due goal. Questo collegamento rappresenta il raffinamento del goal sorgente nel goal finale oppure uno stato di equivalenza se i due goal sono sostituibili. • ooMediator: mediator che importa ontologie e risolvono possibili conflitti tra le ontologie. • wgMediator: mediator che collega un web service ad un goal indicando che il Web Service raggiunge completamente o parzialmente gli obiettivi descritti dal goal. • wwMediator: mediator tra due Web Service. Class mediator sub-Class wsmoElement importsOntology type ontology hasNonFunctionalProperties type nonFunctionalProperty hasSource type {ontology, goal, webService, mediator} hasTarget type {ontology, goal, webService, mediator} hasMediationService type {goal, webService, wwMediator} Class ooMediator sub-Class mediator hasSource type {ontology, ooMediator} Class ggMediator sub-Class mediator usesMediator type ooMediator hasSource type {goal, ggMediator} hasTarget type {goal, ggMediator} Class wgMediator sub-Class mediator usesMediator type ooMediator hasSource type {webService, goal, wgMediator, ggMediator} hasTarget type {webService, goal, ggMediator, wgMediator} Class wwMediator sub-Class mediator usesMediator type ooMediator hasSource type {webService, wwMediator} hasTarget type {webService, wwMediator} Importing Ontology: usato per importare ontologie fino a quando non si generano conflitti. Non-functional Properties: un insieme di proprietà appartenenti al mediator. Source: definisce le entità che sono le sorgenti del mediator. Target: definisce l'entità che rappresenta l'obiettivo del mediator.
  • Mediation Service: punta ad un goal che descrive in maniera dichiarativa la mappatura di mediazione oppure ad un web Service che implementa effettivamente la mappatura oppure ad un wwMediator che si collega un Web service che implementa effettivamente la mappatura. Using Mediator: alcuni tipi specifici di mediator usano un insieme di ooMediator per mappare tra di loro i vocabolari differenti usati nella descrizione di goal o di Web Service. Un wgModel può avere due funzioni distinte: 1. un goal è collegato ad un web service attraverso la coreografia della sua interfaccia indicando che il web service soddisfa il goal indicato. 2. Un web service è collegato ad un goal attraverso l'orchestrazione della sua interfaccia indicando che il web service ha bisogno che questo goal sia soddisfatto per riuscire a compiere la funzionalità descritta. Vi sono due modi per usare i mediator per collegare due entità WSMO: la prima prevede che le entità indicano un mediator per gestire la relazione mentre la seconda prevede che le entità siano indicate direttamente all'interno del mediator. Il Linguaggio Logico per la definizione di Dichiarazioni Formali in WSMO Identificatori di variabili Oltre agli identificatori (URI o anonimi) e ai valori le espressioni in WSMO possono contenere delle variabili. I nomi delle variabili iniziano con il carattere punto interrogativo '?' seguito da un numero positivo di simboli dell'insieme {a-z, A-Z, 0-9,_ , -}. Ad esempio ?var o ?lastValue_Of. Vocabolario di Base e Termini Il vocabolario V del nostro Linguaggio L(V) è composto da i seguenti simboli: • un insieme possibilmente infinito di Uniform Resource Identifier URI • un insieme possibilmente infinito di ID anonimi AnID • un insieme possibilmente infinito di literal Lit • un insieme possibilmente infinito di variabili Var • un insieme possibilmente infinito di simboli di funzione FSym sottoinsieme di URI • un insieme possibilmente infinito di simboli di predicato PSym sottoinsieme di URI • un insieme possibilmente infinito di simboli di predicato con argomenti forniti di nome PSymNamed sottoinsieme di URI • un insieme finito di simboli ausiliari AuxSym che include (, ), ofType, ofTypeSet, memberOf, subConceptOf, hasValue, hasValues, false, true. Un insieme finito di connettori logici e quantificatori che include or, and, not, • implies,impliedBy, equivalent , forAll, exists. Tutti gli insiemi sono mutuamente distinti a meno che non sia specificato altrimenti. Per ogni simbolo S in FSym, PSym o PSymNamed, si assume che sia definita una corrispondente arity arity(S), che è un numero intero non negativo, specificante il numero di argomenti che ci si aspetta dal corrispondente simbolo quando si costruiscono delle espressioni nel nostro linguaggio. Per ogni simbolo S in PSymNamed si assume che sia definito un corrispondente insieme dei nomi dei parametri parName(S) che contiene i nomi dei parametri che devono essere usati quando si costruiscono delle espressioni nel nostro linguaggio. I simboli di funzione con arity pari a zero sono detti costanti. Dato un vocabolario V, definiamo insieme dei termini sul vocabolario V l'insieme Term(V) composto da: • identificatori u in URI • ID anonimi i in AnID • literal l in Lit • variabili v in Var • f(t1,...,tn) dove f appartiene a Fsym e ha arity pari a n e t1,...,tn appartengono a Term(V) Definiamo GroundTerm(V) l'insieme dei termini di Term(V) che non contengono variabili. I Termini sono usati per descrivere computazioni ma anche oggetti in un universo e per questo
  • forniscono dei nomi a delle entità in certi domini. Espressioni Logiche Un'espressione logica semplice in L(V) o formula atomica è induttivamente definita come segue: • Se p è un simbolo di predicato in PSym con arity(p)=n e t1,...,tn sono termini allora p(t1,...,tn) è un'espressione logica semplice in L(V) • Se r è un simbolo di predicato in PSymNamed con arity(r)=n, parNames(r)={p1,...,pn} e t1,...,tn sono termini allora r[p1 hasValue t1,...,pn hasValue tn] è un'espressione logica semplice in L(V) • true e false sono espressioni logiche semplici in L(V) • Se P, ATT, T sono termini allora P[ATT ofType T] è un'espressione logica semplice in L(V) • Se P,ATT, T1,...,Tn (con n>=1) sono termini allora P[ATT ofTypeSet (T1,...,Tn)] è un'espressione logica semplice in L(V) • Se O, T sono termini allora O memberOf T è un'espressione logica semplice in L(V) • Se C1,C2 sono termini allora C1 subConceptOf C2 è un'espressione logica semplice in L(V) • Se R1, R2 sono simboli di predicato in PSym o PSymNamed con la stessa signature allora R1 subRelationOf R2 è un'espressione logica semplice in L(V) • Se O, V, T sono termini allora O[V hasValue T] è un'espressione logica semplice in L(V) • Se O, V, T1,..., Tn (con n>=1) sono termini allora O[V hasValues (T1,...,Tn)] è un'espressione logica semplice in L(V) • Se T1, T2 sono termini allora T1=T2 è un'espressione logica semplice in L(V) L'espressione C[ATT ofType T] definisce un vincolo sui possibili valori che un'istanza della classe C può avere per la proprietà ATT restringendoli hai soli valori di tipo T. O memberOf T è vero se e solo se O è un'istanza di tipo T O[ATT hasValue T] è vera se l'elemento indicato con O ha la proprità ATT con valore T. T1=T2 è vera se T1 e T2 denotano lo stesso elemento all'interno dell'universo. Si estende la definizione precedente per ottenere una definizione induttiva di un'espressione logica complessa in L(V): • Ogni espressione logica semplice è un'espressione logica in L(V). • Se L è un'espressione logica in L(V) allora anche not L è un'espressione logica in L(V). • Se L1 ed L2 sono espressioni logiche in L(V) e op è un connettore logico contenuto nell'insieme {or, and, implies, impliedBy, equivalent} allora L1 op L2 è un'espressione logica in L(V). • Se L è un'espressione logica in L(V), x è una variabile contenuta in Var e Q è un quantificatore contenuto nell'insieme {forAll, exists}, allora Qx(L) è un'espressione logica in L(V). Le notazioni or, and, implies, impliedBy, equivalent corrispondono alla disgiunzione, congiunzione, implicazione, implicazione inversa ed equivalenza.