One way humans deal with the problem is partitioning.  Think about it: If someone asks whether Ghandi was born after King Solomon, most people do not need to calculate or even know the dates.  They immediately know that King Solomon was in “ancient times” and Ghandi was in “the twentieth century”, and these blocks of time easy to calculate.  Unconsciously, time events belong to groups in our memory and the groups have time intervals and the intervals are deep in our memory framework (heavily pre-calculated).

To set this up, various groups of events (“births in ancient Greece”, “current events in 1949″, “stages of construction on the Hoover Dam”) are created with set time intervals, and their before/after relations are created (or implied). Some of the groups will overlap in their intervals. Events are put into those groups and within the groups, before/after relations are created (or implied) for each of events. This two-tiered system allows some of the events to be calculated by partition, as long as the two intervals are non-overlapping.  (There are other things that can be done with the overlapping intervals.)

Note that the exact time of the event does not need to be known.  In order to put this into a group, the group should have an known interval (“events in 1940″ has a definite time limit, even if the events in it were just definitely inside that year), but even the boundaries can be fuzzy (all “ancient roman times” were before “the 1800′s”).  In current events or project management, for instance, this gets important when tracking dialogs, news stories or other sequences, since the date it happened may be known, but the exact time when a specific part of the sequence happened is not – just what was before and after.  We humans do this all day long, every day.

To take advantage of this approach, however, you really need a different relation (“fast before/after” maybe) that uses these rules:

1. If the two events are in the same group, use the direct before/after relations.
2. If the two events are in the different non-overlapping groups use the relations on the group to determine the before/after relation.
3. Otherwise, things get more complicated and it may not be possible to say whether the events are definitely before or after each other. There are some smart approaches that can be applied, but they are not fast.

This can be done in rules inside the engine, but there is also the option of offloading the partition function. In SWRL, for instance, a custom built-in function could be defined to offload some of this functionality into a relational database.  Relational databases can take advantage of indexing to speed up the queries in each of the first two steps.  This is especially true if you have a lot of highly interconnected events in a group, such as in long-running dialogs, stories or meeting notes.  If you are doing knowledge engineering, this could be an index of subject matter expert interviews, for instance.

As loose as these groups may be, even with fuzzy intervals, they can dramatically cut down on the amount of events that need to be considered in a query, so they can allow knowledge bases to get an order of magnitude larger when applied properly.

For example, history is full of births and geneology (kings and emperors, for instance).  Births are instants, even if the date is not known, and geneologies are sets of relations between births.  If dates are known for a birth, then they can be attached to the birth event.  This part is simple.

However, there is also general understanding that rules apply to the sequence of time events.  For instance, a person cannot be born before his parents (either of them).  This is also transitive, so it would apply to grandparents as well, and so on.  Prior (see reference in the previous entry) lays out a fairly comprehensive logical system for representing relative time and operators which covers the representation of before, after and so on.  If these rules are applied in a birth and geneology ontology, then they would also have to be repeated in many other time-based areas where relative sequences were used (project planning, development, speech, news casts items).

To avoid this, intermediate or upper ontologies can be used to hold the rules and general relations, then application areas can state sub-property relations to “inherit” from the general ontologies, allowing rule reuse.

Using Owl-Time as a base ontology, say a new ontology is defined which defines the following rules (SWRL presentation, sort of):

@prefix time: <http://www.w3.org/2006/time>

time:Instant(?t1), time:Instant(?t2), time:Instant(?t3), time:before(?t1,?t2), time:before(?t2,?t3) -> time:before(?t1,?t3) .

time:Instant(?t1), time:Instant(?t2), time:Instant(?t3), time:after(?t1,?t2), time:after(?t2,?t3) -> time:after(?t1,?t3) .

Pretty simple stuff, of course.  Any serious ontology would also include combinations of time:Interval and time:Instant and there are a number of more interesting axioms in Prior’s paper that could be stated as rules in the ontology.

In the Births and Geneologies (gen:) ontology, these concepts and rules would be inherited and extended.  The primary concept is gen:Person, which could have a birth property, but to take advantage of the existing types, births are stated as a type of time:Instant and related with an object property (gen:birth).  The basic relation between children and parents might be gen:parentOf (with sub-properties gen:motherOf and gen:fatherOf, normally).  If relative time is an issue for the application, a rule can be stated thus:

