Control Schema Design

Version 2002/07

 Ian Harrison, SRI International

 

 

1.   Introduction

 

This document describes the current status of the control markup language (ControlML), which we are proposing to use for messages to communicate between components in EELD. ControlML messages can use the HypothesisML and PatternML schema within the messages.

 

 

2.   Design of Control Schema

 

The design goal for ControlML was that it had to provide a messaging schema within EELD, so that different EELD components could task other components in a uniform manner. The schema assumes a request/response style messaging system and is designed to be neutral to actual messaging infrastructure implementation. The content of the messages for controlML are likely to contain elements drawn from the HypothesisML and PatternML schemas.

.

The control schema was developed using Tibco’s XML Turbo tool. Several iterations between members of the SRI EELD team resulted in this current version.

 

3.   Control Schema

 

message

The message element (see Figure 1) is the root element for describing a message. A message element can contain 0 or 1 request elements, or 0 or 1 response elements. The message element has 3 attributes: id (required), timestamp and sender. id is a unique identifier that is used to track messages (eventually this will be a UUID). timestamp is a time and date using the dateTime XML Schema data type. sender is a reference to the id of the agent that send the message (eventually this will be a UUID). sender will be used by control agents for control purposes.

 

 

 

Figure 1: message element

 

 

A request element has a single attribute, responseRequired (required) that is either of value Yes or No. A request element can contain 3 types of element: action, pattern and criteria.

 

An action element can be thought of the verb of the message -- telling a controller what to do, e.g. MATCH a pattern; DISPLAY a graph. A request element must contain 1 and only 1 action element. We've left the content model as Mixed so that it can contain string text for now, or other (to be defined) elements in the future. We anticipate that an ontology of tool capabilities will be defined and we'll be able to leverage this for the content model of this element.

 

There can be 0 or more pattern elements. Pattern elements describe the subject of the request.

 

There can be 0 or more criteria elements. Criteria elements are designed to specify control criteria to be used by a controller to decide how to deal with the request. A criteria element can contain up to 5 types of element: number, timeLimit, belief, format, inputdata. The criteria element is designed to specify control criteria to be used by a controller, to describe how to deal with the message. Hence number element can be used to specify how much you want returned, The timeLimit element can be used to specify how quickly you want a response. The format element can be used to specify the format you want things returned in. The belief element can be used as a threshold controller, so that a measure/value pair of belief can be specified e.g. to state a minimum belief threshold of information that you want returned. All these content elements are optional, with a maximum of 1 of each. The 5th possible element type is inputdata. Again this is optional and there can be 0 or more of these. The inputdata element is designed to specify what data is to be used for the matching.

 

A response element has 2 attributes: status (not required) and messageid (required). The status attribute is a string reporting on the response to the request e.g. failed, successful. Eventually we will probably define a taxonomy of status terms - for now any string text is OK. The messageid attribute is a reference to the id of the message that contained the request message that this is the response to. A response element can contain either text or other elements. We've left the content model open at this point, although we may eventually want to further define the allowed content.

 

Appendix A: ControlML Schema

 

 <?xml version="1.0" encoding="UTF-8"?>

