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>