IntensionalEvaluation

From OpenCog
Jump to: navigation, search

IDEA: Using intension to represent linguistic modifiers

A problem with our current representation of linguistic modifiers has been highlighted by Roman Treutlein’s current work mapping Lojban into the Atomspace… (September 2015).

This page discusses the problem and a suggested solution, using both Lojban and English examples. The Lojban discussion is less cluttered because Lojban lacks many of the complexities and ambiguities of natural languages like English.

The examples discussed here illustrate some general aspects of intensional relationships in PLN logic, and are worth thinking about in that regard.

See also

Lojban Example of the Problem

A Lojban example is given by the two tanru (ordered word combinations)

  • blanu tsani — meaning “blue sky”
  • tsani blanu — meaning “sky blue” (a color, e.g. a color for a tube of paint… the sky-like shade of blue)

These involve the Lojban words

  • blanu — a predicate whose first argument has the semantics: x1 is blue
  • tsani — a predicate whose two arguments have the semantics: x1 is the sky of x2

The convention in Lojban is that a tanru takes the argument structure of the rightmost word..

Note that in Lojban, all words are predicates, so the most straightforward thing is to map them all into OpenCog PredicateNodes.

Regarding the two above examples, what we don’t want is to map both of these into something like

PredicateNode x123 (let's call this **)

where

ImplicationLink
	x123
	PredicateNode “blanu”

ImplicationLink
	x123
	PredicateNode “tsani”

This doesn’t distinguish which predicate has the head role -- i.e. it doesn't distinguish whether one is talking about a sky that is blue, or a blue that is sky-ish.

But if we map “blanu tsani” as

ImplicationLink
	PredicateNode “tsani123”
	PredicateNode “tsani”

ImplicationLink
	PredicateNode “tsani123”
	PredicateNode “blanu”

and “tsanu blanu” as

ImplicationLink
	PredicateNode “blanu123”
	PredicateNode “tsani”

ImplicationLink
	PredicateNode “blanu123”
	PredicateNode “blanu”

then the undesired (**) is pretty much what we have, since the name of a PredicateNode isn’t explicit semantic content, and we don’t want it to be required to follow links from PredicateNodes to associated WordNodes to find the semantic content of the PredicateNodes…

A Possible Solution to the Problem

I thought a bit about various solutions here…. My ultimate conclusion was that some new link types would be convenient.

Everyone knows

EvaluationLink
	F
	X

is equivalent to

MemberLink
	X
	SatisfyingSet
		F

My tentative suggestion is: Along these lines, we may also introduce


IntensionalEvaluationLink
	F
	X

meaning

IntensionalInheritanceLink
	X
	SatisfyingSet
		F

i.e. X has the properties of those x so that F(x) is true

and

MixedEvaluationLink
	F
	X

meaning

InheritanceLink
	X
	SatisfyingSet
		F

i.e. X has the properties of those x so that F(x) is true, and X also contains some x so that F(x) is true

Solution of the Lojbanic Problem Using the New Link types

Using these relationships, we could say “blanu tsani” means


ImplicationLink 
	PredicateNode “tsani123”
	PredicateNode “tsani”

MixedEvaluationLink
	PredicateNode “blanu”
	PredicateNode “tsani123”


and we could say “tsani blanu” means


ImplicationLink 
	PredicateNode “blanu123”
	PredicateNode “blanu”

MixedEvaluationLink
	PredicateNode “tsani”
	PredicateNode “blanu123”

In fact, in this case it would be even more accurate to replace the latter link with

IntensionalEvaluationLink
	PredicateNode “tsani”
	PredicateNode “blanu123”


English Example

The same issue exists in English with “blue sky” versus “sky blue”, but it’s obscured a bit by the existence of different parts of speech, etc. (In Lojban every word is a predicate…)

To understand the issue in an English context, take a look at the adjectivial-modifier Relex2Logic rule

For instance, given the sentence "I saw a blue sky over Hong Kong today", the RelEx output would contain the relation

amod(blue, sky)

which the R2L amod-rule would turn into stuff like

InheritanceLink blue_77 blue
InheritanceLink sky_15 sky
InheritanceLink sky_77 blue_15

With no word=sense disambiguation this might be cleaned up to

InheritanceLink sky_77 sky
InheritanceLink blue_77 blue

Or with WSD in place, it might be cleaned up instead to

InheritanceLink sky_77 sky_sense_1
InheritanceLink sky_77 blue_sense_1

(where e.g. "sky_77" is shorthand for "ConceptNode "sky_77").


Now how would the current NL comprehension pipeline deal with "sky blue"? Here "sky" is a noun modifier, i.e. a noun acting like an adjective. So (assuming WSD is in place; this is irrelevant to the point under consideration anyway) the semantic output should also end up something like

InheritanceLink blue_77 sky_sense_1
InheritanceLink blue_77 blue_sense_1

There is a difference from "blue sky" in the sense that "sky" links to a WordNode that is a noun, whereas "blue" links to a WordNode that is an adjective -- but this is a syntactic difference, and it's not desirable (in terms of OpenCog representations) to have to refer to a syntactic difference like that, to resolve such a basic semantic difference as the difference in meaning between "sky blue" and "blue sky."


Solution of the Problem in the English Example

Paralleling the Lojban solution, the solution for English would be


SubsetLink    \\recalling that Subset means purely extensional inheritance
	ConceptNode “sky123”
	ConceptNode “sky_sense_1”

InheritanceLink   \\recalling that Inheritance is supposed to be mixed extensional/intensional
	ConceptNode “sky123”
	ConceptNode “blue_sense_1”


and we could say “sky blue” means


SubsetLink    \\recalling that Subset means purely extensional inheritance
	ConceptNode “blue123”
	ConceptNode “blue_sense_1”

InheritanceLink   \\recalling that Inheritance is supposed to be mixed extensional/intensional
	ConceptNode “blue123”
	ConceptNode “sky_sense_1”

or more accurately, we could replace the latter with

IntensionalInheritanceLink   \\recalling that Inheritance is supposed to be mixed extensional/intensional
	ConceptNode “blue123”
	ConceptNode “sky_sense_1”

since we know the shade of blue in question is not literally (extensionally) a sky, but is only sharing some properties of sky.


A Fuller Solution of the Problem for English

The above style of solution looks OK conceptually, but on careful thought, one finds it works better for Lojban than for English, because in Lojban the general modus operandi is to use words literally. For instance, in English, one might look at a fireworks snake ( https://www.youtube.com/watch?v=F3aAksyabes ) and say "It's alive!" .... In Lojban, this would not be considered good practice. Instead one would say something analogous to "It seems alive" ("simlu jmive", seem alive ...)..

In English, each (explicit or implicit) usage of "is" contains both intensional and extensional elements, and the mix of these is not generally made explicit....

To address this, a more careful solution to "blue sky" versus "sky blue" for English would look something like the following.

For blue sky,

SubsetLink  <.6> // sky123 is literally a sky_sense_1
	ConceptNode “sky123”
	ConceptNode “sky_sense_1”

IntensionalInheritanceLink  <s>  //sky123 shares properties of a sky_sense_1
	ConceptNode “sky123”
	ConceptNode “sky_sense_1”

IntensionalInheritanceLink  <s>  //sky123 shares properties of a blue_sense_1
	ConceptNode “sky123”
	ConceptNode “blue_sense_1”


and we could say “sky blue” means


SubsetLink <.6>    \\recalling that Subset means purely extensional inheritance
	ConceptNode “blue123”
	ConceptNode “blue_sense_1”

IntensionalInheritanceLink  <s>  //blue123 shares properties of blue_sense_1
	ConceptNode “blue123”
	ConceptNode “blue_sense_1”

IntensionalInheritanceLink   <s>  \\recalling that Inheritance is supposed to be mixed extensional/intensional
	ConceptNode “blue123”
	ConceptNode “sky_sense_1”

This addresses the confusing mixture of intension and extension in English "is", but doesn't address what strength values of the intensional inheritance links make sense.

More About Intensions, Attractions and Contexts

Next let's look more deeply at these intensional inheritance links. This suggests some possible modifications to the above mappings.

Why does it make sense to say e.g. that

IntensionalInheritanceLink   <s> 
	ConceptNode “blue123”
	ConceptNode “sky_sense_1”

?

The important observation is that blue123 and sky_sense_1 have properties in common, because, let's say,

AttractionLink sky sky_blue_color <.6>

AttractionLink sky_blue_color sky_blue_color <1>

That is, we are saying that the "sky blue" color has a property in common with the sky -- namely its color.

Now, the sky blue color also has properties that the sky does not have -- for instance, it can appear on shirts or shoes... But it does have an important property in common with the sky.

I wonder if instead of

IntensionalInheritanceLink   <s>  (***)
	ConceptNode “blue123”
	ConceptNode “sky_sense_1”

we really want to be looking at

ContextLink <s> (****)
      ConceptNode "blue"
      IntensionalInheritanceLink   
	  ConceptNode “blue123”
	  ConceptNode “sky_sense_1”

Because the truth value s of this ContextLink could get a much higher truth value. In this context, when we calculate

AttractionLink  sky_blue_color  worn_on_shirt 

we would look at

P( worn_on_shirt & blue_sense_1 | sky_blue_color & blue_sense_1) - P(worn_on_shirt & blue_sense_1 | ~sky_blue_color & blue_sense_1) 
=
P( worn_on_shirt  | sky_blue_color) - P(worn_on_shirt | ~sky_blue_color & blue_sense_1)

which would give ZERO, unless sky blue color is more likely to be worn on shirts than blue color...

So, (****) will give a much higher truth value, via ignoring contextually irrelevant attractions.

This suggests a possible interpretation such as, for "sky blue" in English

SubsetLink <.6>    
	ConceptNode “blue123”
	ConceptNode “blue_sense_1”

ContextLink <.6>
     ConceptNode "blue_sense_1"
     IntensionalInheritanceLink  <  //blue123 shares properties of blue_sense_1
	 ConceptNode “blue123”
	 ConceptNode “blue_sense_1”

ContextLink <.6>
     Conceptnode "blue_sense_1"
     IntensionalInheritanceLink   <s>  
	 ConceptNode “blue123”
	 ConceptNode “sky_sense_1”

(For "blue sky", the contextualization would by by "sky_sense_1" and not "blue_sense_1".

This possible modification also would affect the Lojban interpretations, e.g. suggesting perhaps constructs like

ContextLink <.6>
     PredicateNode "blanu"
     IntensionalEvaluationLink
           PredicateNode "tsani"
           PredicateNode "blanu123"

Without the ContextLink, it seems that the truth value of the intensional links may come out quite low, which may (or may not) be problematic...

I am harping on this issue because it has potential implications well beyond this example, obviously... biology inference and language learning are two other examples that would heavily use this sort of intensional relationship...

Also, this particular example may exemplify some underlying truth about language and contextual embedding, that should be articulated more clearly and generally. For instance, maybe the head of a phrase in linguistics, should generally be treated semantically as a context of the other words in the phrase? This would match the idea that a phrase is semantically closed in some sense, and external relations w/ the phrase should go through the head...