The Whiteboard

In 2013 marijuana became legal in Colorado and Washington. It did not escape the notice of our clients that all Semantic Arts staff are from those two states. Suspicions grew deeper when we told them about the large collaborative knowledge base called Freebase. The looks on their faces told us they were thinking about freebase.   We were but a whisker away from the last straw on the day we introduced them to the idea of degeneracy.  “No, no we insisted, we are talking about a situation that commonly arises in mathematics and computing  where something is considered to be a degenerate case of something else”.  That was a close call;  fortunately, all that confusion was “just semantics”.

Today we explain the idea of degeneracy and why it is useful for computing and ontology.

Figure 1: Examples of Degeneracy

Examples of Degeneracy: A circle is defined to be the set of points that are equidistant from a given point. The radius of the circle is that distance.  But what do you have if the radius is zero?  You have the set of points that are zero length from a given point, which is to say just that one point. In mathematics we would say a point is the degenerate case of a circle.

We all know what a rectangle is, but what happens if the width of an otherwise ordinary rectangle is zero? Then you just get a single line segment.  Again, we say that a line segment is a degenerate case of a rectangle.

A set normally has two or more members, otherwise what is the point of calling it a set? Yet, the need for speaking of and representing sets that have 0 or 1 elements often arises. It happens so frequently that they have names:  empty set and singleton set.  They are degenerate cases of a set.

An example of a more complex structure than a set, is a process that consists of any number of tasks, and some ordering indicating what tasks must be done before what other tasks.  However, sometimes, during computation or analysis, it can be convenient or even necessary to allow for processes that have zero tasks, or just one task.  We could refer to such processes as empty or singleton processes.  These are degenerate cases of a process that ordinarily should have two or more tasks.

What do all these examples have in common? What can we say about every case of degeneracy?

Definition

I propose the following as a working definition of degeneracy.  We say that an X is a degenerate case of a Y when:

1. Strictly speaking, an X can be seen to be an example of a Y
   1. a point is a circle with radius equal to zero
   2. a line segment is a rectangle with one of the dimensions having zero length.
2. An X is substantially simpler than a Y, some of the essence of being a Y is missing.
3. The much simpler nature of an X results in the X having lost so much of the essence of being a Y, that in most circumstances, no one would even think to call the X a Y. Ordinarily:
   1. no one would think to refer to a point as a circle.
   2. no one would think to refer to nothing at all as a set.
   3. no one would think to refer to doing a single thing (much less nothing) as a process

Figure 2: Number units as Degenerate Units of Measure

Why bother?

It might seem rather silly, or something that only mathematicians would bother about, but it turns out that in computing, degeneracy is very important.  Let’s say you want to compute the average of an arbitrary set of numbers. In every day parlance, it makes no sense to speak of the average of a single number. However, you want your algorithm to work if you get a set that happens to only have one number in it.  You therefore want to be able to pass the algorithm a set with one element in it.

When processes are being executed, tasks are being done, so a set of tasks may dwindle down to one and then to zero. If you want the algorithm to work, it needs to understand what it means to have a process with 1 or zero tasks.  When there are no tasks left, the task is to do nothing. Sometimes it is even helpful to consciously put a ‘do nothing’ task in a plan or process.

Generally speaking, degenerate cases are useful when you want computational infrastructure to still work on the edge cases.

The most interesting example that I have seen of this in the context of ontology work arises in the context of doing unit conversions for physical quantities. For example, you convert 4 cm meters using a conversion factor of .01.  You convert 3 kg to grams by using a conversion factor of 1000.   We have an ontology for representing such physical quantities with units and conversion factors.  Using this ontology, we have code to do units analysis and computing conversions.

It turns out to be convenient to give pure numbers ‘units’ just like we give physical quantities units. For example, a wine merchant might sell cases with 12 bottles each. A unit of ‘dozen’ would come in handy, with a conversion of 12.  Another convenient number unit is percent with a conversion of .01.  To convert 250% to the true number, you multiply 250 by .01 to get 2.5. To convert 4 dozen to the true number, you multiply 4 by 12 to get 48.

The is completely analogous to converting 250 cm to meters, you multiply 250 by .01 to get 2.5 meters.  It turns out that you can represent pure numbers this way using units in a way that is exactly analogous to how your represent physical quantities like 4 cm and 5 watts. This means that the same code for doing units conversions on physical quantities with ordinary units also works for number units.  A pure number like 48 represented as a 4 with the unit ‘dozen’ is a degenerate case of a physical quantity such as ‘250 cm’.  Pure number units like dozen and percent are degenerate cases of ordinary physical units like cm or watt.

