11 May 2005 22:18

### play(player, game)

```hi,

i do not understand why the last assert is possible, can anyone give me
a hand? can i assert everything independent of the definitions made bevor?

thanks!

(DEFCONCEPT PLAYER)
(DEFCONCEPT GAME)
(DEFRELATION PLAY (?X ?Y)
:=> (AND (PLAYER ?X) (GAME ?Y)))

// or (defrelation play ((?x player) (?y game)))

(ASSERT (CLOSED GAME))
(ASSERT (CLOSED PLAYER))
(ASSERT (PLAYER JANO))
(ASSERT (PLAYER CHESS))
(ASSERT (PLAY JANO CHESS))
(ASSERT (PLAY JANO JANO))

regards
k.janowicz
```
13 May 2005 22:11

### play(player, game)

```Krzysztof,

I'm not sure why you think the last assertion should not be possible.
At that point both JANO and CHESS are of type PLAYER (via explicit
assertion) and GAME (inferred via the type constraint on PLAY).  You
asserted GAME and PLAYER to be closed which only means (NOT (GAME/PLAYER ?x))
will be concluded if (GAME/PLAYER ?x) cannot be inferred.  So, there
are no contradictions I can see.

Hans

>>>>> Krzysztof Janowicz <k <at> janowicz.de> writes:

> hi,
> i do not understand why the last assert is possible, can anyone give me
> a hand? can i assert everything independent of the definitions made bevor?

> thanks!

> (DEFCONCEPT PLAYER)
> (DEFCONCEPT GAME)
> (DEFRELATION PLAY (?X ?Y)
>    :=> (AND (PLAYER ?X) (GAME ?Y)))

> // or (defrelation play ((?x player) (?y game)))

> (ASSERT (CLOSED GAME))
> (ASSERT (CLOSED PLAYER))
> (ASSERT (PLAYER JANO))
> (ASSERT (PLAYER CHESS))
```

23 May 2005 23:50

### Re: play(player, game)

```Hans,

After looking a little into this, now I'm confused too about the semantics of
the CLOSED predicate.  I understand why the example below does not lead to
any contradictions. But I'm not sure I understand why CLOSED only has effect
on NOT questions. Like for instance:

? (defconcept player)
|c|PLAYER
? (assert (closed player))
|P|(CLOSED PLAYER)
? (assert (player jano))
|P|(PLAYER JANO)
Processing check-types agenda...
TRUE
UNKNOWN

I'm not sure I understand why the last query doesn't return FALSE. I take it
it has to do with the fact that PowerLoom doesn't put much effort into
disproving a query. The manual says:

"The PowerLoom command ask returns one of three values: true if it can prove
the truth of a proposition, false if it can easily prove the falsity of a
proposition and otherwise it returns unknown."

So in this case PowerLoom does know that the query failed, and it seems to me
it would be easy to check that the predicate is CLOSED, and then change the
result to FALSE. This would be more in line with the "negation as failure"
```

25 May 2005 03:46

### Re: play(player, game)

```Octav,

you are right that the primary reason for this is the asymmetric
effort by PowerLoom on proving the query as stated as opposed to
trying to prove its negation.  You are also right that the system
looks somewhat stupid/buggy using this behavior when querying closed
relations.  Tom Russ was offended by this also recently and has been
working on a fix.  I'm not sure exactly where we are on this, but
we'll try to fix this for the next release.

Hans

>>>>> Octav Popescu <octav <at> cmu.edu> writes:

> Hans,
> After looking a little into this, now I'm confused too about the semantics of
> the CLOSED predicate.  I understand why the example below does not lead to
> any contradictions. But I'm not sure I understand why CLOSED only has effect
> on NOT questions. Like for instance:

> ? (defconcept player)
> |c|PLAYER
> ? (assert (closed player))
> |P|(CLOSED PLAYER)
> ? (assert (player jano))
> |P|(PLAYER JANO)
> ? (ask (not (player chess)))
> Processing check-types agenda...
> TRUE
```

25 May 2005 07:38

### Re: play(player, game)

