User, inference engine, and RDBMS interactions

The inferred data should be seen as a regular relation. In such a case SQL remains the communication method between the user and the database. The inference engine becomes transparent. As it is mentioned in Section 8.2, this relation can be perceived as a view.

The user communicates with the database issuing SQL queries. If the query refers to a view which is to be generated by the inference engine, then the inference engine takes over, generates the required data, and then the query may be processed by the database. The user cannot distinguish if the data is generated by the inference engine, or if this is just a plain view^8.4. This dynamically generated view is called a Jelly View.

If the query does not involve a Jelly View, then it is passed to the database. So the system can be applied to existing databases. The inference engine is used only when necessary. The performance and functionality of the database is not spoiled.

Having a Jelly View which is a regular view, has one drawback. There is no way to pass directly any parameters to it. There are two options then:

• make the view taking parameters which are placed in some other relation prior to the query, or
• use the syntax of function, instead of that of a view.

In the first case the relation which holds parameters should be a temporary one, in order to avoid conflicts with other sessions, or just users connected to the same database. It has a significant drawback. Any parameter passing requires the insertion of the parameters into some well defined relation, prior to the execution of the query. So it requires a two-step querying, which is ineffective and requires additional efforts to be taken by the user.

The second approach is much better than the first one. The function syntax can be used instead of the parameterless view. Therefore, parameters may be passed directly to a Jelly View. Assuming that there is a Jelly View sibling which infers data about defined siblings. A query: ``Who is Simon's sibling?'' can be issued as follows:

  SELECT * FROM sibling('simon',NULL);

NULL keyword indicates that the second parameter is unbounded. Therefore, values for the second attribute of the view will be inferred. The second approach is selected then.