Advancing Modeling

[AdamSobieski]

To advance scenarios involving automated planning and scheduling, we can work to advance the languages of planning and scheduling. However, these languages can be described as serializations of runtime models of domains, types, objects, predicates, operators, actions, constraints, and preferences. So, it is these models that we want to advance.

[aiaustin]

As part of that effort it would also be useful to look seriously again at the work on plan and activity representations. The ontologies of the objects, actors and task involved had been extensively studied. One example under a DARPA program working group published some draft of a "Shared Planning and Activity Representation" (SPAR) set of ontological underlying entities for planning tasks.

A write up of this effort as well as the (draft) SPAR proposal is available at https://www.aiai.ed.ac.uk/project/spar/.

Tate, A. (1998) Roots of SPAR — Shared Planning and Activity Representation, The Knowledge Engineering Review, Volume 13, Issue 1, March 1998, pp. 121-128, Cambridge University Press. https://www.aiai.ed.ac.uk/project/spar/DOCS/spar-roots.html

This summary paper also provides a history of previous work on plan and activity representations.

[AdamSobieski]

@aiaustin, thank you for sharing that information on SPAR. I just looked at the slides at: https://www.aiai.ed.ac.uk/project/spar/DOCS/ARPI-Nov97/sld001.htm and the publication at: https://www.aiai.ed.ac.uk/project/spar/DOCS/spar-roots.html . There are technologies indicated in the slideshow that we could enhance our group’s wiki timelines with.

Brainstorming on how to build upon and beyond SPAR, and doing so would be a durative group process, we could explore pertinent innovations which have occurred since SPAR, e.g., in terms of programming languages.

There are, for instance, templates and generics to consider for types, though these “have existed in high-level languages since at least the 1970’s in languages such as ML, CLU, and Ada, and were subsequently adopted by many object-based and object-oriented languages, including BETA, C++, D, Eiffel, Java, and DEC's now defunct Trellis-Owl language.”

With respect to genericity, parametric polymorphism, and knowledge representation, we might consider client-side preprocessing (see: #21, see: WICG/proposals#82) that produces content in OWL, RDF, N3, Turtle, or sets or sequences of predicate calculus expressions. While preprocessing and general-purpose macro processing trace back to the 1960's, client-side preprocessing as a feature of a planning domain definition language could be a new idea.

We can consider something like the following rough-draft markup sketch which intends to express that both the metadata and type definition could vary based on properties of and knowledge about the argument provided for type parameter T, this knowledge available in a contextual knowledgebase argument provided to the client-side preprocessor:

<types>
  <type name="widget" uri="...">
    <parameters>
      <parameter name="T" uri="...">
        <!-- describe type parameter here -->
      </parameter>
    </parameters>
    <metadata preprocess="text/php" type="text/n3">
      <!-- preprocessor receives the type argument for parameter T and a knowledgebase -->
    </metadata>
    <definition preprocess="text/php" type="text/n3">
      <!-- preprocessor receives the type argument for parameter T and a knowledgebase -->
    </definition>
  </type>
</types>

We could also enhance models by adding extensible metadata to as many model elements as possible. This might resemble and surpass
the expressiveness of C#’s [Attribute] and Java’s @Attribute. For instance:

[Metadata1]
class Foo
{
  [return: Metadata2]
  [Metadata3]
  public bool bar<[Metadata4] T>([Metadata5] int x)
  {
    // …
  }
}

though, for our purposes, metadata might be comprised of sets or sequences of predicate-calculus expressions or of graphs of triples.