General comments on submissions

Empirical Modelling should be capitalised - Empirical Modelling is not 'empirical modelling'. Likewise, the term "EM artefact" (or EM construal, model, program) is to be preferred to "Empirical Model". The principles of EM have to do with the way that the modelling activity is conducted through establishing "as-of-now" immediate experiential relationships between an artefact and a potential referent. Observables, dependencies and agents are EM concepts. Pay particular attention to the spelling of key terms, such as dependent. Note that often agent is to be preferred to agency - which generally refers to the capacity that an agent has to act

Need to be clear about your answer to the question: Why is your paper about EM?

Helpful to address this by thinking about what kind of EM-related topic(s) you are addressing: application, tools, critique, and figuring out how to orient your topic to the key concepts. Can help to explore the relevance of a topic to EM by seeing how you can usefully mention ODA for instance. Making something using EM isn't enough - after all systems for the functions you are exploring in your papers may already exist and surpass anything that can be readily built with our current EM tools (if so, it's good to show awareness of this!). You may also make connections between EM and your chosen subject by exploiting the openness to different types of account - describing what you're doing towards making an application, refining tools, or contributing to a critique. Sometimes the term 'empirical modelling' applies well to what you want to do in your paper and model - where you're trying to use model-building to shed light on practical problems in well-known fields. You need to be aware when this is the case, as this can make it harder to link what you do to Empirical Modelling.

I remarked before that the advent of EDEN clocks promoted an evident emphasis on process modelling in 2005-6 - the initial emphasis on DOSTE may have prompted more interest once again in contexts where processes are or are to be established. Bear in mind that EM originates with visual concrete experience of a specific situation. This means that you should be wary if your title and theme have a generic system/process-like quality about them - a very broad title may be an indication of that.

You should reflect on how your modelling theme relates at different levels to specific situations and states, particular patterns of interaction in applications, and generic domains. It can be tempting to see EM as potentially breaking new ground in AI, but bear in mind that the kind of advanced model of an environment that supports reasoning corresponds to very high level of systematisation of experience. (Recall the heapsort model in this connection.) Whilst it's possible to have a specific objective for system simulation - "finding the solution to a particular problem ...", you need to approach this goal in a way that reflects EM thinking.

Note for instance that classical problem-solving restricts attention to particular subproblems and functionality in order to make model-building easier. But, taking an EM stance, making a simple model of a specific state-in-mind is actually a way of enabling more potential functionality, not less. If you put restrictions on your model (like "no sheep in the flock dies" etc) you are taking away potentially intersting interpretations and motivations for using EM in preference to some other modelling approach.

Ignorance, uncertainty and unexpectedness are allies of EM, so you shouldn't be in too much of a hurry to assert facts about your model. It's not a good idea to express your expectations too strongly - it's not the experiments that have an expected outcome that are characteristic of EM. In educational applications, beware of reinforcing the trad models of learning - why do we need EM if our feedback is quite formulaic and predictable?

Some of the best examples of EM models have been based on domains where good construals are not easy to come by. Paul Ness's sailboat simulation is an example of working in such a domain, as is Daniel Keer's ant navigation. In these cases, making models is a way of arguing in favour of a particular construal. Of course, you may want to locate your modelling exercise in a familiar domain where construals are well-established - it would perhaps be perverse to try to make a model of projectile motion that wasn't based on Newton's Laws. Think about which kind of domain you are concerned with, and what emphasis you are making within it. Are you modelling on top of a coherent understanding of a domain, or negotiating meanings within it?

If you are dealing with a domain that has a familiar well-established construal then think about ways of elaborating or subverting your context so that understanding has qualities that motivate EM. Thinking about a learner's perspective is one recourse (note how this means presuming that things that at first appear to be obvious and simple are no longer going to admit obvious and simple answers). Seeing your modelling exercise from many perspectives is another device (as in considering various different kinds of queue and seeing them from the perspectives of different agents). Having highlighted a variety of modes of agent interaction and interpretation, you can then explore EM as a way to negotiate conceptual integrity (as in the hybrid railway animation model, but also in relation to the 'simple' exercises of making a line-drawing model of a room). Another way of making the apparently routine less amenable to a rational systems approach is to consider the implications of singular or even pathological events.

Finally some miscellaneous pieces of advice:

• Make sure that your references are properly organised, and follow the formatting conventions exemplified in James Silver's paper last year (see notes for the Tuesday Week 9 seminar).
• Take advantage where you can of revisiting what was topical before the current versions of the EM tools were so well-developed. In that way, you will understand where some of our thinking originated, and typically be able to identify ways in which the model-building that older tools supported can now be refined (e.g. through using eddi, the presentation environment, the dmt, the aop, gel or of course DOSTE). It's good to see a historical emphasis in the choice of EM papers referenced e.g. in the WEB-EM-6 "Dining Philosophers" proposal, as there is a strong spiral development component in developing a long-term research project. Problems have to be pended until other issues have been addressed, and new tools can be developed.
• Try to represent what you're doing in as positive a light as you can. Rather than saying "This paper attempts to ..." use the vocabulary of "exploratory experiment" or "feasibility study".
• Please consult us, or post messages on the Forum, if you are looking for technical solutions that haven't featured prominently in the module. There are some topics that have been studied several times, and for which some kinds of solution have been devised. These include (e.g.): drawing a graph in Eden, making shortened lines to link labelled points without overwriting those labels, interfacing with simple USB devices, compiling some simple C functions into Eden (and of course it's likely that several of these admit more effective solutions based on using DOSTE). Sharing good solutions via the forum is something we'd like to encourage, as we have limited resources for development and see a benefit to everyone in making progress visible to all. You can always write to us first to claim priority if you are concerned about not getting the credit for your innovations. 
• Individual Feedback will be given, either in person or via email, in the next few days.