Go back and look at the previous section and check the extent to which pure numbers and number units fit the definition of degeneracy.

1. Strictly speaking a pure number like ‘4 dozen’ can be seen as a physical quantity, in the sense that it can be represented exactly like one, with a unit and a number.
2. Pure numbers are simpler than physical quantities because they are only numbers, very different from say 3 meters or 20 amperes.
3. No one would normally think to refer to a pure number like 4 or 48 as something that had a unit attached to it. The essence that has been lost is to have a unit that changes the character from being a pure number.  Number units like dozen and percent do not change the quantity from still just being a number.  4 dozen and 4 and 4% are all just numbers.  Whereas the difference between 4 and 4 cm and 4 amperes is huge.

For a detailed look at number units see the blog: Quantities, Number Units and Counting

As the Season to be Jolly gets into full swing, I reflect one of my favorite ways to be jolly:  laughter. What makes us laugh (or not) in a given situation?    Some people just laugh, like my mother, who regularly burst into gales of laughter, for no apparent reason.   The more puzzled our looks, the harder she laughed.   I dedicate this blog to my mom, who passed away just before Christmas a year ago.

What happened?

There are many things that can trigger us to laugh. It is often someone making a quip or writing/telling a story or joke with the intention to make others laugh.  Of course, such attempts often fall flat.  Conversely, sometimes things just happen that are found to be funny, and no one was playing the role of comedian.  The trigger event might be something that is unfolding live – perhaps just a stray thought that comes into your head.  Or you might be watching videos, reading, or listening to a podcast.  Or worse, the person next to you on a boring commute, earbuds in place, is doing so and laughing their head off.

Then what did you do?

So an event happens that comes into our awareness, and we outwardly respond to it in some way.  f we are not impressed, we may: grimace, groan, guffaw, blank stare,  or say “yark yark”.  On the positive side, reactions include: smile, chuckle, giggle, laugh, gales of laughter and falling over laughing. In extreme cases, each time you recall the event, in subsequent minutes, hours and days, you will again laugh uncontrollably. It could be weeks, months or even years before your response to merely remembering the original event fades back to a mere smile, or warm feeling inside.  See the diagram below.  Note the similarity to how gratitude was characterized in the Thanksgiving Blog several weeks ago.

Why did you do that?

What is interesting is not so much the trigger event itself, nor even what the reactions are: it’s what happens in between. What do we find funny and why?  First, we see or understand the thing that is [or is supposed to be] funny.  When the event is an overt attempt at humor, we call this ‘getting it’.   The next step is very personal; how much and why do we appreciate what we just saw or understood?  Many people that get a bad pun won’t enjoy or appreciate it in any way.   Other people may readily acknowledge that that same pun is pretty bad, but they giggle nevertheless.  Below are just a few thoughts that come to mind: patterns for things that contribute to being funny.

• We watch someone make mistakes, e.g. the Darwin awards are often uproariously funny. We will often laugh if somoen falls into a puddle, or at ourselves for say putting the left shoe on the right foot (er, the wrong foot).
• Plays on words, including the lowly pun as well as other more respectable forms of double entendre. For example: “The past, the present and the future walk into a bar. It was tense.”
• Something is startling, non-obvious, or the exact opposite of what we are expecting. This is not enough on its own to be funny, but often contributes. For example, did you hear about the guy who walked onto a train and saw Albert Einstein?  He asked Albert: “do you know whether Boston comes to this train”?
• Reference to an event that happened recently that is similar to what is going on at a given moment. Surprisingly, this can often be funny, all by itself, in the right situation, but it is hard to convey – you really do have to be there. Look out for it.

For the 2014 Season to be Jolly, you now have a simple conceptual model describing the main elements of laughter & amusement how they relate to each other.  In our business, we call this an ‘ontology’.   Sometimes the hardest thing is to come up with is a good name for an ontology.    The ones that first come to mind are descriptive, but boring – like Ontology of  Laughter (OoL) , or The Laughter Ontology (TLO).  Or if you want cool acronym, you might try Crafted Ontology Of Laughter (yark yark).   Alternatively,  the name you think of calls attention to itself by trying so hard to be clever it falls flat on its face, like “OnJollygy” (pronounced: on jolly jee).

Exercise for the reader:

