History

 

2005/05/14	Title:                 NodeBrain Module Reference Author:                         Ed Trettevik <eat@nodebrain.org> Publisher:          The Boeing Company
	Release 0.6.3 ·          This document, like the software it describes, is a “prototype” version.  Revisions will be made in response to user feedback. ·          Much of the original content of this document has been moved here from the NodeBrain User’s Guide to make a clean separation between modules and the core interpreter/agent/client.
2006/04/05	Release 0.6.4 ·          Servant module included ·          Included Appendix A, Module Characteristics

 

 

Preface

 

This document is for users of NodeBrain skill modules (plug-ins).   A skill module is a dynamic load module that conforms to NodeBrain’s skill module API to extend the functionality of the NodeBrain interpreter (rule engine). 

 

The reader is expected to be familiar with the content of the NodeBrain User Guide and the NodeBrain Language Reference.  If you are new to NodeBrain, you should start with the NodeBrain Tutorial.

 

If you are looking for information on writing your own skill modules to extend NodeBrain, see the NodeBrain API Reference.  However, always consider the servant module described in this document as a way to extend your agent before writing new skill modules---this approach may save you time.

 

See www.nodebrain.org for more information and the latest update to this document.

 

Documents:

 

          NodeBrain Tutorial

NodeBrain User Guide

          NodeBrain Language Reference

          NodeBrain Module Reference

          NodeBrain API Reference

 

 

 

 

Document Conventions

 

We use a modified BNF (Backus Neur Form) notation to describe the syntax of commands supported by individual skill modules.  The notation is illustrated by the following example.

 

Syntax:
	servantDefinition	::= define š term š expert [š servantSpec ] •
	servantSpec	::= servant [ ( servantOptions ) ]  : [ | ] servantCmd
	servantOptions	::= there are currently no options defined for this module
	servantCmd	::= see “-“ and “=” command in the NodeBrain User Guide

 

Meta-symbols have a special meaning, except when in bold font where they represent themselves as symbol within the language.

 

          ::=     is defined as

          |        or

          (  )     sub-expression – e.g. ( happy | sad ) day

          [  ]     optional expression – 0 or 1 – e.g. [ really ] happy

          {  }    repeating expression – 0 or more – e.g. { really } happy

          “”       literal string – e.g. “|”, “(“, “)”, etc. (prefer bold font)

 

We deviate from BNF in our distinction between terminal symbols and syntax rule identifiers.  Instead of enclosing syntax rule identifiers between “<” and “>”, we use a different font for identifiers and terminal symbols.

 

          term             Italics for syntax rule identifiers

          define             Bold font for symbols of the language (terminal symbols)

 

When we want to emphasize the importance of “white space” or an “end of line” character, we use special symbols.

 

          š                  White space identifier

          •                  End of line identifier (LF | CR | null character)

 

Sometimes we get a bit lazy and leave rule identifiers undefined if it seems obvious, or more often because they are defined elsewhere in the document.  We also assume a terminating character does not exist within the construct it terminates.  In the following example we assume no character is a quote.

 

          “ { character } “

 

We also don’t bother to quote our literal quotes.  Bold quotes with a space on both sides are literal quotes---symbols of the language, not meta-symbols.  When quotes are used to convert a meta-symbol into a literal symbol, it is clear by the spacing and the font.

 

          “{“     Literal brace

 

We are phasing out this use of meta-symbol quotes by simply using bold font to identify literals.

 

          {        Literal brace

          {        Meta-symbol

 

The following rules describe the syntax of our modified BNF. 

 

Syntax:
	rule	::= identifier ::= expression
	expression	::= term { š | š term }
	term	::= factor [ š term ]
	factor	::= identifier | spaceIdentifier | eolIdentifier | terminal |     subExpression | optionalExpression | repeatExpression
	identifier	::=  alpha { alpha }
	alpha	::=  a-z | A-Z
	spaceIdentifier	::=  š                                   Represents one or more space characters
	eolIdentifier	::=  •                                   Represents end-of-line character
	terminal	::=  string | “ string “ | boldString
	string	::=  character { character }
	boldString	String in bold font
	subExpression	::= ( expression )
	optionalExpression	::=  [ expression ]
	repeatExpression	::= { expression }

 

In examples we sometimes use “…” to mean “blah blah blah” in a place that is not the focus of the example.  You must replace “…” with valid syntax if you want to experiment with the example.

 

          define r1 on(…) a=5;

          define goldenRule on(others) …; # as you would have them do onto you

 

Sometimes commands that must be coded on a single line are shown as multiple lines in an example.  This is indicated by one line ending with “ …” and the next line starting with “… ”.

 

          define r1 on((a=5 and b=7) or (c=2 and d=17)): …

          … {on(a=2);(mo,we,fr):-dir;}

---

Copyright © 2003-2006 The Boeing Company