L'approccio ontologico dei linguaggi di modellazione

Partiamo da questa definizione di Ontologia:

Lo studio delle categorie di una certa entità che esiste o che potrebbe esistere in un determinato dominio, viene chiamato ontologia, ovvero “un catalogo dei tipi di una entità di cui viene assunta la sua esistenza in un dominio D in prospettiva del suo accesso da parte di un attore che utilizzi un linguaggio L per accedere o comunicare con D”. A seguito di questa affermazione l’ontologia è sinonimo di comunicazione. Essa, infatti, permette di definire il significato dei concetti che fanno parte di un determinato dominio, stabilisce le relazioni intercorrenti tra i termini stessi, definisce quindi la semantica che costituisce l’”humus” del sistema e la garanzia della persistenza delle informazioni trattate. In particolare permette la formalizzazione di un modello di mondo (o parte di esso)  che include concetti e relazioni aggregate in gruppi di attori semplici (subiscono il sistema) e/o attori esperti (gestiscono il sistema). Quindi possiamo dire che lo scopo di una definizione ontologica è la formalizzaizone di una certa entità che in un dato momento esiste all'interno di un dominio applicativo. Questa formalizzazione del modello non ha in effetti un modus operandis operativo, cioè la sua modellazione non ha degli step prefissati.

E' comunque prassi rapportarla alla formalizzazione di una base di dati, cioè partendo dal problema in forma letterale, in linguaggio naturale per intenderci, si procede scegliendo l'approccio migliore alla modellazione del sistema e quindi si focalizza sul problema della definizione di entità e relazioni tra di esse. Queste entità diventeranno tabelle del sistema con propri attributi e quindi tipi di dato, indici e vincoli..... Questo post vuole essere una riflessione e non un tutorial sulle basi di dati, quindi riprendendo il discorso abbiamo bisogno di un linguaggio che ci permetta di formalizzare l'ontologia.

I linguaggi utilizzati sono quelli che derivano dallo logica predicativa  del 1° ordine, e sono:

• Ontolingua
• RDF(S)
• OWL (DAML+OIL)

Perchè questi linguaggi sono adatti e gli altri no?

La domanda non dovrebbe essere proprio questa ma la risposta sicuramente non è facile ed intuitiva. Non si tratta purtroppo della discriminazione del mondo letterale verso i linguaggi utilizzati per specifici domini applicativi ma penso sia una necessità di leicitare, secondo un uso comune, una piccola famiglia di linguaggi formali in grado di soddisfare i vincoli di relazione sopra citati.

Vi chiederete adesso.... ma UML può essere considerato un lingaggio per modellare Ontologie?

Partiamo dalla definizione di questo linguaggio:

The OMG specification states:

"The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system.
The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components."

The important point to note here is that UML is a 'language' for specifying and not a method or procedure. The UML is used to define a software system; to detail the artifacts in the system, to document and construct - it is the language that the blueprint is written in. The UML may be used in a variety of ways to support a software development methodology (such as the Rational Unified Process) - but in itself it does not specify that methodology or process.

UML defines the notation and semantics for the following domains:

-	The User Interaction or Use Case Model - describes the boundary and interaction between the system and users. Corresponds in some respects to a requirements model.
-	The Interaction or Communication Model - describes how objects in the system will interact with each other to get work done.
-	The State or Dynamic Model - State charts describe the states or conditions that classes assume over time. Activity graphs describe the workflow's the system will implement.
-	The Logical or Class Model - describes the classes and objects that will make up the system.
-	The Physical Component Model - describes the software (and sometimes hardware components) that make up the system.
-	The Physical Deployment Model - describes the physical architecture and the deployment of components on that hardware architecture.

Da questo possiamo dire che UML UML è un linguaggio di modellazione visuale per analizzare, specificare, visualizzare e documentare lo sviluppo di sistemi software Object-Oriented. In poche parole è un ``linguaggio per la creazione di modelli software ad oggetti'', ossia un linguaggio universale per la progettazione di sistemi Object-Oriented.
Però ci sono realtà in cui questo linguaggio di modellazione è stato arrichito con dei template per modellare "ontologie", un esmepio su tutti è PASSI.

The PASSI Lifecycle

Abbiamo visto attarverso questa descrizione dei passi logici, che questo tool descrive ambienti MAS e da la possibilità di modellare solo l'aspetto relazionale di una ontologia per una certa entità verso le classi del sistema.

Mi riprometto di approfondire il discorso, ma resto dell'idea che un linguaggio semi-formale difficilmente potrà mai descrivere un modello firmale di realtà. :-( Lo stesso post è visibile qui per i più "tecnici"

The models and phases of PASSI are:

System Requirements Model. An anthropomorphic model of the system requirements in terms of agency and purpose. Developing this model involves four steps:

• Domain Description (D.D.): A functional description of the system using conventional use-case diagrams.

• Agent Identification (A.Id.): Separation of responsibility concerns into agents, represented as stereotyped UML packages.

• Role Identification (R.Id.): Use of sequence diagrams to explore each agent’s responsibilities through role-specific scenarios.

• Task Specification (T.Sp.): Specification through activity diagrams of the capabilities of each agent.

Agent Society Model. A model of the social interactions and dependencies among the agents involved in the solution. Developing this model involves three steps in addition to part of the previous model:

• Role Identification (R.Id.). See the System Requirements Model.

• Ontology Description (O.D.). Use of class diagrams and OCL constraints to describe the knowledge ascribed to individual agents and the pragmatics of their interactions.

• Role Description (R.D.). Use of class diagrams to show distinct roles played by agents, the tasks involved that the roles involve, communication capabilities and inter-agent dependencies.

• Protocol Description (P.D.). Use of sequence diagrams to specify the grammar of each pragmatic communication protocol in terms of speech-act performatives.

Agent Implementation Model. A model of the solution architecture in terms of classes and methods, the development of which involves the following steps:

• Agent Structure Definition (A.S.D.). Use of conventional class diagrams to describe the structure of solution agent classes.

• Agent Behavior Description (A.B.D.). Use of activity diagrams or statecharts to describe the behavior of individual agents.

Code Model. A model of the solution at the code level requiring the following steps to produce:

• Code Reuse Library (C.R.). A library of class and activity diagrams with associated reusable code.

• Code Completion Baseline (C.C.). Source code of the target system.

Deployment Model. A model of the distribution of the parts of the system across hardware processing units, and their migration between processing units. It involves one step:

• Deployment Configuration (D.C.). Use of deployment diagrams to describe the allocation of agents to the available processing units and any constraints on migration and mobility.