Dear John,
My comments are below,
-Rich
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
On 8/10/2012 4:51 PM, Rich
Cooper wrote:
> The reason it is
important to store rules as well as facts in the > database is that such
architecture makes it very easy to store a table > of context IDs and relate
them to which rules and facts apply to each > context ID. Searching for
contexts becomes very manageable with that
> method.
But you need to do much
more than storing and finding rules in order to make a DB into a deductive
DB. The critical task is to make the deductive component a natural
extension of the query component.
Yes, and many SQL
implementations allow the programmer to define application-specific
domains. Defining custom domains lets the programmer encode a deduction
engine to use the “rule” domain as a structure encoded in the <Node,Arc>
tables which are stored in the database, and queries which are either stored as
“query” domains or simply interpreted by the application if the
queries are not dynamic.
In SQL, for example, a
view V uses a WHERE-clause to define a *virtual* relation that accesses some
logical combination of other relations (which may be stored and/or virtual
relations).
True, and views are very
useful, but you also need to keep running the view queries when changes have
been made to the underlying data. There may be some SQLs now that support
in-view updates automatically, but I haven’t found any. I also
haven’t looked recently, so they may exist, but if so they are
recent.
To an SQL user, V looks
like an ordinary relation. But any use of V will trigger a
backward-chaining deduction that is similar to what happens in a rule-based
language like Prolog.
SQL implementations use a
method of storing and indexing their relations, either stored or virtual.
But that method is separate from the methods for storing data. If you
store a view as data in the DB, it will never get used as a view.
If you are referring to
the rule encoding in <Node,Arc> tables I mentioned, I don’t quite
understand how you can store a view as data, other than the specification of
the view. Why would you want to store a view that way? Perhaps you
are thinking of a case where the view specifications are stored, and updatable,
in which case you have to reexecute the view definition SQL statement to make
the view change.
John