[Zero]

Hi guys,

Could you please help me make a complete list of every thing that can exist, or occur, in a mind. Every item should fall in one of these 3 categories:
- state
- process
- event/act

EDIT: The list currently looks like this.


state
   type of thoughts
      concept
         abstract
         concrete
         instance
      conjecture
      decision
      definition
         term
         meaning
         synonym
            nuance
            context
         antonym
            nuance
            context
      explanation
         fact
         cause
         consequence
         context
      hypothesis
      idea
      logical argument
      logical assertion
      mental image
      percept
         perceptual component
      premise
      proposition
      syllogism
      thought experiment
   content of thoughts
      argument
      belief
         certainty
         probability
         bayesian network
      data
      information
      knowledge
         theoretical
            cause consequence chain
         practical
            know how to
      schema
   memory
      implicit
         procedural
         perceptual
      explicit
         episodic
         semantic
   goal
      requirement
      subgoal
      goal-to-current path
         state event state
         path criteria
   association
   plan
      step
   language
      vocabulary
      grammar
   emotion
      attraction
      repulsion
   thought frames
      active frame
      suspended frame
process
   thought frame handling
   generalizing
      pattern recognition
      pattern label creation
   associating
   focusing
      unexpected event noticing
   reasoning
      abductive reasoning
      analogical reasoning
      deductive reasoning
      inductive reasoning
      moral reasoning
      probabilistic reasoning
   volition
      decision making
         goal-to-current pathfinding
         path comparing
      acting
      problem solving
   planning
   learning
   percepting
   interpreting
      context targeting
      choosing role set
      role dispatching
   imagining
      scene space creation
      scene element evocation
      scene evolution
   memorizing
   remembering
   comparing
eventact
   frame
      open thought frame
      switch thought frame
      close thought frame
   goal
      find goal-to-current path
   percept
      link new percept to set of percepts



It's far from complete!

[ivan.moony]

This is how I sorted it out:

• processes change states
• events monitor state changes and fire processes

This is a dynamic part of  knowledge representation. Static part includes some tree-table, or other way interlinked representation of static knowledge. Data may be linked as in some spreadsheet (we change one cell, others update accordingly), but no circular references should exist. Talking about interlinked knowledge representation, I find functions as a good candidate for special handling of linking parameters to results. Also, static knowledge could be divided in three parts: input placeholders, output placeholders, and intermediate placeholders that serve as a linkage between input and output.

If you are looking for specific examples of state / process / event triad, maybe a good way to start from is analyzing our input sensors and output activities. Instinct should be inherited input -> output pairs that can be overridden later in the life by other, more suitable pairs. Basically, I think that learning is a process of realizing what output happens at what input, observed in our environment. When we find out a function that describes the behavior, we have a chance to remember it and use it in later planning of our actions.

But what really happens in human brain? It is possible that we use only static knowledge. Then dynamic part would represent a time flow, bringing us from moment to moment, where a past is passed as input to our brain, resulting in our future output. I imagine it like this:

Brain (Past) -> Future

where Past and Future carry on information about a change, while Brain is a function that represent static knowledge. I'm still not sure if this past / future theory is correct, but it may be worth of pointing it out. Functional languages still have issues with neatly representing time flow (I never liked a use of monads), and if brain works similar to functional languages, it may be a case that this past / future theory is correct.

[ranch vermin]

u could hook this thing up to monitor an ai doing things, and it would fall into the categories when they spark up.   u could even monitor a person like this if u had an action string of what they were doing.  maybe u could give them scores as well and develop a certain kind of behaviour.

to add some myself..

the literal thing.
the thing as an idea in a different form, like a symbol of it instead of the real thing. (metaphor)

generalization,   as in the scene taken from a slowly disintrigating detail from the whole explicit motion.

knowing door knob as high level adjectives,  as well as the specific photo.  - and using this measurement in another form of another behaviour?

[Zero]

Here is how I see things.