```Then I guess my question is again: Any idea when you'll issue the next
release?

Related to the problem with the CLOSED relations, I was trying to think of
possible problems, so I was wondering if you would fix that only at the top
level, or also at intermediate levels in the reasoning process. Like for
instance if one tries to prove (AND (P1 A) (P2 A)), and (P1 A) is TRUE and
(P2 A) cannot be proved but is declared CLOSED, would the whole result be
FALSE? Can this be generalized to quantified formulas?

Another question: irrespective of the CLOSED declaration, does PowerLoom do
3-value (or 5-value with the defaults) logic computation? Like saying (AND
UNKNOWN FALSE) = FALSE, (AND UNKNOWN TRUE) = UNKNOWN, (OR UNKNOWN TRUE) =
TRUE, (OR UNKNOWN FALSE) = UNKNOWN.

Thanks,
Octav

--On Tuesday, May 24, 2005 6:46 PM -0700 Hans Chalupsky <hans <at> ISI.EDU> wrote:

> Octav,
>
> you are right that the primary reason for this is the asymmetric
> effort by PowerLoom on proving the query as stated as opposed to
> trying to prove its negation.  You are also right that the system
> looks somewhat stupid/buggy using this behavior when querying closed
> relations.  Tom Russ was offended by this also recently and has been
> working on a fix.  I'm not sure exactly where we are on this, but
> we'll try to fix this for the next release.
>
```

25 May 2005 18:34

### Re: play(player, game)

```I'll let Hans handle the other issues, but I'll tackle closed world.

On May 24, 2005, at 10:38 PM, Octav Popescu wrote:

> Then I guess my question is again: Any idea when you'll issue the next
> release?
>
> Related to the problem with the CLOSED relations, I was trying to
> think of possible problems, so I was wondering if you would fix that
> only at the top level, or also at intermediate levels in the reasoning
> process. Like for instance if one tries to prove (AND (P1 A) (P2 A)),
> and (P1 A) is TRUE and (P2 A) cannot be proved but is declared CLOSED,
> would the whole result be FALSE?

That would be my preferred solution.  That is, in part, why
it is taking a while to get something running out.

>  Can this be generalized to quantified formulas?

I think so.  It really depends on how sophisticated our code
is for determining which propositions are closed, so I can't
really guarantee it.

> Another question: irrespective of the CLOSED declaration, does
> PowerLoom do 3-value (or 5-value with the defaults) logic computation?
> Like saying (AND UNKNOWN FALSE) = FALSE, (AND UNKNOWN TRUE) = UNKNOWN,
> (OR UNKNOWN TRUE) = TRUE, (OR UNKNOWN FALSE) = UNKNOWN.
>
> Thanks,
> Octav
```

25 May 2005 21:47

### Re: play(player, game)

```>>>>> Octav Popescu <octav <at> cmu.edu> writes:

> Then I guess my question is again: Any idea when you'll issue the next
> release?

We are working on another release which will be licensed open-source
similar to STELLA.  It will also include our database interface for
PowerLoom (currently only supporting MySQL).

> Another question: irrespective of the CLOSED declaration, does PowerLoom do
> 3-value (or 5-value with the defaults) logic computation? Like saying (AND
> UNKNOWN FALSE) = FALSE, (AND UNKNOWN TRUE) = UNKNOWN, (OR UNKNOWN TRUE) =
> TRUE, (OR UNKNOWN FALSE) = UNKNOWN.

Yes, for example:

STELLA(3): (defrelation happy (?x))
|r|HAPPY
STELLA(4): (assert (not (happy joe)))
|P|(NOT (HAPPY JOE))
UNKNOWN
STELLA(6): (ask (and (happy joe) (happy fred)))
FALSE
STELLA(7): (ask (or (happy joe) (happy fred)))
UNKNOWN
STELLA(8): (ask (or (not (happy joe)) (happy fred)))
TRUE
STELLA(10): (ask (and (not (happy joe)) (happy fred)))
UNKNOWN
```

26 May 2005 01:00

### Re: play(player, game)

