[Top] [All Lists]

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

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Rich Cooper" <rich@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sun, 12 Aug 2012 10:53:41 -0700
Message-id: <B3312FF7413E4A44AEDC04681E03D2F6@Gateway>

Dear John,


My comments are below,




Rich Cooper


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. 




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)

<Prev in Thread] Current Thread [Next in Thread>