Chunking a Timeline

So, say you have the case in the last entry and an exponential number of event before/after relations.  Either you pre-calculate the entries, which uses lots of space but minimizes the query time) or you leave it up to the engine to run the rules in real time (in which case even the smartest engine will need to calculate a huge pile of inferences at query time).  One way or another, the rules need to get fired and for even a medium-sized database, this could make operations crawl.

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.

Advertisement