# Presentation: 946413

## MDA® & ODM Overview

- Elisa Kendall
- Sandpiper Software
- January 28, 2005

## Level of Expressivity

**Reflects the nature of the knowledge representation formalism**
**Term lists****, Acronym lists**
**Glossaries, ****Controlled Vocabularies**** (terms and definitions)**
**Simple, Hierarchical Taxonomies**** (may or may not include attributes)**
**Relational Database Schema**** – defines terms through classes (implemented as rows), attributes (implemented as columns), and a restricted set of relations (foreign keys)**
**Object-Oriented Software Model**** – includes a broad set of binary relations, may specify constraints, behavior, choreography on ****classes or objects**
**Knowledge ****Representation System**** ****– supports n-ary relations, ****highly expressive constraints, ****rules, axioms, choreography**

## Context: MDA® – KR Perspective

**EII solutions rely on strict adherence to agreements based on common information models that take weeks or months to build  **
**Modifications to the interchange agreements are costly and time consuming **
**Today, the analysis and reasoning required to align multiple parties’ information models has to be done by people  **
**Machines display only *****syntactic***** information models and informal text describing the semantics of the models  **
**Without formal *****semantics*****, machines cannot aid the alignment process  **
**Translations from each party’s syntactic format to the agreed-upon common format have to be hand-coded by programmers**
**MOF® and MDA® provide the basis for automating the syntactic transformations ...**

## MOF and KR Together

**MOF technology streamlines the *****mechanics***** of managing models as XML documents, Java objects, CORBA objects**
**Knowledge Representation supports *****reasoning***** about resources**
**Supports semantic alignment among differing vocabularies and nomenclatures**
**Enables consistency checking and model validation, business rule analysis **
**Allows us to ask questions over multiple resources that we could not answer previously**
**Enables policy-driven applications to leverage existing knowledge and policies to solve business problems**
**Detect inconsistent financial transactions**
**Support business policy enforcement**
**Facilitate next generation network management and security applications**
**	****while integrating with existing RDBMS and OLAP data stores**
**MOF provides no help with reasoning**
**KR is not focused on the mechanics of managing models or metadata**
**Complementary technologies – despite some overlap**

## Metadata Management Scenarios

## Cost of Knowledge Capture

**Most tools are oriented towards taxonomy or limited ontology formation vs. knowledge base development, terminology reconciliation, or alignment**
**They require significant knowledge of formal logic and domain analysis from an ontological perspective**
**Few are graphical and/or standards based**
**Vulcan estimates the cost of encoding 50 pages of basic high school chemistry textbook knowledge at $10,000 per page*******
**Tools to assist subject matter experts (SMEs) in encoding knowledge, including increasing automation in developing the starting points for ontology and KB development are essential**
**Combining MOF****®**** and MDA****® technologies with KR dramatically reduces cost, increases likelihood of success, increases availability to a much broader community of potential users**

- * See Vulcan, Inc. – Project Halo, at http://www.projecthalo.com/

## ODM RFP Overview

**Notes:**
        A standard MOF2 compliant metamodel for Ontology Definition (ODM)  
        A UML2 Profile to support reuse of UML notation for ontology definition
        A mapping from the Ontology Definition Metamodel to the profile, and 
        A language mapping for the ODM to the W3C Web Ontology Language for Description Logics, OWL DL.

## Classifying Ontologies

**Classification techniques are as diverse**
**as conceptual models; and generally**
** ****include understanding**
**Methodology**
**Target Usage**
**Level of Expressivity**
**Level of Complexity**
**Reliability / Level of Authoritativeness**
**Relevance**
**Amount of Automation**
**Metrics Captured and/or Available**

## Model Dynamics

**Model Dynamics**

** From Usage Scenarios and Goals for ODM Presentation*
*       **-- Lewis Hart, AT&T Government Solutions, February 2004*

- Model centric perspectives characterize the ontologies themselves and are concerned with their structure, formalism and dynamics.

**Perspective**
**Level of****Authoritativeness**
**Source of Structure**
**Degree of  Formality**
**Model Dynamics**
**Instance Dynamics**

***One Extreme***
**Least authoritative, broader shallowly defined ontologies**
**Passive (Transcendent) - Structure originates outside the system**
**Informal or primarily taxonomic**
**Read-only, ontologies are static **
**Read-only, resource instances are static**

