Re: PowerLoom's BNF usage

I've had a project on the back burner for sometime now that may be of
interest.  I am creating a CLIF translation of the SUMO (something I call
SUMO-CL).  I've been contemplating creating a mapping between SUMO-CL and
PowerLoom (there has been some discussion regarding this on this list).
I've recently secured some funding for this project and it will finally be
moving up on my priority list.  Some of the artifacts from this work may be
generally useful here.

Cameron.


On Tue, Jul 8, 2008 at 10:06 PM, Rich Morin <[email protected]> wrote:

> 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
> _______________________________________________
> powerloom-forum mailing list
> [email protected]
> http://mailman.isi.edu/mailman/listinfo/powerloom-forum
>



-- 
Cameron Ross, M.Sc.
Director of Technology
Symboticware Incorporated
www.symboticware.com

_______________________________________________
powerloom-forum mailing list
[email protected]
http://mailman.isi.edu/mailman/listinfo/powerloom-forum