Compositional grounding is not composing

[kwalcock]

I wonder whether at

eidos/src/main/scala/org/clulab/wm/eidos/groundings/grounders/SRLCompositionalGrounder.scala

Line 285 in 8758be8

val predicateGroundings = exactPredicateGrounding +: inexactPredicateGroundings

the exact and inexact groundings should not be combined in a sequence but rather into a combined predicate grounding.

[MihaiSurdeanu]

The sequence allows for the following sort to happen, no?

[MihaiSurdeanu]

But the bigger question is in the title... Do we know where compositions are lost?

[kwalcock]

The sequence only contains compositional groundings that aren't really composed. I'm thinking of something like

eidos/src/main/scala/org/clulab/wm/eidos/groundings/grounders/SRLCompositionalGrounder.scala

Lines 343 to 347 in 621ca46

	val combinedPredicateGroundings = inexactPredicateGroundings.flatMap { inexactPredicateGrounding =>
	combineExactAndInexact(exactPredicateGrounding, inexactPredicateGrounding)
	}
	// Do all the ones that can be combined, then the exact only, then the individual inexact ones.
	val predicateGroundings = (combinedPredicateGroundings :+ exactPredicateGrounding) ++ inexactPredicateGroundings

[MihaiSurdeanu]

Ok...
But where are these combined with the concepts that serve as arguments to these predicates?

[kwalcock]

In order to collect the inexactPredicateGroundings there are variables like isArg and isPred. If there are predicates, this seems like the only place they would be composed.

Pseudo call stack:

groundEidosMention
groundSentenceSpan
groundSentenceSpan
if (validPredicates.isEmpty) groundWithoutPredicates(sentenceHelper)
else groundWithPredicates(sentenceHelper)
  groundWithPredicates
  findExactPredicateGroundingAndRange
  findInexactPredicateGroundings

[MihaiSurdeanu]

Ok, thanks!

Can you please try to find where the concepts get lost? For example, for the phrase "transportation of oil", where do we lose the grounding for "oil"?

[kwalcock]

The program is running, but IIRC oil is grounded to fuel and is not an exact match. Transportation is not an exact match, either.
Not sure why. Inexact matches are not combined.

[kwalcock]

Ben's "transportation of water" works, almost. The scores don't sort well. The noisyOr is only applied to filled slots, so filling a second slot with a lower value is not as good as having the first single slot.

THEME PROCESS: wm/process/transportation/ (1.2696835) Total: 1.2596835
THEME: wm/concept/goods/water (1.0) THEME PROCESS: wm/process/transportation/ (1.2696835) Total: 1.0025969
THEME: wm/concept/goods/water (1.0) Total: 0.99

[MihaiSurdeanu]

Sure. I think most matches in the real world will be inexact due to language sparsity. But we should assemble predicates and their arguments regardless of exact/inexact match.

[MihaiSurdeanu]

Ben's "transportation of water" works, almost. The scores don't sort well. The noisyOr is only applied to filled slots, so filling a second slot with a lower value is not as good as having the first single slot.

THEME PROCESS: wm/process/transportation/ (1.2696835) Total: 1.2596835
THEME: wm/concept/goods/water (1.0) THEME PROCESS: wm/process/transportation/ (1.2696835) Total: 1.0025969
THEME: wm/concept/goods/water (1.0) Total: 0.99

This is pretty nice!
Then what did Ben see? Is there a bug?

[kwalcock]

They (water and transportation) weren't combined before. They were separate compositional groundings in the Seq that got sorted.

[MihaiSurdeanu]

I see. Awesome!

[kwalcock]

When there is a predicate, as is the case with both "(price) of oil" and "water (transportation)", the findExactPredicateGroundingAndRange does not necessarily find an exact match at all or may find an exact match which doesn't include the predicate, I should have called it be called findExactGroundingAndRangeIfThereIsAPredicateSomewhere. If it doesn't find an exact match as is the case with "price of oil", perhaps it should specifically target the predicate, make do with whatever it can find, and then go on to look for possible arguments, etc. In this particular case, it looks like the ontology doesn't help by having a node called price_or_cost. It would be better to pick one or the other and move the extra to an example. For "water transportation", water matches first, even though it isn't the predicate, but it is possible to do them in the other order, apparently.