[topicmapmail] Conceptual Graphs are Step 6

[Thomas B. Passin]

Dan Corwin wrote:

> * Tom Passin wrote May 1 on another thread:
> 
>> The best approach, IMO, is to first convert the natual language 
>> constructs into Conceptual Graphs.
> 
> 
> I agree Conceptual Graphs seem useful, but building them is NOT the 
> first step.  Classical NLP theory says five preprocessing steps would
>  have to be run first on that language, even to extract its
> SITUATIONS. These steps are summarized in this diagram:
> 
> [1] http://www.lexikos.com/charts/index_files/image003.jpg
> 
> Each prior step is *required* to cull out one well-known kind of 
> ambiguity from a paragraph - lexical, structural, semantic,
> referential, etc.  Unless all 5 are present and accurate, errors
> accumulate so fast that related software will just be a digital
> garbage churn.
> 

I agree, however, I really had something else in mind.  I meant to take 
representative instances of NL expressions, turn them (by hand) into 
CGs, and with the CG in hand, with its thematic roles, etc., construct 
associations as isomporphic as possible to those CGs.  Having done that, 
you have templates for populating with the results of your processing 
steps.  It looks like you have been doing this already.

>> Conceptual Graphs are ... easy to comprehend and were specifically
>>  designed to translate natural language statements into a formal
>> logic.
> 
> 
> I agree, except CGs really do not *translate* NL.  They *express* 
> assertions in predicate calculus about the role players that fill 
> verb-specific association templates based on case frames.
> 

Yes, but let me quote what Sowa says in his "knowledge Representation"
book (I just found these passages today) -

(p. 41) "Since textbooks use natural languages to define everything in
mathematics, the FOL translations of natural language must also be
sufficient to define all of mathematics."

and

(p. 14) "When the graph is translated to predicate logic, ..."

I consider this to be good authority for using the word "translate" in
this context.


> Good news:  NLP software is getting better good at resolving such 
> ambiguities.  With heuristics, public lexical data, and sneaky
> tricks, software encapsulating steps 1-5 can now guess about such
> things and in some circumstances generate low error rates.
> 
> My MODELER design can do this.  In fact, if you configure it
> properly, and interact with it about noticed problems (like
> misspellings), it will cull ambiguities from your paragraphs with
> *virtually no* errors, and dump an XTM chart which says in *your*
> ontology what they asserted:
> 

Well, you are so far ahead of me - I have never done any machine NL work
- so there's probably not much I can offer here.

>> I consider Topic Maps to be essentially a subset of Conceptual
>> Graphs (with a few additional wrinkles).  Some CGs can be expressed
>> as TMs and some cannot.  The ones that can be so expressed are
>> nearly identical except for some syntax details.
> 
> 
> I believe TMs can hold graph structures fully equivalent to those of 
> any CG, but TMs have no standard inferencing model.  CGs do: some FOL
> engine that can infer things by using predicate calculus.
> 

TM is missing universal quantification and negation,in addition of the
inferencing prescriptions.  To be able to add negation we need to be
able to use unary (1 role-player) associations.  So I oppose efforts
being made in some of the modeling efforts to requie an association to
have at least two role-players.

> 
> So, Tom, okay - if you really do think CGs in volume are a good idea,
>  here's a partial proposal for a 2-part project able to produce them:
> 
> 
> 1. On this public thread, we debate XTM models that would be ideal 
> for a chart, and craft a few prototypes by hand in LTM.  Iff we get a
> consensus, we will then have a CG-compatible base ontology in TM
> terms, which MODELER will adapt to use for step 5 output.
> 
> 2. To guide such work in part 1, we can also imagine a file-to-file 
> converter that takes that XTM chart and produces CGIF.  We should 
> limit it to use *only* the XTM input syntax, then notice and feed 
> back requirements on what data that part 1 output must contain.
> 
> Seriously, I have no concrete plans yet in MODELER for a CGIF output 
> module, because I do not know CGs or FOL in depth; because I sense
> they are mostly a tool for teaching logic than a standard; and
> because it is not yet clear to me how many people actually care about
> CGIF.

Murray Altheim is very unhappy about the state of CG and CGIF
specifications - he says they are not precise enough to build 
interoperating software with.  He's looked into it a lot more than I 
have, so I expect he's right.  That leaves things uncertain about how to 
proceed.

Cheers,

Tom P