🚀 go-pugleaf

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?

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).

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)

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. 

	-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).

	-kitten