🚀 go-pugleaf

Patrick Juola schrieb in Nachricht <7iu7i3$pl0$1@quine.mathcs.duq.edu>...
>In article <01bea8ef$3ca8fb30$54c011ac@ws6147>,
>Stefan MUEHLBACHER <SMuehlba@frequentis.com> wrote:
>>> So, how can you implement this maxim with computer programs?  i.e. How
>>> are  you  going  to  represent  these  concepts in  a  computer  in  a
>>> relatively neutral manner?  Should the computer represent "I'm hungry"
>>> as "I AM hungry" or "I HAVE hunger", or neither (e.g. "I --> <state of
>>> being hungry>")?
>>
>>of For me it is clear that the neutral manner to represent this sentence
>>consists
>>of two global symbols (it does not matter if those symbols consist of
>>letters or
>>are just pictograms).
>>
>>1.) State of being hungry: So we need a symbol for a relation that can be
>>used together with one operand: Lets call it SYMBOL_FOR_BEING_HUNGRY
>>
>>2.) The other symbol is needed for the person that is in that state:
>>Lets call it SYMBOL_FOR_PERSON.
>>
>>And the relation may be represented like:
>>SYMBOL_FOR_BEING_HUNGRY (SYMBOL_FOR_PERSON).
>>
>>The two sentences "I am hungry" or "I have hunger" are just two ways to
>>translate the same relation into english.
>
>Doesn't quite work, I'm afraid.
>
>Presumably you'll postulate a similar SYMBOL_FOR_BEING_TIRED?
>

You are right, I would postulate this.

>Unfortunately, although the sentence "I am tired and hungry" works
>well in English with a single verb and compound adjective, there is
>no (structural) equivalent in French (due to the different verbs.
>
>As was pointed out a little bit further downthread, you're using a
>fairly simple first order predicate logic here(*).  Let me switch into
>Prolog notation for brevity....
>
>The problem is that we need some way to get from
>
>is_tired(person).
> and
>is_hungry(person).
> to
>
>is_tired_and_hungry(person).
>

There is a base principle for the abstract representation of knowledge with
global symbols:
In this model there are two distinct domains:
- One is the knowledge representation domain (this is not the communication
form, it is just used to store knowledge).
- One is a natural language (similar) domain where syntax will be regarded
(used to tell knowledge to a human).

In the knowledge representation domain it is normally not a good idea to use
many predicates in a single expression: So in this domain it would not
represent
the knowledge as 'is_tired_and_hungry(person)'.
It is better to represent the knowledge just as two independent pieces:
is_tired(person), is_hungry(person).
In this domain there is no need to merge the two pieces!

So the sentence: "I am tired and hungry" is just an abbreviation in the
syntactical domain.
This abbreviation will not be available for all languages. It need not be
available, because omitting the abbreviation
does not prevent anybody from telling the same knowledge in a longer form.

In my opinion in this case the problem is just a language dependent
syntactical problem, but not
a knowledge representation problem.

>to capture the English structure.  And it's difficult if not impossible
>to come up with a universalizable and computational rule to state when
>you can create new predictates like this on the fly (and when you can't):
>
> x (A), y (A) -> x_and_y (A)
>


You are right, rules like that are language dependent.

>So the next step would be to break the problem down further; to noted
>that hunger and tiredness are themselves both atomic properties, to
>note that
>
>has_property(person,tired).
>has_property(person,hungry).
>
>And that these can be conflated to a property list
>
>has_property(person,[tired,hungry]).
>
>This can capture both the English and French syntax but at the
>cost of another level of abstraction in the representation.  These
>representational levels unfortunately add up; unless you're a great
>deal cleverer than I, you'll probably find yourself afloat in a
>sea of abstract properties trying to rationalize to yourself
>what property lamps have that no other objects in the world (including
>flashlights and campfires) have, because it's necessary to find such
>a distinguishing property in order to capture the syntax of
>Chinese classifiers.



This is a bit like to say: It is true that it is true that it is true that
paris is the capital of france.
I see no reason to need that in the knowledge representation domain.

regards, Stefan Muehlbacher




> -kitten
>
>
>(*) Let me also inquire why you choose to make property symbols
>into functions and object symbols into arguments.  Why
>
>is_tired(person).
>
>and not
>
>person(is_tired).
>

The reason is that there could be additional parameters like:

is_tired(person,today)

When I write: persion(is_tired,today) then predicates will be mixed up with
operands.

But nevertheless it is just a convention to be chosen.

> -kitten