***Other Extreme***
**Most authoritative, narrower, more deeply defined ontologies**
**Active(Immanent) - Structure emerges from data or behavior**
**Formal, having rigorously defined types, relations, and theories or axioms**
**Volatile, ontologies are fluid and changing**
**Volatile, resource instances change continuously**

## Application Characteristics

** From Usage Scenarios and Goals for ODM Presentation*
*       **-- Lewis Hart, AT&T Government Solutions, February 2004*

- Application centric perspectives are concerned with how applications use and manipulate ontologies.

**Perspective**
**Control/Degree ****of Manageability**
**Application****Changeability**
**Coupling**
**Integration Focus**
**Lifecycle Usage**

***One Extreme***
**Externally focused, public****(little or no control)**
**Static (with periodic updates)**
**Loosely-coupled**
**Information integration**
**Design Time**

***Other Extreme***
**Internally focused, private****(full control)**
**Dynamic**
**Tightly-coupled**
**Application integration**
**Run Time**

## Environment Characteristics

**Distributed** **– highly decentralized, distributed systems and information asset environment on multiple levels: international, regional, local vs. centralized**
**Heterogeneity** **– many distinct systems with independent and sometimes conflicting requirements for integration vs. homogeneous environments**
**Autonomy**** – organizational requirements differ by locale, organizational structure, time constraints, external pressures**
**Organic**** – highly interdependent processes across organizations, systems, functions**
**Cross-Enterprise**** – potentially a multi-company operation where configuration may be managed at varying levels of detail across organizational boundaries depending on client/partner requirements **

## Ontologies have well-defined, formal semantics:
To support reasoning
To represent shared semantics for intelligent agents or semantic web services
To represent declarative policies (with legal implications, such as regulatory policies)
Elements frequently cross meta-levels or apply at multiple levels (e.g., act as a class and as an individual at the same time)
Reuse of complex relationships and axioms is critical to successful development:
Relations are first class elements
Associations in UML2 are insufficient to meet this need
Individuals may be specified independently and may have properties that are not properties of the classes of which they are members (e.g., owl:sameAs, owl:differentFrom)

**To support reasoning**
**To represent shared semantics for intelligent agents or semantic web services**
**To represent declarative policies (with legal implications, such as regulatory policies)**
**Elements frequently cross meta-levels or apply at multiple levels (*****e.g*****., act as a class and as an individual at the same time)**
**Reuse of complex relationships and axioms is critical to successful development:**
**Relations are first class elements**
**Associations in UML2 are insufficient to meet this need**
**Individuals may be specified independently and may have properties that are not properties of the classes of which they are members (*****e.g.,***** owl:sameAs, owl:differentFrom)**

**Knowledge Representation vs. UML**

## Forward & reverse engineering of source material and ontologies
Support ontologies expressed in existing description logics (e.g., OWL DL) and a limited set of higher order languages (e.g., OWL Full, SCL)
UML Profiles vs. Metamodels
Both are required due to structural and semantic distinctions between KR languages and UML
Metamodels precisely represent the abstract syntax
Profiles facilitate use of UML notation and “code” generation
Extending the UML2 metamodel vs. new, distinct metamodels
Extension would introduce unnecessary complexity
Mismatches in underlying semantics
Limit unnecessary dependencies
Should there be a core ODM metamodel that the others extend?
No obvious commonalities
Goal was to be true to the abstract syntax and formal semantics of the selected KR languages – without unnecessary complexity

**Support ontologies expressed in existing description logics (*****e.g*****., OWL DL) *****and***** a limited set of higher order languages (*****e.g*****., OWL Full, SCL)**
**UML Profiles vs. Metamodels**
**Both are required due to structural and semantic distinctions between KR languages and UML**
**Metamodels precisely represent the abstract syntax**
**Profiles facilitate use of UML notation and “code” generation**
**Extending the UML2 metamodel vs. new, distinct metamodels**
**Extension would introduce unnecessary complexity**
**Mismatches in underlying semantics**
**Limit unnecessary dependencies**
**Should there be a core ODM metamodel that the others extend?**
**No obvious commonalities**
**Goal was to be true to the abstract syntax and formal semantics of the selected KR languages – without unnecessary complexity**

**Design Rationale**

## Impedance Mismatches     and Issues