gen:Person(?child), gen:Person(?parent), gen:birth(?child,?t1), gen:birth(?parent, ?t2), gen:parentOf(?parent,?child) -> gen:before(?t2, ?t1).

When this rule fires, the system will know that parents birth dates are before their child birth dates, and thanks to the upper-level ontology rules that work on time:Instant, the same will be true of the grand parents and great-grand-parents.

Of course, if the system is capable of running simple rules like this (and that is a stretch at the moment), the above rule will lead to an exponentially growing set of assertions about dates.  If you give 10 kings (just a paternal line), the last will have 9 assertions, the one before will have 8 assertions and so on.  Considering that other “interesting” relations and rules may have been added at the upper-level time ontology and that this is only one small dimension that might be needed in even a basic geneology knowledge base, this will be a serious scalability issue.

Normally, a historical application would need to have more than a single line of rulers, and a typical question might be “Who else was alive during his lifetime?”  To answer concurrency problems in history, there is no choice but to keep these relations. How can this be improved?

• Prior, A. N. (1971). Recent Advances in Tense Logic.  In E. Freeman and W. Sellars (Ed.), Basic Issues in the Philosophy of Time, The Open Court Publishing Co., La Salle, Illinois.

Many systems have been proposed over time for dealing with Time.  Pat Hayes published a good summary of the various theories that were in use in 1995 in his A Catalog of Temporal Theories.  Among other things, this catalog includes his breakdown of major types of Time covered by the current theories.  Some of the common notions that are really important include:

• Calendar Instants (Absolute Timestamps) and Intervals - These concepts represent a known point in time relative to an absolute time frame, such as the Gregorian Calendar (“June 23, 1883 at 3:05 pm in the afternoon”).  The issue of whether a time like this is an instant or a duration depends on the practical usage of the term, for knowledge workers, if not philosophers. There are large and rich systems of relations between intervals and times (before, after, during, ending at the same time).
• Recurrent Instants and Intervals – Whether in absolute time or not, there are applications that need to record recurring times for rules (“closed on Sundays”), schedules (“Conferences held yearly”, “Meeting recurs every Tuesday at 8:30 am”) and so on. A related notion is the use of relative times in scripts (“Bring to a boil for 5 minutes, then turn to minimum and simmer for 10 minutes before serving.”).
• Durations - A duration is a length of time (with or without a related absolute start and end time), such as “The half-life of Thorium”.
• Units of Time – Aside from time frames like Gregorian time, the units used to measure time are also an area of concepts, like “Second” and the conversions between units.

These are common and basic, but like all foundational concepts, they build into larger concepts, like Events, Schedules, Scripts and Change Management Processes, all of which are crucial in knowledge base construction (or DB Schemas).  Likewise, dozens of critical relations exist between the basic concepts, like before, after, occurs during and so on.

So, naturally, most of the Upper Ontologies discussed earlier devote a portion of their content to ideas of Time and its relations. SUMO, for instance, has dozens of time concepts high in its class heirarcy.  There are also widespread domain-specific ontologies that deal with time, notably the OWL-Time ontology.

In most information systems, the Calendar Time concepts are the most important. They represent times elements in logs, financial transactions, historical events, meeting dates and many other domain concepts. Most ontologies that represent times support both atomic timestamps and “exploded” time formats.  Atomic formats are compact, such as the XML date-time type, which represents a time and can be compared to another date-time.  “Exploded” formats break the various elements (year, month, day, hour…) into attributes of the Timestamp concept, which allows partial representations (“Thursday” of any week), unit conversions (the number of seconds between two dates in 1993) and other more complicated operations. Both of these can be interchanged when convenient in an application.

In the next few entries, I will look at some of these concepts.

At several points, I have compared SQL to the W3C language stack and one of the capabilities in SQL that was awkward in the OWL/SWRL combination was the lack of a way to construct complex results (such as blank nodes and new sub-graphs) in the way that SQL can do with its data manipulation language.  Ideally, we want to be able to do all with the new stack that the older relational languages could do and without needing to leave the session (all in the same script).

