Built-in functions in Cwm

The processing we have done so far involves matching existing data against a template, and where a match occurs, generating more inferred data. This is much like which you do with a database using SQL, and just as with SQL, in practice you need to be able to combine it with basic arithmetic, string operations, and so on.

This is done by some magic "built-in" properties of which cwm knows the meaning. It automatically test the truth of a statement, or calculate the rest of the statement given part of it.

Built-in functions are properties for which cwm can calculate the object, given the subject.

Built-in inverse functions are properties for which cwm can calculate the subject, given the object.

Some built-ins are both. Examples are log:uri, the relationship between a resource and its URI, and time:inSeconds, the relationship between a date-time in standard string form and the date-time as number seconds since the start of the era. One can work these either way.

Relational operators are bultins where you can't calculate either side from the other, but you can test for truth if both sides have been resolved. Examples are comparison operations such as math:equalTo and string:greaterThan.

A complete list of of bultin- functions is available.

Builtin-in functions in cwm only work when they are used inside the left-hand side of a rule.

They are only used to figure out what things could take the place of a variable. If you just add data to the strore with a built-in function in it, it is just stored.

Let's make a more complicated thermostat rule::

{ :thermostat :temp ?x.  ?x math:greaterThan "70" } log:implies { :cooling :power "high" } .

The first part, :thermostat :temp ?x, is statisfied by looking in the strore, where presumably the temperature at the thermostat is stored as, say, :thermostat :temp "76.4". Under the hypothesis that ?x is is "76.4", then the second part, which now looks like "76.4" math:greaterThan "70" , is satified just by the built-in property of the math:greaterThan operator.

You can use path expressions to invoke builtins: this is of course especially useful for chaining them.

{ "1".os:argv^log:uri  log:semantics ?f } => { ?f a :InputFormula }.

You could read this along the lines of "If the first command line argument -- well, whatever has that as a URI -- has semantics f, then f is an input formula". Here it is in longhand:

{ "1".os:argv  ?x.
  ?d log:uri   ?x.
  ?d log:semantics ?f
} => {
  ?f a :InputFormula
}.

Some functions need more than one parameter. The convention we have used is that they take lists as the subject.

{   ((?x.tempInF "32").math:difference "0.5555") math:product ?c) } => { ?x tempInC ?c}.
 

Let's look at that one without the path expressions.

{   (?x.tempInF "32") math:difference ?a.
    (?a "0.5555") math:product ?c.
} => {
     ?x  tempInC ?c.
}.
 

Tip: Its useful to think of where the rule engine is going to start with some data, which will alow it to find the values of variables.

{ ?x math:greaterThan ?y. } => { ?x :moreInterestingThan ?y }.

This doesn't give cwm, a forward reasoner, much to go on. It won't list all pairs of number where the first is greater than the second. A backward reasoner, such as Euler, will be able to use that. Future semantic web engines will get smarter about picking rules to use and algorithms to use them with.

These built-in functions give allow you to use basic properties of strings and numbers in your rules. They also allow you to do pragmatic things, such as pick up command line parameters and environment variables, which allow the whole rules system to be parameterized. They also allow you do do somthing else. They allow you to make rules which interrogate the Web, parse documents, and look objectively at the contents of documents. This opens up some very interesting possibilities -- so much so that it warrants a move to the next chapter.