Referential Nets as ACT-R Declarative Memory Representation

ed versions of descriptions like the one given above can be captured by chunks of the following type: (chunk-type abs-designation op var predicate) where op is a description operator ( , , some-t, all-t), var is the abstraction variable and predicate refers to a chunk containing the predicate, here: a wife chunk. (Using variable slot names is not standard but possible in ACT-R.) While this part of the translation is straightforward, two other issues cause problems. The first one is that attributes can have values, which can be lists. For example, the above refO representing David could stand for a scientist belonging to two research groups, represented by the list attribute member_of([‘GRP1’, ‘GRP2’]). In order to represent this as chunks, the list must be spilt up into multiple attributes: member_of(‘GRP1’), member_of(‘GRP2’). The second and more severe problem is to translate the assignment of expressions to referential objects, e.g. to represent that human is an attribute of r1. This is problematic, because refOs are not restricted in their number and kind of attributes or designations. Thus, although refOs and chunks fulfil similar roles in organising and structuring the representation (memory), they differ in that chunks are typed expressions, while refOs are simply terms, i.e. they are proxies of entities. For simplicity, at this point I will discuss only the assignment of attributes to refOs. Assigning designations (which actually can also have attributes) to refOs works analogously. The two ways to realise these assignments in ACT-R make different predictions in the resulting models. The first solution is to define a general chunk-type and distribute the information over multiple chunks: (chunk-type attrib-assign refo attrib) (att1 ISA attrib-assign refo r1 attrib human) (att2 ISA attrib-assign refo r1 attrib male) Under this solution, the knowledge about the entity represented by r1 cannot be accessed at once. Instead multiple chunk retrievals have to be performed until the required information has been found. The second solution is to store the attributes in a list and have just one chunk per refO, which means that all attributes are available at once: (chunk-type att-assig refo att) (assig1 ISA att-assig refo r1 att '(human male)) The difference between the solutions is substantial, because solution 1 predicts that accessing knowledge about a refO can take considerable time, while solution 2 finishes the comparison within a single ACT-R cycle. While the ACT-R theory does not permit lists as slot values (and, thus, predicts behaviour according to solution 1), referential nets allow immediate access to all information about a refO (predicting solution 2). An indication that solution 2 is cognitively valid is the model INC (incremental conceptualiser, Guhe et al 2003), which produces reliable simulations of humans performing the task of conceptualisation for language production. The processing of concepts is a good example for determining the correct solution because of the predicted processing times: solution 1 predicts longer processing times for bigger refOs: at least one ACT-R cycle per attribute. (See Guhe in press on why refOs are appropriate to represent concepts.) Empirical support for this prediction of solution 1 is lacking: there is no evidence that familiar concepts (i.e. concepts about which much is known) take longer to process. In ACT-R 6, the theory’s current implementation, the function computing the similarity between two chunks has had to be extended to allow for lists. In a prototype implementation I have realised the similarity function as computing the number of shared attributes over the number of all attributes (cf. Guhe in press), e.g. '(human male) x '(human) = 1/2 '(human male) x '(human woman) = 1/3 (The computation is in fact more complex: (1) attributes can contain arguments (memb_of_family (‘SMITH’)); (2) these arguments can be lists (member_of([‘GRP1’, ‘GRP2’])); (3) designations must be compared, as well. )