[topicmapmail] Conceptual Graphs are Step 6

[Dan Corwin]

* Murray Altheim wrote:

> Peter Becker, myself, and a few others have been trying for several
> years now to nudge the CG community into providing a reasonable
> specification for Conceptual Graphs.

Lots of luck, Murray.  Your audience there is logicians - who love to
argue, but not over specs.  Nonetheless, what I see on the web does a
commendable job of explaining CGs - with one glaring omission (below).

> ... there's no way to build a CG tool that follows any specification
> ... as the CG spec isn't complete enough.

The TM community and specs might actually help out here, by absorbing
the CG paradigm into a new XTM ontology of topic and association types
any TM engine could import.  TMs could then interoperate with CGs, and
CGs get a new interchange format ISO has already blessed - XTM 1.0  :-)

Earlier, I posted this link for CG's case frame roles.  As a spec, it
was last modified in 2000, and it has John Sowa's KR book behind it:

   [1] http://users.bestweb.net/%7Esowa/ontology/thematic.htm

I feel [1] is a decent spec on most of the role types we'd require,
and is certainly ample for an informal debate on this thread about
what future changes or extensions (if any) we'd like to make to it.

To augment completeness, this useful introduction to CGs gives us a
handy way to learn and debate what ELSE our CG ontology might require.
I'd guess that its "Module I" covers pretty much all we'd need:

   [2] http://www.huminf.aau.dk/cg/Module_I/1142.html

In particular, link [2] models *the same* topics as link [1], but also
adds a nearby tutorial, plus links into its sub-sections and a useful
glossary.  I suggest we adopt all these links as temporary PSIs.

> To put it bluntly, I don't think CGs are
> any more ready for TMs than TMs are ready for CGs. And XTM is just
> syntax. I don't see that anything is going to "fall out" of this

What *I expect* will fall out, in short order, is a valid CG ontology,
cast in temporary PSIs and today's XTM specs, which is *equivalent* to
the CG *graph* notation as spec'ed by [1] & [2], and does *no damage*
to the idea that FOL rules might later infer things from such graphs.

A side benefit of this XTM ontology - assuming we build it - would be to
totally remove "FOL" from CGs, and thus dispel a persistently confusing
claim about CGs - that they somehow intrinsically involve FOL.

In fact, [1] really has nothing at all do with FOL, nor has it ever.
It is a paradigm that arose in the *linguistic* community, predating
the creation of CGs by dozens of years.  The CGs we know have merely
adopted the variation of that paradigm printed in John Sowa's KR book.
Many competitors once existed, but his is now *a* standard.  So is:

[3] http://www.icsi.berkeley.edu/~framenet/  (browse its examples)

CGs do *express* such linguistic models (case frames) in FOL terms by
stating *facts* about roles and associations of case frame instances.
This lets inferences be made later - *iff* related FOL rules get added.

Big deal!  Anyone can express *exactly* those same facts in XTM, SQL,
HTML, MS Excel or a text file.  What the CG specs manage to omit is
clarity on this point.  They suggest not that FOL is a *nice tool* for
processing CGs - it may well be - but that it is essential.  It ain't.

In fact, CGs are no more (or less) related to FOL than to ASCII is.

But under the NLP theories that led to them, *some* kind of executable
logic does need to be driven by case frames.  FOL is one option, but
I much prefer scripted topics, for which these PSIs already exist:

[4]  http://www.lexikos.com/psi/words/

This thread is on CGs, but I will note in passing that WORDS scripts
are their 2nd cousin.  Whichever notation gets used, this central truth
emerges - at some point, English lexicons must become *executable*.

- - - - Building an executable lexicon from CGs

One way to prove the CG rules free of FOL is to rewrite them, at least
conceptually, into a TM ontology which is FOL free.  Here is how I'd
do it.  A critique of this plan by all thread readers is welcomed:

A) Use [1] & [2] to build PSIs defining a couple dozen role types,
not just any types, but *the specific* ones which underly NL verbs.
The above specs are not unreasonable, but they need flexible ways
to be extended.  That is why [3] and [4] add data inheritance - so
each such role can be easily "enhanced" in domain-specific ways.

B) Each verb-like association type in your application's vocabulary
must then declare which such roles it expects, and become executable
either with FOL rules, application code, or inherited/embedded scripts.
This must happen separately for *each* case role a verb-sense expects,
to add application-specific semantic constraints and rules of inference.

C) For all other CG types with a PSI in [2], create a typed topic
that represents a specific pattern of sub-graphs of types B or C.

- - - -  Using the above ontology at run time

If any type C gets instantiated, it instantiates all its parts, and
associates itself (as the whole) to each one of them.  Such CG types
can model tense, collections, or any compositional mini-paradigm -
even a quasi-logical one like a conjunction of subgraphs.  To add
new/better subgraph types in TMs is as easy as adding new PSIs :-)

If any type B gets instantiated, it represents a specific English clause
that has been *understood* by a local UI layer in terms of constrained,
verb-specific pattern of those topics cited as its role players.

Under NLP theory, type B associations should be *unambiguous* assertions
of whatever the speaker of the clause meant to say, but in practice it
can be whatever garbage was offered up within the input CG.  That is one
reason for the semantic constraints - they help defend against nonsense.

At the application level - in Java, scripted topics, or Python - you can
also add any rules that you like on "reacting-to* a newly instantiated
clause - using verb-specific implications on whatever a clause "said".

Such "enhancements" indeed *DO* things, and usually make inferences, but
not necessarily by using FOL.  If you prefer using COBOL, go for it!

- - - -  Summing up

Jack, I believe that CGs really are "just topic maps" - or properly are
just an ontology for topic maps.  Their only wrinkle is that messy bit
involving "enhancements", which must be executable code.  Normally, I
would say that such code resides at the TM application software level,
well outside the realm of XTM, the DM, or the RM.  Do you agree?

Murray, do not expect to find many specs on such implications at the CG
web site or anywhere else, as they are generally specific to particular
domains and applications.  CGs as a tool are not yet mature or widely
used enough to have built up a base of examples.  I hear some do exist,
but only for "toy" vocabularies.  For example systems that do more, you
need to search AI history, generally starting with SHRDLU, which was
the first NLP system to drive an FOL back-end in human-like ways.  It
was done by my grad school TA, Terry Winograd, in the early '70s.

This is way too long, and I'm soon off for a 3-day weekend.  I hope you
enjoy yours, whatever its length, and maybe find time in it to mull over
my A-B-C plan to map [1] and [2] into a portable XTM ontology.

Best Regards
Dan Corwin