Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
hekate:hmr [2009/05/08 20:17]
gjn
hekate:hmr [2019/06/27 15:49] (current)
Line 1: Line 1:
 +
 +
 ====== Hekate Meta Representation ====== ====== Hekate Meta Representation ======
  
-//HMR// provides a high-level textual human-readable rule representation for [[XTT2]].+The visual ​[[XTT2]] ​model is represented by means of a human readable, algebraic notation, also called the XTT presentation syntax, or //HeKatE Meta Representation (HMR)//.
  
-It is directly ​executable ​by the [[HeaRT]] ​engine.+The representation can be directly ​run by the HeKatE RunTime environment ​[[HeaRT]]
 +HMR file is in fact a legal Prolog code that can be interpreted directly (number of custom operators are defined). 
 +Therefore HeaRT prototype is implemented in Prolog and provides the implementation for number of inference solutions including the three described before.
  
-It can be used to write rules directly, or 
-it can be generated by the [[HQEd]] XTT2 editor from the visual [[XTT2]] model. 
  
 +HMR can be used to write rules directly, or it can be generated by the [[HQEd]] XTT2 editor from the visual [[XTT2]] model.
 The same rule-based knowledge can be serialized to XML-based [[hekate_markup_language|HML]]. The same rule-based knowledge can be serialized to XML-based [[hekate_markup_language|HML]].
  
 See the [[HaDEs]] page for an overview. See the [[HaDEs]] page for an overview.
  
-A simple ​example ​for the [[hekate_case_thermostat|Thermostat case]]:+===== Example ===== 
 + 
 +An example ​excerpt of HMR is given below:
  
 <code prolog> <code prolog>
