HIGHFLEET’s Use of Ontologies (Logic Models)
- Introduction - What’s This About?
- What an ontology (Logic Model) is for HIGHFLEET.
- Why does HIGHFLEET use Logic Models/Ontologies in Its Information Systems?
- Using a Logic Model - the HIGHFLEET System.
- HIGHFLEET’s Solutions – Semantic Federation of Existing Databases (SemFed), and the eXtensible Knowledge Server (XKS)
- Broad Applications of HIGHFLEET’s Systems.
- Specific Implementations of HIGHFLEET’s System.
- The Knowledge Capture Process.
- Ontology Example
- What an ontology is not - a list of commonly encountered folly.
Introduction - What’s This About?
HIGHFLEET’s capabilities reside within what the market is calling “semantic technologies”. Anyone familiar with this field or who researches it a little will encounter the unfortunate term “Ontology”. I say “unfortunate” because “Ontology” at once clouds the understanding, taking what is in fact a disciplined approach to modeling reality and making it sound like some kind of exotic new science beyond the ken of mortals. And unfortunate because, like “semantics”, it has lost all meaning in this field. As companies sense a marketing opportunity “Ontology” and “semantics” have become victims, mere shadows of their former selves, bent into the service of joining a perceived band wagon.
Consequently, HIGHFLEET feels it is necessary to clarify what Ontology is and how HIGHFLEET uses the logic models we create using the discipline of Ontology, to help the enterprise understand what their data means operationally and for strategic decision making. The discipline of Ontology gives us high fidelity models that when used in our deductive reasoning systems provide a deep context of meaning (semantics) to enterprise data, giving the enterprise powerful analytic insight into all its data.
What is an Ontology (Logic Model) for HIGHFLEET?
Knowledge Capture into a Logic Programming System
An ontology is a Logic Model that expresses in computer understandable form the entirety of the bounded domain you wish to model. It is, for a particular domain, the things in the domain, their relations, the logic that controls those relations and interactions, AND rules as necessary to fully model the knowledge you wish to instantiate. A Logic Model captures the knowledge of a domain to the extent required by the customer’s needs.
So this is a richer, more contextual, machine understandable artifact than say, a taxonomy, or a data model . . . or a list of words (See “What an ontology is not” on Page 8 below.). Most “semantic technology” companies do not write their ontologies directly to a logic programming language as HIGHFLEET does. Consequently, they cannot state that their “ontologies” are Logic Models.
Consequently, while we use the discipline of Ontology (big “O”), what we create with that intellectual discipline and process is a Logic Model (a.k.a. and ontology). We will use the term “Logic Model” to describe our domain models created for use in our deductive systems.
For HIGHFLEET, the term Logic Model = an ontology.
Why does HIGHFLEET use Logic Models/Ontologies in Its Information Systems?
To perform deep analyses on enterprise knowledge and data, because businesses are drowning in data that they can’t make sense of. HIGHFLEET solves this sense making problem, for big data problems, mundane problems and hard analytic challenges.
HIGHFLEET was founded with the intention of creating Deductive Databases, that is, logic programming based systems that would do deductive inference, at run time, on complex Logic Models and large amounts of appended data, providing deep analysis of enterprise information.
Having talked to numerous CEOs, CIOs and CTOs, it is clear that most firms face a common challenge. They have lots of structured data in repositories in different locations and of different types, including spreadsheets, and no practical solution, meaning not prohibitively expensive and not disruptive to the enterprise. And not a form of wet cement that will harden over your enterprise and have you filling out some computer generated form until the heat death of the universe.
These information problems range from the mundane to the very sophisticated. A mundane example: I know of a firm that has dead, retired or otherwise absent people still on the HR database, and these people are still getting emails about taking ethics training, or completing their time cards. This might seem trivial, but it seems intractable for this firm and could have possibly serious compliance and regulatory consequences. A more sophisticated example is complex event analysis over large numbers of databases for product quality control, logistics management, or forensic analysis.
So a means is needed to reason over the meaning of data, that is, the semantics of the data, so that it can be linked to knowledge, and linked at the level of meaning in the real world. Two things are required: 1. a technique or discipline for capturing knowledge in models that reflect great fidelity to how things work in the real world; and 2. a means for a computer to do deductive inference, reasoning, over the knowledge and appended data and thus make sense of the data in relation to the knowledge - a Reasoner.
Such a system would end the spaghetti tangle of trying to get “smarts” into expensive, brittle, and costly applications that all have a different view of what the data means.
HIGHFLEET’s Founders determined that the discipline of Ontology would produce the high-fidelity Logic Models of various domains, providing the material on which the HIGHFLEET Parallel Query Engine (PiQuE) Reasoner would perform analysis. The ontology is that Logic Model. Building ontologies is not the goal, it is a tool.
The computer reasoning piece is provided by HIGHFLEET’s Parallel Query Engine, or PiQuE Reasoner, that does deduction over the ontology/Logic Models. Divorced of the exotic sounding “ontology” we all intuitively understand Logic Models. We all have in our minds a world model that we’ve been building since we were toddlers. And it is a model we’ve augmented with various amounts of formal education. Thanks to this model we know what things mean in the context of our deep experience. We know that when our desk phone rings we don’t go answer the door; you answer the phone. We know that cups hold fluids, but they have to be right side up. We also know that cups afford many other uses, such as holding granular solids, pencils, and other small objects. That is, we know cup use can have different contexts. We know that only female mosquitoes need a blood meal. We know mosquitoes inject anticoagulant to keep blood flowing as they ingest it. We might know that anticoagulants are a large body of substances of many types and chemistry. But an enterprise might suspect, but not know, that a product made in one location for one purpose at $5.00 per unit, is made in another for less cost per unit and could serve the same purpose as the more costly to produce item. But they don’t have a logic model against which to put data from disparate sources, and so continue to run a very sub-optimal business.
Our Logic Models perform analysis and sense making as humans do in using deduction to reason over a domain model. By taking advantage of what computers are good at – remembering everything and doing lots and lots of logic operations really fast – our systems do far more deductive reasoning over far larger, more complex models and far more data than any human could. This translates into powerful analytic and sense making capabilities.
When the benefits of a our deductive systems are applied to large federations of existing databases as we do with our Semantic Federation of Existing Databases (SemFed), then an enterprise can get full analytic value from its data repositories and finally understand what its data means for day-to-day operations and for strategic decision making.
Using a Logic Model - the HIGHFLEET System
An ontology/Logic Model is just a file that you can print to provide a carpet for your budgerigar . . . unless it is used in a complete system.
HIGHFLEET’s core system is a stack of:
- Query Optimizer - finds the most efficient path to an answer since in logic systems there can be many paths of reasoning that lead to the same answer.
- Reasoner - a First-Order Logic Based parallelized system that performs deductive inference across the Logic Model (ontology) and data.
- Persistence Store – We can use the persistence stores of major commercial databases and Postgres. Thus enabling enterprises to get full value from their investment in other commercial databases. NOTE: But we do NOT use a typical relational database structure. It is here that our hypergraph structure is used. And we do not use the full “stack” of the other commercial db, only the persistence store.
The stack is built for efficient parallel processing of queries and answers.
All these components are used in our Semantic Federation of Existing Databases (SemFed) solution, and in our eXtensible Knowledge Server (XKS) product - a standalone Deductive Database.
We can also use our Reasoner and the rest of the stack in front of a Data Warehouse. In this configuration, we endow the Data Warehouse with a richer model of the domain, greater flexibility and analytic power. We can also easily install sophisticated Role-Based Access Control (RBAC) and reasoning over fact level security labels to provide very fine-grained access control to information in a Data Warehouse or other repository.
HIGHFLEET’s Solutions – Semantic Federation of Existing Databases (SemFed), and the eXtensible Knowledge Server (XKS)
To productize the analytic capability described above, HIGHFLEET offers two key solutions:
Our Semantic Federation of Existing Databases (SemFed), which is a cost effective means of federating numerous enterprise databases with our analytics “baked in”; and
The eXtensible Knowledge Server (XKS) is a standalone deductive database for those who want a new analytic system, or to replace expensive commercial databases.
Semantic Federation - SemFed
eXtensible Knowledge Server - XKS
The XKS is a “standalone” Deductive Database providing analytics and sense making for those needing a new analytic database, or for clients who want to replace expensive existing databases. If you have dbs priced by the vendor on number of cores on the server running the db, you’ll want to consider the XKS. The XKS has a one-time purchase cost not tied to number of server cores. Licenses are perpetual.
Broad Applications and Benefits of HIGHFLEET’s Systems
But why perform this knowledge capture and instantiation in our Reasoner systems in the first place? There are several excellent reasons.
- Analysis and Sense Making: We meet the need to perform analyses on enterprise information across numerous repositories. This requires an ontology/Logic Model of the domain, data, AND our Reasoner.
- Sense Making across Big Data – Semantic Federation of Existing Databases: Our SemFed solution enables the enterprise understand and use all its data to drive operations and strategic decision making. Again this requires our SemFed solution, which contains our robust Reasoner.
- Complex Event Alerts and Analysis – Standing Wave: Standing Wave is our ability to continuously run a logically complex query that might need information to arrive into our Logic Model from several sources. And whose importance is only realized when our Reasoner does masses of deductive inference on the new information. When that information arrives the query completes and Standing Wave alerts the user to the event. This has numerous applications.
- Sophisticated Security Solutions - With our PiQuE Reasoner you can now have sophisticated, real time Role Based Access Control (RBAC), a solution for Personally Identifiable Information (PII), Provenance, and fact-level reasoning on security labels as well as reasoning over Security Policy.
- Low life-cycle costs: Our Logic Model will be the “reality” to which all applications look. This way, all applications have the same view of business. This is definitely not the case with data models built to meet the one-off needs of an application. Eventually this latter approach leads to a brittle, expensive to maintain and confusing view into enterprise data.
- Data Integrity: You want to be able to trust your data. Most databases become highly corrupted with bad data because the databases are happy to accept bad data. Estimates for the costs of bad data to U.S. businesses range around $600 billion a year. HIGHFLEET’s system employs Integrity Constraints, IC’s. HIGHFLEET system’s Reasoner will check data against the logic in the model and flag bad data. We know of a “system of record” fleet maintenance db where the odometer readings decreased with time in the db. Someone’s going to ruin that $300,000 road grader because they missed the oil change. This kind of robust IC capability requires a sophisticated Reasoner.
- Flexibility: A typical database is built to answer a handful of questions thought to be important at the time. Good luck if you want to ask different questions later. With our Logic Model of the domain and our Reasoner, you can just ask a different question, or feed a new output to an application.
- Knowledge Capture and Re-use: Maybe you’ve heard about the “baby boomer drain”. This demographic pig in a python is seeing a huge number of older, knowledgeable employees of all ranks walk out the door in the next few year. It’s a looming crisis for firms around the world. See the Society for Human Resource Management: http://www.shrm.org/hrdisciplines/staffingmanagement/Articles/Pages/Work... HIGHFLEET’s knowledge capture and reuse is unparalleled thanks to our Logic Modeling and Reasoner systems.
Specific Implementations of HIGHFLEET’s System
HIGHFLEET has built Logic Models for the following domains among others:
- Metabolic pathways
- Interoperating Design Engineering and Manufacturing Engineering models
- Social Networks, including business and other transactions
- Competitive Intelligence
- Classified Intelligence Analysis
- Technical networks (IT infrastructure)
- Order of Battle
- Product diversion (theft).
- Intellectual Property theft
- Indications and Warning (I & W), a.k.a. Threat Assessment
- Rapid fault detection and location for Cable Networks
- Project Management
- Semantic Search, and others
Note that we do not model the world. We have not encountered a client who wants to model the world entire, or even every aspect of a particular domain.
That list should give you some idea of what is meant by a “domain”.
We are also applying our Reasoning systems, our “brain in a box”, to:
- Business Intelligence and Competitive Intelligence
- Intelligent Manufacturing Systems (IMS) and Flexible Manufacturing
- Advanced Services and Resource Management for City Government
- Knowledge Capture and Re-use
The Knowledge Capture Process
Creating the Logic Model
HIGHFLEET’s Ontologists build a rich, high-fidelity ontology/Logic Model of the client’s domain (business processes and/or analytic challenge). We use our Integrated Ontology Development Environment (IODE) and our team of Ontologists to build the Logic Model. The IODE can support large ontologies and data sets for testing.
Some important points:
- HIGHFLEET never starts from a blank sheet when creating a Logic Model. Our systems have a base model, a mid-level model, and specific modeling that can be re-used. This jump starts the creation and considerably shortens the time needed to complete a project.
- Complex logic models can be created in relatively short times. Our tools, expert personnel, and aspects such as that in the first bullet accelerate model creation.
- The Logic Model can easily be extended. Extensions can be made in anywhere from an hour to a couple days.
- Unlike changes to a Data Model, extensions to our Logic Model will not break applications that use the Logic Model.
Typically, a Logic Model has four types of sources. (This is taken largely from our Case Study on machined parts diversion.)
- Subject Matter Experts’ pre-existing ideas. e.g. “A part which is sold online at too low of a price is likely diverted.” This and other expert knowledge was captured in the IODE, forming part of the Diversion Logic Model.
- Our logic and modeling discipline. e.g. What is a “part”? Is it a type of thing, like “M6-1.0 x 16mm Phillips Pan Head Metric Screw” or a particular object in the world like “the M6-1.0 x 16mm Phillips Pan Head Metric Screw I bought from Home Depot in a package of 10 yesterday”? Although it seems obvious that these kinds of distinctions would be essential in a Diversion analysis—how else can you distinguish a diverted part from the legal part? Such necessary distinctions were not made in any of the data sources.
- Our analysis of the customer’s data. E.g. “Part prices vary with time, country of sale, and exchange rates.”
- Pre-existing models that we have here at HIGHFLEET. E.g. geographic model, event models, etc.
We encoded the information from each of these sources in machine-understandable logic using the IODE, creating a single Diversion Model. During this process we discovered that to fully understand the domain and the data, we needed to model not only the availability of parts online (the client’s original focus) but also the company’s supply chain practices and the social networking relationships between suspected diverters.
HIGHFLEET and the Wolfson School of Mechanical and Manufacturing Engineering at Loughborough University in the U.K. collaborated on an important project in engineering knowledge capture and re-use. This project made the knowledge of Design Engineers and Manufacturing Engineers available to both disciplines. Our XKS was used to house this knowledge and to provide a Reasoner for the model. This greatly decreases the time (and cost) from Design to Manufacture, while also removing errors. Such a Reasoning System is crucial to advanced work in Intelligent Manufacturing Systems (IMS) and Flexible Manufacturing. HIGHFLEET continues to be involved with Loughborough University and Industry Partners for Flexible Manufacturing and Intelligent Manufacturing Systems.
Loughborough U. built an ontology of machine parts manufacturing constraints that allowed parts engineers to evaluate the feasibility of their parts designs earlier in the design process. The School used our Integrated Ontology Development Environment (IODE) and our XKS deductive database system.
Previously, an entire component was designed and then sent to manufacturing for review. Manufacturing specified which parts would be impossible or impractical to build (e.g. requiring precision in excess of the manufacturing equipment’s tolerance or exceeding the dimensions the equipment’s capability) and revised the design. However, manufacturing lacked knowledge of the goals of the design, and their revised plans often failed to meet the project’s initial requirements. So engineering would further revise the design in an attempt to meet their original requirements, but introduce new violations of the manufacturing restrictions! This costly process continued for several iterations, each group having their own expert knowledge but lacking the complete picture necessary to complete the design.
An ontology capturing these manufacturing restrictions and other detailed knowledge solved this problem. Engineers upload their designs into the ontological system, which evaluates them against known manufacturing constraints. The ontology reports any violations and suggests modifications. The engineers use the system to tweak their designs to meet manufacturing constraints and requirements in an immediate, interactive fashion—before sending them to the manufacturing division for a final check.
Here’s an example rule from this ontology:
(=> (and (Groove ?g) (NeckWidth ?n) (hasParameter ?g ?n) (hasValue ?n (mm ?real1))) (inInterval ?real1 (interval in 8 12 in))) :IC hard "NeckWidth is out of range (8mm to 12mm)"
This rule indicates that to be manufactured on existing equipment, the neck of a groove must be between 8 and 12 mm wide. (The => symbol means “if-then” and the symbols preceded by question marks are variables. If there is a groove ?g with a neck width of ?n, the value of ?n measured in mm must be within the interval 8-12 inclusive. The “IC hard” message indicates what will be displayed to the user if he/she uploads a design that violates this integrity constraint (IC).)The ontology uses hundreds of such rules to capture the restraints of the manufacturing equipment, automating a costly and inefficient manual process. Because the constraints are recorded in logic that is separate from the procedural code that ingests the uploaded designs, they are easy to modify as the manufacturing situation changes.
What an Ontology is Not.
The instances in the list below are so pervasive that it is useful to address these misapprehensions.
- A list of words - seriously, I know of government programs that pretty much have people making lists of words and calling it an “ontology”. The list of words is preceded by “OWL Class”. I guess it’s the class of things found on planet Earth. Vendors are paid a lot of money to do this. The government gets . . . a list of words.
- A magical artifact - the idea exists, I don’t know its origins, that if you can just get your hands on an “ontology” it will solve your data access and sensemaking problems. When such an artifact, or something its creators call an ontology, more likely a list of words or at most a taxonomy, imperturbably fails to do this, the recipient is disappointed and angry. An ontology, even the real ontologies HIGHFLEET produces, is just a text file. You can print it and put it on the bottom of your bird cage. It will then do something. If someone convinced you that you “just need an ontology”, then you’ve been flimflammed, er, misled.
- A taxonomy - this is a step up from some “ontologies” but it isn’t very useful. All ontologies contain a taxonomy, but this a case of necessary but not sufficient.
- A “controlled vocabulary” - There is an effort in some circles to get everyone to use the same words. Good luck with that. While this is useful in some constrained applications, getting vast enterprises or organizations to do this is not useful. One feature of a real ontology is that we don’t care about the words; we care about meaning in context. So the effort to impose the same “controlled vocabulary” on all and sundry can be misguided and unnecessary.
- An end in itself - back to “magical artifact”.
- An artifact constructed by someone who was a file clerk a day ago - a lot of government projects, thinking that more is better, staff up with “Ontologists” who are essentially untrained personnel who know that a dog is kind of mammal. When asked to “dog the hatch” on a ship, they are flummoxed. Or worse, to puzzle out issues of temporal logic, or mereology. HIGHFLEET takes the Discipline of Ontology very seriously. Our Ontologists have degrees that emphasize mathematics, logic, computer science and rigorous philosophy. An Ontologist has to be able to capture complex knowledge in a rigorously correct form. This is not a trivial exercise. There is no ontology development tool that will make a bad Ontologist into a good one. In fact, most commercial ontology development tools only compound the problem, making it very easy to build a bad ontology. Ease of use by the unqualified trumps quality output.
Please contact us to discuss application of our SemFed and XKS to your needs.