ontolog-forum
[Top] [All Lists]

[ontolog-forum] Executable English and Logic (Was: accounting inteoperab

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Adrian Walker" <adriandwalker@xxxxxxxxx>
Date: Sat, 10 May 2008 16:04:01 -0400
Message-id: <1e89d6a40805101304med8c430h3460962afea3370e@xxxxxxxxxxxxxx>
Hi John --

Yes, as you say, an executable "pivot" logic language is most important.

I think we would all agree that such a language has to have a useful model theoretic semantics. 

Classical logic is a prime candidate language.  Unfortunately, classical logic assigns a meaning to negation that differs from the way databases are actually used.  So Common Logic, OMG SBVR, and many other widely discussed language designs -- surprisingly -- don't actually assign relevant meanings for practical use with relational databases.  (To see this, note that classical logic reasoning over a current IBM employee database answers the question "Does John_Sowa work for IBM ?" with "Unknown", whereas the answer should be "No" **.)

It is mainly because of this divergence from actual usage that the semantics of Datalog extended with negation-as-failure (NAF) has been widely studied, and has been assigned its own model theoretic semantics.  The semantics used inside the Internet Business Logic system [1] is based on a model theory [2] for Datalog extended with NAF,  with some further extensions for aggregation and other numeric computation.

I believe that where you and I agree is that it's crucial to have an executable English layer between end author-users and the logic.  Such a layer captures the intention of an author, so that a user can see what the intention is.  Calling this a "semantic layer" would seem to be justifiable.

You and I appear to diverge on where the semantics for the English layer should reside.  You advocate an approach based on a grammar of English together with a dictionary defining, once and forever, the meanings of individual words.  I advocate a lightweight approach in which words take their meaning from context, because it appears to be less brittle, and better able to support government acronyms, jargon usage, ontological notations [3,4], and so on.  The lightweight approach is the one used in [1].

Your point about avoiding lock-in by supporting a broad version of logic is well taken, so long as the model theoretic semantics is a relevant one.  For developers, rather than end-authors, [1] provides a Service Oriented Architecture endpoint on the Web.  Developers can use notations such as in the example [5].

                                   Cheers,  -- Adrian

[1]  Internet Business Logic.  A Wiki and SOA Endpoint for Executable Open Vocabulary English over SQL.  Online at www.reengineeringllc.com    Shared use is free

[2]  Backchain Iteration: Towards a Practical Inference Method that is Simple
  Enough to be Proved Terminating, Sound and Complete. Journal of Automated Reasoning, 11:1-22.  (This is an early paper, and others have extended the semantics in an upward compatible manner.)

[3]  www.reengineeringllc.com/demo_agents/SemanticResolution1.agent

[4]  www.reengineeringllc.com/demo_agents/RDFQueryLangComparison1.agent

[5]  www.reengineeringllc.com/demo_agents/RelBioOntDefn3.agent

** This can be finagled, but then you are no longer using a clean model theoretic semantics, or you are hacking at the application level.




On Sat, May 10, 2008 at 11:33 AM, John F. Sowa <sowa@xxxxxxxxxxx> wrote:
Adrian,

As I've said many times, I believe that humanly readable
versions of logic such as executable English and various
kinds of controlled natural languages are important.

However, I would not call any such language a "semantic
layer".  All of them are formalized languages that express
some version of logic, and that logic (plus whatever
ontology is used) would be the semantic layer.

I'm not sure what version of logic your executable English
covers, but I had the impression that it's a Horn clause
subset of FOL closely related to Datalog.  I'm sure you have
specified that logic, but that logic is the appropriate level
for standardization and interchange.

That is the primary role of the Common Logic standard:
define a flexible and expressive version of logic that
includes many widely used logic-based languages as subsets.
Datalog is one subset, and I suspect that executable English
is equivalent to either Datalog or some subset of Datalog.

Having a semantic layer that can be supported by many
different surface notations is essential for promoting
widespread use.  Businesses are reluctant to build
mission-critical applications on languages that lock them
into a single supplier -- especially a small supplier.

But if the level of lock-in is a broad version of logic,
such as Common Logic or Datalog, they would have much
greater freedom to experiment with novel notations.
Anything that they implemented in executable English,
for example, could be automatically converted to or
from any other notation that supported the same logic.

That option maximizes the flexibility and opportunity
for everybody.  Developers could choose any notation
that provided the best human factors and methodologies
for their users without worrying about being locked into
a system that might not be supported for the long term.

John



_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: 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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx



_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Subscribe/Config: 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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (01)

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