**Subclassing vs. Mapping**
**OWL metamodel depends on the RDFS metamodel**
**OWL DL metamodel with further constrain OWL Full**
**All others are related through mapping**
**Naming**
**Namespaces are defined at the package level in UML and MOF**
**Namespaces are global in RDFS/OWL, SCL, and TM**
**Associations**
**Relations and Properties are “first class entities” in  RDFS/OWL and SCL**
**AssociationEnds must be defined in UML **
**Inheritance of features, attributes, or slots, as well as axioms and other relevant production rules ***on associations*** is poorly supported in UML2, not at all previously**
**OCL is insufficiently rich to support rules, axioms**

## Six EMOF platform independent metamodels, (PIMs), five normative
Mappings (currently tables, QVT planned)
UML2 Profiles
RDFS
OWL
TM 
Generated collateral
Proof of concepts
Java APIs 
Conformance
RDFS & OWL
All else optional

**Mappings (currently tables, QVT planned)**
**UML2 Profiles**
**RDFS**
**OWL**
**TM **
**Generated collateral**
**Proof of concepts**
**Java APIs **
**Conformance**
**RDFS & OWL**
**All else optional**

**Overview of the ODM**

## Metamodel reflects the abstract syntax of the Resource Description Framework (RDF) and RDF Schema (W3C Recommendations)
Design Considerations
Namespaces and Naming Conventions
Lack of Distinction between meta-levels
Classes and Properties as first class citizens in RDF (with globally unique identifiers)
Need for a scoping mechanism
No way to separate RDF from RDF Schema at the abstract syntax level
Key Features
Classes
Properties
Containers and Collections (Lists)

**Design Considerations**
**Namespaces and Naming Conventions**
**Lack of Distinction between meta-levels**
**Classes and Properties as first class citizens in RDF (with globally unique identifiers)**
**Need for a scoping mechanism**
**No way to separate RDF from RDF Schema at the abstract syntax level**
**Key Features**
**Classes**
**Properties**
**Containers and Collections (Lists)**

**RDFS Metamodel**

## RDFS Classes

**RDFS Classes**

## Metamodel reflects the abstract syntax of the Web Ontology Language (for both OWL Full and OWL DL, W3C Recommendation)
Design Considerations
Namespaces and Naming Conventions
Lack of Distinction between meta-levels
Classes and Properties as first class citizens in OWL (with globally unique identifiers)
Need for a scoping mechanism
Three sublanguages, two of which share common abstract syntax, distinct semantics (OWL DL is more constrained)
Key Features
Classes and Restrictions
Properties
Individuals

**Design Considerations**
**Namespaces and Naming Conventions**
**Lack of Distinction between meta-levels**
**Classes and Properties as first class citizens in OWL (with globally unique identifiers)**
**Need for a scoping mechanism**
**Three sublanguages, two of which share common abstract syntax, distinct semantics (OWL DL is more constrained)**
**Key Features**
**Classes and Restrictions**
**Properties**
**Individuals**

**OWL Metamodel**

## OWL Classes

## OWL Restrictions

## OWL Properties

## OWL Individuals

**OWL Individuals**

## Metamodel reflects the abstract syntax of Simple Common Logic (ISO draft standard 24707)*
Design Considerations
Namespaces and Naming Conventions
Lack of Distinction between meta-levels
All Terms are first class citizens in SCL (classes, relations,  functions, individuals)
Need to develop strategy for use of SCL constraints with OWL ontologies in the context of UML tools and applications
Key Features
Terms and Atoms (atomic sentences)
Sequence variables (finite list representation)
Boolean and Quantified Sentences
Built-in scope and annotation mechanisms

* Name may be simplified to Common Logic, in keeping with the ISO standard

**Design Considerations**
**Namespaces and Naming Conventions**
**Lack of Distinction between meta-levels**
**All Terms are first class citizens in SCL (classes, relations,  functions, individuals)**
**Need to develop strategy for use of SCL constraints with OWL ontologies in the context of UML tools and applications**
**Key Features**
**Terms and Atoms (atomic sentences)**
**Sequence variables (finite list representation)**
**Boolean and Quantified Sentences**
**Built-in scope and annotation mechanisms**
*** Name may be simplified to Common Logic, in keeping with the ISO standard**

**SCL Metamodel**

## SCL Atoms

**SCL Atoms**

## SCL Quantified Sentences

## SCL Boolean Sentences

**SCL Boolean Sentences**

## Metamodel derived from the CWM ER extension example and major ER modeling tools
Design Considerations
Entities and Relationships as first-class citizens in ER
Value-based identities and references
N-ary relationships
Relationships with attributes
Key Features
Entities
Relationships
Keys
Instances

