A proposal for a strongly-typed ACR framework Stephen Cranefield, Mariusz Nowostawski and Martin Purvis Department of Information Science University of Otago Dunedin, New Zealand scranefield, mnowostawski, mpurvis @infoscience.otago.ac.nz December 21, 2001 1 Introduction This proposal briefly presents a design for an abstract content representation scheme that makes no more commitments on the style of content language allowed than the FIPA abstract architecture and allows for automated type-checking of content expressions. The ACR presented here is based on UML. Class diagrams are used to define an ACL and a set of con- tent language concepts used by the ACL. In addition, particular content languages such as SL or specialised domain-specific ones can also have their abstract syntax defined using class diagrams. The interface be- tween content languages and the ACL is explained using the notion of type substitution: classes in a content language can be declared to ‘implement’ a predefined interface representing a specific type of content ex- pression (e.g. proposition, term, action or definite description). In this framework, a message is viewed in the abstract as a network of objects that are instances of the classes in the ACL and content languages models, and it can be represented graphically as a UML object diagram (see Figure 5). To provide concrete instantiations of messages, ACR mappings need to be defined from UML to imple- mentation languages and serialisation formats. This has been demonstrated to be possible for Java together with a serialisation format using the XML-based Resource Description Framework [1, 2]; however, the current version of this ACR framework includes some UML features that are not supported directly by Java and are not yet simulated in the Java mapping (multiple inheritance, discriminators on generalization relationships, and multiple instantiation). 2 Content language concepts Figure 1 presents a UML diagram defining a set of interfaces representing types of content language ex- pressions that the FIPA ACL and communicative act library refer to (we will refer to this as “the CL package”). The ‘marker interface’ pattern [3] is used 1 : the interfaces have no operations but represent distinct (externally-defined) semantic notions. Some dependency relationships (dashed arrows) are shown, for example, to indicate that an action description is generally composed from a reference to an agent and a description of an act to be performed 2 . However, at this abstract level it is not appropriate to make any decisions about how the implementation structure of these three concepts should be related. The key content language concepts identified by the FIPA abstract architecture are Proposition, ActionDescription and Term. DefDescription (definite description) is also required for use 1 Alternatively, UML’s “type” stereotype could have been used, but the notation for types and implementation classes is more cumbersome than that for interfaces and classes that realise them. 2 The terminology used here is that an “act” is something that can be peformed by an agent and an “action” is the performance of an act by an agent. 1