The title to this post probably makes it sound much more grandiose than it is. Still there's an important kernel here I don't want to lose, so I'll write it in my exocortex.

Suppose I've got an evented expense report application that automatically enters information from my travel in an expense report. The app wants to know when I've arrived at my destination or when I've arrived home, so it can book those transactions.

The problem is that my smartphone isn't signalling an "arrived at SFO" event; it's sending a "location SFO" event. The idea of arriving is specific to the context of traveling from one airport to another. So, a "location SFO" event only equals an "arrived at SFO" event if I was known to have been on a plane. For example, my if travel itinerary shows that I was scheduled to be on a flight from SLC to SFO, it's a pretty good bet that I'm arriving at SFO, not departing or merely dropping someone off.

The expense report app needs to work in concert with a travel app that knows the context of what I'm doing and translates events like "location SFO" to "arriving SFO" when I've just gotten off a plane or to "departing SFO" when I'm scheduled to board a plane shortly. Here's how we might express this in KRL pseudocode:

rule arriving {
  select when mobile location 
  pre {
    airport_code = event:attr("airport");
    //find line with this airport as destination
    flight = 
      itinerary.pick("$..line[?(@.destination eq airport_code)]"; 
  }
  if(flight{"depart_time"} < time:now()) then noop();
  fired {
    raise event arriving with airport = airport_code
  }
}

There's a few holes here. Production code would need to be more complicated in calculating if this event is really an arrival, taking into account things like arriving and departing on the same day, late flights, and so on. (Not to mention I've made the code easier to read by using < for time comparison.) Nevertheless, the idea of using a rule like this to perform semantic translation for events should be clear.

You might be curious about the noop() action in the rule. Rules used for event abstraction almost always have a null action since we want their effect (raising an event) not their action. If rules like this become commonplace, we may need to allow actionless rules in KRL.

This use of context to perform semantic translations of events is something I've only recently come to appreciate. I know it's not in the Live Web book anywhere. I'll have to see how to get it in there...