1. Notice what just happened: a bad attempt at humor
2. Notice you own reaction to this proposed name
3. See how your own reaction matches with the elements in OnJollygy

For example, for me, this name just came as a random thought (trigger event).  Because I am total sucker for plays on words, I immediately enjoyed it and giggled with glee (reaction) – but the first person I told gave me a blank stare and the next one just grimaced.

Feel free to think I’m a bit weird.   I attribute this to genetics.  My mom never needed reason to laugh and my dad is a die-hard punster who wears a t-shirt that says:  “A Mature Pun is Fully Groan”.  His favorite was a quintuple pun involving lions, sea gulls and commerce – have you heard that one?

Whether you experience Groans,  Giggles or Gales of Laughter, may your Holidays be Jollily filled with Joy.

I wrote the following last year, and am inspired to share this more publicly, today, the Monday of Thanksgiving week, 2014.

It is Thanksgiving Day, 2013 and I just came across an article describing how science has tied gratitude to “the tendency to feel more hopeful and optimistic about one’s own future, better coping mechanisms for dealing with adversity and stress, [and] less instances of depression” among other things.

But what exactly is gratitude? And will all forms of gratitude give a similar boost to happiness? Examples range from a simple automatic thank you when someone opens a door for you, to a profound mystical experience where one may find oneself weeping in an alpine meadow of flowers surrounded by glacier-draped peaks.

An ontological analysis that I conducted in the last hour reveals the following essential elements of gratitude.

1. Person: the thankful one
2. Trigger Event: An event that triggers the person’s gratitude response
3. Gratitude Response: The expression of gratitude by that person in response to the event.

Here is a picture. The rectangles represent the key kind of things, the links indicate how they are related to each other.  Note that the person has to be aware of the trigger event in order for them to express gratitude in response to it.

Main Elements of Gratitude

In addition, every  gratitude response will have a certain form and a certain character.  The character of the gratitude response might be unconscious or conscious; if the latter, it might be at a thinking level without any real feeling, or it might be deeply felt.  A gratitude response will also take a certain form, e.g. returning a favor, a verbal or written thank you, or just an inner feeling.

This is what is essential, but there are various optional things too. For example, the trigger event may have been triggered by another person, or others may have had nothing to do with it (e.g. a rainbow). If the former, the triggering person may or may not have explicitly intended to benefit the thankful one. They may have just made an offhand remark that someone found value in, or written something in an article that had a great benefit to a reader who emailed a thank you.  In this example, the gratitude response was targeted at the author who triggered the response, but that would not always be the case. The thankful one may have just felt deep gratitude that the author never knew about.

Then there is the question of whether the gratitude response actually affected anyone.  The author might be pleased that a reader expressed gratitude, or they might not care, or they might not even see the thank you email.   Even the thankful one might not be affected, if their gratitude response is fully on autopilot (e.g. thanking one for opening a door).

Below is a diagram summarizing all the points we have raised about gratitude. It is essentially an ontology of gratitude. The dotted lines indicate optional links, the solid ones are necessary.

So how can we use this ontology of gratitude to pave the road to euphoria?  I speculate that the science on gratitude will show that the gratitude has to be felt to be the most valuable.  On Thanksgiving, we often go around the table and say what we are thankful for.  But does it really mean anything? Are we just saying it or do we really feel it?

This thanksgiving, I am thankful for my creative mind and that I have a job that pays me to do what I love: distilling the essence from a complex web of ideas. It is deeply felt.  There, I feel much better already!

Happy Thanksgiving

We humans are categorizing machines, which is to say, we like to create metaphorical buckets, and put things inside. But there are different kinds of buckets, and different ways to model them in OWL and gist. The most common bucket represents a kind of thing, such as Person, or Building. Things that go into those buckets are individuals of those kinds, e.g. Albert Einstein, or the particular office building you work in. We represent this kind of bucket as an owl:Class and we use rdf:type to put something into the bucket.

Another kind of bucket is when you have a group of things, like a jury or a deck of cards that are functionally connected in some way. Those related things go into the bucket (12 members of a jury, or 52 cards). We have a special class in gist called Collection, for this kind of bucket. A specific bucket of this sort will be an instance of a subclass of gist:Collection. E.g. OJs_Jury is an instance of the class Jury, a subclass of gist:Collection. We use gist:memberOf to put things into the bucket. Convince yourself that these buckets do not represent a kind of thing. A jury is a kind of thing, a particular jury is not. We would use rdf:type to connect OJ’s jury to the owl:ClassJury, and use gist:memberOf to connect the specific jurors to OJ’s jury.

