The Query Language CBQL

 

In ConceptBase queries are defined as special classes whose instances are the answers to the query [STAU90]. This section first defines the structural properties of the query language CBQL and then introduces the predicative component. Queries are instances of a system class QueryClass which is defined as follows:

Individual QueryClass in Class isA Class with
     attribute
         retrieved_attribute: Proposition;
         computed_attribute: Proposition
     attribute,single
         constraint: MSFOLquery
end

If one specifies super-classes to a query class then all answers must be instances of the super-classes, i.e. the answers are restricted by the ranges of the super-classes. Example: ``socially interested'' are those managers that are member of a union.

Individual Union in Class, SimpleClass
end

Individual UnionMember in Class, SimpleClass with
    attribute
        union:Union
end 

QueryClass SI_Manager_0 isA Manager,UnionMember
end


QueryClass SI_Manager isA Manager,UnionMember with
     retrieved_attribute
         union: Union;
         salary: Integer
end

Note that the super-classes themselves may be query classes which is the first kind of query recombination. The second frame shows the feature of retrieved attributes which is similar to projection in relational algebra. Example: one wants to see the name of the union and the salary of socially interested managers. The attributes must be present in one of the super-classes of the query class. In this example, the union attribute is obviously inherited from the class UnionMember and salary is inherited from Manager. CBQL demands that retrieved attributes are necessary: each answer must instantiate them. If an object does not have such an attribute then it will not be part of the solution. As usual with attribute inheritance, one may specialize the attribute value class, e.g.

QueryClass Well_off_SI_Manager isA SI_Manager with
     retrieved_attribute
         salary: HighSalary
end 


Individual HighSalary in Class,SimpleClass isA Integer with
     rule
       highsalaryrule: $ forall m/Integer
                           (m >= 60000) 
                                 ==> (m in HighSalary)
                       $ 
end

The new attribute value class HighSalary is a subclass of Integer so that each solution of the restricted query class is also a solution of the more general one. It should also be noted that HighSalary also could have been another query class. This is the second way of query recombination.

Retrieved attributes and super-classes already offer a simple way of querying a knowledge base: projection and set intersection. For more expressive queries there is an predicative extension, the so-called query constraint. We use the same many-sorted predicative language as in section 2.2 for deductive rules and integrity constraints and introduce a useful abbreviation:

Let Q be a query class with a constraint F that contains the predefined variable this. Then the query rule is an abbreviation for the formula

forall this/Proposition F ==> Q(this)

ConceptBase automatically derives solutions (this in Q) from the answer literal Q(this).

This means that this stands for any answer object of Q. The following example shows how to use it.

QueryClass Well_off_SI_Manager1 isA SI_Manager with
     retrieved_attribute
         union: Union
     constraint
         well_off_rule: $ exists s/HighSalary
                        (this salary s) $
end

Classes occuring in a query constraint may be query classes. This is the third way of query recombination. The next feature introduces so-called computed attributes, i.e. attributes that are defined for the query class itself but not for its super-classes. The assignment of values for the solution is defined within the query rule. We introduce a second abbreviation:

If ca is the label of a computed attribute with class C of query class Q with query rule F then F stands for the formula

         forall this/Proposition forall v/C
                F' ==> Q(this,v).

The primed F' stands for the substitution F[v/ca]. If Q contains more than one computed attribute then the answer literal Q(...) has a corresponding number of additional parameters. ConceptBase automatically derives solutions (this in Q), (this ca v) from the answer literal.

The following example defines a computed attribute head_of that stands for the department a manager is leading.

QueryClass Well_off_SI_Manager2 isA SI_Manager with
     retrieved_attribute
         union: Union
     computed_attribute
         head_of: Department
     constraint
         well_off_rule: $ exists s/HighSalary
                    (this salary s) and
                    (~head_of head this) $
end

Note, that since ConceptBase 5.0 the variable head_of for the computed attribute must be prefixed with ~.

Like retrieved attributes computed attributes are necessary, i.e. any solution of a query with a computed attribute must assign a value for this attribute. Example:

Individual Lloyd in Well_off_SI_Manager2 with
     union
        LloydsUnion : DAG
     head_of
        COMPUTED : Production
end 


Individual DAG in Union
end 


Individual Production in Department
end

Recursion can be introduced to queries by using recursive deductive rules or by refering recursively to query classes. The example asks for all direct or indirect bosses of Bill:

QueryClass BillsMetaBoss isA Manager with
     constraint
         billsBosses: 
            $ (Bill boss this) or
              exists m/Manager 
                (m in BillsMetaBoss) and
                (m boss this)$
end

Further examples can be found in the directory

$CB_HOME/examples/QUERIES.

Queries are represented as Telos classes and consequently they can be stored in the knowledge base for future use. It is a common case that one knows at design time generic queries that are executed at run-time with certain parameters. CBQL supports such parameterized queries:

Individual GenericQueryClass isA QueryClass with
     attribute
        parameter: Proposition
end

Generic queries are queries of their own right: they can be evaluated. Their speciality is that one can easily derive specialized forms of them by substituting the parameters. An important property is that each solution of a spezialized form is also a solution of the generic query. This is a replay of the inheritance paradigm. The example shows that parameters can be retrieved or computed attributes at the same time: (note, that variable for the parameter in the constraint is prefixed with ~).

GenericQueryClass What_SI_Manager isA Manager,UnionMember with
     retrieved_attribute,parameter
        salary: HighSalary;
        u: Union
     computed_attribute,parameter
        head_of: Department
     constraint
        well_off_rule: $(this union ~u) and (~head_of head this)$
end

There are two kinds of specializing generic query classes:

1. Specialization of a parameter [a:C']

   Example: What_SI_Manager[salary:TopSalary]

   In this case TopSalary must be a subclass of HighSalary. The solutions are those managers in What_SI_Manager that not only have a high but a top salary.

2. Instantiation of a parameter [v/a]

   Example: What_SI_Manager[Research/head_of]

   The variable head_of is the replaced by the constant Research (which must be an instance of Department).

One may also combine several specializations, e.g.

         What_SI_Manager[salary:TopSalary,Research/head_of].

The specialized queries can occur in other queries in any place where ordinary classes can occur, e.g.

QueryClass FavoriteDepartment isA Department with
     retrieved_attribute
         head: What_SI_Manager[10000/salary]
end

Parameters that don't occur as computed or retrieved attributes are interpreted as existential quantifications if they are not instantiated.

The current implementation provides two executable representations for query classes: SLDNF (Prolog) and MS (Magic set). The first one is efficient in time and space but currently not able to handle recursion. You can specify the default representation when you start the CBserver with the command line argument -q <queryrep>, where <queryrep> must be either SLDNF or MagicSet. If it is set to SLDNF one may use the Magic class to override it:

QueryClass Q in Magic ...

Similar deductive rules can also be represented in the magic format. This is done by using the mrule instead of the rule category:

   ...
   mrule,rule
      myrule: $ forall ... $
        ...

Both representations can be mixed but one should notice that query classes and rules in SLDNF format don't have access to the MS format of other queries and rules.