Ontologies & Enterprise Architecture

See also: Knowledgeable Organizations

Preamble

Ontologies are all too often seen as abstract contraptions best reserved for arcane issues. But once implementations are kept, as they should, under the hood, ontologies are best understood as a way to model contexts and concerns independently of IT systems. As it happens, that is what enterprises are now rediscovering as knowledge graphs.

Enterprises Architecture & Contexts

Long secure behind organizational and technical fences, enterprises now have to navigate through open digitized business environments and markets.

For business processes it means a seamless integration with supporting applications; for corporate governance it means keeping track of heterogeneous and changing business contexts and concerns while assessing the capability of organizations and systems to cope, adjust, and improve.

Hence the benefits of a knowledge architecture framing together the flows of raw data, the idiosyncrasies of business contexts and concerns, and well-defined models of systems functionalities and capabilities.

That is to be best achieved with modular ontologies linking open business perspectives to dependable enterprise architectures.

A Taxonomy of Contexts

Since enterprises operate within social contexts, external ontologies should be first defined with regard to the nature of the social understanding supporting them:

• Institutional: Regulatory authority, steady, changes subject to established procedures.
• Professional: Agreed upon between parties, steady, changes subject to established procedures.
• Corporate: Defined by enterprises, changes subject to internal decision-making.
• Social: Defined by usage, volatile, continuous and informal changes.
• Personal: Customary, defined by named individuals (e.g research paper).

Given such an external taxonomy, it has to be mapped to an enterprise architecture counterpart. For that purpose the Zachman framework appears to be the option of choice.

The Zachman’s taxonomy is built on well established concepts (Who,What,How, Where, When) applied across architecture layers for enterprise (business and organization), systems (logical structures and functionalities), and platforms (technologies). These layers can be extended as to apply uniformly across external ontologies, from well-defined (e.g regulations) to fuzzy (e.g business prospects or new technologies) ones, e.g:

That “divide to conquer” strategy is to serve two purposes:

• By bridging the gap between internal and external taxonomies it significantly enhances the transparency of governance and decision-making.
• By applying the same motif (Who,What, How, Where, When) across the semantics of contexts, it opens the door to a seamless integration of all kinds of knowledge: enterprise, professional, institutional, scientific, etc.

As can be illustrated using Zachman concepts, the benefits are straightforward at enterprise architecture level, due to the clarity of supporting ontologies; taking procurement for example:

But there is no such clarity for business contexts and concerns: if combination has to be applied to ontologies targeting external contexts, overlaps and semantic ambiguities will have to be dealt with. That can be achieved by designing ontologies with regard to perspectives and concerns.

A Taxonomy of Concerns

While the coarse-grained taxonomy introduced above for the social basis of contexts should rub out blanket overlaps, a fine-grained one is needed to manage semantic confusion at items level. And since ontologies are meant to define existential circumstances, it would make sense to characterize ontologies according to the epistemic nature of targeted items, namely terms, documents, symbolic representations, or actual objects and phenomena. That would outline four basic concerns that may or may not be combined:

• Thesaurus: ontologies covering terms and concepts.
• Document Management: ontologies covering documents with regard to topics.
• Organization and Business: ontologies pertaining to enterprise organization, objects and activities.
• Engineering: ontologies pertaining to the symbolic representation of products and services.

Taking an on-line insurance business for example, the knowledge architecture would have to include:

• Medical thesaurus and consolidated regulations (knowledge).
• Principles and resources associated to the web-platform (Engineering).
• Description of products (e.g vehicles) and services (e.g insurance plans) from partners (Business).

As for contexts, that taxonomy of concerns can be directly combined with the Zachman’s one. It would then be possible to map out ontologies requirements with architectures capabilities, e.g:

• Thesaurus: only target terms and their semantics.
• Web search: only target web documents and associated terms and semantics.
• Regulations: target symbolic descriptions of domains of activities and organizations, together with associated terms, semantics, and documents.
• Engineering: target systems representations of specific domains of activities and organizations.

Such a taxonomy carries pragmatic benefits when used as a filter: corresponding sieves can be used to sort heaps of undifferentiated items before  mapping them out to templates. It can also be used to customize views according to users:

Designing  ontologies according to the social basis of contexts and the epistemic nature of concerns is to significantly improve modularity and transparency. But insofar as knowledge is concerned, interoperability is to be determined by a clear distinction between representation syntax and contents semantics.

Representation & Contents

Most of ontologies are implemented by a mix of conceptual graphs and predicate logic generally known as Resource Description Frameworks (RDFs).

Conceptual graphs (or semantic networks) can be summarily defined as made of two kinds of nodes respectively for concepts and conceptual relations. As explicitly stated by Peirce’s seminal work, these nodes stand for “existential” references, respectively for what exists on its own and what exists relatively. But it must be reminded that they are by nature ontologically neutral and support representation and contents semantics independently of domains of concern or perspective.

