supported ops and apply

So a couple of key components today.
Let's start with "supported-ops".
The idea is for every ket, to keep a record of operators that are supported by that ket.
This BTW is built into the context.learn() code, so we never generate it manually, and (the parser) ignores you if you try.

The convention is simply, use "op: " as the category/data-type for operators.
So, a simple example:
sa: name |Fred> => |Fred Roberts>
sa: height |Fred> => |cm: 176>
-- use "dump exact" else supported-ops lines are left out for readability reasons.
sa: dump exact
----------------------------------------
|context> => |context: sw console>

supported-ops |Fred> => |op: name> + |op: height>
name |Fred> => |Fred Roberts>
height |Fred> => |cm: 176>
----------------------------------------
So we see the "name" operator is called |op: name>
And the "height" operator is called |op: height>

Now, add in a little more knowledge:
sa: dob |Fred> => |date: 17/5/1986>
sa: friends |Fred> => |Mary> + |Liz> + |Tom> + |Frank>
sa: mother |Fred> => |Sarah Roberts>
sa: father |Fred> => |James Roberts>

-- see the supported-ops for Fred:
sa: supported-ops |Fred>
|op: name> + |op: height> + |op: dob> + |op: friends> + |op: mother> + |op: father>

So, what is the use of this thing?
Well, one example usage (there are others) is to make use of it in the apply() function (more on functions in BKO later!)

sa: apply(|op: father> + |op: mother>,|Fred>)
|James Roberts> + |Sarah Roberts>

And here is one way to see everything we know about Fred in one superposition:
sa: apply(supported-ops |Fred>,|Fred>)
|Fred Roberts> + |cm: 176> + |date: 17/5/1986> + |Mary> + |Liz> + |Tom> + |Frank> + |Sarah Roberts> + |James Roberts>

And once more for luck, here is everything we now know about Fred: 
sa: dump exact
----------------------------------------
|context> => |context: sw console>

supported-ops |Fred> => |op: name> + |op: height> + |op: dob> + |op: friends> + |op: mother> + |op: father>
name |Fred> => |Fred Roberts>
height |Fred> => |cm: 176>
dob |Fred> => |date: 17/5/1986>
friends |Fred> => |Mary> + |Liz> + |Tom> + |Frank>
mother |Fred> => |Sarah Roberts>
father |Fred> => |James Roberts>
----------------------------------------
And once more! We are working on knowledge representation, right? Well, one component of that is there are multiple possible representations of the same knowledge. Here is a more readable version (compared to standard BKO), the display function: 
sa: display |Fred>
  Fred
  supported-ops: op: name, op: height, op: dob, op: friends, op: mother, op: father
           name: Fred Roberts
         height: cm: 176
            dob: date: 17/5/1986
        friends: Mary, Liz, Tom, Frank
         mother: Sarah Roberts
         father: James Roberts
I will write up inverse in the next post. Decided they needed separate posts.

Update: apply() is really quite useful. I probably should have put it in its own post, but too late now. Anyway, one common usage is this thing: 
star |*> #=> apply(supported-ops |_self>,|_self>)
which returns everything we know about a ket in one superposition. Alternatively, we could call it: 
what-do-you-know-about |*> #=> apply(supported-ops |_self>,|_self>)
Update: for a quick guide to how well you understand something (in this case "x"), you can do:
how-many supported-ops |x>

Update: now with the magic of tables: 
  name |Fred> => |Fred Roberts>
  height |Fred> => |cm: 176>
  dob |Fred> => |date: 17/5/1986>
  friends |Fred> => |Mary> + |Liz> + |Tom> + |Frank>
  mother |Fred> => |Sarah Roberts>
  father |Fred> => |James Roberts>
  Fred |*> #=> apply(|_self>,|Fred>)

sa: table[op,Fred] ops |Fred>
+---------+-----------------------+
| op      | Fred                  |
+---------+-----------------------+
| name    | Fred Roberts          |
| height  | 176                   |
| dob     | 17/5/1986             |
| friends | Mary, Liz, Tom, Frank |
| mother  | Sarah Roberts         |
| father  | James Roberts         |
+---------+-----------------------+


Home
previous: learning indirectly
next: inverse

updated: 19/12/2016
by Garry Morrison
email: garry -at- semantic-db.org