I think that a State can be adequately defined as an object-oriented structure: types (classes), values (attributes), and how to manipulate these values (methods).

A Process can be any ongoing activity / runtime / loop. In fact, it can be an extended Behavior Tree. It has a target (a set of States it works on), and it can be started, retargeted, suspended, resumed, or stopped, by other processes. Its current state is also part of a State structure.

EventActs are both events and acts. Calling a method of a State structure is an act, which is also an event. When a State structure is modified, for example because the State of a process changes, or because the input changes, an event is emitted. Input can also be made of events.

Static part includes some tree-table, or other way interlinked representation of static knowledge.

Maybe mixing entity-relationship and semi-structured data...

Data may be linked as in some spreadsheet (we change one cell, others update accordingly), but no circular references should exist.

Yes, the updating could be done by Processes!

the literal thing.
the thing as an idea in a different form, like a symbol of it instead of the real thing. (metaphor)

Ok, a "symbolizing", and a "symbolized"...

knowing door knob as high level adjectives,  as well as the specific photo.  - and using this measurement in another form of another behaviour?

I didn't understand that.

[ranch vermin]

That symobology thing, might be syllogy  - u already had it in your list.
As im thinking about it - Its a complex subject to do with the robot describing things instead of actually going through the process.   so explaining things is different from actually doing them.   its important now i come to think of it!!!    Because the robot needs to be trained to do things without implanting into its head,  and communication is symbolic rather than the actual practice.

With the door knob thing Sorry I dont even know what I was on about really yet, maybe its got something to do with the same thing.

This idea seems cool,  because you could have a monitor going by as it switches its states through its process, (sorta like those terminator cuts, out of its eye, where it picks out of different swear words to evade situations that are bad for its mission.)
It has a form of willpower this way, because it chooses to gather knowledge instead of being on constantly, perhaps.  or whatever youd want.

[Zero]

It looks good so far. I need more items in the list. And I need a syntax now! I just can't think without a way to write things down in a formal language! I'm working on it.

[Zero]

This is a declarative language draft.

It's free form, indentation doesn't mean anything to the parser.

You do two things with this language: importing declarations from other files, and defining "items", which can be anything.

Every item has a name. An item can be either:

• a nestable meta/data semi-structured tree
• a typed relation between existing items
• a reusable set of parameterized items

Informal syntax taste-of:

   namespace prefix = "filename"

   item name -> [ meta | data ]

   item name -> relation type { slot1: item1, item2, ... ; slot2: item3; }

   new relation { parameters } = ( items declarations )




Here is the meta/data syntax. In "meta" you'd put everything needed to determine how to manipulate the data part. In "data" you'd put the data to be manipulated.

my favorite site ->
[
   [type|
      website
      [media|forum]
      [topic|AI]
   ]
|
   [name|AIDreams]
   [members|foo bar geez]
   [posts|
      [
         [number|1]
         [by|foo]
      |
         Hi guys, blah blah...
      ]
   ]
]

In XML, the "meta" part would be the attributes of an element. XML is weaker here, since attributes are merely associative arrays. In M|D, attributes are trees themselves, allowing a perfect representation of information, even when the complexity reaches high levels. Moreover, being tree everywhere, the representation is consistent and easier to manipulate.



Now, here is the relation syntax. It looks a bit like CSS. First you put the name of the type of relation, then between curly braces, a list of items following their role in the relation. Several items can have the same role.

rain wets -> explanation {
   fact: everyone is wet;
   causes: it rains, nobody has an umbrella;
   consequences: they'll catch a cold;
}




Now the last one, a bit more complicated. It's a bit like a function, but for items declaration. The idea is to freeze parts that are always the same in a pattern, and give this pattern a name.

dog of {animal, someone} = (

   kind -> instance of concept { instance: animal; concept: dog, pet; }
   
   ownership -> owns{owner:someone; owned:animal;}
)

me and Max -> dog of { someone: me; animal: Max; }

