The CS405 Introduction to EM module given annually at Warwick devotes a substantial part of its 40 hours to covering material that was dealt with only sketchily in our two day workshop. For an overview of the main themes of EM that inform CS405, you may find it helpful to consult Karl King's MSc thesis. Some of the key diagrams discussed in the module can be found here. They may help to clarify some of the issues raised during the workshop, one or two which are here discussed in a little more depth. In the text below, references to numbered slides refer to slides from the presentation that contains the key diagrams. Only the first slide (Slide 1.1), which depicts the as-of-now and dynamically evolving relationship between the modeller's construal, referent, understanding and context, was highlighted in the main sessions.

Mayuree Srikulwong (aka "Em") asked several very perceptive questions in the course of the workshop. Here are some brief notes relating to some of the issues she raised.

• What relation is there between EM and other forms for modelling for software development? It is natural to seek to relate EM with the modelling activities that are involved in conventional software development. For instance, it is tempting to see EM as playing the same role as the Unified Modelling Language (UML) prior to the detailed specification of a software system. Though EM can certainly be relevant to understanding requirements, its nature is radically different from conventional modelling. The key distinction is that EM aims to record and enhance the modeller's understanding implicitly rather than by explicit 'knowledge representation' techniques. What the modeller understands is tacit in what the he/she learns through interaction with an artefact they are creating, and what expectations and skills in interacting and interpreting they develop in the process. The difference in orientation between conventional software development and software development based on EM principles is the subject of EM paper #121. The practical distinction between what can be captured in a traditional UML artefact such as a statechart and what is implicit in an EM construal is illustrated in the digital watch construal in the EM projects archive. Slides 1.2 and 1.3 depict the way in which a family of definitions describes an environment for interaction within which program-like behaviours can in principal be traced. The completely different character of the EM development process that results is highlighted in Slides 1.4 and 1.5.

• The difficulty of coping with the richness of experience. The key notion of EM, as expressed in Slide 1, is that an interactive experience we contrive (the EM construal) can be used to make sense of another interactive experience (its referent). The idea of exploring how one experience can illuminate another experience through engineering a connection that is itself experienced is in line with William James's philosophical stance of "radical empiricism" (cf. EM paper #078). If you appreciate the bold nature of this Jamesian stance, you will find it rather startling, as it argues that semantic relationships are not necessarily or in any absolute sense amenable to explanation - they can be given in experience. A natural reaction is then to ask how we can cope with appealing to experience as a basis for meaning in this way - especially when you consider how we are trained as computer scientists to accept only formal accounts of semantics. As I observed at the time, Em's comment on the challenge that such an approach to interpreting experience entails echoes James's own words on the subject: Experiences come on an enormous scale, and if we take them all together, they come in a chaos of incommensurable relations that we can not straighten out. We have to abstract different groups of them, and handle these separately if we are to talk of them at all. But how the experiences ever get themselves made, or why their characters and relations are just such as appear, we can not begin to understand. (William James, Essays in Radical Empiricism p133). We can regard the activity of "abstracting different groups of them, and handling thes separately" as characteristic of EM, and note that it is more primitive in character than the model-building activities that traditionally surround "formulating a specification".

• Adopting person-centric directions for navigation. Em's specialist interest in the theme of human navigation led her to remark that the room construal made use of an inappropriately external objective frame of reference, in which the SE, SW, NE, NW corners of the room featured prominently for instance. Given that we made such play with the idea that the room construal might relate directly to our immediate experience of the actual room in which the workshop was held, it was natural to argue that the frame of reference should be centred on the person, and the direction in which they were oriented. Em even proposed that we should consult the author of the construal to ask permission to modify the frame of reference in this way. This feedback raises several interesting issues. In the first place, whilst it is quite appropriate to stress the as-of-this-moment quality of the experience that informs making the room construal, it is quite clear that experience of moving about within a room is not the principal focus of the room construal in its current state. It is much more appropriately configured for rudimentary architectural planning and design, where simultaneously making a door and door frame wider is an appropriate agent action, and movement of furniture within room is to be interpreted as disposing rather than manipulating furniture. So the objective frame of reference reflects the way an architect might view the room from an external objectified standpoint. There are extensions of the room construal in which students have embellished the other viewpoint - that of a real room user moving furniture around in a physically more realistic manner. Making such adaptations curiously can be handled simply by extending the model allowing shifts of context - in somewhat like the way in which we change the context of a physical when we call in the decorators or the builders. (I say 'curiously' because you might expect a specialisation of the construal to entail restriction rather extension cf. the impact of including the humanNim.e file in Session 4.) Without doubt, person-centric frames would be a good feature to incorporate when introducing such a context shift. But the idea of having to consult the original author for permission to make such a change is strangely out-of-place where making construals is concerned. After all, the meaning of a construal is constructed by the person or person(s) currently in charge of the model-building - it is shaped by the interactions and interpretations that they are able to sustain. For that reason, many EM construals exist in several different versions and the matters of authorship and integrity are pragmatically rather than formally determined. In some sense, the fact that many people take on the development of a construal in their own personal way is to be seen as positive endorsement of the work of its initial author, and in no way a threat to their ownership of the personal contribution they have made to its meaning.

