Re: PowerLoom's BNF usage

At 21:59 -0700 7/7/08, Hans Chalupsky wrote:
> Cameron,
>
> thanks for the pointer.  It definitely make sense to relate PL-KIF to
> CLIF and align them as much as possible.  PowerLoom was intended to
> support multiple logic dialects (thus the "in-dialect" construct).  If
> we can't reasonably make PL-KIF a superset of CLIF, we should at least
> be able to support them as alternative input language variants.
> Given that Common Logic is an actual ISO standard now, we have some
> motivation to attempt this fairly soon.

At 22:15 -0700 7/7/08, Hans Chalupsky wrote:
> ...  As I said in a previous message, given that Common
> Logic is a bonafide standard now, we'll work on making the
> relationship between Common Logic and PL-KIF more precise.

+1


Full disclosure: I sat in on the Common Logic email list, asked some
questions, sent in copy edits, and helped write the Wikipedia entry.
So, I'm pretty familiar with the project, but nowhere near being an
expert on the standard's finer technical points.  For that, you'll
want to rope in some of the standard's authors (eg, Delaguch, Hays,
Menzel, Sowa).  A note to the mailing list ([email protected])
would probably be a Good Idea, as someone might offer to help.


One of the really interesting things about Common Logic is that it
defines semantic capabilities, but not syntax.  Sort of "duck typing,
applied to language definition".  If a syntax can be mechanically
translated to/from another Common Logic representation, it qualifies
as a Common Logic dialect.  The Wikipedia entry, more formally, says:

  Common Logic (CL) is a framework for a family of logic languages,
  based on first-order logic, intended to facilitate the exchange
  and transmission of knowledge in computer-based systems.  The CL
  definition permits and encourages the development of a variety of
  different syntactic forms, called "dialects."  A dialect may use
  any desired syntax, but it must be possible to demonstrate precisely
  how the concrete syntax of a dialect conforms to the abstract CL
  semantics, which are based on a model theoretic interpretation.
  Each dialect may be then treated as a formal language.

  Once syntactic conformance is established, a dialect gets the CL
  semantics for free, as they are specified relative to the abstract
  syntax only, and hence are inherited by any conformant dialect.
  In addition, all CL dialects are equivalent (i.e., can be
  mechanically translated to each other), although some may be more
  expressive than others.  In general, a less expressive subset of
  CL may be translated to a more expressive version of CL, but the
  reverse translation is only defined on a subset of the larger
  language.

    http://en.wikipedia.org/wiki/Common_logic


As a result, there are several Common Logic dialects, including:

  Conceptual Graph Interchange Format (CGIF)

  Common Logic Controlled English (CLCE)
  http://www.jfsowa.com/clce/specs.htm

  Common Logic Interchange Format (CLIF)

  eXtended Common Logic Markup Language (XCL)


As Hans notes, there are several approaches to PL supporting CL.
All of them require "making the relationship between Common Logic
and PL-KIF more precise".  However, the devil is in the details.

  *  "make PL-KIF a superset of CLIF" - Given CL's goals and
     approach, I would be amazed if PL critically needs anything
     that CL doesn't handle.  However, the relationship needs to
     be made precise enough to enable mechanical translation.

  *  Supporting CL as an alternative input language variant isn't
     really enough.  In order to be a full player (not to mention
     having a way to test things out), PL will need translation
     both to and from a CL dialect (presumably, CLIF).


With these things in place, however, PL stands to gain greatly
from becoming a participant in the standard.  PL's users would be
able to import and export assorted KBs, then compare and contrast
the capabilities of different systems in making queries, etc.

If the translation were performed to (John Sowa's) Conceptual
Graphs (CGIF) and Controlled English (CLCE) dialects, PL would
gain new ways for users to view and edit statements, queries,
etc.  Both seasoned and naive users would benefit from having
these dialects available.

Finally, just as PL's Open Source licensing and flexible language
implementation (ie, STELLA) protect its users, having the option
of mechanical translation with other CL dialects should be quite
reassuring to any KR&R user.  (Like SQL, CL is not a magic wand
for interchange, but it's a critically needed starting point.)


In summary, I am very enthusiastic about this prospect and will
be happy to help in any areas where my skills are appropriate.

-r
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     [email protected]
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development