Taking that neutrality into account, it would be tempting to align the nature of semantics with the type of nodes (top):

• Nodes would represent elements specific to domains (bottom right).
• Connection nodes would be used for semantically neutral (aka syntactic) associations to be applied uniformly across domains (bottom left).

That can be illustrated with the simple example of cars:

Along that understanding, ontology designers would have to make three kinds of decisions:

1. How to define and use the formal semantics (aka ontology syntax).
2. How to define and use domain specific nodes meant to be shared across ontologies.
3. How to design specific contents.

That’s the theory because, for good or bad and trivia set apart, reality cannot be comprehensively and universally aligned with logic. Assuming that there will always be arguments about where semantic lines have to be drawn, beacons and compasses are required.

Proprietary Solutions & Ontological Silos

Conceptual graphs being neutral, a free semantic hand is given to ontology designers, which they extend at full range. Despite W3C’s attempt with the Ontology Web Language (OWL), the landscape appears as a mix of hedged gardens and interlaced jungles, the former with cultivated semantics set in frames, the latter with entwined shrubs of generic and specific terms. If there isn’t much to learn from bushes, orchards offer some lessons, as can be illustrated by the FacetOntology of the Tetherless World Constellation (TWC):

• Domain specific categories (yellow): products, manufacturers.
• Domain specific instances of categories (orange): hard drive, SeaGate.
• Terms defined by the FacetOntology meta-language (green) bear formal (non specific) semantics: facet (aka aspect, aka feature), predicate…
• Instances of formal constructs (blue).
• Abstraction connector (is a).

Such schemes do support principled and effective combinations of ontologies, yet they remain proprietary buildings; and evidence shows that floors and stairs are usually at odds, with dire consequences for interoperability. Even without taking into account relationships and integrity constraints, weaving together ontologies from different sources is to be cumbersome, the costs substantial, and the outcome often reduced to a muddy maze of ambiguous semantics.

Ontologies Filters

As pointed up by proprietary solutions, semantic overlaps and folds are much easier to be ironed out along a built-in semantic distinction between contents on one hand, representation and processing on the other hand. The dilemma is that knowledge pertaining to business contexts and objectives is framed by assumptions and expectations, which means that the lines between contents, representations, and processing are to shift with perspectives.

That can be illustrated with a simple example combining vehicles and leasing: assuming that a thesaurus already covers all specific concepts and terms, ontology designers would begin with the definition of targets, actual objects for some, blueprints or contracts for others:

• Targeted instances: for car designers it would be vehicle platforms (symbolic objects), for manufacturers it would be models (symbolic objects), and for leasing it would be contracts (symbolic objects) and cars (actual objects).
• Domain specific relationships: for designers and manufacturers, models combine platforms with motors (symbolic objects); for leasing, actual cars are associated with actual motors, locations, and leasing contracts.

That leaves ontologies designers with different options as how to use formal and specific relationships, e.g:

• Structure vs Relationship: Since Leased Car and Motor stand for actual entities, standard composition is pertinent (a). That’s not the case for the relationships between the symbolic descriptions of models, platforms, and motors (b).
• Instance vs Is-a: Given the distinction between symbolic and actual motors, standard instantiation can be applied between them (c); by contrast, if both cars and leased cars denote actual entities, the latter can only be a subset of the former (d).

That put designers in a dilemma: to be of any use business oriented ontologies have to combine different resources; but that cannot be achieved without a clear distinction between formal and domain specific semantics. And that distinction somewhat depends on the perspectives of business ontologies. Trying to sort out syntactic and semantic connections, one would set apart the designs of cars (symbolic) and the locations of leased cars (actual):

While that could ensure the interoperability of implementations, it would have no effect on semantic interoperability: if external ontologies are to be shared, the semantics have also to be sorted out as to separate representations (to be consistently shared) and contents (to be exchanged on a need-to-know basis).

Given the motley of external ontologies compared to the neat layout of internal ones, a pragmatic approach would be to try to align the former’s nodes with the latter’s ones.

Open Ontologies

If external ontologies are to be anchored to enterprise architectures, one have to decide what belongs to commons and what is to go with circumstances. And there is no reason to assume that every business’ facet belongs to circumstances, or that every systems’ feature belongs to commons.

That’s a matter of design, and if external ontologies are to be reined in, modularity, interoperability, and traceability should be assessed with regard to enterprise architecture.

Along that understanding, well established principles for object-oriented design can be effectively applied to ontologies:

• Open-Closed Principle (OPC): contents semantics cannot be modified. In other words they can be specialized but not generalized.
• Substitution Principle (LSP): contexts targeted by lower level ontologies must be subsets of the ones denoted at upper levels. That ensures that concepts are consistently understood  across knowledge architectures.
• Dependency-Inversion principle (DIP): higher levels semantics are defined independently of lower levels (no circular definitions). That ensures that semantics of lower ontologies are consistently, but not necessarily uniformly, defined across knowledge architectures.
• Interface-Segregation Principle (ISP): semantics and representations are congruent, i.e all features are meaningful for whoever is using a concept. That ensures that there is no overlapping of semantics even when ontologies overlap.

