From Object Memory Modeling Incubator Group Wiki
Jump to: navigation, search

OMM Standardized Blocks for Active Knowledge

In addition to passive and history knowledge, an object memory may contain active knowledge. Active knowledge is intended to be executed by human operators dealing with the object, or interpreted as code in an information system, as opposed to being only read and treated as data by information systems. Thereby, the interpretation can happen inside the object itself, in which case it must comprise an embedded computer, or by an external system.


OMM XML offers the PROCEDURE block type to describe such active knowledge.

<block id="_BLOCK_123_">
      <creator type="email"></creator>
      <tag type="text" value="The decalcification procedure for the coffee machine" />

    <lifecycle step="MAINTENANCE" />
          <!-- this is relevant during maintenance phase -->
    <interactive value="1" />
          <!-- the process requires manual intervention -->
       <observes id="P1" required=”TRUE”> 
          <dim:StressOrPressure rdf:about=""/>
          <!-- this is a type of context value that is used in this procedure, e.g., to adjust the amount of descaling. The element itself needs to be imported from an ontology (or via dim: namespace) -->
       <observes id="P2" required=”FALSE”> 
          <dim:Temperature rdf:about=""/>
               <!-- another context value, less useful. The idea is to bind these values to the ids, so that the procedure can refer to them. The actual value can be provided by a thermometer in the environment or by another DOM -->
    </sensing >
<!-- description of the procedure in ECMA Script (maybe good for W3C, but not implemented), or XPDL (here we can contribute), or any language, from binary to LISP.-->
output.document.write("<html>hello user, this is a message from a procedure! P1 currently senses:" + getElementReferencedBySensor("P1").getValue() + "</html>");

Standardized blockMeta elements for this block:

  • Lifecycle: the step in the lifecycle where this procedure should be used. Can be any of the following: DEVELOPMENT, PRODUCTION, SHIPPING, USE, MAINTENANCE, REPAIR, DISPOSAL. These values can be discussed, they basically reflect the SmartProducts model of Life-cycle. *Note* this means that the current life-cycle state is a object global variable, maybe along the ID of the whole DOM?.
  • Interactive: whether this procedure can be automated or needs manual intervention. This may be hard to decide in advance, a procedure may become manual, if the right sensors are not available.
  • Sensing: Sensor / context data that is needed for the process (required=”TRUE”) or optional but can be used by the process (required=”FALSE”). Inside this element should be a list of observation elements, specifying the type of information that is used.

Input/Output to the User (as opposed to sensing)

Procedures should be able to specify output to the user, e.g., by getting a reference to a DOM (*Document* Object Model) that is rendered somewhere. This way, we could think about using ECMA Script for defining procedures, which could change the output to the user, as well as change the DOM (Digital Object Memory). The language, i.e., XPDL, ECMA Script, binary etc. should be clear from the MIME-TYPE. Here we need to specify language bindings to the input/output, the digital object memory itself (e.g., to change things),and the sensed values.