As I was reviewing SPARQL, the W3C query language, I came across the CONSTRUCT query type.  This allows a query to create a new graph (group of triples) constructed from the data in the triples.  I am starting to look at this as a possible way to get around the issue.  It appears that if OWL/SWRL takes care of making the logical inferences, the facts can then be gathered and re-formed into a new “shape” using SPARQL CONSTRUCT queries.  The problem is that while OWL/SWRL live in the session, SPARQL really lives outside, in the sense that the SPARQL query is initiated externally to pull information from the knowledge base or working memory.  If this knowledge was needed in the session, it would need to be pulled, then reinserted by some external process.

Since the topic right now needs to do work with existing ontologies, new object construction will be an issue. I need to be able to take data in one OWL schema and construct equivalent objects in types of a new ontology.  One project that will probably come up is converting existing data to an upper ontology (such as SUMO) and this is sure to come up.

As with any part of the stack, having it work on a given platform is always in question.  It will need to be tested. To do the project above, I am creating some convenience modules in JAVA to let me construct an ETL process for OWL data (much like the loader components I would use with a SQL database or XML with ESB components).

Back to Ontology again.

• Domain-Specific Ontologies (DSO) – Domain-specific ontologies define groups of concepts about a particular area of interest. These are defined by subject matter experts who use the definitions.
• Upper Ontologies (UO) – Upper ontologies try to define the universe of concepts at a very abstract level. Instead of describing concrete types, they concentrate on notions like Binary Relations and Temporal Entities. They are not directly useful for defining concrete concepts. Instead they are used to relate more concrete concepts by giving designers a set of high-level classifications for objects. The intent is that if they are used for a large number of DSO’s, they will enable rich inference across domains, allow data interchange and save everyone the effort of figuring out the basic concepts to use. UO’s are generally defined by philosophers and can have a heavy learning curve.

A list of some of the available UO’s is:

For further information on these ontologies, you can look at the web sites. Also, here are a few of the references I have used:

• Salim K. Semy, Mary K. Pulvermacher, Leo J. Obrst. (2004) Toward the Use of an Upper Ontology for U.S. Government and U.S. Military Domains: An Evaluation
• Viviana Mascardi1, Valentina Cordì1, Paolo Rosso2. (2006) A Comparison of Upper Ontologies

My recommendation? Choose one, it will save you time and extend the usefulness of your design. However, be prepared to commit some time to learn how the concepts work. If you are doing serious work with ontology in general, it helps to have a design strategy and a UO will give you that.

CYC is notable, not only because it is HUGE, but because it is comprehensive and has an excellent system of Micro-Theories which allow a federated approach to dealing with ambiguous and mismatched knowledge domains (fungus in medicine versus fungus in botany, for instance). However, it is bound to the proprietary CYC engine which makes interchange difficult.

One of the seriously important thing about CYC is that it has an excellent tutorial system. These documents cover a number of topics, including their use of events and time concepts. Anyone starting on ontology work should go through these materials.

I had to choose one a few years ago, so my choice was SUMO. I support it because it had been available for a while and is fairly comprehensive, but more because I am familliar with it at this point. I don’t think it is necessarily the best, but it is more than enough for the work that I do. I will expand on it in some of the discussions ahead.

First of all, the W3C languages (OWL/SWRL/RDF) are not the only language group that can be used for serious Ontology work.

• KIF was created in the 1990′s and had several variants, including SUO-KIF, a version currently in use on the SUMO project.  KIF is logic in a LISP-like syntax and is quite easy to learn and expressive. One thing it lacks is RDF’s partitioning (KIF has a single name space, so the names tend to get long for disambiguation).
• MELD, the language used by CYC and the open source OPEN-CYC (a publically released spin-off project which contains a subset of the full CYC product).  This is another LISP-like language with several extensions to support the special inference capabilities of the CYC engine.
• Common Logic is an upcoming ISO standard language for logic.  Like RDF, it comes in several syntaxes.  Common Logic Interchange Language (CLIF) is a LISP-like syntax (which just proves that computer scientists seriously love their nested parenteses). However, there are other syntaxes such as CGIF (Conceptual Graph Interchange Format), XCL (XML-based notation for Common Logic) and CLCE (Common Logic Controlled English).  The latter is significant, because it represents a trend towards natural controlled languages for specifying logic (also see SBVR and ACE).

