Re: [ontolog-forum] Ontologies, knowledge model, knowledge base

[Adrian Walker <adriandwalker@xxxxxxxxx>]

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".

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.

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.

Just my 2 cents.

                                -- 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.

John

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (01)