Re: PowerLoom's BNF usage

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

Does the following correctly summarize what would happen if 
CLIF-compliance is achieved:

1.  One would have to provide translations back and forth for one's dialect;

2.  Because of 1, if one is compliant, one is automagically able to 
translate one's code into the other dialects?

I think part of this question is "what does it mean to provide a 
translation?"  does it mean one has to provide publicly usable code, or 
just an algorithm specification?

Also, what if one has a language with, say, some second-order features 
(which I am just assuming are not included in Common Logic)?  Does one 
define a subset of one's language which permits translation back and forth?

Thanks,
r