Knowledge Engineering for Historians/Print version

Preface

The following is a Wikibook textbook on how historians can leverage the technology of knowledge engineering in their work.

A Wikibook can be edited by anyone which wants to expand the usability and correctness of the work, however, please do not contribute any works that you do not hold the copyright to. If you find that this textbook is incomplete, feel free to fill in the blanks.

See also: The WikiBook on Artificial Intelligence and Historiography at Wikipedia.

Introduction

Introduction | Knowledge Engineering — A Primer | Modelling Historical Knowledge | Advanced Topics

Introduction

This wikibook is about how historians can leverage the technical contributions that the discipline of Knowledge Engineering has made to modern research in their own work.

How We Got Here

• historians are trying to take advantages of the technologies that computers have, but they have no money to fund any research
• the Internet and its search engines are a great help
• in the early 80s, in the heyday's of AI, it looked like expert systems would be the way to go, but then the AI winter hit before the historians could really learn how to build or use them
• the "Let's use Databases!" movement fizzled in the late 90s because it was not immediately obvious how to address the issues of semantics underlying the coding of the data
• with OWL, the knowledge engineering is getting back into the swing of things
• ontologies such as the Council of Museum's conceptual reference model indicate that the time has come to learn this valuable tool
• one history ontology is already available, embedded in VICODI, see also the paper by Richard Deswarte and Jan Ooesthook on their experience contributing to this effort, the ontology itself

Where we are going to go

• in the primer, we are going to
  • find out what the fundamental benefits derivable from knowledge engineering are
  • get an idea of what the various (freely) available tools offer

• in the basic round, we are going to
  • model some fundamental facts that historians need all the time
  • model some intermediate concepts, like sources and point of view

• in the advanced round, we are going to
  • model more difficult stuff, like temporal projections
  • consider modelling problems that involve shifting the resolution of the knowledge we are reasoning over

Primer

Introduction | Knowledge Engineering — A Primer | Modelling Historical Knowledge | Advanced Topics

Knowledge Engineering — A Primer

Introduction

• give links to good KE tutorials
• give links to good tools and their tutorials
• give links to the AI book here on wikibooks

Discussion Plan

1. The Basic Elements
2. The Composite Elements
3. Additional Infrastructure
4. Engineering Choices

Primer Basic Elements

The Basic Elements

Knowledge Engineering's basic tools are entities and relations.

Entities

An entity is something like a concept — e.g. the feudal system — or an individual — St. Peter's Cathedral, Charlemagne, etc. Some entities are timeless and self-denoting, like numbers or names; others have complex histories, like the two entities we just mentioned.

Before we look at some examples, a brief comment on notation: For the purposes of the examples presented here, we will notate entities with capital letters and relations with initial lowercase letters. And we will use double-semicolons — ;; — to denote comments in our representation; so anything that follows a double-semicolon mark to the end of that line is a comment and can contain arbitrary characters.

That said, let's look at some examples:

;; a couple of entities from the 4th century AD
Trier-RomanCity
ConstantineTheGreat
HelenaOfConstantinople

Here we have identified three entities: the Roman city of Trier, Germany; the 4th century AD Roman Emperor Constantine the Great; and his mother, the later Augusta Helena of Constantinople.

Relations

Definition and Arity

A relation is an entity in its own right (or at least should be) and is used to connect (usually) two entities together. More precisely, the number of entities that a relation can connect together is called the arity of the relation.

;; something about our entities
yearOfBirth(ConstantineTheGreat,272)
motherOf(ConstantineTheGreat,HelenaOfConstantinople)
residence(ConstantineTheGreat,Trier-RomanCity)

Assigning Type Information

While one might suspect that relations that connect two entities (so-called binary relations) be the most useful, there are indeed interesting uses for relations with an arity of one (unary relations), namely stating that an entity belongs to a specific class or type:

;; some type information about our entities 
male(ConstantineTheGreat)
female(HelenaOfConstantinople)
city(Trier)

