Using IBML as a Query Language
Version 2.001 2020-11-20
ORIGINAL Date: Mon, 8 Aug 2005 18:08:01 -0700 (PDT)
- Author:
- Richard Weyhrauch (IBUKI)
- Note:
- The information in this document (and its companion documents) is
the confidential proprietary property of IBUKI. It contains trade secret,
published and unpublished components. The SEUS has been developed over
a substantial period of time at IBUKI's expense.
We want to specify query language and search system (or collection system)
that can use this query in realtime to get a useful answer - including the
possibility of reconfiguring the entire search system for better performance.
We will use IBML to dramatically increase the complexity of the questions
that can be asked - and to say why we can expect that our searcher can
use this to find meaningful answer. We will use these ideas as a blueprint
to build (and by extension sell) a searcher that can answer such questions.
========================================
A simple example.
The syntax I am using comes is a simplified version of that given in "Getting
started with IBML Type Definitions".
The basic idea is as follows:
IBML gives us the ability to define some data structures called types.
Associated with each type is a collection of objects called its examples
examples(T) = E
We think about the elements of E as the examples of things of type T. We
also have a relation on types called "refinement". We write
T2 refines T1
to mean that the examples of things of type T2 "have at least as much and
hopefully more information" then the things of type T1. We note that refining
a type results in no loss of information.
Types not only describe objects but WE CAN USE TYPES AS QUERIES in the
sense that each type can be also thought of as a question "What more
specific information can be found out about the things described by
this type?", i.e., find me a refinement of this type possibly both by
looking in a DB or looking at our environment. The ability to integrate
this view with using sensors to gather information leads us to sometimes
call our searcher a collection system.
=========================================
Suppose we want to know about driving times between cities. The first
thing we would do is rev up the searcher interface. It comes up with
a screen that has a menu
what are you interested in today
"Trouble in Burma (is there still a Burma?)"
"Driving Times"
"Terrorists in General"
...
This screen is generated because the searcher knows which types/models it
knows how to refine. We imagine the user picks "Driving Times". A new
screen appears containing
starting-city |NYC| (multiple choice)
|DC|
|Aspen|
ending-city |NYC| (multiple choice)
|DC|
|Aspen|
driving-time-in-minutes lowest [ 0] highest [ ]
where did the system get this screen from? The SEARCHER has a "master" type
(or model) of [driving time] and in IBML would be defined as
(|model| [driving-time]
(|starting-city| *type* [us-city])
(|ending-city| *type* [us-city])
(|driving-time-in-minute| *type* {0 ... ))
)
The meaning of this type definition is that the attributes, |starting-city|
and |ending-city| are to be examples of the type [us-city]. Suppose there are
three examples of cities (which here are just symbols): |NYC| |DC| and |Aspen|.
And [driving-time-in-minites] is of type [range]. The screen can be generated
automatically from this model (how this happens requires tools available to
the search system for rendering querys that DATA-MINE the user!!! Note this
already uses IBML types (our model of [driving-time]) to query the user.
Vaguely put, the type specifies the following examples:
{ |
c1, c2 are [us-city]s and
nat1, nat2 are [integer]s
nat1 <= nat2
From the point of view of the search system this is a QUERY that describes
what general information the search system can find uot about driving times.
The search system then asks the user to "describe/refine" this query by
saying how to narrow the search to driving times of interest.
=========================================================
Scenario 1. The user chooses the starting cities NYC and DC and the ending
city Aspen.
The result of "querying/data-mining the user" is the model
(|model| [driving-time-user-query4529]
refinement-of
[driving-time]
(|starting-city| *type* {|NYC| |DC|})
(|ending-city| *data* |Aspen|)
(|driving-time-in-minutes| *type* {0 ...})
)
Note: The result of this "querying the user" was a new type which is a
refinement of the original general model/query!!!! That is, a query is
a type and its answer was a refinement (subtype) of that type. In this
view the answer to a query is always a type that is a refinement of the
original query. In this view the operations that are of interest to us
are the operations on types, not the hunt for examples.
The search system then uses its prowess to 'search the world' for what it
knows. It finally returns with
(|model| [ans-driving-time-user-query4529]
refinement-of
[driving-time-user-query4529]
(|examples|
((starting-city *data* |NYC|)
(ending-city *data* |Aspen|)
(driving-time-in-minutes *data* {120 ...})
)
((|starting-city| *data* |DC|)
(|ending-city| *data* |Aspen|))
(|driving-time-in-minutes| *data* {3000 ... 3600})
)
)
)
Once again the answer to the query is a refinement of the query. Note that
it has some information but some is under-determined. It "discovered" an
estimate of the time from DC to Aspen (between 50 and 60 hours) but was
unable to narrow the time for NYC to Aspen by much, but it knew that it
takes 2 hours to get out of the city to anywhere. This information can
be returned to the user in some convienent form. This note does not
cover the tools the search system has for making this refinement.
=========================================================
Scenario 2. We choose as starting city NYC and 20 min max.
The result of "querying/data-mining the user" is the model
(model [driving-time-result-query4530]
refinement-of
[driving-time]
(|starting-city| *data* |NYC|)
(|ending-city| *type* [us-city])
(|driving-time-in-minutes| *type* {0 ... 20})
)
The result is again a new type which is a refinement of the original
model/query!!!! This time the 'starting-city' is only |NYC| and the user
doesn't care where they go! as long as you can get there in a hurry (20
min or less).
The search system then uses its prowess to 'search the world' for what it
knows. It finally returns with
(|model| [ans-driving-time-user-query4530]
refinement-of
[driving-time-result-user-query4529]
(|examples|
(
(|starting-city| *data* |NYC|)
(|ending-city| *data* {})
(|driving-time-in-minutes| *data* 0)
)
)
)
Once again the answer to the query is a refinement of it. Note that there are
no destinations or range of minutes that 'made sense'. (How the constraint
that the |starting-city| and the |ending-city| is expressed is not covered
in this note.) The result is again returned to the user in some convienent
form.
=========================================================
By writing down these simple types I hope the ideas are a little clearer.
It shows what types look like and how types can be used as queries that
a system can use both to ask the user about the information they need
and to ask 'the environment' (including databases and sensors) for an
answer. I also hinted at how a user interface can be generated uniformly
from types just on the basis of the definition of a type and the type of
the values of its attributes.
This shows how IBML types can be used to build working system that covers
everything from user interaction to the information search system itself.
| 