It's a way to create new relation types. A macro, sort of.



Again, it's just a draft.
 

[Zero]

item -> [ meta | data ]

item -> { slot: item, item; slot: item; }

namespace: "filename"

pattern: ( arg, arg ) = ( ... )

pattern ( arg, arg )


It's not really a new relation type, but rather a pattern, a user-defined syntactic sugar.

[Zero]

I'm dropping user-defined syntactic sugar, because anyway the template system would be very weak. That's an entire topic in itself, so I leave it outside of scope. That would be the job of a diagramming IDE maybe?

But I add one last thing: a behavior description syntax. The formalism is based on Behavior Trees as used in video games. The syntax is similar to s-expression, except items are not separated by white spaces but by commas. Why? Because in the semi-structured syntax, and in the relation syntax, we can already use identifiers that contain white spaces. It would be weird to forbid them only in the behavior syntax.

item -> ( do until success, ( ... ), ( ... ) )

Here are a few base nodes for behavior trees (there can be many more):
- always fail
- always succeed
- always invert
- repeat until success
- repeat until failure
- do until success
- do until failure
- do concurrently

ED: I'm a huge fan of PLEXIL, but I think it's too heavy here.

[Korrelan]

Hi Zero… It looks cool so far.

So is this going to be like a scripted language?

Then the scripts/ programs are then run through a compiler/ engine and interpreted?

If so… what language are you considering writing the actual interpreter in?

 

[Zero]

Thank you. Yes it would be a sort of declarative scripted language, targetting directly high level human-style mental functions.

I know AGI is often considered as being about unsupervised learning. But I think that if we had the right tools, we could build an adult working mind directly. Then, if complete, it could learn on its own.

The meta/data unstructured syntax is meant to be used in representations of mental materia. The relation syntax is employed in linking mental items together. The behavior syntax is for mental behaviors.

The whole thing would be interpreted, yes. Probably, little chunks would be developped by the user, just to see if one little part of a mind, one little mental function, works correctly. Then libraries could be shared.

I'm targetting browsers maybe. I have a few specific ideas about user interface I'd like to try: something very minimalist, white screen, a few words in the center, maybe a line or two, and "directions" on the sides... I'll talk about this soon in the other new childboard!

 

[Zero]

The same problem occured often, during my AI research, and I'm pretty sure anyone really trying to find the "heart" of AGI had the same problem. It is the "modeling loop" problem. You work on a specifc aspect of the mind, and you can create a model of it that's quite accurate. Then you realize it's related to another aspect of the mind, which you have already modeled really differently. So you align the model of the other aspect, to fit with the first one. But doing so, you realize you have to align a third aspect with the second one. And aligning the third one, you realize you have to align the first again because it doesn't fit anymore. It's an unsolvable cycle.

For example, in the big list of the first post, you could say that "generalizing", with its subnodes "pattern recognition" and "pattern label creation", are strongly related to "interpreting" and its 3 subnodes, and also related to "percepting".

My solution to the "modeling loop" problem is not to align models anymore. This tree will just continue to grow, going deeper towards subnodes of subnodes, until things are simple enough to be executable. In the resulting system, there will be several equivalent representations of data, and a translation engine will continuously maintain integrity by updating representations that are related.

ED: The list is bigger now!

[ranch vermin]

Now, here is the relation syntax. It looks a bit like CSS. First you put the name of the type of relation, then between curly braces, a list of items following their role in the relation. Several items can have the same role.

rain wets -> explanation {
   fact: everyone is wet;
   causes: it rains, nobody has an umbrella;
   consequences: they'll catch a cold;
}

these will definitely work, its just a high level truth table (and truth tables EXECUTE!!) rather than just having the bits themselves, your relating them to other items.
making it all interrelate, as i imagine the whole thing is just cause and effect.    keep going brainiak!

just make sure you dont end up like the open cyc guys with a database that isnt geared to pump a reaction out of it everyframe.