Notice that not all ontologies handle type information this way; indeed, we could treat "maleness" as an entity in its own right and then use a binary relation to attribute this to emperor Constantine.

;; for those who dont like unary relations
is-a(ConstantineTheGreat,Male)
is-a(HelenaOfConstantinople,Female)
is-a(Trier-RomanCity,City)

The advantage of doing things this way is that concepts like city really feel like they ought to be entities in their own right. However, this is not true for all types. Indeed, some types look odd when treated as an entity:

;; which looks better? many think the first one does
red(MyFerrari)
is-a(MyFerrari,RedObject)

Some representation languages choose to not treat relations as entities in their own right (e.g. frame-based systems), and this imputes a preference for assigning type information with binary predicates. However, as we stated above, there is really no excuse for not treating relations as entities in their own right!

Arity: How Much is Too Much?

For some representation languages, the maximum arity of its relations may be an implementation dependent choice. This is defensible insofar as, theoretically speaking, it is always possible to construct the equivalent of an n-ary relationship using only binary relations provided on elevates the relationship itself to the level of an entity.

;; Henry VIII and his wives, using a 7-ary relation
hadAsWives(HenryVIIIofEngland,CatherineOfAragon,AnneBoleyn,JaneSeymour,AnneOfCleves,CatherineHoward,CatherineParr)

;; gets away with just binary relations
memberOf(TheWivesOfHenryVIII,CatherineOfAragon)
memberOf(TheWivesOfHenryVIII,AnneBoleyn)
memberOf(TheWivesOfHenryVIII,JaneSeymour)
memberOf(TheWivesOfHenryVIII,AnneOfCleves)
memberOf(TheWivesOfHenryVIII,CatherineHoward)
memberOf(TheWivesOfHenryVIII,CatherineParr)

This approach is sometimes called "Davidsonian Representation" after philosopher Donald Davidson, an issue we will discuss in more detail later. Of course, one might have tried the following, but that does not capture the commonality that these ladies (somewhat inadvertantly) shared in quite the same way:

;; uses a another binary relations
spouses(HenryVIII,CatherineOfAragon)
spouses(HenryVIII,AnneBoleyn)
spouses(HenryVIII,JaneSeymour)
spouses(HenryVIII,AnneOfCleves)
spouses(HenryVIII,CatherineHoward)
spouses(HenryVIII,CatherineParr)

For it would not allow us to attribute any information to the relation as such:

;; this is only possible by making the relationship itself an entity
nameOfTopic(TheWivesOfHenryVIII,"The Six Wives of Henry VIII")
themeOfTVShow(TheWivesOfHenryVIII,TheSixWivesOfHenryVIII-PBSSpecial)

Types of Relations

Now that we have seen a couple of relations, it is clear that they come in rather different flavors. Let's put some really different kinds and discuss what makes their differences:

;; some place information -- true though maybe not a deep insight
locationOf(Trier-RomanCity,Germany)  
locationOf(Trier-RomanCity,Trier-RomanCity)

