RE: CLIPS/C++ -> Ontolingua translation
James Rice <rice@HPP.Stanford.EDU>
Date: Tue, 2 May 1995 13:39:31 -0700 (PDT)
From: James Rice <rice@HPP.Stanford.EDU>
Sender: rice@HPP.Stanford.EDU
Reply-To: rice@HPP.Stanford.EDU
Subject: RE: CLIPS/C++ -> Ontolingua translation
To: "Benjamin D. Branch" <bbranch@ncat.edu>
cc: ontolingua@HPP.Stanford.EDU
In-reply-to: Benjamin D. Branch's message of Tue, 2 May 1995 08:28:42 -0400 (EDT): <Pine.3.89.9505020801.C1482-0100000@garfield.ncat.edu>
Message-id: <XLView.799448624.152.rice@hpp-ss10-1>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Benjamin D. Branch <bbranch@ncat.edu> writes:
>>
>>I'm trying to download translators and I am having problems. I looking
>>for clips to ontolingua translator and c++ to ontolingua translator
>>
No translators, that we are aware of, translate from any representation
_into_ Ontolingua, the translations work the other way. Therefore,
the short answer to your question is that you're out of luck. Having
said this, there may be something for you in the long answer:......
In general it is going to be hard to translate much from a system
without clean semantics into a language like Ontolingua. Both CLIPS
and C++ fall into this category. However, if you are mostly concerned
with translating just the class hierarchy and the slot definitions
then this should be possible.
In the case of CLIPS, things are sufficiently close that is would
probably be pretty trivial to make the above translation, but you would
never, in general, be able to do much with translating CLIPS rules into
Ontolingua (this may or may not be relevant to you).
In the case of C++, life would be a fair bit harder, since C++
data structures don't know anything about themselves at runtime.
You'd pretty well have to write something that actually parses
a C++ source file and understands it enough to build up a
representation that you could translate into Ontolingua.
There is one other option that may be significant. We are, at
this very moment tidying up for an alpha release of a set of C client
stub definitions for the whole of the Generic Frame Protocol. Using
this protocol, you can talk programmatically to the KSL Network Services
Ontology Library. Assuming you have some sort of representation
of your program in your language of choice, it should from there
be a relatively simple process (we hope) to make GFP calls to generate
a representation in Ontolingua land. Of course, given that GFP is
intentionally a "lowest common denominator" frame protocol, you
won't be able to do anything with your rules in CLIPS unless you can
translate them into KIF axioms at your end. Obviously, all bets are off
for the general C++ code case. No way is anyone ever going to be able
to translate arbitrary C/C++ code into KIF axioms.
The key thought is that the goal of Ontolingua has always been that
it should be a language out of which one would perform translations.
The reverse translation process is almost always going to be too hard
because of the ideosynchrasies of the particular target system.
Obviously, this doesn't help you if you already have a huge CLIPS KB
that you'd like to get into Ontolingua, but with any luck, translating
the frame-ish axioms will cover the majority of the problem for you.
You may even be able to do this at the source code level with a few
fancy emacs keyboard macros. We don't, at present, have an Ontolingua
-> C++ back end, though something is clearly possible assuming one
doesn't mind losing a lot of what was originally expressed in Ontolingua.
One ought to be able to generate a set of C++ class definitions, the
slots and maybe a few slot types that hopefully would end up being somewhat
more specific than void*. This may or may not be useful. I can't say.
Rice.