| 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. |
done |
| 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. | done |
| 2.5 | Dan | Medium | Make the scales in the property spec hyperlinks that point to the documentation for that scale (see item 3, below). | work in progress |
| 3 | Dan | 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. |
work in progress |
| 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). |
dependent upon completion of 3 |
| 6 | James | Medium | Review the Role's. Add documentation for the ones that are missing. Tag as released. | done |
| 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. | done |
| 9 | Ken | Medium | Ken and Art are creating new components. Document them as they become available. | done |
| 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. |
Proposal under BP & KB's review |
| 11 | James | Medium |
Another new KM feature is a simple mechanism for defaults:
- experimental use of (:default
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. |
Work in progress. |
| 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:
|
no longer important |
| 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. | Done |
| 15 | Ken | Medium | Check biology for core concepts. | done |
| 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. | done |
| 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". | Done |
| 20 | Bruce/Ken | Medium | Explore how we can support the UMASS simulator. | done |
| 21 | Ken | Medium | Incrementally re-build COA1 for presentation. Include explicit links back to the textual description of it. | done |
| 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. | done |
| 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. |
done |
| 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:
|
Done. |
| 26 | Dan | Medium |
Sweep the library to make all element-type values classes instead of
instances. For example(element-type ((a Entity)))should be instead (element-type (Entity)) |
done |
| 27 | Ken | High | Implement a Capabilities capability. | |
| ## | Who | Priority | What's next? |