Ontology in Practice (1) : The Meaning of Data That Should Survive a System Change
Ontology in Practice series 1/4 · (1) The Meaning of Data That Should Survive a System Change · (2) Four Tasks Behind a Sewing Data Dictionary · (3) Finding Meaning in a Database Without Keys · (4) Letting AI Answer on Top of a Meaning Layer
KEY POINTS
A table is a container for data. What a value means in the business has to be defined outside the table if that meaning is to survive a system change. An ontology writes those definitions down as concepts (classes), individual objects (instances), values (properties) and connections (relations), and public standards such as RDF, OWL and SWRL express them in a form computers can read. SIJE runs its data systems by defining business concepts first, pulling the calculation rules hidden in reports and spreadsheets out into documents, and then having AI answer on the basis of those definitions.
Companies that replace their ERP run into the same problem. They hand the table specifications of their existing database to the new ERP vendor, and the answer comes back that the field names and units do not match, so the specification cannot be used for integration. From that point on, the people doing the work start getting questions like this.
“The table names have changed. Is our return still the same return as before?”
The short answer is that what changes is the way data is stored. Business concepts such as product, supplier, receipt, sale, return and inventory, and their definitions, have to stay the same. An ontology is a way of managing those definitions separately from the tables of any particular system, and SIJE runs its data systems this way. This series first covers the ontology technology that is publicly available, and then, over four parts, shows how SIJE has applied it to sewing data and to customer data.
The difference between a table and its meaning
A table holds data in rows and columns. Even for the same business concept, different systems can hold the data in different ways. The example below compares two ways of handling returns.
| Item | System A | System B |
|---|---|---|
| How returns are stored | A return flag is set on the original sales slip | A separate return slip is created |
| How returns are counted | Count sales slips with the return flag set to Y | Count return slips |
| Exchanges | Not distinguished | The return slip is linked to a new sales slip |
※ Example for explanation.
To put the return counts from the two systems side by side, you first have to decide which transactions count as a return and whether an exchange counts as a return. If that definition lives only in someone’s memory or inside report formulas, it disappears the moment the system is replaced, and it has to be worked out again from scratch in the new system.
Think of what happens when a city changes its street addressing system. The buildings stay where they are. What changes is the way you find them, yet the postal service, the land registry and the courier companies all have to reconnect the new addresses to the same buildings. Data works the same way. The business concept is the building and the table and column names are the address, so the list of buildings has to be kept separately if you want to reconnect them after the addressing system changes.
What an ontology is and what it is made of
An ontology is a model that organizes the concepts used in a field, and the relations between them, the way the people in that field have agreed on, and writes them down in a form computers can read.12 The academic definitions and the subway map analogy were covered in the last article of the Knowledge AI series, “How Measured Values Become a Company Asset“, so here the components are simply mapped to apparel supply chain data.
| Component | Definition | Apparel supply chain example |
|---|---|---|
| Class | A category of things of the same kind | Fabric, style, process, supplier |
| Instance | An individual object that belongs to a class | One fabric roll, one style number |
| Property | A value attached to an object | Fabric width, fiber content, standard process time |
| Relation | A connection between two objects | A style uses a fabric; a process belongs to a garment part |
Properties come in two kinds. Attaching a number or text to an object, such as a fabric width of 58 inches, is called a data property. Linking one object to another, such as a style using a particular fabric, is called an object property.4 The relations in the table are object properties.
Two kinds of relation
Relations are either taxonomic or non-taxonomic. A taxonomic relation is a parent and child relation meaning “A is a kind of B”, usually written isA. Non-taxonomic relations are every other kind of connection. Typical examples are partOf for parts, locatedIn for location and cause for cause and effect.
| Relation | Apparel supply chain example | Where it is used in data |
|---|---|---|
| isA (taxonomic) | Denim is a kind of woven fabric | When fabric runs short, finding substitutes within the same parent class |
| partOf (part) | The collar is a part of the shirt | Collecting processes and materials by garment part to calculate cost |
| locatedIn (location) | A production line belongs to a factory | Rolling up line output into factory capacity |
| cause (cause) | A cutting delay causes a delay in sewing input | Tracing the cause of a late delivery |
※ The relation examples are simplified for explanation.
With only taxonomic relations you get a well organized list. Non-taxonomic relations are what let you answer questions like “If this fabric is late, which process on which order gets pushed back?” The more your questions require following relations across several steps, the more it pays to organize data around relations rather than table joins.
Standards for writing meaning down: RDF, OWL and SWRL
Definitions left in documents that only people read are of no use to computers. That is why the web standards body W3C has published languages for writing concepts and relations in a machine readable form. The three best known are RDF, OWL and SWRL.
RDF (Resource Description Framework) writes every fact in three slots: subject, predicate and object. A set of three slots is called a triple.3 Think of it as breaking a sentence down into who, does what, to what.
(Style #S) --uses--> (Fabric #F)
(Fabric #F) --classified as--> (Denim)
(Denim) --subclass of--> (Woven fabric)※ #S and #F are placeholder numbers for explanation.
OWL (Web Ontology Language) sits on top of RDF and describes class hierarchies and constraints.4 A constraint is a condition the data must always satisfy. For example, if you state that every return slip must point to its original sales slip, you can automatically find return slips that are not linked to a sales slip.
SWRL (Semantic Web Rule Language) writes rules of the form “if these conditions hold, conclude this”.5 It takes the judgment a person makes in their head on the floor and splits it into conditions and a conclusion.
Condition: days left until the order's delivery date < days of production still needed
Conclusion: order status = delivery at risk※ An example to show the rule format.
Put simply, RDF is used to write facts, OWL to write structure and constraints, and SWRL to write judgment rules.
Three layers: data, logic and action
When you run a data system with an ontology, you divide what needs defining into three layers.
| Layer | What it holds | Apparel supply chain example |
|---|---|---|
| Data | Objects, properties and relations | Orders, styles, fabrics, processes, inventory |
| Logic | Formulas, judgment rules and forecasting models | Costing formula, delivery risk rule, output forecast |
| Action | Applying a judgment to business systems | Creating a purchase order, changing a work order, reassigning a line |
If you define only the data layer and leave the logic in report formulas, spreadsheet macros and people’s experience, then when the system changes and the results come out different, the cause is hard to find. Logic has to be tied to the defined objects and managed as documents, so that the same data produces the same judgment, and the basis for that judgment can be traced when it is turned into an action.
How SIJE runs its data systems
SIJE applies this technology to running data systems through four principles.
| Principle | What it means in practice |
|---|---|
| Define concepts first | Before looking at the table names in a customer’s system, we organize business concepts such as product, supplier, receipt, shipment, sale, return and inventory, and what each one means |
| Bring hidden rules into the open | We find the calculation rules buried in report formulas and spreadsheets, move them into rule documents and confirm their meaning with the customer |
| Leave definition documents behind | Separately from the software, we deliver data rule definitions as a deliverable, so the definitions stay with the company even when the system changes |
| Let AI answer on top of the definitions | We design AI to answer questions on the basis of the defined concepts and rules, not by guessing at table structures |
The reason for the fourth principle is simple. When the meaning, context and specific properties of the information in documents and data are defined in advance, the AI reads a document already knowing what kind of information to expect, so it is far less likely to connect the wrong column to the wrong concept.
SIJE’s sewing data dictionary is what you get when these principles are applied to sewing process data. So far, 47,359 standard processes have been organized in this dictionary. The next part covers the four tasks behind the dictionary: normalizing process names, mapping machines, giving styles coordinates and attaching statistics to each entry.
👉 Ontology in Practice (2) : Four Tasks Behind a Sewing Data Dictionary
Sewing Production Glossary
Ontology
A model that organizes the concepts in a field and the relations between them as agreed, written in a form computers can read.
Class / Instance
A category of things of the same kind / an individual object that belongs to that category.
Data property / Object property
A property that attaches a value to an object / a property that links one object to another.
Taxonomic relation (isA)
A parent and child relation meaning “A is a kind of B”.
Triple
The basic unit of RDF, which records a fact in three slots: subject, predicate and object.
Constraint
A condition the data must always satisfy, used as the test for finding data that breaks it.
References
- Thomas R. Gruber, A Translation Approach to Portable Ontology Specifications, Knowledge Acquisition 5(2), 199~220, 1993. Defines an ontology as an explicit specification of a conceptualization. ↩
- Rudi Studer, V. Richard Benjamins, Dieter Fensel, Knowledge Engineering: Principles and Methods, Data & Knowledge Engineering 25, 1998. An ontology as a shared conceptualization agreed by a group. ↩
- W3C, RDF 1.1 Concepts and Abstract Syntax, 2014. Definition of the triple made of subject, predicate and object. ↩
- W3C, OWL 2 Web Ontology Language Primer (Second Edition), 2012. Class hierarchies, data properties and object properties, and constraints. ↩
- W3C, SWRL: A Semantic Web Rule Language Combining OWL and RuleML, W3C Member Submission, 2004. Rules made of conditions and conclusions. ↩
