Tutorial: Retargeting

contact: [email protected]

---

In general, we believe that retargeting the application to a new application consists of several crucial steps:

1. Identify application domain and its relevant vocabulary, as well as the API; if the API doesn't exist, define/design it.
2. Design n-tuple templates to convey semantics to Problem Solver.
3. Add relevant tokens (and schemas/constructions, if necessary) to the grammar with the Token Tool.
4. Extend existing Core Specializer and Problem Solver as needed for application.
5. Build and test the new product.

Below is a hypothetical example of retargeting this system to a new domain.

KARMA

KARMA (Naryanan, 1997) was a system that made predictions about economic states and policies based on metaphors in language. The original project did not include a module for language analysis, however, and assumed as input an ntuple-like feature-structure.

We considered how one would integrate a working KARMA system with our system, and came up with the steps below.

1. Identify application domain and its relevant vocabulary, as well as the API; if the API doesn't exist, define/design it.

Domain: Economic policy metaphors
Vocabulary:
Source: MOTION (stumble, collapse...)
HEALTH (cure, prescribe, sick ...)
TARGET: ECONOMIC POLICY (economy, depression..)
App: (after) KARMA

Example sentence:
India is stumbling in implementing its economic policy

2. Design n-tuple templates to convey semantics to Problem Solver.

Action_is_Motion: {  
   mover: @India  
   actionary: @stumble  
   aspect: @progressive  
   frame: SelfMotion  
   action: {   
       actionary: @implement  
       createdThing: @policy  
       creator: @India  
       frame: Creation  
   }  
}  

3. Add relevant tokens (and schemas/constructions, if necessary) to the grammar with the Token Tool.

India :: Country :: self.m.referent <-- @India  
Stumble :: SelfMotion :: self.m.actionary <-- @stumble  
Policy :: AbstractNoun :: self.m.ontological-category <-- @policy  
Implement :: CreationType :: self.m.actionary <-- @implement  

4. Extend existing Core Specializer and Problem Solver as needed for application.

We didn't actually implement the application, but here is text describing how the Problem Solver can be extended:

Technically, one needs to extend the CoreProblemSolver Python class for this, and add API calls as appropriate. This >involves some programming, but it also gives a system integrator considerable flexibility for all kinds of APIs, no >matter if they are based on HTTP requests, Sockets, or other protocols.

And the Core Specializer:

Extending the Specializer can be done by subclassing the existing CoreSpecializer, and adding or overriding existing >methods when appropriate. The main methods of the CoreSpecializer govern how the Specializer crawls the SemSpec >according to the declarative instructions provided by ActionSpec templates; these methods should not have to change. >However, if the application-specific Problem Solver needs new types of ``descriptors'', some new code for extracting the >right information and formatting it appropriately might be necessary.

5. Build and test the new product.

India is stumbling in implementing its economic policy.

Metaphor: DIFFICULTIES ARE OBSTACLES
Metaphor: INDIA IS A MOVER ALONG A PATH