<!-- edited with XML Spy v4.4 U (http://www.xmlspy.com) by IWH (My co) -->

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

      <xsd:include schemaLocation="http://www.ai.sri.com/~law/schemas/2002/07/pattern"/>

      <xsd:include schemaLocation="http://www.ai.sri.com/~law/schemas/2002/07/hypothesis"/>

      <xsd:element name="message">

            <xsd:annotation>

                  <xsd:documentation>message element is the root element. </xsd:documentation>

                  <xsd:documentation>message element has 3 attributes: messageid (required), timestamp and sender. messageid is a unique identifier that is used to track messages (eventually this will be a uuid). timestamp is a time and date using the dateTime XML Schema data dype. sender is a reference to the id of the agent that send the message (eventually this will be a uuid). sender will be used by control agents.

         </xsd:documentation>

                  <xsd:documentation>A message element can contain either a request or response element.

         </xsd:documentation>

            </xsd:annotation>

            <xsd:complexType>

                  <xsd:choice>

                        <xsd:element ref="request"/>

                        <xsd:element ref="response"/>

                  </xsd:choice>

                  <xsd:attribute name="id" type="xsd:string" use="required"/>

                  <xsd:attribute name="timestamp" type="xsd:dateTime"/>

                  <xsd:attribute name="sender" type="xsd:string"/>

            </xsd:complexType>

      </xsd:element>

      <xsd:element name="request">

            <xsd:annotation>

                  <xsd:documentation>a request element has a single attribute, responseRequired (required) that is either of value Yes or No.

         </xsd:documentation>

                  <xsd:documentation>a request element can contain 3 types of element: action, pattern and criteria. There must be 1 and only 1 action element. There can be 0 or more pattern elements and there can be 0 or more criteria elements.

         </xsd:documentation>

            </xsd:annotation>

            <xsd:complexType>

                  <xsd:sequence>

                        <xsd:element ref="action"/>

                        <xsd:element ref="pattern" minOccurs="0" maxOccurs="unbounded"/>

                        <xsd:element ref="criteria" minOccurs="0" maxOccurs="unbounded"/>

                  </xsd:sequence>

                  <xsd:attribute name="responseRequired" use="required">

                        <xsd:simpleType>

                              <xsd:restriction base="xsd:NMTOKEN">

                                    <xsd:enumeration value="Yes"/>

                                    <xsd:enumeration value="No"/>

                              </xsd:restriction>

                        </xsd:simpleType>

                  </xsd:attribute>

            </xsd:complexType>

      </xsd:element>

      <xsd:element name="response">

            <xsd:annotation>

                  <xsd:documentation>a response element has 2 attributes: status (not required) and messageid (required). status is a string reporting on the response to the request e.g. failed, successful. Eventually we will probably define a taxonomy of status terms - for now any string text is OK. messageid is a reference to the id of the message that contained the request message that this is the response to.

         </xsd:documentation>

                  <xsd:documentation>a response element can contain either text or other elements. We've left the contents open at the point, although we may eventually want to further define the allowed content.

         </xsd:documentation>

            </xsd:annotation>

            <xsd:complexType mixed="true">

                  <xsd:sequence>

                        <xsd:any minOccurs="0" maxOccurs="unbounded"/>

                  </xsd:sequence>

                  <xsd:attribute name="status" type="xsd:string"/>

                  <xsd:attribute name="messageid" type="xsd:string"/>

            </xsd:complexType>

      </xsd:element>

      <xsd:element name="number" type="xsd:string">

            <xsd:annotation>

                  <xsd:documentation>a number element is a type of request criteria and is designed for specifying the number of matches -- minimum, maximum, first 20 etc. </xsd:documentation>

            </xsd:annotation>

      </xsd:element>

      <xsd:element name="timeLimit" type="xsd:time">

            <xsd:annotation>

                  <xsd:documentation>timeLimit element is a type of request criteria and is designed for specifying a timeLimit (e.g. 20 seconds) to respond to the request. </xsd:documentation>

            </xsd:annotation>

      </xsd:element>

      <xsd:element name="format" type="xsd:string">

            <xsd:annotation>

                  <xsd:documentation>format element is a type of request criteria and is designed for specifying the format you want the response information in. </xsd:documentation>

            </xsd:annotation>

      </xsd:element>

      <xsd:element name="inputdata">

            <xsd:annotation>

                  <xsd:documentation>an inputdata element is a type of request criteria and is designed for specifying the data that is to be used for the matching. </xsd:documentation>

            </xsd:annotation>

            <xsd:complexType>

                  <xsd:attribute name = "label" type = "xsd:string"/>

                  <xsd:attribute name = "uri" type = "xsd:anyURI"/>

            </xsd:complexType>

      </xsd:element>

      <xsd:element name="criteria">

            <xsd:annotation>

                  <xsd:documentation>a criteria element can contain up to 5 types of element: number, timeLimit, belief, format, inputdata. The criteria element is designed to specify control criteria to be used by a controller to describe how to deal with the message. Hence number element can be used to specify how much you want returned, timeLimit used to specify how quickly you want stuff returned, format to specify the format you want things returned in. Belief is designed to be used as a threshold controller, so that a measure/value pair of belief can be specified e.g. to state a minimum belief threshold of information that you want returned. All these content elements are optional, with a maximum of 1 of each. The 5th possible element type is inputdata. Again this is optional and there can be 0 or more of these. Inputdata is designed to specify what data is to be used for the matching.

         </xsd:documentation>

            </xsd:annotation>

            <xsd:complexType mixed="true">

                  <xsd:sequence>

                        <xsd:element ref="number" minOccurs="0"/>

                        <xsd:element ref="timeLimit" minOccurs="0"/>

                        <xsd:element ref="belief" minOccurs="0"/>

                        <xsd:element ref="format" minOccurs="0"/>

                        <xsd:element ref="inputdata" minOccurs="0" maxOccurs="unbounded"/>

                  </xsd:sequence>

            </xsd:complexType>

      </xsd:element>

      <xsd:element name="action">

            <xsd:annotation>

                  <xsd:documentation>action element can be thought of the verb of the message -- telling a controller what to do, e.g. MATCH a pattern; DISPLAY a graph. A message must contain 1 and only 1 action element. We've left the content model as Mixed so that it can contain string text for now, or other (to be defined) elements in the future. We anticpate an ontology of tool capabilities will be defined and we'll be able to leverage this for the content model of this element.               </xsd:documentation>

            </xsd:annotation>

            <xsd:complexType mixed="true">

                  <xsd:choice/>

            </xsd:complexType>

      </xsd:element>

</xsd:schema>

 

 

Appendix B: Example ControlML File

 

An example ControlML file (a message request).

 

<?xml version="1.0" encoding="UTF-8" ?>

<message xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.ai.sri.com/~law/schemas/2002/07/control" sender="Ian Harrison" id="message123" timestamp="2002-03-25T17:20:00">

 <request responseRequired="Yes">

  <action>match</action>

  <pattern id="contract_murder1" label="contract murder">

   <ontology id="eeld_ontology">

     <class id="contract_murder" label="contract murder">

       <subClassOf classid="murder" />

     </class>

   </ontology>

   <body>

    <node id="contractor.x" label="directing_agent">

     <instanceOf classid="person" />

    </node>

    <node id="killer.x" label="hitman">

     <instanceOf classid="person" />

    </node>

    <node id="payment.x" label="initial_payment">

     <instanceOf classid="paying_event" />

    </node>

    <node id="payment.y" label="final_payment">

     <instanceOf classid="paying_event" />

    </node>

    <edge from="contractor.x" to="payment.x" id="source.payment.x" label="source" />

    <edge from="killer.x" to="payment.x" id="recipient.payment.x" label="recipient" />

    <edge from="contractor.x" to="payment.y" id="source.payment.y" label="source" />

    <edge from="killer.x" to="payment.y" id="recipient.payment.y" label="recipient" />

   </body>

  </pattern>

  <criteria>

   <number>12</number>

   <timeLimit>17:30:00</timeLimit>

   <inputdata uri="http://www.ai.sri.com/~law/0.1/data/data1.xml"/>

   <inputdata uri="http://www.ai.sri.com/~law/0.1/data/data1.xml" label="data2"/>

  </criteria>

 </request>

</message>