Relations like locationOf are called reflexive; they have the property that they also (usually trivially) relate the first argument to itself. Not surprisingly, reflexive relations are always binary (what's the point in relating a thing to itself more than once?).

;; a bit of dynastic knowledge
childOf(HenryVIII,HenryVII)
childOf(MaryI,HenryVIII) 

These dynastic relations are the opposite of reflexive, they are irreflexive.

;; more generally speaking
descendant(HenryVIII,HenryVII)
descendant(MaryI,HenryVIII) 

With this example, the interesting property of the relation is that — without explicitly saying it — we know that Queen Mary I is also a descendant of king Henry VII (he is after all her grandfather). Such relations are called transitive, which means that the property that they are conveying can be transferred from one entity to another via an intermediary that they share relationship with. childOf for example is not transitive, or more technically intransitive.

;; more dynastic details
spouses(HenryVIII,CatherineParr)

The relation spouses is interestingly different from the other relations in that the argument order conveys no information. Such relations are called symmetric and that just means that one can write the arguments in either order without changing what one is saying. This is definitely not true for childOf or parentOf — here the argument order is critical.

Interestingly, there is a small group of relations that combine these three features — reflexivity, symmetry and transitivity — and these are called equivalence relations — possibly because equals is a classic example for one of these relations.

The features that type relations are not restricted to considering the relation alone; one can also identify features that relate two relations to each other.

;; another dynastic variation
husbandOf(HenryVIII,CatherineParr)
wifeOf(CatherineParr,HenryVIII)

This asymmetric variation on the marriage information is interesting because these two relations convey opposite views of the same information. We call such relations inverses of each other, because one needs to invert the argument position of the entities to say the same thing.

Primer Composite Elements

Composing the Basic Elements

So far we have been happily conflating a notion that we now need to tease apart. When we write ConstantineTheGreat, we are of course not writing an entity; the entity Constantine the Great is no longer among us and cannot be brought back by writing. Rather, we have been manipulating a term, namely the term with the unique character string sequence "ConstantineTheGreat", which is supposed to refer to Constantine the Great.

This is not hair-splitting, because once one has terms, it becomes obvious that multiple terms can actually refer to the same entity. (This also gives us a chance to show an equivalence relation in action!)

;; some examples (the first is a classic)
equals(MorningStar,EveningStar)  
equals(FirstWifeOfHenryVIII,CathrineOfArragon)

Functions — Dependent Terms

Sometimes an entity can be defined in terms of another entity. Indeed, if we look at the second example from the term introduction, it becomes pretty much clear from the term's name that this term is defined in terms of another:

equals(FirstWifeOfHenryVIII,CathrineOfArragon)

In knowledge engineering, this case is expressed via a function. A function is a composite term that denotes an entity in terms of one or more other terms (including self-denoting ones such as character strings and numbers). For example, we could rewrite the above example as follows:

equals(NthWifeOfFn(HenryVIII,1),CathrineOfArragon) 

Notice the notational convention of appending Fn and capitalizing the expression. The advantages of this approach are several:

• We now have captured additional information (namely the ordinal position) represented in the function rather snuck away in the name of a simple term. This is good because the programs we employ for knowledge representation are challenged when it comes to getting things out of names, but they do pretty well with arguments!
• We can now type self-denotating terms (which will allow us to undo a little cheat we undertook earlier):

;; typing dimensionless scalars
MeterFn(272)
;; or tying them to a convention 
YearFn(272,CE)
;; we can now do a more proper rendition of old Constantine
yearOfBirth(ConstantineTheGreat,YearFn(272,CE))

• Consider the alternative to having functional terms; if you were not happy with 272 by itself denoting both a distance and a year, then you would have to create simple terms for each one of them

;; a pointless exercise
..., TheDistanceOf271Meters, TheDistanceOf272Meters, TheDistanceOf273Meters, ...
..., TheYear271CE, TheYear272CE, TheYear273CE ...

Not all representation languages support this feature, though, and here is why: The power of flexibility comes with the price of now having a humongous number of terms in the language. This can introduce problems for the underlying reasoning system. Consequently, some representation languages prefer to keep this problem at bay by not supporting this feature. There, you have to work around the issue with relations and more complex statements.

;; a more complex way if you dont have functions
yearOfBirth(ConstantineTheGreat,?X) 
&& typeOfScalar(?X,Year)
&& valueOfScalar(?X,272)

Complex Statements

So far we had primarily looked at simple statements, but as the last example showed, by introducing some additional material, namely logical connectives and variables, we can say more complex things. The logical connectives that knowledge representation systems usually support are:

• the and operation, denoted here as &&
• the (inclusive-)or operation, denoted here as ||
• the unary negation operator, denoted here as ~

We also need to briefly talk about quantifiers, which specify constraints on variables. There are basically two flavors of quantifier: the existential quantifier, which says that there is at least one of this kind (there exists one, therefore existential); and the universal quantifier, which says that the following is true for all entities that satisfy the properties. Let's briefly reconsider our non-functional birth year of Constantine example:

;; we had basically treated existential quantification as assumed
thereExists(?X,
  yearOfBirth(ConstantineTheGreat,?X) 
  && typeOfScalar(?X,Year)
  && valueOfScalar(?X,272))
;; all birth years are years
forAll(?X,
 forAll(?Y,
  yearOfBirth(?Y,?X)
  && typeOfScalar(?X,Year)))  

Rules — Patterns of Relationship

Now that we know about complex statements, we can turn our attention to a whole variety of complex statements called rules. Rules are like being able to say many things at the same time; they state a pattern for making statements of specific type. This is not only a notational convenience, but allows one to make statements about entities that one has not even encountered yet. For example, the statement that all people have a mother is true for people that are not even born yet.

Notationally, we will use the implies operator, which takes a precondition and a postcondition (or antecedent and consequent), and states that if the precondition is true, then the post-condition is true also.

;; all people have a mother
implies(forAll(?X,person(?X)),
        thereExists(?Y,motherOf(?Y,?X))

Since the antecedent is implicitly universal, many languages permit to leave the forAll off:

;; with functional speak we get the veryt terse
implies(person(?X),motherOf(MotherFn(?X),?X))

Primer Additional Infrastructure

Knowledge Engineering for Historians/Primer Additional Infrastructure

Modelling Historical Knowledge

Introduction | Knowledge Engineering — A Primer | Modelling Historical Knowledge | Advanced Topics

Modelling Historical Knowledge

Now that we are clear on the basics of knowledge modelling in general, we can turn to our task proper at hand and consider the tasks historians face in their research and how to deal with them appropriately.

We first would like to look at a main concern of historians, the proper handling of sources. Historians are nothing without their sources and they contain the knowledge we wish to represent and utilize. We then turn to the problem of how to deal appropriately with the work of their colleagues, another key element to historical research.

However, in order to discuss this topic we need to introduce some additional infrastructure, namely the notion of contexts. We will explain why we need these contexts, how they work, and what kind of problems their use poses.

1. Introducing Contexts
2. Modelling Sources
3. Modelling Interpretations

Modelling Introducing Contexts

Introducing Contexts

Since this is a book for historians, we will mention that there is a a whole history of the concepts underlying the following discussions, that we will however not get into just now, because they do not contribute to an initial understanding.

The basic problem of knowledge engineering is that the logical theories that perform the actual reasoning cannot deal well with inconsistent or contradicting information (remember those exploding computers on Star Trek?). Unfortunately, the human theories that knowledge engineering models are often mutually inconsistent.

Enter contexts, which basically allow us to assign the individual statements to individual speakers.

Contexts as additional Arguments

Speaking more as the knowledge engineers we are trying to become, we can best explain contexts by introducing a new relation: let ist mean "is true (in context)".

;; the controversy surrounding Wolfang Amadeus Mozart's relationship
;; with Antonio Salieri represented
kills(AntonioSalieri,WolfgangAmadeusMozart)
not(kills(AntonioSalieri,WolfgangAmadeusMozart))

;; contextualizing the claims via ist
ist(Amadeus-TheMovie,kills(AntonioSalieri,WolfgangAmadeusMozart))
ist(Austria18thCenturyContext,not(kills(AntonioSalieri,WolfgangAmadeusMozart)))

While the first representation will clearly cause a contradiction, the second need not; indeed, the claims are nicely segregated into the different contexts. However, contextualization is an all-or-nothing proposition; either every statement is "curried" with a context, or none are. Typically, this situation is handled by identifying a base or default context where those things that are not sensibly contextualizable (i.e. shared by all contexts) can be placed.

Context Hierarchies

Contexts can be organized into subsumption hierarchies, just as we saw that type hierarchies can be.

Some of the background knowledge that our two contexts, Amadeus-TheMovie and Austria18thCenturyContext, share could now be moved into a parent context, say, GenericMozartFama or the like. Such movement of knowledge into other contexts is sometimes called lifting. Such an approach makes developing a new context very affordable: Most of what needs to be known has already been said in other contexts, which can then be simply subsumed in the new context.

Contexts are not First-Order-Logic

• explain why the first-orderization using arguments does not work

Reasoning into Contexts

A side-effect of the ist approach to context representation is that it is relatively straight-forwarded to reason into other contexts. For example the following query could be used to find all cases where the movie and the real life of Mozart differ:

;; get the points of contention
ist(?CONTEXT-A,?SENTENCE) 
&& subsumesContext(?CONTEXT-A,GenericMozartFama)
&& ist(?CONTEXT-B,not(?SENTENCE))
&& subsumesContext(?CONTEXT-B,GenericMozartFama)

Again, this is not a first-order logic query anymore, because we are no longer looking just at relations, but at whole sentences which include predicates. This is a higher-order query.

Some Notes on Implementation

Some representations languages, such as CycL are designed with strong assumptions about the availability of contexts; there they are called microtheories and have special implementation support in OpenCyc and other implementations for CycL. Many representation or reasoning systems unfortunately do not have explicit support for contexts. And because of the non-FOL needs, simulating contexts may turn out to be difficult.

Conclusion

After this short overview of what contribution contexts make to the reasoning in knowledge engineering, we are ready to go into a large example that will highlight all of the features we have discussed so far. The hope is that this will draw the disparate pieces together and give you an idea of how knowledge engineering for historians becomes actionable.

Without further ado, let's look at our modelling example, Modelling the Christmas Story (see also Christmas). }

Modelling Xmas Story

Modelling the Christmas Story

We will now user our knowledge engineering skillz to model the Christmas stories in Matthew and Luke that a historian can compare and contrast them.

Functional Prerequisites

Matthew and Luke want to show that Jesus of Nazareth is the Messiah. Matthew and Luke want to show that Jesus of Nazareth is the Messiah; this calls for our modal statement and projection microtheory setup.

In Mt: GospelOfMatthewIntentionMt. 
f: (beliefs (AuthorFn Matthew-BookOfBible) 
     (isa JesusOfNazareth Messiah)). 

In Mt: GospelOfMatthewMt. 
f: (isa JesusOfNazareth Messiah). 

In Mt: GospelOfLukeIntentionMt. 
f: (beliefs (AuthorFn Luke-BookOfBible) 
     (isa JesusOfNazareth Messiah)). 

In Mt: GospelOfLukeMt. 
f: (isa JesusOfNazareth Messiah).

From the Old Testament, specifically its prophecies, Matthew and Luke know that the Messiah has to be born in Bethlehem. From the historical life of Jesus of Nazareth, however, they also know that Jesus has to end up living his childhood in Nazareth — as his name suggests.

The Prophetic Precondition

The prophetic passage regarding the location of the birth is the prophet Micah 5:2:

'But you, Bethlehem, in the land of Judah
  are by no means least among the rulers of Judah;
for out of you will come a ruler
  who will be the shepherd of my people Israel.'

The prophetic passage regarding the virgin birth is in Isiah 7:14:

The virgin will be with child and will give birth to a son, and they will call him Immanuel—which means, "God with us."

The critical aspects that the two gospels amalgamate from these two prophetic passages can be represented as follows:

In Mt: MessianicPropheciesMt.
f: (implies
      (and
        (isa ?SON MalePerson)
        (isa ?VIRGIN Virgin)
        (isa ?B-DAY BirthingEvent)
        (birthChild ?B-DAY ?SON)
        (birthParent ?B-DAY ?VIRGIN)
        (locationOf ?B-DAY Bethlehem))
      (isa ?SON Messiah)).

The Historical Precondition

The basic problem is expressed by the following rule:

In Mt: FertileCrescentNamingConventionMt.
f: (implies
      (and
         (isa ?PERSON FamousPerson)
         (isa ?EVENT Childhood)
         (animateActedOn ?EVENT ?PERSON)
         (locationOf ?EVENT ?TOWN)
         (firstName ?PERSON ?NAME))
      (ist EnglishLexiconMt 
         (commonNickName ?PERSON (WordConcatenationFn ?NAME Of-TheWord ?TOWN))).
  

This rule explains Herodotus of Halikarnassos as well as it explains Jesus of Nazareth. Which means that the narrative of the childhood of Jesus has to be brought round to end up in the village of Nazareth in Galilee.

The Differences in the Christmas Narratives

Now we get into the individual differences between the two narratives as provided by Matthew and Luke. It will become immediately obvious that these two narratives could not co-exist in the same context of reasoning without inducing contradictions.

The Announcement of the Miraculous Birth

1. Who is the recipient of the announcement?
2. Does the announcement preceed the begin of the pregnancy?
3. Where and when does the announcement occur?

Constant: AnnouncementOfBirthOfMessiah.
In Mt: SharedNewTestamentMt.
isa: AnnouncingSomething.
ibtGenerated: BirthOfMessiah-IBT. 

Notice that the contents of the information bearing thing, the angelic message, would also be represented as a context of its own, a propositional information thing derived from the information bearing thing that is the announcement. While these announcements differ slightly, they are similar enough that for our current purposes we can use the following representational approach:

In Mt: BaseMt.
f: (genlMt (PITofIBTFn BirthOfMessiah-IBT) SharedNewTestamentMt). 
In Mt: (PITofIBTFn BirthOfMessiah-IBT).
f: (thereExists ?EVENT
     (and 
       (thereExists ?SON
         (isa ?EVENT Birth)
         (birthParent ?EVENT Mary-MotherOfJesus)
         (birthChild ?EVENT ?SON) 
         (isa ?SON MalePerson)
         (nameString ?SON "Jesus"))
       (startsAfterEndOf ?EVENT AnnouncementOfBirthOfMessiah)). 

Now we get to the meat of the differences. First, the recipients are different:

In Mt: GospelAccordingToLukeMt.
senderOfInfo: Gabriel-ArchAngel.
f: (intendedAudience BirthOfMessiah-IBT Mary-MotherOfJesus).

In Mt: GospelAccordingToMatthewMt.
senderOfInfo: (SomeFn Angel).
f: (intendedAudience BirthOfMessiah-IBT Joseph-FatherOfJesus).

Secondly, the temporal relationship to the pregnancy differs:

In Mt: SharedNewTestamentMt.
Constant: MiraculousPregnancyOfMaryWithJesus.
isa: Pregnancy.
physiologicalConditionAffects: Mary-MotherOfJesus. 

In Mt: GospelAccordingToLukeMt.
f: (startsAfterEndOf MiraculousPregnancyOfMaryWithJesus AnnouncementOfBirthOfMessiah).

In Mt: GospelAccordingToMatthewMt.
f: (startsAfterStartOf AnnouncementOfBirthOfMessiah MiraculousPregnancyOfMaryWithJesus).

For right now we will gloss over the fact that one of the announcements happened inside a dream (as they always do in the Gospel of Matthew), while the other happens in broad daylight in Mary's house (which presumably means in the house of her parents). But we can capture the fact that the announcements happened in the different cities:

In Mt: GospelAccordingToLukeMt.
f: (eventOccursAt AnnouncementOfBirthOfMessiah NazarethGalilee).

In Mt: GospelAccordingToMatthewMt.
f: (eventOccursAt AnnouncementOfBirthOfMessiah BethlehemJudea).

Establishing the Location of the Birth

1. What do Mary and Joseph have to do to be in Bethlehem?
2. Where does the birth take place?

We have already pointed out that according to Matthew, Joseph and Mary lived in Bethlehem all along, which in Luke they have to travel to Bethlehem, based on a census ordered by Roman emperor August.

In Mt: GospelOfMatthewMt.
f: (residesInRegion Mary-MotherOfJesus BethlehemJudea).
f: (residesInRegion Joseph-FatherOfJesus BethlehemJudea).

In Mt: GospelOfLukeMt.
f: (residesInRegion Mary-MotherOfJesus NazarethGalilee).
f: (residesInRegion Joseph-FatherOfJesus NazarethGalilee).

Constant: JourneyToBethlehemForCensus.
isa: Travel-TripEvent.
doneBy: Joseph-FatherOfJesus, Mary-MotherOfJesus.
fromLocation: NazarethGalilee.
toLocation: BethlehemJudea.

Now that we have the holy couple securely in Bethlehem ready to fulfill the prophecy, we can describe the birthing event.

In Mt: BirthOfTheMessiah.
isa: BirthEvent.
birthParent: Mary-MotherOfJesus.
birthChild: JesusOfNazareth.

In Mt: GospelOfMatthewMt.
Constant: HouseOfJosephInBethlehem.
isa: House.
f: (owns Joseph-FatherOfJesus HouseOfJosephInBethlehem).
f: (eventOccursAt BirthOfTheMessiah HouseOfJosephInBethlehem).

In Mt: GospelOfLukeMt.
Constant: StableWhereJesusWasBorn.
isa: Stable.
internalSubRegion: BethlehemJudea.
adjacentTo: (SomeFn HotelBuilding).
f: (eventOccursAt BirthOfTheMessiah StableWhereJesusWasBorn).

The First Visitors

From what has been shown so far, it should be pretty obvious how to handle the first visitors, namely the shepards in the case of Luke versus the Wise Kings or Magi from the East in Matthew. In fact, these are left as an exercise to the reader since they add nothing new in terms of how to approach this problem.

On to Nazareth

1. How direct is the route to Nazareth?

What we said above about the visitors of Baby Jesus equally applies to the eventual return to Nazareth. There is the same angelic visions in dreams in Matthew and the journeying first to Egypt and then back to Galilee (via the stop-over in Judea). Luke does not even recount the story of the return.

A Temporal Correction

There is actually at least one subtle mistake in the representation we have given so far: specifically, we have glossed over the fact that the temporal extent of the microtheory contexts is in some cases larger than is appropriate for the facts we have stated. The indivudal events are fine — here the actor and role assignments are understood to be restricted to the temporal extent of event, not to the temporal extent of the enveloping context. But what about our residency statements regarding Joseph and Mary in the Gospel of Matthewe?

;; WRONG WRONG WRONG WRONG
In Mt: GospelOfMatthewMt.
f: (residesInRegion Mary-MotherOfJesus BethlehemJudea).
f: (residesInRegion Joseph-FatherOfJesus BethlehemJudea).

This is false, because they also reside in Egypt for a couple of years and then they move to Nazareth altogether — we already discussed this. Anything asserted in the GospelOfMatthewMt would have temporal extent to the whole of the story time as narrated, i.e. from the time of the opening geneaology to Jesus' ascension at the end of the Gospel.

In general temporal qualification is usually understood to mean mapping to an absolute timeline, like the Julian calendar.

In Mt: GospelOfMatthewMt.
Time Dimension: (TimeIntervalInclusiveFn (YearBCE-JulianFn 7) (YearBCE-JulianFn 3)).
Time Parameter: Time-Point.
f: (residesInRegion JesusOfNazareth BethlehemJudea).

However, for our situation this is often inappropriate; for many of the events recounted here, we do not have dates (and sometimes we might not even have rough estimates). Fortunately, temporal qualification is not restricted to absolute dates. Rather, the temporal constraints of an event can be pushed up into the temporal dimension. So we can relate the constraints in terms of story time, as long as the events themselves are temporally related to each other in terms of their sequence.

In Mt: GospelOfMatthewMt.
Constant: HolyFamilyHidingInEgypt.
isa: Event.
startsAfterEndOf: BirthOfTheMessiah.
endsBeforeStartOf: HolyFamilyBackInNazareth.
f: (subEvents ChildhoodOfJesusOfNazareth HolyFamilyHidingInEgypt).

Time Dimension: (TemporalExtentInMtFn HolyFamilyHidingInEgypt GospelOfMatthewMt)
Time Parameter: Time-Point.
f: (residesInRegion JesusOfNazareth Egypt).

Advanced Topics

Knowledge Engineering for Historians/Advanced Topics