Dear Adrian and 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
Hi John & All,
There's another dimension to the discussion about storing rules, triggers etc
in an SQL database.
As John has described, the result is a Rube Goldberg combination of different
semantics of different components, reminiscent of the OWL/RDF/SPARQL
"stack".
True, using domains as I
suggested is by no means an elegant solution, but it works.
Exposing these different components provides many job
opportunities for programmers, but un-maintainability comes much sooner than it
should as such a system scales up in complexity.
Also very true, but there
is presently no economical alternative that works well in products that are economic
and available and well supported.
Bottom line -- there should be a single clean
programmer interface with well defined semantics. The interface can be
implemented with different subsystems, but they should be completely hidden in
a black box.
Agreed also, but such an
approach remains a customization of existing products, mostly using domains as
I suggested in the previous email. There are other ways to do the same thing,
but like you say, they are all kludges in one way or another.
Just my 2 cents.
Thanks! Well worth the
price!
-- Adrian
Internet Business Logic
A Wiki and SOA Endpoint for Executable Open Vocabulary English Q/A over SQL and
RDF
Online at www.reengineeringllc.com
Shared use is free, and there are no advertisements
Adrian Walker
Reengineering
On Sat, Aug 11, 2012 at 8:41 AM, John F Sowa <sowa@xxxxxxxxxxx> wrote:
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.
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).
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.