Part 1 : TITLE PAGE | Preface | What is Consciousness? | Outline of the system Part 2 : Building bricks | Layer-1 | Layer-2 | Layer-3 | Layer-4 | Layer-5 Part 3 : Discussion | Arguments | Conclusions | Addenda Tartan Hen Publications : Home | more books | Contact : feedback@tartanhen.co.uk REPRESENTATION: THE BASICSThe Issue of SignificanceMy whole thesis pivots on the issue of representation. It is deceptively easy to devise forms of representation for all manner of things, but the crux of the matter, is the significance which is ascribed to a given representation. By "significance" I mean, the extent to which a representation can operate as a foundation for action. For example, I could find various ways to represent the shape of an object, using all kinds of coordinate systems. It scarcely matters, however, which is chosen. What does matter, is whether or not that representation will provide the information needed for a robotic arm to pick the object up, or use it as a tool, or judge whether it will fit neatly into a hole, or recognise it as a potential source of danger, and so on. I hold this to be a self-evident fact. A robotic mechanism is able to operate in a way which we migght describe as intelligent, if and only if, the actions it carries out, are INFORMED by an internal store of information. The criteria I have used in choosing the form of representation which I will describe, are these - (1) The form of representation must be capable of being evolved from pre-existing characteristics of the mechanism (2) It must contain the information which will inform the actions we wish the mechanism to perform. Note the criteria I have NOT included. I have not given much consideration to the convenience of a form of representation, or its computational efficiency. These are considerations which must be taken into account if one was trying to produce a practical implementation of the mechanism. They are not relevant to my objectives. Basic Units 1. #STATE NOTE1: the "#" (hash-prefix) denotes a special structural unit. NOTE2: Recall how #states are formed The basic unit of representation is the #STATE. A #state is a collection of #perceptions, all of which occurred during the same time interval. Every #state carries a unique identifier, a time-stamp and a set of perceptions. A simple way to denote a #state is this - where S = the identifier T = the time-stamp and (P1,P2,P3,P4 ...) = the collection of perceptions. We do not need to have an actual value for any of these indicators. At this stage all we need is the ability to distinguish between indicators. Whenever that is necessary we can append numerical postfixes S1, S2 S3 etc. Although we do not need to have actual values for the indicators, we do need to be able to express a relationship between them. So if we have a set of time-stamps (T1, T2, T3, .... ) we need to be able to write T1 < T2 < T3 ... where the "<" symbol has its usual connotation. In this case it means that T1 came before T2 which came before T3, and so on. So we can order #states by their time-stamps in a chronological sequence. 2. #CAUSAL-LINK The next unit we must consider is the #causal-link. As explained in the chapter on layer-3, a #causal-link consists of two #states which occur frequently together as an associated pair, such that the first is a reliable predictor of the second. So we have two #states - say [S1,T1] and [S2,T2]. I omit the list of #perceptions because these do not affect the representation. It should be assumed, however, that these lists are present. The two #states are linked (and encapsulated) by a third which spans the time-interval of both. This can be written this way - where C1 is the unique identifier of this structure. ext(T1,T2) indicates a time-interval (or "extension") which starts at time T1 and ends at time T2. To avoid unfortunate overlaps or gaps between contiguous chronological time intervals we can adopt the convention that a time-interval of that kind will include its starting time, but exclude its ending time. cause(S1,S2) indicates that the #state S1 is recognised as a causal precursor of #state S2. LINKING THE CAUSAL LINKS The main reason why I have chosen to represent a causal-link in this explicit way (rather than simply by means of a pointer, or relationship link as is common in computer science), is because I want to be able to re-use these #causal-links as structural units within a representation of some more complex situation. By having #causal-links which have a structure form of their own, which is distinct from that of the #states for which they express a causal relationship, we are able to introduce another #causal-link which links the #causal-links. So if we have two #causal-links say C1 and C2 such that C2 = [C2,ext(T3,T4), cause(S3,S4)] And why is that important? We will inevitably come across situations where this arrangement arises. eg: "I hit John because he burst my balloon deliberately." Note that it was not the condition of the balloon being burst which cause the speaker to strike, it was the fact that he CAUSED it to be burst (with malice aforethought) The ability to link #causal-links, in additional more complex cuasal relationships, endows this representational form with great power. By introducing negative #states (eg: NOT(S1) we can then also represent the circumstance where one #state PREVENTS the occurrence of another. There is more to be said on the topic of causality. How, for example, can we represent the situation if we expect several different outcomes from a given event? And how can we represent the situation if these different outcomes are alternatives? These issues will be exploreed in the section on CAUSAL LINKS. 3. #CONCEPTS #Concepts are the constructional units with which an #interpretation is built. The #concept is a complex structure which contains, possibly many, #states and #causal-links. A #concept can occur in two forms. It can have the basic form in which it is stored in the #conceptual memory. In this form the detailed information is missing. All it has are the empty slots, where the details can be stored. The basic form of the #concept of a DOG, for example, will have no colour. All it will have is the vacant slot where a colour can be recorded. Thus every dog does have a colour, but not all dogs have the same colour. A #concept can also have the copy-version format. In this form the details are filled in as required. It is in this form that the #concept becoomes a component of an #interpretation. The sub-units, or components of a #concept, are grouped under four main headings #CONCEPT = HEADER INFORMATION CORE INFORMATION INCIDENCE ASSOCIATIONS The HEADER INFORMATION contains the following Unique identifier Name Status Context Super-ordinate Sub-ordinate UNIQUE IDENTIFIER this allows other structures to refer to the #concept. NAME. This is merely a convenience which allows us to discuss the #concept without to identify it with uninformative numerical identifiers. We can then talk about the #concept which represents "a person", or "a box", or "an idea". The NAME can be combined with the curly-bracket notation which allows me to write {PERSON} which denotes "the #concept structure which represents a person" and {BOX} which denote "the concept structure which represents a box". The STATUS can have the value REAL or POTENTIAL. A potential concept is one which is envisaged as when a prediction is made about future events. A concept with REAL status has either occurred in the past or is a current event. CONTEXT is the identifier of the structure (usually an #interpretation) of which the #concept is a component. SUPER-ORDINATE is a reference to the higher level #concept of which this #concept is a sub-ordinate. For example {FIDO} would have {DOG} as its super-ordinate #concept. SUB-ORDINATE component is the reciprocal relationship. That is, it is the reference pointer with which {DOG} refers to {FIDO} and all the other sub-ordinates {ROVER}, {SPOT} and so on. The CORE INFORMATION is a set of components which to a great extent define the concept. The CORE contains information about the location, size, shape and trajectory of a phyical object. Indeed it is by providing space for these quantities to be recorded, that a #concept defines a physical object. A physical object can also have sub-ordinate components. For example a {PERSON} will have such components as {LEGS}, {ARMS}, {TRUNK} and {HEAD}. It will also have {FLESH}, {BLOOD} and {SKELETON}. And that, if one considers what then may ensue, is in common parlance, the oopenig of a can of worms. Just where is this analysis into components going to stop? My answer to that, is that it must stop at the very first layer of components. Let any further break down into smaller components, be handled by the #concepts corresponding to the first layer. And the next layer down will be handled by their first layers, and so on. The #concepts belonging to someone qualified in anatomy, will break down further than the one I have for example. The context of discourse, will determine how far we might wish to explore the analysis into parts but sooner or later, the analysis will end when it reaches the limit of a person's knowledge. This strategy avoids the embarrassment of every conversation about a {PERSON} becoming a treatise on anatomy and physiology. At its most extreme, this problem, often descirbed as "the explosiion of parts", could take us down to a treatise on the physics of sub-atomic particles. There has to be an arbitrary limit set to this process, and the first layer down would seem to be the sensible default option. Only if the context demands it, should we allow the system to go further. The CORE will contain information about the size and shape of an object. The stored version of a #concept cannot provide any information about dimensions, but it can priovide prototypical information. Every type of physical object will, for example, have a standard size indicator. This will not be given in numerical form. It will just be another of those simple unique identifiers. A {MOUSE} will have a standard mouse-size and an {ELEPHANT} will have a standard elephant-size. Denote these STD-1 and STD-2. Although we will not have any information about the actual size of these measures, it will be known that STD-1 << STD-2. By that I mean that the standard size of a mouse is very much smaller than the standard size of an elephant. If the system encouters a reference to a large mouse, the stored version of the #concept {MOUSE} will be copied to form a copy-version and the sizze information will be changed to be another indicator (say SZE-1) where SZE-1 > STD-1 (bigger than standard mouse-size). The notion of a small elephant can be handled in the same way, without there being any danger that the system will regard a large mouse as being larger than a small elephant. All quantities are therefore represented in the form of relationsl data of that kind. There will be standard shapes, standard colours and standard textures. All detailed information will be given in the form of departures from these standards. The CORE informatio will also contain references to the #concepts, of which it is itself a component. A {PERSON} for example, is a component of {COMMUNITY} which is a component of {HUMANITY}. Note that these references to component parts and higher order groupings, are in addition to the conceptual hierarchies to which reference is made in the HEADER INFORMATION. A {PERSON} is simultaneously a member of {SOCIETY} and of the {ANIMAL KINGDOM}. A {PERSON} is the super-ordinate to {TOM}, {DICK} and {HARRY} and also can be analysed into {ARMS}, {LEGS} and {HEAD}. INCIDENCE INFORMATION Recall how a #concept is formed. It starts life as a chunk of data extracted by the compression algorithm because it is repeated several times. Each of these compression objects is an "occurrence" of the experience. The INCIDENCE component of a #concept, is a list of all these occurrences. ASSOCIATIONS The ASSOCIATIONS consists of chunks of experience which frequently (but not consistently) accompany the occurrence of the #concept experience. For example, the occurrence of a balloon will often be associated with the occurrence of the experience which we learn to call "a party". When #concepts are re-processed by the compression algorithm, to generate higher level #concepts, these repetitions may be identified leading to the formation of the #concept {PARTY}. Summary #STATE, #CAUSAL-LINK and #CONCEPT - these are the constructional units of the representational structures which I will describe in further sections. The description begins with simple solid PHYSICAL OBJECTS. To see a list, return to the ADDENDA.
{REALITY} Part 1 : TITLE PAGE | Preface | What is Consciousness? | Outline of the system Part 2 : Building bricks | Layer-1 | Layer-2 | Layer-3 | Layer-4 | Layer-5 Part 3 : Discussion | Arguments | Conclusions | Addenda Tartan Hen Publications : Home | more books | Contact : feedback@tartanhen.co.uk Copyright © Hugh Noble (Nov 2006) |