**Design Considerations**
**Entities and Relationships as first-class citizens in ER**
**Value-based identities and references**
**N-ary relationships**
**Relationships with attributes**
**Key Features**
**Entities**
**Relationships**
**Keys**
**Instances**

**ER Metamodel**

## ER Model

## ER Relationships

## ER Keys

## Metamodel reflects the abstract syntax of the Topic Map Data Model (ISO draft standard ISO 13250-2)
Design Considerations
Parallels the TMDM non-normative UML representation.
Identifier verses Subject Locators verses Source Locators
Everything is a subject, including Topic Map Constructs
Classes handled as Published Subjects
Key Features
Topics about Subjects
N-ary Associations
Scoping
Identity

**Design Considerations**
**Parallels the TMDM non-normative UML representation.**
**Identifier verses Subject Locators verses Source Locators**
**Everything is a subject, including Topic Map Constructs**
**Classes handled as Published Subjects**
**Key Features**
**Topics about Subjects**
**N-ary Associations**
**Scoping**
**Identity**

**TM Metamodel**

## Topic and Association

## Provide standard UML notation for each of the languages
RDFS/OWL was highest priority based on RFP
Topic Maps was high priority based on user community input
What about ER and SCL?
ER has an existing graphical notation, though no “standard” notation – a profile for ER has been requested
SCL was originally included for constraint/rule representation – a profile has been requested due to its utility for BSBR and interoperability with other ISO efforts
Essentially a one-to-one mapping from concrete meta-model element to stereotype
Abstract meta-classes contribute to base classes for stereotypes

**RDFS/OWL was highest priority based on RFP**
**Topic Maps was high priority based on user community input**
**What about ER and SCL?**
**ER has an existing graphical notation, though no “standard” notation – a profile for ER has been requested**
**SCL was originally included for constraint/rule representation – a profile has been requested due to its utility for BSBR and interoperability with other ISO efforts**
**Essentially a one-to-one mapping from concrete meta-model element to stereotype**
**Abstract meta-classes contribute to base classes for stereotypes**

**ODM Profiles**

## OWL Full was selected as the core ODM metamodel to limit NxN mapping requirements
Current draft includes 
two-way mappings from UML2, TM, and ER to RDFS/OWL
one-way mapping from RDFS/OWL to SCL
Additional mappings requested include
from UML, ER and TM to SCL 
from SCL to UML and RDFS/OWL
Current set were developed either using tables or an interim QVT notation – plan to migrate all to QVT once the specification is adopted

**Current draft includes **
**two-way mappings from UML2, TM, and ER to RDFS/OWL**
**one-way mapping from RDFS/OWL to SCL**
**Additional mappings requested include**
**from UML, ER and TM to SCL **
**from SCL to UML and RDFS/OWL**
**Current set were developed either using tables or an interim QVT notation – plan to migrate all to QVT once the specification is adopted**

**ODM Mappings**

## Bridging KR and MDA 

## Translating ER to OWL

## Completeness of the RDFS, OWL and ER metamodels (OCL constraints)
Mappings specified as QVT mappings – completion relies on finalization of the QVT
Relating user-defined instances of OWLOntologyProperty and OWLAnnotationProperty to instances of user-defined ontologies and ontology constructs, respectively
MOF2-compliant graphical metamodels – tool availability/support
UML2-compliant profiles – tool availability/support
MOF2-compliant XMI artifacts – tool availability/support
MOF2-compliant JMI artifacts – tool availability/support

**Mappings specified as QVT mappings ****– ****completion relies on finalization of the QVT**
**Relating user-defined instances of OWLOntologyProperty and OWLAnnotationProperty to instances of user-defined ontologies and ontology constructs, respectively**
**MOF2-compliant graphical metamodels – tool availability/support**
**UML2-compliant profiles – tool availability/support**
**MOF2-compliant XMI artifacts – tool availability/support**
**MOF2-compliant JMI artifacts – tool availability/support**

**Open Issues**

## Next Steps

**Resolve open issues where possible**
**Feedback by April 4 for resolution by May 30**
**Add requested profiles/mappings as time permits**
**ER, TM, UML to SCL mappings**
**SCL and ER Profiles**
**Post final draft of revised submission by May 30**
**AB Presentation planned for Boston Meeting (June 20)**