Preface - This is the English version of Hum - Hum EnglishThe notations shown here are for the English-language version of Hum which we refer to as "Hum English". The concepts of Hum are the same from language to language. But the notation may vary to accommodate the conventions and keyboards associated with different languages. |
Hum applications are composed from short vignettes called frames. There are several types of frames which serve different purposes. Each type of frame uses a slightly different notation.
While one goal of Hum is to be as natural as possible, one must recognize that written English is not as "natural" as verbal English. Various notations and conventions are used in written English for various contexts and purposes. For example, technical documents often contain specific notations that have their own peculiar semantics and, if read aloud, would be unusable as verbal English. (For example: Consider a train schedule.) And thus, even written English contains many examples of synthetic language.
Hum has notations that are intended to be easy to learn and highly readable. The notations are designed around the concepts that they are intended to record and convey. Computer languages such as FORTRAN, Basic, C, and Java are designed as much for the computer's convenience as for human convenience. Hum is designed for human convenience.
|
There are several types of frames
- each with a different purpose and a different notation.
.
|
The purpose of a Task Frame is to describe part of a process. A component of the system called the Planner creates programs, called plan trees, by assembling related Task Frames. The Planner assembles task frames to form a plan. It does that by working backwards from a goal. The goal matches a post-condition in one of the task frames.
The notation of the task frame is designed to concisely describe an individual task. It also facilitates starting with an end-goal and then letting the system identify what process knowledge remains to be described.
--- Task: (imperative sentence - is the name/title of the task) Post: (declarative sentence) Pre: . (pre-condition - matches some other task's post-condition) . (pre-condition) . (...) . (Some tasks have no pre-conditions. They are ready to run.) Actions: . (role) : (action - understood by an actor assigned the role) . (role) : (action) . (...) . (Some tasks will have no actions. They simply define a named-state.) ---
Task: Deliver order to customer. Post: Order delivered to customer. Pre: . Customer has paid for order. . Order is ready for delivery. Actions: . Counter: Give order package to customer. . Bookkeeper: Account for order revenue and taxes.
Role Frames provide the instructions required to perform a action. At run-time, these instructions will be executed by an actor assigned the role named in the step.
Since the instructions are written in Hum, they can be understood equally well by humans, robots, and sim-bots. When we run the actual business, the instructions are executed by humans and/or robots. When we simulate the operation of the business, the instructions are performed by sim-bots. The same system can be used to operate the business in the real world or in a virtual world. In fact, we may want to test our processes in the virtual world before running them in the real-world.
--- Role: (role) << Actors are assigned roles Action: (action invoked in a task frame step) << Task Frames invoke actions. . (instruction) << Actors execute instructions. . (instruction) . (instruction) To: (instruction used elsewhere in this frame) << Explain detail in more detail. . (instruction) . (instruction) . (instruction) ---
The purpose of a Dictionary Frame is to describe the vocabulary of the task world. Dictionary items map new concepts to concepts that the Hum system already knows. The Hum system already understands terms such as: order, order item, bill-of-material, material, part, assembly, container, person, worker, employee, organization, roles, measure, metric, money, cost, price, account, resource, resource pool, inventory, and more.
The design of the dictionary notation is meant to allow people to describe terms in a natural style. The style is close to written English in this case.
Syntax:
---
Dictionary:
A (name) is a (name).
("a" and "an" are interchangeable.)
(name = noun phrase)
A (name) is described by its (name), (name), (name), (name), and (name).
---
Example:
--- Dictionary: Coffee-Mech Facts. . A coffee-mech is a robot. . A coffee-mech is described by its make, model, and software-release. . A coffee-mech is identified by its serial-number. . JavaBot is a synonym for coffee-mech. . SN is shorthand for serial-number. --- Dictionary: Employee Relationships. . Relationship: Worker W is assigned mentor M. . Relationship: Worker W works in store S. (many to many) . Relationship: Employee E is assigned role R effective on date D. . Relationship: Worker W is assigned to supervisor S when working in role R. . A mentor is an employee. . An employee is a worker. (Some workers are employees.) . A contractor is a worker. (Some workers are contractors.) . A worker is a person. . A supervisor is an employee. ---
The dictionary accommodates acronyms with the phase: "... is shorthand for ..." Synonyms are recorded with the phrase: "... is a synonym for ..."
--- Dictionary: QOH is shorthand for quantity-on-hand. Client is synonym for customer. ---
Shorthand
allows the programmer to substitute a short term for a longer one
at the time that a statement is entered.
The system immediately replaces the shorthand token with the full term.
"Smart edit" tools are expected to implement this feature.
Synonyms are used to indicate a word or phrase that can be mapped to another word or phrase which is already known to the system. When the system interprets statements, it will use synonyms to match a statement to similar statements. Synonyms allow a statements to assume two or more alternate forms.
Do not declare a synonym when you should declare a subtype.
Synonyms may be used where they conform to normal usage in the parlance of the industry or shop. Unlike a shorthand, a synonym is not replaced on input. The statement is stored in the frame base with the synonym intact. Thus, you can use synonyms when they make statements and instructions more human-readable.
Enumerations are sets of values that describe a kind of attribute. For example: Colors are given names. The set of names that might describe a color constitute an enumeration.
--- Dictionary: A car may be described by its body color. Categories for color include red, green, blue, yellow, orange, brown, . black, white, grey, purple, mauve, maroon, tan, pink, . (colors that reference something else ...) . silver, gold, copper, bronze, ivory, ebony, cobalt, cyan, taupe, charcoal, . lavender, lilac, rose, maize, indigo, magenta, chartreuse, . cranberry, raspberry, burgundy, apricot, peach, cream, . navy blue (which navy?), royal purple (which royalty?), . sky blue, forest green. ---
This probably needs more thought.
Is color a member of some semantic set?
(A "quality", a "category")
Think about the nature of enumerations.
{ dark, light }
{ short, tall }
{ small, medium, large, very large, extra large }
{ hot, warm, cold, freezing }
{ liberal, conservative, moderate, radical, reactionary }
One purpose of a view frame is to indicate how a business entity (entity) is displayed. A business entity is an object instance that appears in the problem domain. It typically will have several attributes of different types.
View frames represent "forms" (fill-in the blank forms). They are intended for text-mode displays. They can be rendered as forms in almost any run-time environment including web-pages, applets, MS-Windows, X-Windows, Java applications, et cetera.
A view frame may be used for display or for input or for both. The use depends on the context.
Should we have different verbs in dialogs to indicate display versus input?
Perhaps "Ask [entity]" versus "Show [entity]".
--- View: (entity name) label: [attribute name] << text field (1) choice one (2) choice two (3) choice three << radio buttons . (1) attribute = value1 << attribute set to value . (2) attribute = value2 . (3) attribute = value3 [1] pepperoni [2] sausage [3] green pepper << check boxes . [1] attribute1 [2] attribute2 [3] attribute3 << elements set true/false label: [enumeration name *] << combo box description: [text attribute name ... 5] << multi-line box of 5 lines [[ Place Order ]] Send my order to the kitchen. . [[ Place Order ]] Deliver [pizza] order. << Button sets goal. ---
. [[ Button Label ]] Goal-statement.
The current design does not fully anticipate voice input. The view frames could be adapted to that use. However, some serious thought is needed, because in that mode, the view frames will interact strongly with dialog frames -- the panel and dialog frames becoming closely coupled. In that kind of environment, the view frames might be designed to guide the Speaker which is running a series of prompts. The view frames might indicate optimum order.
View frames represent "forms".
Forms are ubiquitous in our culture with strong conventions.
Forms provide a traditional way to structure a communication
when several data elements are required
or when there are several choices.
People who routinely communicate in writing find them convenient.
-
An avatar that helps a user fill-in a form panel
is certainly possible.
It might be based on existing actors designed to aid people
with physical handicaps.
The following syntax expands the notation to include something like a wiki mark-up.
This provides a way to format content
and avoid the need to drop into HTML.
Hum notations are meant to be as close to written English
as possible.
In this case, we have adapted some ideas from wiki mark-up to achieve that goal.
---
View: (Example of wiki mark-up usage.)
! First-Level Heading (a main heading)
!! Second-Level Heading (a sub-heading)
!!! Third-Level Heading (a sub-sub-heading)
* First list item
** Indented list item
*** Twice indented
Emphasis is indicated as follows:
a pair of asterisk indicates *bold emphasis*
a pair of tilde indicates ~italic emphasis~
a pair of underscore indicates _underscore emphasis_
.Table (Signals the start of table formatting.)
. Row (Row -or- Header Row)
This content goes into first column by default.
. Column
This content is in second column of the first row.
. Row (Signals start of next row.)
. Column (Column -or- Header Column)
This content is in first column of the second row.
. Column
This content is in second column of the second row.
.End Table (Signals the end of table formatting.)
___ (Begin line with 3 or more "_" or "-" to indicate a horizontal-rule.)
.HTML (Signals that mark-up has switched to HTML.)
Raw HTML may be needed for features
that are not available the Hum mark-up notation.
For example, if you wanted to include an image map,
inserting raw HTML would be a way to do that.
.End HTML
---
In the Hum system, most dialogs are automatically constructed by the system. For example: When given a user goal, the Planner will construct a plan tree from task frames by back-chaining. When the plan tree is complete, the Planner will then determine what data is required to articulate the plan. Some data may be in the world memory and some may be needed from the user. The system's user interface actor will ask the user for needed data using whatever medium is available. If we are in contact with the user via HTML, an HTML page with HTML forms will be sent.
The purpose of a Dialog Frame is to describe a dialog between the user and the system. In the notation, a line starting with "U:" is something the user might say. A line starting with "S:" is the system's dialog response. A line starting with a dot "." is the system's action. This notation is the Hum equivalent of the Artificial Intelligence Markup Language (AIML) XML notation for natural language software actors.
--- Dialog: User enters site. U: Knock. (User appears at entry.) S: Hello. What can I do for you? . Show 'Activities'. U: I would like to [act]. (Browse Catalog, Check Order Status, Cancel Order, Open Account) S: An excellent choice! . Show [act]. . Switch context to [act]. --- Dialog: User browses product catalog. Context: Browse Catalog U: I want * [product category]. U: Show me * [product category]. U: Do you have * [product category]? S: Here are the different kinds of [product category]. . Show [product category] choices. . Add [product category] to context. --- Dialog: User is looking at specific product category. Context: Media U: Show me * by [artist]. S: Let us see if we have anything indexed that way. . Show [product category] items by [artist]. . (If there are none, the "Show" format will say so.) --- U: I want to buy [item.title]. U: I want to buy [item.number]. S: [item] is now in your shopping cart. You may remove it later if you change your mind. . Put [item] in shopping-cart. ---
Think more carefully about how [entity] (see above "[item]") in dialog is related to a noun in an action statement or goal statement.
Dialog frames require a full chapter to explain them. For a overview, read this decomposition of the example above:
. Show ..." instructions
are directed to the Speaker.
Here is the proverbial "Hello World" example:
--- Dialog: Hello world example. U: Knock knock. (User appears at our entry.) S: Who's there? . Set context to "first name". --- Context: first name. U: * S: * who? . Set context to "last name". . Assert: User's first name is *. --- Context: last name. U: * S: Hello, [firstName] *. . Assert: User's last-name is *.
In the example above, the "Assert:" instructions go to the "Assert" actor.
Other instructions go to the Speaker by default because no role is indicated.
Roles are indicated by the instruction syntax
". (role): ..."
- with a role-name and a colon preceding the statement.
This is the same syntax that we use in task frames and role frames
to indicate what role is performing an instruction.
Data frames are used to communicate data. They are used in message payloads between actors and resource managers, and to record configuration data. Hum authors (programmers) will rarely need to write data frames but may want to read them.
---
Data: (data set name) << Indicate a data frame. Give the frame a name/title.
Worker << The following data is for a worker (entity).
. ID: (string) << The system knows an ID should be unique.
. name: (string) << provides the data value for worker's "name" attribute.
. Home Address << "Home Address" is an embedded entity.
. . line1: (string)
. . line2: (string)
. . postal code: (string)<< "Reader" and "Smart Editor" validate values.
. age: (string) << This value should be a positive integer.
Site << The following data is for a Site (entity)
. name: (string) << name of site
. description: << The description of the site is in text format.
""" << Arbitrary text delimited by triples as shown here.
(text) << The text data starts on the line after the triple.
""" << A triple (""") or (''') starts and ends the text.
. Site Address << "Site Address" is an embedded entity.
. . line1: (string)
. . postal code: (string)
---
The comments in the example above follow the "<<" marker. The comments indicate how the data frame notation works.
In this example, we have a Worker entity and a Site entity. The Worker has four attributes: ID, name, Home Address, and age. The Home Address attribute is another entity embedded in the Worker entity data. The indentation indicates that the Home Address belongs to the Worker.
The Site entity has three attributes: name, description, and Site Address. The value of the description attribute contains multiple lines of text between lines that start with the triple quote (""" or '''). You can put any text between the triple quotes except for another line that starts the same way. (That would confuse the data reader.)
Within a Data Frame, an attribute might contain a table. This is appropriate when the attribute is a collection of "child" entities and the child entities have a "flat" structure. For example, a worker's weekly schedule might look like this:
--- Data: Worker's Scheduled Hours Worker . ID: 12345 . name: Robin Good . weekly hours: """ table of weekly-hours delimited by | | Day | Begin | End | | Monday | 0600 | 1400 | | Tuesday | 0600 | 1400 | | Wednesday | 0600 | 1400 | | Thursday | 0600 | 1400 | | Friday | 0600 | 1400 | """ ---
A table is multi-line text enclosed in triple quotes. The table text follows a special notation.
Think about how to represent relationships.
For example, suppose we have relationships such as:
"Assert: Store S is in region R." (to one)
"Assert: Store S in in state-province P." (to one)
"Assert: Male M is married to female F during period P." (association)