they ended up coding a reaction on top of it, that just spat out what it knew.  but it should come from the truth tables themselves to knock out a reaction each frame.  of what do i do?   we all do things in life, especially in the toilet, and once one hasnt enough to do he gets depression so its big a part of life!

maybe its a bit like sherlock holmes.

one last thing to spit out of my head to you.

You may find that repetition in your big net, is going to be necessary to build it, without hiccups appearing in the formation where things wont fit.   i know it sounds ugly but it might help?  just a suggestion.

[Zero]

just make sure you dont end up like the open cyc guys with a database that isnt geared to pump a reaction out of it everyframe.

Sure! I think the dynamic part of it could work a bit like in an Entity Component System, as used in video games. Let me explain my view.

In ECS, Entities and Components are the easy part. Systems are what's really interesting. They are like tiny engines, ready to work on any thing that matches what they like to work on. A System has two parts:
- A requirement part, that defines what an Entity should be like to be eligible
- A procedural part, that does the actual state-change job
As soon as an Entity corresponds to what a System wants, the System works on it.

For example, requirement can be like
- being part of this or that relation
- respecting this or that schema
- containing this or that item
- ...etc.

When an Entity's state changes, you check its new state against existing Systems. When there's a match, you register this item on this System. If it doesn't match anymore, you unregister it.

And every turn, you run every System.

Here, Entities are "items", and Systems are "processes".

[Zero]

Here is the PEGjs syntax for items. You can test it at https://pegjs.org/online

   namespace prefix : "filename"
   item id -> [ meta | data ]
   item id -> relation type { slot1: item1, item2, ... ; slot2: item3; }
   item id -> ( behavior node, ... , ... )

   namespace / namespace / item id

Code

sourceCode
= ns:namespace* id:itemDef* _ { return { namespaces:ns, definitions:id }; }


_
= [ \t\r\n]*


namespace
= _ ns:namespaceId _ ":" _ '"' fp:filepath '"' { return { namespace: ns, filepath: fp }; }


itemDef
= _ id:localItemId _ "->" _ iv:itemValue { return { item:id, value:iv }; }


namespaceId
= c:normalChar* { return c.join('').trim(); }


filepath
= c:[^"\t\r\n]* { return c.join('').trim(); }


itemValue
= metadata / relationship / behavior


localItemId
= c:normalChar+ { return c.join('').trim(); }


itemId
= fns:namespaceId nns:nextItemPath* {

  var whole = [fns].concat(nns);
  var id = whole.pop();
  
  return { type:"item", id:id, path:whole };
}


nextItemPath
= "/" ns:namespaceId { return ns; }


metadata
= _ "[" meta:metadataContent+ "|" data:metadataContent+ "]" {

	return { type:"meta/data", content: { meta:meta, data:data } };
}


relationship
= _ ri:relationshipId _ "{" _ sd:slotDef* _ "}" {

	return { type:"relation", name:ri, content: sd };
}


behavior
= _ "(" fb:behaviorContent nb:nextBehaviorContent* ")" {

	return { type:"behavior", content: [fb].concat(nb)};
}


metadataContent
= itemValue
/ textContent


textContent
= c:normalChar+ { return { type:"text", content: c.join('') }; }


relationshipId
= c:normalChar+ { return c.join('').trim(); }


slotDef
= _ si:slotId _ ":" _ fi:slotValue _ ni:nextSlotValue* _ ";" {

    return { slot:si, value:[fi].concat(ni) };
}


behaviorContent
= itemValue / itemId


nextBehaviorContent
= _ "," _ b:behaviorContent { return b; }


slotId
= c:normalChar+ { return c.join('').trim(); }


slotValue
= itemId / itemValue


nextSlotValue
= _ "," _ v:slotValue { return v; }


normalChar
= c:[^\-\<\>\{\}\[\]\(\)\:\/\,\;\|\\] { return c; }
/ "-" c:[^>] { return "-"+c; }
/ "\\" c:. { return c; }

Back in black.