 |
 |
 |
 |
|
 |
Overview:
the View Factory |
|
[Back to Architecture]
[View definition] [View
creation]
The View Factory updates the cache adding more structure (classes,
attributes, methods) and data.
Given the following information:
-
current schema
The current schema is the schema of the
cache resulting from previous queries. When asking a first query, the current
schema is empty.
-
target structure
The target structure is the structure
inferred from the user's query by matching schema components and completion,
required to answer the user's query. For example, when asking "What
are the conferences located in Paris?", a target
structure composed of two concept classes
Conference
and Location combined with the attribute location
is inferred from the query.
the View Factory computes the view definition.
[TOP]
View definition
Our view definitions are simple since our actual conceptual representation
is flat (there is no subclassing relationship between concept classes).
Intuitively, when a concept class is expressed in the user's query, then
it has to be defined in the schema of the cache specialized with the attributes
necessary to answer the query. A view definition results from a translation
of the target structure into a view-expression.
The view-expressions are either of the form:
-
c <= Specialization_P(), when class c is defined from
scratch with attributes mentioned in P.
-
c <= Specialization_P(c), when class c is already
defined in the cache, but has to be specialized by attributes mentioned
in
P.
Suppose that the user is asking "What are the conferences with a submission
deadline in 1998?", as a first query. The query can be expressed as:
select x.name
from x in Conference
where x.submission_deadline.year=1998
and the target structure extracted by the Dispatcher consists of
two classes Conference and Date
combined with the attribute submission_deadline.
The
View Factory checks the current schema,
which is empty, since it is the first query, and generates the following
view-definition.
e_1 = Conference <= Specialization_{(name, Conference->string),
(submission_deadline, Conference->Date)}(),
Date <= Specialization_{(month, Date->integer),
(day, Date->integer),
(year, Date->integer)}()
Both classes Conference and Date are defined from scratch
(always specialized by their corresponding key attributes).
Suppose now that the user asks a second query (refinement) such as "What
are the conferences located in Paris?", expressed by:
select x.name
from x in Conference
where x.location.city="Paris"
The target structure extracted by the Dispatcher consists of two
classes Conference and Location
combined with the attribute location. The
current schema has two classes Conference
and Date combined with the attribute submission_deadline.
The
View Factory generates the the following view-definition.
e_2 = Conference <= Specialization_{(location, Conference->Location)}(),
Location <= Specialization_{(city, Location->string),
(state, Location->string),
(country, Location->string)}()
Class Conference is already defined, but has to be specialized
by a new attribute location. Class Location has to be
defined.
[TOP]
View creation
When the view-expression is generated, the
cache can be updated.
Updating the schema
The view mechanism is based on object-oriented inheritance. Refining (or
specializing) a class, means extending it (in the OO sense).
-
c <= Specialization_P(), an object class c is defined
from scratch with attributes mentioned in P.
-
c <= Specialization_P(c), a class c_ specializes (already
existing class c) with attributes mentioned in
P. Class
c_ is a subclass of c.
Updating the data
Once the new schema has been built, the task is now to migrate the objects
of the cache. The migration is done in two steps: (1) we copy the information
that already exists and (2) we compute the missing information. Each instance
of a class in the AKIRA cache can build itself out of an instance of a
super class. An instance of Conference_ (defined by the extension
e_2 of e_1) is created from an instance of Conference
(defined by the extension e_1). When migrating from Conference
to Conference_, the system automatically uses information extraction
agents for
location.
[TOP]
Copyright AKIRA Project, University
of Pennsylvania
Department of Computer
and Information Science, Institute
for Research in Cognitive Science