.

Tasks for the UT RKF Team

Number People Priority Project Status
1 Dan Medium Go through the Relation's (subclass of Slot) in the Tree. Make sure there is good documentation on every Relation (including inverses). Write a spec, if one's missing.

Check that every Relation is in the Slot Dictionary, and give a list to Ken of any that are missing. (An earlier pass by Dan turned up these omissions: next-event, first-subevent, element-type, brightness, substrate)

Tag the files as released.

2 Jarred Medium Go though the Property's (subclass of Slot), doing the same steps as in 1. Each of the .kml files that document a Property give a list of the scales appropriate for that Property. Make these scales into hyperlinks that point to the documentation for that scale (see item 3, below).
3 Jarred Medium Create documentation files for each Scale (a subclass of Property-Group). This should be done automatically, by a script that reads the .km file and generates a .kml file. This script should run as part of the nightly script, so that doc files are created for any new Scale's that we add to the component library.

As part of this task, consider whether we need doc files for Age-Scale (say), the *young-old-scale, and the Constants (e.g. *old) on that scale. (I'm thinking we just need documentation on the *young-old-scale and the Constants, and that both can be created automatically.)

Tag as Released "Scale" and all the files under it. Tag as Released "Constant" and all the files under it.

4 Jarred Medium Consider whether we need documentation files for the subclasses of Unit-of-Measurement and their instances. If so, try to generate that documentation automatically.

Tag as Released Unit-of-Measurement and all the files under it. Find out why *gram-atoms/liter is a direct instance of Unit-of-Measurement and fix it.

done
5 Dan Medium Add a pointer to Ken's GPD on Properties to every documentation file related to Properties (i.e. property slots, Scales, Constants). See the email exchange between me and Vinay regarding where this documentation should reside (see: ~porter/Open/gpd-emails).

Add a pointer to Ken's GPD on Roles to the documentation files for Role and all its subclasses. See the email exchange between me and Vinay regarding where this documentation should reside (see: ~porter/Open/gpd-emails).

Add a pointer to Ken's GPD on Aggregates to the documentation files for Aggregate and all its subclasses. See the email exchange between me and Vinay regarding where this documentation should reside (see: ~porter/Open/gpd-emails).

6 James Medium Review the Role's. Add documentation for the ones that are missing. Tag as released.
7 Ken Medium As we're adding documentation files, do we need to be adding links to WordNet, or has this already been done?
8 Bruce Medium Review the Events. Some of them (especially the ones displayed red in our Tree) lack documentation files. Write that documentation.
9 Ken Medium Ken and Art are creating new components. Document them as they become available.
10 James/Peter Medium KM 1.4.5.39 has several new features, including: "Multiple (class) values are now allowed on the slot's `domain' and `range'. Instances which are the domain/range of that slot should be in at least one of the domain/range classes given." Use this new feature to tighten the constraints in our library. (Try a small test case first; make sure that SHAKEN will play nicely with this change.)

James, Peter: tightened constraints should help your projects; explore how.

11 James Medium Another new KM feature is a simple mechanism for defaults:
         - experimental use of (:default ) slot, where a default
           value may be overridden by a constraint, for example:
                KM> (every Car has 
                       (parts ((a Engine) (:default (a Seat)))))
                KM> (*MyCar has
                       (instance-of (Car))
                       (parts ((mustnt-be-a Seat))))
                KM> (the parts of *MyCar)
                (_Engine2)                      ; note, no Seat

Will this meet our purposes? Review the parts of the library in which defaults have been "penciled in" and determine whether the proposed mechanism is adequate.

Propose a way for incorporating defaults into SHAKEN's CMaps. How should default information be displayed on a CMap? How might a SME be allowed to override a default?

A good test case for defaults is the elements of a Army Division. Try to make it work there.

12 Ken Medium Review the component library to make sure we're SADL compliant.
13 Art/Martin Medium Encode a couple more COA's using SHAKEN in order to:
  • find bugs and submit bug reports
  • determine new components that we need in the library
  • generate examples for James (of loosespeak) and Peter (of Patterns)
Use this occassion to test SHAKEN, especially the new features in version 2.2. (Sunil's description of the new features is in: ~porter/Open/shaken-2.2). Also, thoroughly test the delete function.
14 Peter Medium Build a Tree that has bsp, but omits biology. This is the version of the component library that should be delivered to SRI each day.
15 Ken Medium Check biology for core concepts.
16 Bruce Medium Figure out what to do with Scenario. Either make it a first-class entity (with documentation, subclasses perhaps, and tagged released), or kill it off. done
17 Art (content+SHAKEN)
James (as defaults)
Medium Add preparatory-events to the Events that currently lack them. Test in SHAKEN whether preparatory-events are working well. (They're suppose to accelerate knowledge entry.) Preparatory-events are usually defaults, so consider this in the context of item #10.
18 James High Explore how loose-speak can be used in SHAKEN. (For example, when the SME is linking two nodes, and SHAKEN displays the list of slots that might be used, the list might include "illegal slots" displayed in a shadowy font. If the SME selects an "illegal slot", SHAKEN tries to interpret it as loose-speak.) We need a proposal by Monday.
19 Peter High Explore how to build patterns and match COA's using SHAKEN's representation of KM (i.e. prototypes). Explore ways in which SME's can author patterns in the current SHAKEN, i.e. without special support from a "pattern editor".
20 Bruce/Ken Medium Explore how we can support the UMASS simulator.
21 Ken Medium Incrementally re-build COA1 for presentation. Include explicit links back to the textual description of it.
22 Dan/Ken Medium Work with Pete Clark and SRI to better integrate Aggregates into KM/SHAKEN. A SME should be able to use an Aggregate anywhere that the Aggregate's elements can be used.
23 Jarred Medium Make a quad out of Move-Into, Move-Out-of and Be-Contained. Update the documentation for those components to describe the quad.
24 Art/Peter
(Ken)
Medium In the last release of the spec for this summer's challenge problem, IET lists military units, military tasks and terrain characteristics that would be useful pump priming. The spec also includes pointers to relevant prior work during HPKB on formalizing these terms. See: http://www.iet.com/Projects/RKF/COA%20CP-spec--v0.3.doc

Develop representations in KM for these terms (including characterstics of Units wrt types of Terrain), borrowing from past work as appropriate.

25 Peter/Dan Medium The "front page" of our tree contains this text:

Many of the terms in the taxonomy are from biology, which is our application area, and one textbook (by Alberts) in particular. The display of these terms follows this color scheme: terms that originate in Chapter 7 of the Alberts text are displayed in Blue , and terms that originate earlier are displayed in magenta .

I suggest that we change that text to be:

Some of the terms in the taxonomy are from biology or course-of-action critiquing: the two application areas where we have applied our work so far. The display of these terms follows this color scheme: biology terms are displayed in magenta, and course-of-action terms are displayed in blue.

To implement this, we need to do the following:

  • tag all the concepts in the bsp directory with a new tag, say "COA"
  • in the code that displays the tree, all biology terms (regardless of whether or not they're tagged as pumppriming) should be displayed in magenta
  • all terms tagged COA should be displayed in blue