```--On Wednesday, May 25, 2005 12:47 -0700 Hans Chalupsky <hans <at> ISI.EDU> wrote:

>>>>>> Octav Popescu <octav <at> cmu.edu> writes:
>
>> Another question: irrespective of the CLOSED declaration, does PowerLoom
>> do  3-value (or 5-value with the defaults) logic computation? Like saying
>> (AND  UNKNOWN FALSE) = FALSE, (AND UNKNOWN TRUE) = UNKNOWN, (OR UNKNOWN
>> TRUE) =  TRUE, (OR UNKNOWN FALSE) = UNKNOWN.
>
> Yes, for example:
>
> STELLA(3): (defrelation happy (?x))
>| r|HAPPY
> STELLA(4): (assert (not (happy joe)))
>| P|(NOT (HAPPY JOE))
> UNKNOWN
> STELLA(6): (ask (and (happy joe) (happy fred)))
> FALSE
> STELLA(7): (ask (or (happy joe) (happy fred)))
> UNKNOWN
> STELLA(8): (ask (or (not (happy joe)) (happy fred)))
> TRUE
> STELLA(10): (ask (and (not (happy joe)) (happy fred)))
> UNKNOWN
> STELLA(11):
>
> Hans

Well, that's great, but then I get:
```

26 May 2005 01:16

### Re: play(player, game)

```One more question: It seems to me that even if you implement this change,
this won't change Krzysztof's example in any way, right? I'm not trying to
suggest it should, just trying to find out how it'd work. CLOSED wouldn't
mean that all members of the relation have to be asserted explicitly, some
could be inferred in the reasoning process. So in his example (ASSERT (PLAY
JANO JANO)) will infer (GAME JANO) and there would still be no contradiction
with the fact that it was not declared explicitly.

Thanks,
Octav

--On Wednesday, May 25, 2005 09:34 -0700 Thomas Russ <tar <at> ISI.EDU> wrote:

> I'll let Hans handle the other issues, but I'll tackle closed world.
>
> On May 24, 2005, at 10:38 PM, Octav Popescu wrote:
>
>> Then I guess my question is again: Any idea when you'll issue the next
>> release?
>>
>> Related to the problem with the CLOSED relations, I was trying to
>> think of possible problems, so I was wondering if you would fix that
>> only at the top level, or also at intermediate levels in the reasoning
>> process. Like for instance if one tries to prove (AND (P1 A) (P2 A)),
>> and (P1 A) is TRUE and (P2 A) cannot be proved but is declared CLOSED,
>> would the whole result be FALSE?
>
> That would be my preferred solution.  That is, in part, why
> it is taking a while to get something running out.
>
```

26 May 2005 03:05

### Re: play(player, game)

```>>>>> Octav Popescu <octav <at> cmu.edu> writes:

> --On Wednesday, May 25, 2005 12:47 -0700 Hans Chalupsky <hans <at> ISI.EDU> wrote:
>>>>>>> Octav Popescu <octav <at> cmu.edu> writes:
>>
>>> Another question: irrespective of the CLOSED declaration, does PowerLoom
>>> do  3-value (or 5-value with the defaults) logic computation? Like saying
>>> (AND  UNKNOWN FALSE) = FALSE, (AND UNKNOWN TRUE) = UNKNOWN, (OR UNKNOWN
>>> TRUE) =  TRUE, (OR UNKNOWN FALSE) = UNKNOWN.
>>
>> Yes, for example:
>>
>> STELLA(3): (defrelation happy (?x))
>> | r|HAPPY
>> STELLA(4): (assert (not (happy joe)))
>> | P|(NOT (HAPPY JOE))
>> UNKNOWN
>> STELLA(6): (ask (and (happy joe) (happy fred)))
>> FALSE
>> STELLA(7): (ask (or (happy joe) (happy fred)))
>> UNKNOWN
>> STELLA(8): (ask (or (not (happy joe)) (happy fred)))
>> TRUE
>> STELLA(10): (ask (and (not (happy joe)) (happy fred)))
>> UNKNOWN
>> STELLA(11):
>>
>> Hans

```