The type checker can be used to validate the type, or more specifically, the type signature of an atom. Type checking is performed by the pattern matcher to restrict the kinds of types that might be matched during a pattern query. Type checking is also performed by PutLink, to avoid the creation of inappropriate structures, thus implementing a defacto kind of FilterLink. Type checking is also performed by MapLink, again, to perform a kind of filtering (the MapLink should be thought of as a dual to PutLink: its an UnputLink).
In the future, type checking might be used to prevent the insertion of inappropriate atom types into the AtomSpace.
Type-checking code is primarily located in the "is_type()" method on class Variables; see /opencog/atoms/core/Variables.h However, it is also performed in an ad-hoc basis in several places. One such is the MapLink::extract() method, which does the recursive type checking needed to unput values in types; see /opencog/atoms/core/MapLink.cc.
At this time, it does not have a scheme wrapper, but it could; see below.
Currently in the Atomspace, nothing stops you from creating
InheritanceLink NumberNode "9" GroundedSchemaNode "print"
even though this is nonsense....
Also, if we had a PredicateNode whose input is supposed to be a GroundedSchemaNode mapping NumberNodes to NumberNodes, e.g.
PredicateNode isDifferentiable GroundedSchemaNode "x squared" ExecutionLink GroundedSchemaNode "xsquared" NumberNode 3 NumberNode 9
We have no way to represent these type distinctions so we could also form
PredicateNode isDifferentiable WordNode "frog" ExecutionLink GroundedSchemaNode "xsquared" Sentence Node "I am not squarable"
It would be useful to be able to verify that a link or a node is of a specific type.
The type of an atom can be specified by using a SignatureLink. If the atom is just a node, the TypeNode can be used to specify it's type. If the atom can be any one of several types (i.e. it is polymorphic), the TypeChoice link can be used.
The above-mentioned "is_type()" method on class Variables will return a yes/no answer as to whether a given graph is a given type.
To search for all graphs of a given type, this could be done as follows:
GetLink TypedVariableLink VariableNode "$X" SignatureLink .. whatever deep type you want... VariableNode "$X"
which will return all atoms having the specified signature. This query works today. This query is currently not optimized, and might run slow on a big atomspace. Its not hard to make it run faster, no one has needed this yet.
A new function, say 'cog-check-type' could be created (it hasn't been yet): it would accept two arguments: a SignatureLink, and an atom whose type needs to be checked.
Type checking could be performed at the time that atoms are added to the AtomSpace: the AtomSpace could maintain an table of approved types that are admitted, and compare to each. Because checking would slow down the addition of atoms, it would probably have to be made optional.
I suppose the only value of these would be to flag an error if someone's code created links that don't make sense. This may not be a problem that exists right now, thus it may not be worth solving the problem right now....
On the other hand, even if we don't enforce the type restrictions on code right now it would be useful to have clearly stated somewhere what type restrictions the Link types in use now are supposed to have. This info is all contained in some publication somewhere but is not always easy to find...
The page OpenCogPrime:TypeInheritance discusses how type inheritance works. If one merely need to see if (A->B) inherits from (C->D), one can do that with a 5-line-long scheme program or a 20-line long c++ (or a 10-line python program) I'm not sure where this would be needed, currently...
The pattern matcher does not check type inheritance at the moment; it could do this, with a minor extension. Define two new atoms TypeInhNode and TypeCoInhNode that work just like TypeNode, except that the first one looks downwards in the type-inheritance hierarchy, while the second looks upwards.