A third kind of bucket is a tag which represents a topic and is used to categorize individual items for the purpose of indexing a body of content. For example, the tag “Winter” might be used to index photographs, books and/or YouTube videos. Any content item that depicts or relates to winter in some way should be categorized using this tag. In gist, we represent this in a way that is structurally the same as how we represent buckets that are collections of functionally connected items. The differences are 1) the bucket is an instance of a subclass of gist:Category, rather than of gist:Collection and 2) we put things into the bucket using gist:categorizedBy rather than gist:memberOf . The Winter tag is essentially a bucket containing all the things that have been indexed or categorized using that tag.

Below is a summary table showing these different kinds of buckets, and how we represent them in OWL and gist.

In a prior blog (SPARQL: Updating the URI of an owl:Class in place) we looked into how to use SPARQL to rename a class in a triple store.  The main steps are below. We showed how to do this for the example of renaming the class veh:Auto to veh:Car.

1. change the instances of the old class to be instances of the new class
2. replace the triples where the class is used in either the subject or object of the triple
3. look around for anywhere else the old class name is used, and change accordingly.

The last step addresses the fact that there are a few other things that you might need to do to address all the consequences of renaming a class.   Today we will see how to handle the situation where your instances use a naming convention that includes the name of the class.  Let’s say the instances of Car (formerly Auto) are all like this:  veh:_Auto_234 and veh:_Auto_12. We will want to change them to be like: veh:_Car_234.

The main steps are:

1. Figure out how you are going to use SPARQL string operations to create the new URI given an old URI.
2. Replace triples using the oldURI in the object of a triple.
   1. Determine where the oldURI is used as the object in a triple, and use CONSTRUCT to preview the new triples using the results of step 1.
   2. Use DELETE and INSERT to swap out the old triples with the new URI in the object.
3. Replace triples using the oldURI in the subject of a triple.
   1. Determine where the oldURI is used as the subject in a triple, and use CONSTRUCT to preview the new triples using the results of step 1.
   2. Use DELETE and INSERT to swap out the old triples with the new URI in the subject

In practice, we do step 1 and step 2a at the same time.  We find a specific instance, and filter on just that one (e.g. veh:_Auto_234) to keep things simple. Because we will be using strings to create URIs, we have to spell the namespaces out in full, or else the URI will incorrectly contain the string “veh:” instead the expanded form, which is: “http://ontologies.myorg.com/vehicles#”.

CONSTRUCT {?s ?p ?newURI}
WHERE {?oldURI rdf:type veh:Car .
       ?s ?p ?oldURI.
       FILTER (?oldURI in (veh:_Auto_234))
       BIND (URI(CONCAT ("http://ontologies.myorg.com/vehicles#_Car_",
                         STRAFTER (STR(?oldURI),"_Auto_")))
             AS ?newURI)
       }

This should return a table something like this:

This tells you there are exactly three triples with veh:_Auto_234 in the object, and shows you what the new triples will be when you replace the old ones.   After this, you might want to remove the FILTER and see a wider range of triples, setting a LIMIT as needed. Now you are ready to do the actual replacement (step 2b).   This is what you do:

1. Add a DELETE statement to remove the triple that will be replaced.
2. Replace the “CONSTRUCT” with “INSERT” leaving alone what is in the brackets.
3. Leave the WHERE clause as it is, except to remove the FILTER statement, if it is still there (or just comment it out).

Sample Graph of Triples

This will do the change in place for all affected triples. Note that we have constructed the URI from scratch, when all we really needed to do was do a string replace.  The latter is simpler and more robust.  Using CONCAT and STRAFTER gives the wrong answer if the string “_Auto_” does not appear in the URI. Here is the query to execute, with the simpler string operation:

DELETE {?s ?p ?oldURI}
INSERT {?s ?p ?newURI }
WHERE {?oldURI rdf:type veh:Car .
       ?s ?p ?oldURI .
       BIND (URI(REPLACE(STR(?oldURI), "_Auto_", "_Car_")) AS ?newURI)
       }

Step 3 is pretty much identical, except flip the subject and object.  In fact, you can combine steps 2 and 3 into a single query.  There are a few things to watch out for:

