ORB
Visualization
(soon)
National Knowledge Project
John M (JCM)
As I said to Dick, syntax is not the problem. The corollary is that no syntax of any kind can be, by itself, the solution.
JCM
>
Have you had some experience with people
>
using CLCE to provide machine parsable knowledge?
>How are the inter-coder reliability issues?
I will grant that Dick successfully enabled people to do useful work with his Mark systems. But I claim that the value of such systems lies in the methodology they support. I would go further and claim that the value of any of the notations that people have used successfully (such as the UML family, for example) is not in their syntax, but in the associated methodology.
The next point I would make is that methodology, by itself, is not the goal, but a method for achieving the real goal, which is to analyze and understand the problems and to develop effective solutions.
Each methodology embodies an approach to analyzing and a particular class of problems and developing solutions to them.
Description logics, for example, have been successfully used for a particular class of problems. But those problems could be solved equally well in any syntax that was combined with the same methodology and toolset.
My reason for developing CLCE is not to propose yet another syntax, but to eliminate the syntactic arguments by saying, in effect, "Why bother?"
The real contribution is not in the syntax of any particular language, but in the methodology for problem solving. So let's dispense with the syntactic issues right at the beginning by letting people use their own native language as the notation, if they like (or by giving them graphics tools in addition to NL as visual aids).
To answer your question: No, I have not used CLCE for any particular problem. But many people have used versions of controlled natural languages for database design, expert systems design, and pseudo-code for program design. I am just designing CLCE as a common syntax that can be subsetted, as needed, for any such purpose.
People could use the DL (descriptive logic) subset of CLCE, the SQL query subset, the FOL (first order logic) subset, or the imperative subset as needed. Or they could supplement it with any graphics aids they like.
My main goal in developing CLCE is to get rid of monstrosities such as OWL, the Object Constraint Language (OCL) of UML, and the multitude of semi-NL (natural language)-like languages such as SQL. As replacements, I suggest two kinds of languages:
As
the inner language for computer processing,
I recommend logic, in whichever subset is appropriate for each particular problem.
As
the outer language for human consumption,
I recommend controlled natural languages (NL) together with graphic supplements whenever they are helpful.
As a result, the controlled NL serves as documentation that is readable by both computers and humans. There can be no discrepancy between the documentation and the implementation, since the documentation is directly compiled to the implementation.
Given this approach, R & D can be diverted from syntax to the real questions of semantics and methodology: What knowledge is required to solve particular problems, how can it be acquired, and how can it be used and reused?
John Sowa