Modification of semantics to allow the existence of definitional extensions in CL

[greenTara]

CLIF should be changed such that conservative and definitional extensions can be formulated. The proposed solution achieving this is to merge cl-text and cl-module into one construct, and introduce syntax @name for non-discourse names.

[tillmo]

The relevant discussion is in http://philebus.tamu.edu/pipermail/cl/2012-August/002448.html http://philebus.tamu.edu/pipermail/cl/2012-August/002483.html http://philebus.tamu.edu/pipermail/cl/2012-August/002489.html http://philebus.tamu.edu/pipermail/cl/2012-August/002505.html http://philebus.tamu.edu/pipermail/cl/2012-August/002506.html

Conservative and definitional extensions are often non-existent in CLIF, because CLIF is unsegregated, and the introduction of defined predicates and functions generally requires the (non-conservative) introduction of new elements into the domain of discourse. With non-discourse names for the defined predicates and functions, this problem vanishes.

The proposed solution is to elevate the CLIF module construction to the top level, so that we can talk about interpretations of modules directly. Such texts with a non-empty exclude list might be called segregated texts (and all names in the exclude list are non-discourse names). This means that some CLIF interpretations need to be interpretations of segregated dialects. Moreover, there will be a shorthand @name, marking name as an excluded and non-discourse name.

Proposed changes:

1. change of namedtext in section A.2.3.11 namedtext = open, 'cl:text' interpretablename, [open, 'cl:domain', interpretablename, close], [open, 'cl:excludes', {name}, close], text, close;
2. Moreover, if an interpretable name of the form "@charsequence" (in other words, an enclosed name, which starts with the string '@') occurs within a sentence and the sentence is phrase of a named text and charsequence is a valid interpretable name, then all occurrences of "@charsequence" in the text are replaced by "charsequence" and "charsequence" is added to the exclusion list of the named text.
3. Semantics of namedtext: see the existing semantics of modules.

Open question: modules can now be defined as syntactic sugar. Should we do this, or keep their direct semantics?

[greenTara]

You appear to be suggesting to merge the named text and module syntax and semantics. However, the current semantics of named texts and modules are somewhat different. In particular, a named text only asserts something about the name of the text, not the interpretation of the body text. A module, according to the current semantics, does assert the body text as well as determine the denotation of the name.

So in the new merged semantics, is it like the old semantics of named texts or the old semantics of modules?

[tillmo]

Good point. I think it should be as in the old semantics of named texts. Note that still cl-module can be regarded as syntactic sugar, namely for a cl-text statement following by a cl-imports of that text.

[greenTara]

There is a difficulty with treating modules as a sequence of named text and importation, and that is the question of allowing nesting.

In the current CL standard, modules may be nested within texts and other modules. I'm not clear about the nesting of named texts, because the abstract syntax does not explicitly address this. Because of the problems in the CLIF syntax, it is also not clear what was intended there. It has been mentioned in the past on the mailing list that it is undesirable to have nested named texts. The reason, I believe, is that it is awkward to import a named text that is nested, as the outer text must be imported also. If named texts are not allowed to be nested and modules are considered syntactic sugar for a named text plus an importation of that text, then modules could also not be nested.

Personally, I would like to see arbitrary nesting allowed, including nesting of named and unnamed, commented and uncommented texts.

[greenTara]

I am a little unclear as to why the discussion of module syntax and semantics is taking place under this issue instead of #25.

[tillmo]

I do not like the nesting. In #39 (which should be copied to #10) a proposal to remove it is made. Indeed, one could interpret the flaw pointed out in #10 in a way that nesting is not allowed. Namely, text is confused with cl-text, and inside the cl-module rule, it should be disambiguated to text.

[greenTara]

It is quite common in practical implementations to have a hierarchical structure to knowledgebases. For example, in our applications in the legal domain, there is a strong requirement (called isomorphism), to reproduce the structure of the original legal texts in the knowledge base. Without nested texts, we would not be able to use CL for these applications, or would have to create an extension just to handle nested texts. If you don't like nested texts, you don't have to use them, but I see no technical reason to disallow others to use them.

[greenTara]

I believe I misunderstood your objection to nesting as to be against all nesting, including nesting of modules. I see that in #39 it is proposed to still allow nested modules. Also unnamed (commented) texts may be nested within other texts or modules. (Both are choices in the "phrase" non-terminal production.) While I don't see any real harm in having named texts nested within other named texts, I think any use case for constructing a hierarchical knowledgebase could do this (better) with nested modules, so I am ok with disallowing named texts anywhere except at the top level.

[tillmo]

What is so special about the top level? And why would you need nested texts there? For clarity: we are speaking of things like (cl-text foo (cl-text bar body-of-bar) body-of-foo) (Side question: would this allow (cl-imports bar) outside foo?) Why not seperate this into two texts: (cl-text foo (cl-imports bar) body-of-foo) (cl-text bar body-of-bar) Would there be any difference, except that the second version is cleaner?

[greenTara]

Re: what is so special about the top level? In CLIF semantics, the top level is interpreted by a "CLIF interpretation", while a module is interpreted by a restriction of a CLIF interpretation, which does not have to be a CLIF interpretation.

Re: would '''(cl-text foo (cl-text bar body-of-bar) body-of-foo)''' allow '''(cl-imports bar)''' outside '''foo'''? Not directly. However you may have '''(cl-imports foo)''' '''(cl-imports bar)''' outside '''foo'''.

Re: Why not separate this into two texts The approach described above is indeed quite clean, and a particular dialect may choose to allow only this kind of hierarchical text construction. However, the Common Logic abstract syntax should be as general as possible, and not be limited to certain approaches that might be considered optimal according to some criteria. There may be cases where other criteria dominate (e.g. the legal domain example mentioned above.)

However, I think this issue, about definitional extensions, is intertwined with the bug regarding the semantics of modules (Issue #25). We need a comprehensive modification to the semantics which addresses both issues (at least).

[tillmo]

OK, if the two formulations are semantically equivalent, then nested cl-texts can be seen as being just syntactic sugar.