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.