For now, I am sticking to OWL/SWRL, but CLCE and others like it are serious enticements.

So, what next? Here are some important areas that look interesting:

• Existing Ontology Standards – There are literally thousands of published standards available on the web.  Take a look at SchemaWeb or Swoogle. There are a few, though, that have been especially well crafted and have gained wide acceptance. These are important because when doing Ontology work, it is better not to start from scratch every time a project starts.
  • Upper Ontologies – These try to be act as universal definitions of everything. Generally, they are abstract and are meant to be the core to which other ontologies (domain-specific) link terms, allowing all the linked into a single world-view and be able to do cross-inference.
  • Domain-specific Ontologies – There are a number of well-accepted standard ontologies for things like various kinds of time, standards, spatial relations and so on.
• Semantic Design Patterns – What is the best approach to representing various kinds of knowledge domains?  While the whole SW effort has been directed almost exclusively at tools and languages, very little work has been done on exactly what and how all this knowledge should be constructed.  Fortunately, philosophers have been arguing these fine points for centuries.  So what approaches are good?  Some areas to examine:
  • Space - There are many ways to represent space (volumes, cartography, grids), ways to measure space (units) and relations in space (topological, compass directions, containment, touching regions, mereology).
  • Time - There are many types of time, measurement systems for time and relations in time.
  • Events (what/where/who and so on) – How to represent things happening sequentially in space and time.
  • Narrative and reification – This covers notions about statements, including who believes them, who said them and in which form, when they were said and whether they are still valid.  This is important in a number of areas, such as understanding narratives and tracking business requirements in systems engineering.
  • Solution Frameworks – If you have knowledge about a problem, how do you arrange the knowledge (“frame the problem”) so that there is a clear way to solve it?  It is amazing how much tacit knowledge is involved in “simple” high-school physics problems in mechanics can be to describe in a logical form.

So, the application was set up with timers and memory usage logging and three approaches were used:

• Files1 – The original file approach, where the ontology and rules were loaded into memory from RDF files, the file data was read in and added to RDF in memory, all results were inferred and the results were extracted.
• DB1 – The first database approach was to engage a Derby database (easy, in-process, portable and file-based) and a JENA ModelRDB model as storage, then the data was loaded into memory as before.  However, the files were simply loaded as in the first approach, then stored in the DB model.  This is intended to test whether the Pellet reasoner is doing any smart background saves while processing.
• DB2 – The second database approach uses the same DB Model for storage, but after the ontology and rules were loaded, the files and directories were loaded one at a time and for each, the inferences were done and stored to the DB model.  A commit was done at the end of each batch to flush to the DB so the transactions would not get too large.  This limits the amount of inference needed at each step, since all the previous inferences are already available as facts in the DB model.  If Pellet takes advantage of this, the amount of memory usage should drop drastically.

For each run, a set number of files and directories were read.  The number of files is not an exact measure, since on an average, files and directories use different amounts of data, but overall, the average should show a reliable trend.  Likewise, the measure should have been in triples, but this also should not affect the trend much.  At the end of each run, the database was dumped so each run started from scratch with an empty database.

The results are shown in the following two charts.  The first is the memory chart, where the vertical axis is the number of Megabytes allocated by the JVM by the end of the run (Runtime.getRuntime().totalMemory() – crude, but indicative) versus the number of files scanned.

Some notes about this:

• The first approach (“File1″) simply loaded all the file data, ontology and rules into memory, did the inference and extracted the complete results.  Memory rose quickly and exceeded the limits of the machine very quickly.
• The second approach (“DB1″) showed a similar result, which is not surprising if Pellet is doing exactly the same thing and really only stores the results at the very end when the model changes are committed.  This approch does not gain anything.
• The third approach (“DB2″) which commits frequently, reducing the inference results to base facts in the DB model and avoids doing large numbers of inferences shows much better results.  As a matter of fact, it is almost flatline – which is good for applications that need to scale.