What are the virtues of definitive notations for interactive graphics?The rather long-winded and clumsy form of the notations that surround line drawing in EM invites questions. When we compare the way in which the outline of a table is described in Donald with the steps required to draw a table using MacDraw or the simple prescription that is required to specify it in Logo, it is at first hard to see the merits of using definitive scripts. The fundamental concern in EM (cf. Slide 1.1) is that the room construal has a state, manifest in interaction, that embodies dependency relations between observables characteristic of a room layout. A procedural recipe for drawing the room layout is categorically ill-suited for interpretation of this kind. It is on this basis that we regard making construals as far better suited to supporting constructionist learning than Logo programming. (For more discussion of this issue, see Lecture 7 from CS405 2010-11). The distinction between the roles played by developer, teacher and learner in conventional programming and in making an EM construal is depicted in Slides 2.2 and 2.4. Making construals blends the separate activities listed on Slide 2.3.

What form should EM tools / instruments ideally take? The comparison between desktop EDEN and JS-EDEN is thought-provoking. The complex way in which several different definitive notations interact in EDEN (as illustrated in the file humanNim.e for instance) points to JS-EDEN as a much more accessible EM tool. JS-EDEN addresses line-drawing and window layout without adding new special-purpose notations and - in Harfield's JS-EDEN Canvas variant introduced in the workshop - it has a very simple interface. Working with JS-EDEN Canvas seems well-suited to the needs of the EM novice, and has the advantage of requiring less screen space (as is helpful in use on a handheld device). Despite these apparent advantages, there are arguments in favour of a more open-ended environment for supporting EM. The Master variant of JS-EDEN (see http://jseden.dcs.warwick.ac.uk/master) offers an environment in which the very design of the interfaces to agents - including the interface for the modeller - can itself be the subject of the EM activity. This environment may feature many input windows, canvases, html views and symbol viewers, and these can be organised so as to be reconfigured by dependencies and agencies that reflect the current context for interaction. Such an environment is best suited to a large screen rather than a mobile device, and is intended to support visualisation and interaction that does fuller justice to the richness of everyday experience. In principle, such an approach can make provision for input windows in which special-purpose notations such as Donald and Scout can be entered, and allow on-the-fly extension and customisation of the modelling environment through the introduction of new plug-ins. There are good reasons to suppose that this pluralist approach - though it is liable to lead to the same kind of accidental complication that arises in managing multiple notations in desktop EDEN - more faithfully reflects the qualities of commonplace experience. Consider for instance how a line drawing notation such as Donald that is based on an underlying algebra of geometric entities can be adapted for different descriptive purposes (such as specifying geometric relationships on the surface of a sphere, for instance) by interpreting algebraic expressions in a different axiomatic framework. The key point here is that the descriptive qualities of a construal are intrinsically bound up with the way in which it is specified, and the notations used to specify dependency in particular. Though it may seem to be in the spirit of EM to eliminate definitive notations (such as feature in EDEN) in favour of constructions framed using less sophisticated notations (such as feature in JS-EDEN), this is to overlook the experiential significance of notations that operate at a higher-level of abstraction. An interesting and topical comparison can be made between the way in which mathematicians use special-purpose symbolic notations such as differential equations to express relationships and Bret Victor's proposal that concrete representations and intuition-guided exploration can obviate the need for such notations (see worrydream.com/KillMath/). It seems implausible that Victor's approach could emulate the cognitive and experiential advantages afforded by Einstein's summation notation, for instance.

Several questions in the final session related to potential applications of EM. They included:

• How best to get started with EM? The practical sessions in this workshop are useful preparation for developing your own EM construals. You are recommended to set aside the traditional practice of identifying a specific functional behaviour, and to focus instead on identifying relevant agents and modelling key states in which agents interact. It is useful from the outset to recognise that there will typically be a wide range of possible applications that can be derived from a single construal. The initial form of your construal may be very simple, offering plenty of scope for direct interaction and interpretation. Because of the key role that is played by correlating experience of the construal with experience of its intended referent, it is helpful in your first attempts at practising EM to focus on a domain in which you have specialist knowledge and interest. The overall development of the construal is an incremental open-ended process that may extend indefinitely. Demonstration and discussion of your construal throughout the development is a useful source of inspiration in evolving the construal. In the course of making a construal, there are typically several instances of transitions from the single agent to the multi-agent perspective (cf. slides 3.1 and 3.2), accompanied by a trend from manual in an open fluid context towards automated agency in a more constrained context.

• Can EM be exploited in data-intensive applications and/or in association with data analytics? The primary focus for EM application is in situations where the modeller is directly concerned with sense making and shaping the semantic relation between the construal and its referent. To characterise the value of an observable as 'data' suggests a degree of objectivity. EM can be viewed as a means to establishing such objectivity. The term 'data' is also used to refer to what is 'given in experience' - hence 'empirical' in character. William James's radical empiricism, to which EM has great affinity, extends the notion of the empirical to include perceptions of relation. EM is a means of establishing what can be deemed to be 'data' and the nature of the relationships to which this data can be subject. To appreciate the importance of this activity, it is only necessary to consider the subtlety of the procedures that validate the entry of data into an examination spreadsheet, and of the process of interpretation of this data that then associates with this an overall degree result. In data-intensive applications of computing, it is typically the case that the empirical processes involved in identifying and interpreting data are carried out prior to the implementation - the very point being that the scale of data processing is beyond what can be performed with direct human involvement. There remains the possibility that EM could have a role in supporting experiment that is guided by the intuition of an expert modeller (e.g. in tweaking algorithmic parameters and observing the consequences), but the danger of detachment from immediate experience that framing abstract algorithms entails must be borne in mind. The limitations of the EDEN family of tools is another obstacle to applying EM in data-intensive applications. This is one of the topics addressed in Nicolas Pope's doctoral thesis, and motivates his work on the Cadence interpreter as an alternative notation for EM (for further information about Cadence consult the relevant lab sessions for CS304 in 2010-11 and 2011-12).