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).
OWL 2 hierarchies (yellow lines) are used to organize entries on a conceptual basis while remaining neutral with regard to abstraction semantics. For example, systems are defined in terms of agent and artifacts without any assumption regarding inheritance.
Aspects & Properties
Since aspects are not meant to directly represent individuals in domains, they can be defined in terms of standard generic of functional constructs:
- Features (Properties and operations).
- Numeric and logic expressions.
- Abstract data types (collections, graphs, …)
- Rules and heuristics.
With OWL 2, the kernel defines aspects in the Class hierarchy, but connectors are defined as object properties, and attributes as data properties.
Contrary to categories, whose instances are to be checked for external consistency, aspects have only to be checked for internal consistency.
Connectors being the glue of knowledge, their semantics is to make the difference. On that account, kernel connectors (blue lines) make a distinction between five kinds of connectors:
Architecture connectors, used to describe:
- Interdependencies between capabilities at the enterprise level: roles, objects, activities, locations, events and processes.
- References between symbolic representations.
- Flows between activities: passive symbolic or actual content, or active requests.
- Dependencies between processes execution.
- Communication channels between objects or locations according to capabilities: physical, digital, or symbolic.
Knowledge connectors deal with semantics. Thesaurus ones (kernelBw and kernelFw) put the focus on semantic dependencies, 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.
Logical connectors are meant to be aligned with standard logic.
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.
Combining formally defined nodes and connectors greatly enhances the transparency and consistency of models independently of the semantics refinements to be added.
To be ecumenical and avoid endless controversies, kernel entries must be built on a limited set of unambiguous and effective assertions:
- Limited: since axioms serve as roots to acyclic semantic graphs, there should be as few axioms as possible.
- Unambiguous: axioms are meant to be either accepted or rejected, which implies that their meaning should be clear and leave no wiggle room for misunderstanding.
- Effective: the axioms singled out are not meant to be the pillars of some absolute truth, but rather to serve as logical hubs for sound and effective EA categories. They should therefore only be judged on their effectiveness in supporting clear and concise EA definitions.
On that account, and assuming standard logic, seven axioms are used as a basis:
Physical or symbolic occurrences of objects or phenomena (both accepted as postulates): The distinction between physical and symbolic instances is not exclusive (consider hybrids); additionally, fictional instances are instances (physical or symbolic) that are not meant to be realized. Instances are represented by individuals in OWL.
Set of instances managed uniformly, independently of their nature.
Unique value associated with an instance: External identities are defined independently of the organization or system under consideration. External identities can be biological, social, or designed; they are not exclusive (e.g., social security number and fingerprints). Internal identities are used to manage systems components independently of environments.
- A symbol is a sign pointing to something else (referent).
- A symbolic representation is a symbol pointing to a set of instances.
- A symbolic object is an object representing a referent; this means that symbolic objects can be physical, as they usually are.
The ability of an instance to change the state of instances, including itself: Objects are either active (with behavior) or passive (without behavior), and the propriety is exclusive.
Named sets of values that characterize instances of objects (actual or symbolic), processes, or representations, between events. Stateful objects and activities come with a finite number of discrete states; stateless ones don’t have this limited array, and may indeed have an infinite number of discrete states.
Change in the state of objects and phenomena: External events are changes triggered from outside the organization or system under consideration.
These axioms serve as roots and firebreaks in acyclic semantic networks of EA definitions. These definitions are not meant to be “true,” comprehensive, or exclusive; but rather, effective (to make a difference), as simple as possible (Occam’s razor), and open to refutation.
Combined with OWL 2 hierarchies, these semantic networks constitute the kernel of the thesaurus, which can then be fleshed out to build EA Knowledge graphs.
Given the layered organization (axioms and acyclic networks for semantics, and graphs for EA knowledge), consistency checks can be formal with regard to the kernel (e.g., no circular definitions), but pragmatic and customized with regard to EA definitions.
Filters are introduced to manage views. Simple ones set forth or remove specific aspects (e.g., hierarchies), functional ones are driven by purposes, eg., EA, activities, domains.
The EA filter put the focus on the relationships between capabilities: context, roles, objects, activities, execution, and locations.
A basic filter put forward the sequence of activities and the reference to objects and roles.
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.
Four patterns can be used to represent variants:
- Variants as partitions (attribute), e.g., reservations can be pending or confirmed. Specifics can be managed by operations.
- Powertypes are introduced to deal with overlapping partitions and to manage values and operation shared within subsets, e.g., foreign exchange operations are specific to currency zones.
- In contrast to powertypes, whose instances represent subsets, delegation separate each instances in two parts, one for aspects (or features) uniquely valued (e.g., identity), the other for aspects with variants (e.g., business role).
- Subtypes are needed when variants are not only on valued aspects but on the aspects themselves.
On the one hand partitions and 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.
They may or may not serve as a basis for 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