-xtype [name: week_days,​ +xschm th: [today,hour==> [operation].
-       base: symbolic, +
-       ​ordered:​ yes, +
-       ​domain: [monday,tuesday,​wednesday,​thursday,​friday,​saturday,​sunday] +
-      ​].+
  
-xattr [name: ​ day, +xrule th/1: 
-       ​class:​ simple, +  [today eq workday, 
-       ​type: ​ week_days,​ +   hour gt 17]
-       ​comm: ​ in]. +
- +
-xschm dt: [day] ==> [today]. +
- +
-xrule dt/1: +
-  [day in [monday,tuesday,​wednesday,​thursday,​friday]]+
   ==>   ==>
-  [today set workday].+  [operation ​set not_bizhours].
  
-xrule dt/2+xrule th/4
-  [day in [saturday,​sunday]]+  [today eq workday, 
 +   ​hour  ​in [9 to 17]]
   ==>   ==>
-  [today set weekend].+  [operation ​set bizhours].
 </​code>​ </​code>​
 +
 +The first line defines an XTT table scheme, or header, defining all of the attributes used in the table.
 +
 +Its semantics is as follows:\\
 +//The XTT table ''​th''​ has two conditional attributes: ''​today''​ and ''​hour''​ and one decision attribute: ''​operation''//​.\\
 +This information is determined from the conceptual design phase using the ARD method.
 +Then two examples of rules are given.
 +
 +The second rule can be read as:\\
 +//Rule with ID ''​4''​ in the XTT table called ''​th'':​ if value of the attribute ''​today''​ equals (''​=''​) value ''​workday''​ and the value of the attribute ''​hour''​ belongs to the range (''​in''​) ''<​9,​17>''​ then set the value of the attribute ''​operation''​ to the value ''​bizhours''​.//​
 +
 +
 +===== HMR language =====
 +
 +HMR language was created to provide simple and human-readable text representation for XTT diagrams. The HMR language is fully Prolog compatible, which means that it is interpreted directly by Prolog interpreter,​ without any additional parser.
 +The HMR file consists of the following elements:
 +  * Mandatory types definitions (predicate //xtype//)
 +  * Optional types groups definitions (predicate //xtpgr//)
 +  * Mandatory attributes definitions (predicate //xattr//)
 +  * Optional attributes groups definitions (predicate //xatgr//)
 +  * Mandatory schemas definitions (predicate //xschm//)
 +  * Mandatory rules definitions (predicate //xrule//)
 +  * Optional states definitions (predicate //xstat//)
 +  * Optional callbacks definitions (predicate //xcall//)
 +  * Optional actions definitions (predicate //xactn//)
 +  * Generated by verification plugin predicates containing verifications reports (predicate //xhalv//)
 +  * Generated by inference engine predicates containing information about system'​s states changes during inference process (predicate //xtraj//)
 +  ​
 +All HMR elements are described below. Following notation was introduced:
 +  * All mandatory fields are preceded by **+** sign
 +  * All optional fields are preceded by **?** sign
 +  * If there is more than one possible value of the field following notation will be used {value1 | value2 | value3}; the notation means that the filed can take either value1, balue2, or value3.
 +  * %STRING% means a string in Prolog. ​
 +  * %NUMBER% means either integer or floating point number.  ​
 +  * %LIST% means a list in Prolog
 +  * %CLAUSE% means any valid Prolog goal.
 +  ​
 +==== Types definitions ====
 +Types in HMR language are used to define kind, structure and domain for further attributes definitions. Type definition looks as follows:
 +<​code>​xtype [ +name: %STRING%,
 + +base: {numeric | symbolic},
 + +domain: %LIST%,
 + ?scale: %NUMBER%,
 + ?ordered: {yes | no},
 + ?desc: %STRING%].</​code>​
 +
 +  * //name// - a field that contains type's name
 +  * //base// - a field describing base of the type. It can be either numeric, or symbolic
 +  * //domain// - a filed that contains a list of all acceptable values for this type. For ordered symbolic domains, it is possible to assign weights to the values. For instance in the example below, every day has it's own number assigned, that allows referring to the values using this number instead of symbolic name. If a symbolic domain is marked as ordered, and there are no weights assigned explicitly to the domain'​s values, default numbering is assumed that starts from 1 and ends on //n//, where //n// is the number of elements in the domain.
 +  * //scale// - a field denoting precision for floating point numbers
 +  * //ordered// - a field indicating whether domain is ordered or not. Every numeric type has ordered domain by default.
 +  * //desc// - a filed containing longer description of the type
 +  ​
 +Type definition may look as follows:
 +<​code>​
 +xtype [ name: days,
 + domain: [mon/​1,​tue/​3,​wed/​5,​thu/​7,​fri/​9,​sat/​10,​sun/​20],​
 + ordered: yes, 
 + desc: 'Days of the week'​].
 +</​code>​
 +
 +==== Attributes definitions ====
 +Attributes in HMR language denotes instances of defined types. Every attribute in the HMR language must have a type assigned. Only one type can be assigned to one attribute. Type definitions looks as follows:
 +<​code>​xattr [ +name : %STRING%,
 + +class: {simple | general},
 + +type: %XTYPE_NAME%,​
 + +comm: {in | out | inter | comm},
 + ?​callback:​ %LIST%,
 + ?abbrev: %STRING%,
 + ?desc: %STRING%].</​code>​
 +
 +  * //name// - a field contains attribute'​s name
 +  * //call// - a field that denotes weather the attribute is simple (represents simple values) or general (represents set values).
 +  * //type// - a field that contains a name of a type defined as //xtype//. This field denotes the attribute'​s type.
 +  * //comm// - a field that describes attribute'​s relation to the world. If the attribute is //in// it means that a value of it is supposed to be given by the user; if the attribute is out it means that the value of it should be presented to the user; if attribute is inter it means that its value is set by the system as a result of inference process, but it;s not relevant to the user; if the attribute is comm, it means that it's both in and out.
 +  * //​callback//​ - a field that contains an information about which callback is supposed to be fired for the attribute. The list should look as follows: //​[callback_name,​ [callback_parameters] ]//, where callback_name is a name of defined callback (see [[heart_howto#​callbacks_definitions]]),​ and callback_parameters is a list of parameters that the callback takes.
 +  * //abbrev// - a field that contains short name of the attribute. ​
 +  * //desc// - a field that contains longer description of the attribute.
 +  ​
 +Atribute definition may look as follows:
 +<​code>​xattr [name: day,
 + abbrev: day,
 + class: simple,
 + type: days,
 + comm: in,
 + callback: [ask_console,​[day]]].</​code>​
 +
 +
 +==== Types and attributes groups definitions ====
 +Groups contain sets of attributes'​ or types' names. It is possible to refer to a group of attributes or types using group name instead of each type's or attributes name separately. Groups were designed for future use in HeaRT interpreter.
 +
 +Groups definitions looks as follows:
 +
 +<​code>​xtpgr [ +name : %STRING%,
 + ?abbrev: %STRING%,
 + +types: %LIST%
 + ].</​code>​
 +
 +<​code>​xatgr [ +name : %STRING%,
 + ?abbrev: %STRING%,
 + +types: %LIST%
 + ].</​code>​
 +
 +
 +==== Schemas definitions ====
 +Schemas represents XTT tables in HMR language. However, they cannot be considered as entities filled with rows containing rules. Schema is only a representation of relation between attributes that rules falling into this schema realizes. ​
 +Definitions of schema looks as follows:
 +
 +<​code>​xschm +%STRING1%/?​%STRING2% : +%LIST1% ==> +%LIST2%.</​code>​
 +
 +  * //​+%STRING1%//​ - a field containing obligatory schema name
 +  * //​%STRING2%//​ - a field containing an optional schema description,​
 +  * //+%LIST1% ==> +%LIST2%// - represents relation that given schema describes. First list denotes attributes that are required to be known by the rules that falls in this schema, and the second list denoted attributes that values are calculate by the rules in given schema. For instance: [month] ==> [season].
 +  ​
 +An example of schema definitions may look as follows:
 +
 +<​code>​xschm ms: [month] ==> [season].</​code>​
 +
 +==== Rules definitions ====
 +Rules in HMR language are defined as follows:
 +
 +<​code>​xrule %STRING1%/​%NUMBER%:​ %LIST1% ==> %LIST2% **> %LIST3% : %STRING2%.</​code>​
 +
 +  * //​%STRING1%//​ - a field that contains name of the schema that the rule falls into.
 +  * //​%NUMBER%//​ - a field that represents rule ID inside the schema
 +  * //%LIST1%// - contains a list of firing conditions for the rule. Each condition has to be valid ALSV(FD) expression of the form //​attribute_name ALSV_OPERATOR value//
 +  * //%LIST2%// - contains decisions that has to be fired when conditions are true. Decision is of the form //​attribute_name set value//
 +    * The value can be an expression including basic operators like (+,-,/,*) and functions like union, intersect, except
 +  * //%LIST3%// - contains list of actions with its parameters of the form //​[action_name,​ [action_parameters]]//​. Those actions are fired when rule's conditions are true. Actions cannot change system'​s state.
 +  * //​%STRING2%//​ - is a schema (table) name that should be given a token when inference mode is set to Token-Driven.
 +  ​
 +An example of a rule definition is shown below.
 +
 +<​code>​xrule dt/1:
 +      [day in [mon,​tue,​wed,​thu,​fri]]
 +    ==>
 +      [today set workday]
 + **>
 +   [tell_console,​['​Today is a workday'​]]
 +    :​th.</​code>​
 +
 +==== States definitions ====
 +State in HMR language is a set of attributes and corresponding values that describes system'​s status. State definitions looks as follows:
 +
 +<​code>​xstat %STRING%: %LIST%.</​code>​
 +
 +  * %STRING% - is a name of the state. Because each //xstat// record describes only one attribute'​s value, the name is not unique. If a system contains //n// attributes, that have to be described by HMR state, there have to be //n// //xstat// records - each for every attribute.
 +  * %LIST% - is always a two-elements list containing attribute'​s name and value. ​
 +  ​
 +An example of //xstat// record may look as follows:
 +
 +<​code>​xstat s1: [month, january]</​code>​
 +
 +==== Callbacks definitions ====
 +Callback is an operation that is fired at the certain point of inference process, and can change system'​s state. Callbacks are defined as follows:
 +
 +<​code>​xcall %STRING% : %LIST% >>>​ (%CLAUSE%).</​code>​
 +
 +  * %STRING% - is a callback name
 +  * %LIST% - is a list of variables that have to be unified with some values in order to reach a goal defined by %CLAUSE%
 +  * %CLAUSE% - is any Prolog code describing a goal. 
 +  ​
 +An example of //xcall// record is shown below:
 +
 +<​code>​xcall ask_console : [AttName] >>>​ (write('​Type value for attribute: ​ '),
 + write(AttName),​nl,​
 + read(Answer),​
 + alsv_new_val(AttName,​Answer)).</​code>​
 +
 +==== Actions definitions ====
 +Action is an operation that is fired when rule's firing conditions are true. Actions cannot change system'​s state.
 +
 +<​code>​xactn %STRING% : %LIST% >>>​ (%CLAUSE%).</​code>​
 +
 +  * %STRING% - is a action name
 +  * %LIST% - is a list of variables that have to be unified with some values in order to reach a goal defined by %CLAUSE%
 +  * %CLAUSE% - is any Prolog code describing a goal. 
 +  ​
 +An example of //xactn// record is shown below:
 +
 +<​code>​xactn tell_console : [AttName] >>>​ (write('​Attribute '),
 + write(AttName),​
 + write('​ output value is '),
 + xstat(current:​[AttName,​V]),​
 + write(V),​nl).</​code>​
 + 
 +
 +
 +  ​
 +==== Verifications reports ====
 +Predicates containing versification'​s reports are generated automatically by the HeaRT interpreter. Every record contains only one message generated by verification plugin. All messages generated during verification are grouped within a set of //xhalv/1// predicates of the same ID (name). ​
 +Definition of //xhalv/1// looks as follows:
 +<​code>​xhalv %STRING% : %LIST%.</​code>​
 +  * %STRING% - is an unique ID (or name of a set of xhalv records) that is automatically generated every time a verification process is fired.
 +  * %LIST% - is a message generated by the verification process. The list can look differently depending on which verification was performed:
 +    * subsumption:​ [rule_id, description],​ where //rule_id// is a rule that subsumes other rule; a //​description//​ is text message describing in details anomaly that was detected.
 + * contradiction:​ [rule_id, description],​ where //rule_id// is a rule that contradicts with other rule; a //​description//​ is text message describing in details anomaly that was detected.
 + * reduction: [rule_id, description],​ where //rule_id// is a rule that  with other rule; a //​description//​ is text message describing in details anomaly that was detected.
 + * completeness:​ [description],​ where //​description//​ is a text message describing in details anomaly that was detected.
 +
 +==== Trajectory traces ====
 +Predicates containing trajectories of the system'​s inference process are automatically generated by the HeaRT and saved as //​xtraj/​1//​. A single //xtraj/1// record contains information about one inference process from the start until the end. 
 +Definitions of //xtraj/1// are build as follows:
 +<​code>​xtraj %STRING% : %LIST%.</​code>​
 +  * %STRING% - is an unique ID that is automatically generated every time a inference process is fired.
 +  * %LIST% - is a list of two-elements list of the form:
 +    * [entity_id, state_id] - where //​entity_id//​ is a name of entity after which a state of the system was capture (it can be name of a table, name of a rule). Trajectory contains as a first element state of the system before inference process; entity for this state is called //​start//​. ​ \\ The //​state_id//​ is a name of a ''​xstat/​1''​ record where the state of the system was saved.
  
  
hekate/hmr.1241806625.txt.gz · Last modified: 2019/06/27 16:00 (external edit)
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0