The immersion of enterprises into digital environments calls for a seamless integration of data analytics, information systems, and knowledge based decision-making. That can be best achieved through an ontological approach to enterprise architecture frameworks.
In contrast to systems architecture, enterprise architecture must maintain a continuous and consistent representation of business environments and objectives because:
- Architectural changes must be carried out without impairing business.
- Environments may change in parallel with engineering processes.
To demonstrate the benefits of ontologies for EA, a kernel prototype is being developed combining the Stanford’s modeling paradigm with established cognitive and knowledge principles:
- Targets: actual or symbolic.
- Connections: associations and analogies.
- Processing: truth-preserving or domain specific reasoning.
- Layers according to: epistemic nature of contents (concepts, documents, or artifacts), functional nature of contents (environment, enterprise, systems, platforms), and contexts (institutional, professional, corporate, social).
From a theoretical perspective the objective is to demonstrate the benefits of the Stanford modeling paradigm that defines systems as containers managing symbolic representations (aka surrogates) of operational environments.
From a functional perspective the kernel is to meet the principles of knowledge representation set by Davis, Shrobe, and Szolovits in their seminal article:
- Surrogate: KR provides a symbolic counterpart of actual objects, events and relationships.
- Ontological commitments: a KR is a set of statements about the categories of things that may exist in the domain under consideration.
- Fragmentary theory of intelligent reasoning: a KR is a model of what the things can do or can be done with.
- Medium for efficient computation: making knowledge understandable by computers is a necessary step for any learning curve.
- Medium for human expression: one the KR prerequisite is to improve the communication between specific domain experts on one hand, generic knowledge managers on the other hand.
On that basis ontologies deal with numbers 1,2,3, and 5, and models with numbers 4 and 5. The proposed approach is to use ontologies for profiles and domains as to support a seamless conceptual integration with model based systems engineering (MBSE).
That is to be achieved through a compact set of unambiguous concepts, straightforward modeling principles, and implementation with Stanford University’s Protégé/OWL 2.
Ontologies, Models, & Thesauruses
The contents of ontologies can be formally defined in terms language, models and thesaurus:
- Thesauruses define the meaning of terms, categories, and concepts.
- Models add syntax to build representations of contexts and concerns.
- Ontologies add pragmatics in order to put models in broader perspectives.
These levels correspond to the epistemic nature of the targeted elements:
- Concepts: pure semantic constructs defined independently of instances or categories.
- Categories: symbolic descriptions of sets of objects or phenomena: Categories can be associated with actual (descriptive, extensional) or intended (prescriptive, intensional) sets of instances.
- Aspects: descriptions without external instances of their own: Aspects cannot be directly instantiated (or identified) in environments; they can only exist as digital components in systems.
- Documents: entries for documents represent the symbolic contents, with instances representing the actual (or physical) documents.
Besides concepts and documents, which correspond to thesaurus and content management systems (CMS), the backbone of the kernel is built around categories of actual and symbolic entities.
Categories are first defined in line with established notions of objects, agents, activities, events, locations. They are further refined with regard to the nature of instances (actual or symbolic), and the source of their identification (internal or external).
For example, entities are realized by classes, the former realizing aspects at the conceptual or logical level, the latter realizing aspects at the technical level.
Since aspects are not meant to directly represent individuals in domains, they can be defined according to standards, generic of functional constructs:
- Features (Properties and operations).
- Numeric and logic expressions.
- Abstract data types (collections, graphs, …)
- Rules and heuristics.
Contrary to categories, whose instances are to be checked for external consistency, aspects have only to be checked for internal consistency.
Objects properties (Connectors)
Connectors being the glue of knowledge, their semantics is to make the difference. On that account, three kind of connectors are distinguished, depending on targets.
Semantic connectors are set at linguistic level. Kernel connectors (kernelBw and kernelFw) provide the backbone of the thesaurus, ensuring that there is no circular definitions. Semiotic ones deal with basic associations (synonyms, homonyms, metaphors, metonymies, etc.); they are meant to support cognitive operations independently of domain-specific semantics.
Functional (aka semantic) connectors are set at instance level with semantics defined by modeling perspective:
- References connectors can points to symbolic representations (aka surrogates) or to other entries. The kernel provides generic references for core modeling artefacts: activities, locations, processes, actors, events, etc.
- Flows connectors are associated to exchanges between activities: passive symbolic or actual content, or active requests.
- State connectors (aka transitions) are associated to the synchronization of processes execution.
- Channels connectors represent the communication links between actual objects and locations according to capabilities: physical, digital, or symbolic.
Structural (aka syntactic) connectors are set at representation level. Generic ones coincide with established standards for collections, aggregates, and compositions; they are meant to be executable and support truth-preserving operations independently of domain semantics.
Logical connectors do the same for rules:providing for the definition of left or/and right footprints and expressions.
Combining formally defined nodes and connectors greatly enhances the transparency and consistency of models independently of the semantics refinements to be added.
Abstraction is arguably at the core of knowledge, hence the importance of reliable representations. But as far as ontologies are concerned, it can take different meanings depending on targeted elements:
- Categories provide the building blocs of all representations.
- By contrast, concepts are used for knowledge wholly detached from domains’ instances and features.
- Classes (or types) is OWL’s default option, but they take a more specific meaning when used for systems.
- Partitions are types of types and are introduced for subsets of instances with commonly valued features.
Partitions (aka powertypes) represent categories of categories to be managed as business objects on their own, possibly across domains. They can be used as a bridge between generic (categories) and specific (classes) semantics of abstraction.
Using OWL to describe the different aspects of enterprise architectures (data, information models, knowledge and decision-making) calls first for refined the semantics of classes sub-types:
- Conceptual sub-types are intensional: specialization of meaning.
- Documents sub-types are intensional: specialization of topics.
- Category sub-types are extensional: subsets of instances.
- Class sub-types are intensional: specialization of designs.
- Aspect sub-types are intensional: subsets of features.
As the difficulty arises for extensional categories (i.e descriptions tied to external instances), partitions, which like structural and functional links operate at instance level, is to be used as the first step of specialization, which deals with categories. Conversely, concepts can be used to pave the way to generalization.
Given the formal definition of aspects, categories, classes, and partitions, it’s then possible to combine unambiguous semantics of delegation and inheritance connectors.
These examples are focused on three key benefits of the approach, namely:
- The distinction between representation syntax and contents semantics.
- The distinction between truth-preserving and functional reasoning.
- The processing of data into information and knowledge.
Syntax & Semantics: Categories, Aspects, Properties
The distinction between objects and aspects has a well established track record in software design and should be fully supported by ontologies.
- Social Id and roles are structural aspects of manager entity, i.e identified by and used through managers’ instances (a).
- Roles is a symbolic container for multiple (b) functional connectors (c).
- Terms for actors and roles are deemed synonymous (d)
Interfaces consistency can be checked by comparing agents’ actual language capabilities to actors’ required ones.
Integrity: Structural vs Functional Constraints
Factoring out truth-preserving reasoning is a direct benefit of the distinction between representation and domain specific contents.
With mutability uniformly and unambiguously defined across domains, a distinction can be made between what is known and what is open to scrutiny.
- The relationships between cars and models cannot be modified (dark blue).
- The relationships between rentals and cars can be modified (clear blue).
By contrast, the cardinality of occurrences is best defined by domains as it combines functional and structural integrity constraints.
- Existential integrity: rentals must be uniquely associated to cars and groups; but groups can mix models.
- Functional integrity: as business may require multiple assignments of actual cars to rental ones, mandatory constraints should not be mixed with exclusivity ones.
- Inferred connections can be directly specified with the tool.
These object and data properties may have to be refined as to limit the overlapping with OWL 2 native ones.
From Data to Knowledge: Individuals, Categories, Concepts
The benefits of the distinction between representation syntax and domain semantics, as well as its corollary for truth-preserving reasoning, encompass all information systems, and so ensure a sound basis for knowledge management.
But knowledge is dynamic by essence and what is at stake is the processing of raw data into information and knowledge assets:
- Data is first captured through aspects.
- Categories are used to process data into information.
- Concepts serve as bridges to knowledgeable information.
Information models describe what systems are meant to manage in terms of categories, e.g for customers and business processes. Insofar as ontologies are concerned, individuals are logical instances, e.g invoicing insurers or customer with family.
Data is first acquired as hypothetical structures to be mapped to information models, e.g through applying statistical knowledge.
Knowledge is managed through expressions, concepts, and documents. When knowledge is considered, the critical point is to decide what should count as individuals.
- Ontologies & Models
- Conceptual Models & Abstraction Scales
- Models & Meta-models
- Ontologies & Enterprise Architecture
- Ontologies as Productive Assets
- Modeling Paradigm
- Views, Models, & Architectures
- Abstraction Based Systems Engineering
- The Cases for Reuse
- The Economics of Reuse
- Focus: Requirements Reuse
- Projects as non-zero sum games
- Projects Have to Liaise
- Caminao & EACOE
- EA & MDA
- EA: The Matter of Layers
- EA: Maps & Territories
- EA: Work Units & Workflows
- Models Transformation & Agile Development
- Stanford Knowledge Systems Laboratory: “What is an Ontology ?”
- John F. Sowa, “Ontology“
- Davis, Shrobe, and Szolovits: “What is Knowledge Representation“
- OWL Overview
- FacetOntology: Expressive Descriptions of Facets in the Semantic Web
- Zachman Framework As Enterprise Architecture Ontology – SlideShare
- Why the Zachman Framework is not an ontology – Inside Architecture
- Semantic Web Case Studies and Use Cases
- FacetOntology Tetherless World Constellation (TWC)
- Vehicle Sales Ontology
- Ontology for Innovation
- Ontology for eCommerce
- W3C: Concepts and Abstract Syntax