Another thing to note (which is not really seen in the chart) is that the file approach starts out at almost zer0 when the input data is small (important for small applications – if anyone actually has that luxury…).  However, both DB approaches show a minimal baseline above zero, which if you have the actual data, works out to about 12 MB.  This means that the DB model itself is initially taking a constant amount of memory.  I am not sure if that would be repeated for each triplestore used, so it is good to keep in mind.

The time plot is shown below for the same data, where the vertical axis is time in seconds for the given number of files to be read.

Some things to note here:

• The database is deleted between runs, so a minimal overhead is incurred while JENA sets up the triplestore tables in Derby.  That appears to work out to about 14 seconds.
• The DB1 results are worse overall than the File1 results.  This can be explained by the extra time needed to store the inference results at the end of the run when using the DB1, whereas the File1 approach was able to do a quick file dump.
• The DB2 times (subtracting the DB initialization) rose much less rapidly than the other two approaches.  As expected, this approach is far more efficient and scalable.  However, it is not a proportional improvement, since Pellet still has to load a lot of data from the store in order to do the inference.

I do not know the internals of Pellet and its usage of the JENA ModelRDB for triplestores.  There are a lot of potential variables even in a simple example like this and results could vary widely from application to application.  However, it does give some indications that can be useful for planning.

(This last bit is important.  I have been trying a number of engines lately and aside from Pellet and Hermit, I have not found any engines yet that are providing good support for SWRL. I will publish any positive results I get with other engines in future issues. It is irritating to me, though, that given the importance of rules in inference, five YEARS after it became the only widely accepted standard, SWRL support is still limited to a few players.)

Hermit is another Java implementation and it is bundled into a single JAR file, which includes a version of the OWL-API, so it is quite easy to include in projects.  If you need sample code for setting up Hermit, you can get details from the Hermit site above or you can grab a copy of the Hermit test code from the SWRL Test Suite.

The tests are not comprehensive, but they hit most of the areas I needed in my latest development work, so they should at least be a good source of samples.

Currently, they are available by anonymous SVN access from the site:

• http://semwebcentral.org/projects/swrl-test-suite/

If you have any trouble with them, log a question on the help forum on the site. I hope it helps.

Since in this example, it will be difficult to know how many files will be imported in a batch, scalability becomes an important issue.  If the number of files in a batch (for whatever reason) just happens to get near 1000, the inference will fail.

Some common suggestions:

• Increase Memory – “Memory is cheap” is a very common response when this issue is raised.  It can be a fast fix in a pinch. However, most industry people (system architects, for instance) will shoot this down immediately for a number of reasons.
  • No matter how much memory you throw at a solution, if the input is unbounded, eventually there is a risk that the new limit will be reached (unexpectedly).  Normally this will happen during a demonstration to upper management …
  • “Real” applications (enterprise, commercial) have to share resources in an infrastructure and are expected to behave nicely. Resources like memory are frequently shared with other virtual servers (VM’s) in the same way as disk space is on a SAN, and processor speed is trottled by server.  Even if an application has “full access” to a server of it’s own, when it is deployed to production, there may be new limits on what it can use.
  • While this application is mostly dealing with single-thread batch processing, most rule applications in an infrastructure are dealing with any number of concurrent threads.  If all of those threads have unbounded memory, no amount of memory would be safe.
• Tune the Engine – In any rule (or knowledge) base, there are features of the engine that can be turned off to conserve resources.  (Try the information in the Pellet FAQ for instance.) Optimization is good in any application, especially if the gains are good. However, no matter how much you tune the engine, if the number of instances coming into the application is unbounded, eventually a spike in the number of input instances will hit the magic limit.
• Process a Fixed Number of Files – Typically, a rules application will look at a single case at a time and process the results.

It really depends on the application, of course. Research applications (and heavy-AI applications in general) are frequently given more resources than typical enterprise applications.  Tuning and a set limit on input instances is usually possible.

In this case, the chosen approach is to use the third option.  To do this, one approach is to merge the file scanner part of the application into the classification step, load a copy of the file ontology (OWL and SWRL rules) as a base ontology, and for each file or directory found:

1. Assert the file information (name and so on).
2. Run classification.
3. Extract the results and act on them.

This kind of issue pops up frequently, so we will be dealing with it again.