These principles are to be applied globally to the design of ontologies, and specifically for the design of the open concepts meant to be shared across ontologies, e.g:

• OPC: K1 and K2 combine thesaurus and document management respectively for vehicles and insurance regulations; they don’t overlap which ensure that concepts can be defined and refined independently. Nonetheless, since regulations are documents, their contents are left to interpretation and may overlap through car leasing.
• LSP: In contrast to K2, everything in E (and not only Motor Vehicle) is meant to be understood through the whole of K1 (and not only Vehicle) .
• DIP: Propulsion (K1) is defined independently of motors (E) so it can be reused without the risk of semantic ambiguity.
• SIP: Every characteristic of propulsion is meaningful (semantics) for motors in E and valued for actual motors in B (representations).

Open design principles could bridge the conceptual gap between the representation of internal (enterprise architecture) and external (business environment) ontologies; yet that would still not be enough because knowledge is also a matter of language and communication.

Learning Languages On-the-spot

Knowledge is by nature tied up to domain specific languages. While proprietary RDF can be finely tuned to domain semantics, exchanges are to be hampered by translation. Open design would help by reducing ontologies overlaps and sorting out contents and representation semantics, yet the core of semantic complexities is to remain tied to languages. That obstacle could have been irredeemable were it not for deep learning and its impact on natural language processing.

As long as parsers were based on lexicons and grammars, translation was best achieved with predefined rule engines blending languages syntax with domain semantics. Now, deep learning capabilities are turning the task on its head because specific rule engines can be built on the fly through on-the-spot and wholesale mining of what has been written about any domain.

In theory, ontologies could be allocated fine-tuned dedicated interpreters at (almost) no cost; in practice, such interpreters could remain inhibited if the specifics of language and domain were mixed. But they will give their full potential if selectively applied to domains semantics.

That would bring benefits to all kinds of interfaces as the same context-driven paradigm could be used for humans as well as smart systems interfaces. And the design of all interfaces could be directly aligned with the designs of representations.

Furthermore, setting apart representation and communication languages is help deep learning agents to mine through explicit and implicit knowledge, the former already set by languages, the latter still open to interpretation and discovery.

Conclusion

Ontologies are meant to define the categories of things and phenomena that may occur in a domain of concern. That makes them productive assets for enterprises trying to make the best of their business objectives in open and changing contexts. On that account, ontologies requirements should focus on:

Modularity: that comes first because enterprise architectures must be continuously tailored to changes in markets and corporate structures without impairing enterprise performances. That is to be achieved with a customized design of open ontologies.

Integration: the design of ontologies with regard to the social basis of contexts and the epistemic nature of concerns is to facilitate the alignment of enterprises architectures with their environment.

Interoperability: business contexts and objectives are meant to changes while remaining anchored to more stable enterprises architectures. If frictions are to be managed ontologies overlaps are to be minimized and semantic ambiguities stamped out.

Interfaces: taking advantage deep learning technologies, the uniform design of natural language interfaces for humans as well as intelligent systems can be a key success factor for knowledge architectures.

On a broader perspective, a functional approach to ontologies, as opposed to one focused on implementations, is to be guided by the alignment of EA with their environment (regulations, markets, partnerships) and the transparency of decision-making processes.

Annex: Summary Syntax

A core of formal constructs can defined for connectors with regard to:

• Target: nodes (instance or types), and connectors (origin-2-destination).
• Mutability for links (aggregation vs composition) or abstractions (functional vs structural)
• Boolean operators.

Further Reading

• Open Ontologies: From Silos to Architectures
• Ontologies as Productive Assets
• Caminao & DoDAF
• Systems, Information, Knowledge
• Knowledge Architecture
• Ontologies & Models
• Enterprise Governance & Knowledge
• EA: Work Units & Workflows
• Agile Collaboration & Social Creativity
• The Finger & the Moon: Fiddling with Definitions
• Reinventing the wheel
• EA Workflow: Case Study

External Links

• Davis R., Shrobe H., Szolovitz P., “What is a Knowledge Representation?”,  AI Magazine, 14(1):17-33, 1993
• Sowa John F., John A. Zachman, “Extending and formalizing the framework for information systems architecture”
• James Odell, CSC Catalyst Ontology
• Semantic Web Case Studies and Use Cases
• “Is The Enterprise Knowledge Graph Finally Going To Make All Data Usable?” Forbes, Sept 2018
• Mike Bergman, “A Common Sense View of Knowledge Graphs”
• FacetOntology Tetherless World Constellation (TWC)
• Vehicle Sales Ontology
• Ontology for Innovation
• Ontology for eCommerce
• W3C: Concepts and Abstract Syntax