1. VERY IMPORTANT: make sure you do steps 2 and 3 in order.  If you do step 3 first, you will blow away the rdf:type statements that are needed to do step 2.
2. It is easy to make mistakes, backup the store and work on a copy.
3. When creating URIs from strings, use full namespaces rather than the abbreviated qname format.
4. Check the count of all the triples before and after each time you make a change, track down any differences.

Read Next:

• SPARQL: Updating the URI of an owl:Class in place

Background

We have been developing solutions for our clients lately that involve loading an ontology into a triple store, and building a UI for data entry. One of the challenges is how to handle renaming things.  If you want to change the URI of a class or property in Protégé you load all the ontologies and datasets that use the old URI and use the rename entity command in the Refactor menu.  Like magic, and all references to the URI are changed with the press of the Enter key.   In a triple store, it is not so easy. You have to track down and change all the triples that refer to the old URI. This means writing and executing SPARQL queries using INSERT and DELETE to make changes in place.  Below is an outline of how to rename a class.

Steps of Change

Let ?oldClass and ?newClass be variables bound to the URI for the old and new classes respectively – e.g. ?oldClass might be veh:Auto and ?newClass might be veh:Car.   The class rename operation involves the following steps:

1. Change all instances of ?oldClass to be instances of ?newClass instead. e.g.
   veh:myTeslaS   rdf:type   veh:Auto is replaced with
   veh:myTeslaS   rdf:type   veh:Car
2. Find and examine all the triples using ?oldClass as the object.  It may occur in triples where the subject is a blank node and the predicate is one of the several used for defining OWL  restrictions. E.g . _:123B456x78  owl:someValuesFrom   veh:Auto
   Replace triples with the old class URI in the object with new triples using the  new URI. Note, you might want to do the first part of the next step before doing the replace.
3. Find and examine all the triples using ?oldClass as the subject. It may occur in triples for declaring subclass relationships, comments as well as the triple creating the class in the first place. e.g. veh:Auto   rdf:type   owl:Class
   Replace triples with the old class URI in the subject with new triples using the  new URI.
4. Look around for anywhere else that the old name may be used.  Possibilities include:
   1. If your instances use a naming convention that includes the name of the class (e.g. veh:Auto_234)then you will have to find all the URIs that start with veh:_Auto and use veh:_Car  instead.  We will look into this in a future blog.
   2. The class name may occur in comment strings and other documentation.
   3. It may also be used in SPARQL queries that are programmatically called.

Here is some SPARQL for how to do to the first step.

# Rename class veh:Auto to veh:Car
# For each ?instance of ?oldClass
# Replace the triple <?instance rdf:type ?oldClass>
#               with <?instance rdf:type ?newClass>
DELETE {?instance rdf:type ?oldClass}
INSERT {?instance rdf:type ?newClass}
WHERE  {BIND (veh:Auto as ?oldClass)
        BIND (veh:Car as  ?newClass)
        ?instance rdf:type ?oldClass . }

Gotchas

There are many ways to make mistakes here. Watch for the following:

• Having the DELETE before the INSERT seems wrong, fear not, it is just an oddity in the SPARQL syntax.
• Save out a copy of the triple store, in case things go wrong that are hard to undo.  One way to do this is to make all the changes to a copy of the triple store before making them in the production one. Do all the steps, make sure things worked.
• Make sure your namespaces are defined.
• Before you make a change in place using INSERT and DELETE, always use CONSTRUCT to see what new triples will be created.
• Think about the order in which you replace triples.  You can easily end up replacing triples in one step, that you needed to find the triples to replace in the next step.
• Always check the total count of triples before and after an operation that replaces triples. Generally it should be the same; track down any exceptions.  The count may be less due to duplicate triples that may occur in different named graphs.
• A cautious approach would be to first insert the new triples and on a second step remove the old ones.  I tried this and it did not work, it seems like a bug.  Throw caution to wind, and do the delete and insert at once. You have a backup, and once you get the hang of it, the extra step will just be extra work.
• It may not be possible to fully automate changes in comments and SPARQL queries that are used programmatically.  Check to see what needs to change, and what doesn’t.

What Next?

After you get step 1 working, try out steps 2 and 3 on your own, all you need to do is some straight-forward modifications to the above example.  Step 4 involves more exploration and custom changes.

In an upcoming blog, we explore one of those changes.  Specifically, if your naming convention for instances uses the class name in the URI then those instance URIs will have to change (e.g. from veh:_Auto_2421 to veh:_Car_2421).

Read Next:

• SPARQL: Changing Instance URIs

We’ve found ourselves working with D3(d3js.org) more and more lately, both for clients and for our own projects. So far we’ve really just begun to scratch the surface of what it can do (if you’re unfamiliar, take a moment to browse the examples). Despite our relative lack of experience with the library, we’ve been able to crank out demos at a wonderfully satisfying pace thanks to our decision early on to focus on creating high-level, DRY abstractions. Though there is a ton of flexibility and extensibility, D3 does seem to have a few broad categories of visualizations based around the shape of input data. The one we’re going to focus on here is the flare.js format, which looks roughly like this:

This format seems to be the basis of a large number of useful visualizations dealing with nested, tree-shaped data. The challenge is that in semantic systems it’s just not possible to construct a SPARQL query that returns data in a format anywhere near the “flare” example above. What you’re more likely to see something structurally very similar to this:

So what to do? One path we could take is to write a server-side endpoint that returns data in the right structure, but this has the disadvantage of being less flexible, not to mention it spreads out concerns of the visualization layer wider than they need to be. The other option is to do the conversion on the front end. Rather than dive into writing a bespoke method to covert the specific data on hand to a format tailored to the visualization we want, why not take a step back and write a reusable abstraction layer? The end result, without giving too much away, looks roughly like this:

The advantage of this over D3’s built-in nest() method is that it will recursively construct n-depth trees from flat data, as long as the relationships are consistently expressed. This eliminates one of the major time-consumers in creating these visualizations–the data conversion in a reusable and flexible way. But why stop there? We created abstractions for various visualizations as well. Now, creating an icicle graph (like the one above) is as simple as:

This is still in the early stages of development so it’ll be some time before we release it to the public, but stay tuned.

Gist is based on something we call “concrete abstractions”

Most upper level ontologies are based on “abstract abstractions” that is, they are based on philosophical ideas that might be correct but are counter productive to try to convince business people and IT people what they are and what they mean.

We have taken the same posture as Google has with schema.org, most of our classes are classes of “concrete” objects. Watch the video to get an idea what we’re talking about.

Are you struggling with how to make best use of your company’s knowledge assets that have grown overly complex?  Have you wondered how to blend the more informal taxonomic knowledge with the more formal ontological knowledge?  This has been a real head-scratcher for us for quite a while now.  We described some breakthroughs we have made in the past couple of years on this front in a keynote talk at the International Conference on Semantic Computing in Newport Beach.

Ontologies and Taxonomies: Strange Bedfellows

Abstract:

In large companies, key knowledge assets are often unnecessarily complex, making them hard to understand, evolve and reuse. Ambiguity is at the root of the problem; it is often reflected in poorly structured information. We describe an approach using taxonomies and ontologies to root out ambiguity and create a set of building blocks that acts as a solid foundation for creating more useful structure.

We describe the challenges of working with both taxonomies and ontologies, and how we married them to provide a foundation that supports integration across a wide range of enterprise assets including spreadsheets, applications and databases.

Click here to view the presentation.

Written and presented by Michael Uschold

Read Next:

• Part 6: Definitions are even more important than terms are

In recent posts, we stated that while terms are less important than concepts, and they mean nothing from a formal semantics perspective, they are very important for socializing the ontology. The same is true for text definitions, but even more so. Just like terms, the text definitions and any other comments have zero impact on the inferences that will be sanctioned by the ontology axioms. However, from the perspective of communicating meaning (i.e. semantics) to a human being, they play a very important role. Many of the people that want to understand the enterprise ontology to will mainly be looking at the terms and the text definitions, and never see the axioms. Text definitions help the human get a better idea of the intended semantics for a term, even for those that choose to view the axioms as well. For those interested in the axioms, the text helps clarify the meaning and makes it possible to spot errors in the axioms. For example, the text may imply something that conflicts with or is very different from with what the axioms say. The text definitions also say things that are too difficult or are unnecessary to say formally with axioms. Other comments that are not definitions, but that should be included in the ontology include: examples and counter examples, things that are true about a concept, but that are not part of defining it. Collectively all this informal text that is hidden from the inference engine contributes greatly to human understanding of the ontology, which is on the critical path to putting the ontology to use.

Read Next:

• The Importance of Distinguishing between Terms and Concepts
• Part 2: Don’t let terms get in the way!
• Part 3: Concepts first, then terms
• Part 4: Identify the underlying concepts
• Part 5: Good terms are important for socializing the ontology