Re: [ontolog-forum] Requirements of computer language semantics

["Richard H. McCullough" <rhm@xxxxxxxxxxxxx>]

 

 

----- Original Message -----

From: "John F. Sowa" <sowa@xxxxxxxxxxx>

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>

Sent: Friday, March 20, 2009 10:49 AM

Subject: Re: [ontolog-forum] Requirements of computer language semantics

> But what I don't see in that list are the reasoning methods
> that link the symbols in the lattices to the sentences in
> mKR, relate the sentences to one another in order to draw
> inferences and detect contradictions, or interpret the
> context specifications of space, time, and view.
>
> The kinds of reasoning required to relate sentences in
> different contexts to one another, derive implications,
> detect contradictions, answer detailed questions, etc.,
> are extremely complex.  The vagueness in your previous
> notes suggests that you don't do these operations.
>
> If you don't do that, then all the claims about contexts
> are irrelevant.  Those at-clauses are merely decorations
> attached to sentences.  Any meaning that some human might
> think about them has no effect on what the computer does.
>
> To return to my original question:  what kind of processing
> do you do with those contexts, how does it relate to the
> lattice of symbols, the inferences among sentences, etc.?
>
> John

 

In summary,

the current state of mKE "reasoning" is primitive,

but mKE is still a very useful "assistant".

I expect it will take some time to supply all the info. you are

looking for.  But I will make a start by describing some

of the things that the mKE program does internally with

mKR propositions.

 

1. mKE names and classifies and stores all propositions.

In addition, it organizes the knowledge in many different ways.

a. all instances and concepts are stored in a

double-linked lattice structure, so that mKE can answer

any kind of inheritance question by walking up & down the

lattice.  begin hierarchy h;  ...; end hierarchy h; groups are

translated into instance/species statements & stored in lattice.

b. all of the properties & values of a given subject are stored together

in associative arrays.  There is a subhierarchy of properties, but

values are not replicated in this subhierarchy because the time

penalty is too high.

c. begin relation r; ...; end relation r; groups are stored in the

lattice as tuple instances, and the "meaning" of each tuple

(specified by proposition list or a Unicon procedure) is added

to the knowledge base.  Meaning is context-dependent, and

can also be changed by a direct assignment

    r has meaning = { proplist };

so tuples can be reprocessed in the light of new knowledge

entered into mKE.  This feature can also be used to do

simple things like selecting a subrelation.

d. method definitions are saved in lattice, to be used in subsequent

invocations.  Methods can take advantage of the generators

and goal-directed evaluation of the Unicon language.

e. environment variables, current concept attributes, method

arguments, n-ary relation arguments  are held in a

namespace stack.  mKE can access terms from

a stack of nested contexts.

 

2. All of the above propositions & related structures constitute

the current "view", v.   This view can be modified by adding new

concepts to the lattice, deleting concepts, moving concepts.

Any time the input to mKE includes "at view=v", all of its

propositions & associated data structures become the current

view.

 

3. pipelines like { at view = v1 ...} | { at view=v2 ...};

permit adding  & deleting propositions in the same way

that UNIX pipelines permit filtering files.

 

4. The behavior of sequences like

    at view=v1 .... at view=v2 ....

depend on the nature of v2.

If v2 has already been defined, it is simply restored to the

current view.  If v2 is a new view, it is "nested" in v1.

The initial propositions  & associated structures of v2

are a copy of those of v1.  Any sentence which does not

have a context (syntactically speaking) automatically

inherits its context from the previous proposition.

 

5. The iteration statement, e.g.,

    every p isu person; { .... $p ... };

can do most anything you want in the "closed world" context

of the current view.  I have defined, but not implemented,

"open world" iterators which are fairly standard in other languages.

For example

    for all p isu person; { ...

        for some relative ismem family; { ...

            for any school ismem schools attended; { proplist };

        };

    };

 

6. concept aliases, e.g. "x is y;" are handled by an outer layer

which maps to an internal concept name "z".  All aliases map

to the same data structure which stores all of the properties of

that concept (or instance).

 

7. mKR has a convenient set of conditionals, e.g.,

    if -then-else-fi  iff  implies

but conditionals are evaluated by a brute force search in the

in the "closed world" of the current view.

To achieve "open world" reasoning, you have to include

some appropriate "open world" assertions in the input

mKR propositions.

 

8. The values of space, time, view are treated as simple names.

Although the Natural Semantic Metalanguage concepts include

    before, after, above, below, beside, inside, etc.

I have not implemented the evaluation of these relations on

space, time, view.

 

9. The only "contradictions" currently detected are

"closed world" occurrences of

a. {X isu Y;} and {X iss Z;};    # instance and species

b. X isa Y,Z;                        # multiple genus 

c. {X is Y;} and {X is not Y;}; # aliases

As I'm sure you're all aware, many people do not consider

a. and b. to be contradictions.

 

Dick McCullough

http://mkrmke.org

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (01)