Dear Titto
Thank you for your response. Let me try to elaborate on it.
You wrote:
> In orer to fully define a simulation you naturally need
> to represent both the static and the dynamic aspect of
> it.
I think many simulations are embedded into a task, that
typically includes beside the run itself the preparation of
the run and the interpretation of the run. This task might
again be embedded into a learning situation, a decision
situation, etc..
So we have to construct the simulations, the tasks and
the situations. A notation which works for all levels and
connects them would be nice. UML has been shown,
for example for business objects and business processes,
to be seemless in this sense. In the end you not only have
representations of the static and dynamic aspects of the
simulations, but also of the tasks and situations.
> There is nothing that prevents RDF or any other semantic
> framework to express these dynamic aspects as well.
Yes, for example use cases are in fact simple classes and
the actor-use case relationship is a simple uses relationship.
But usefull specialisations of a framework are not as easly
seen if nobody tells you. And tools don't easly support
specialisations that come with special graphical notations,
special analytical procedures, etc..
> UML's Use Cases are very useful to express a system's
> functionality but are not necessarily relevant to simulation.
> Even in normal OO programming you would rather use
> Sequence/Activity diagrams rather than Use Case to
> represent the dynamic behaviour of a system.
Yes, use cases alone are not of very much use. They have
to be completed by something to get an executable spec.
On the other hand they provide a nice abstraction to talk
about a systems functionality.
Whether this abstraction has some relevance to simulation
is one of my questions that I was exploring a little bit recently.
I found, that they can be very usefull. There is a link between
use cases and the knowledge level B, see for example (Menzies
95) slides. Unfortunately use cases are not very common.
> In simulations it all depends on the kind of "architecture" you
> choose. The dynamic migh be implicit in the agent's rule set or
> in the scheduler logic.
What is implicit in the software doesn't have to be implicit in the
modellers mind. So use cases can be very usefull on documenting
decisions that become invisible in the code. We must develop
skills to express "architectures", to discuss these choices. We
could also go on, and assigne use cases to phaenomena that
emerge in our code.
> I also believe that the most relevant result of an intermediate language
> would be to identify the recurrent and reusable abstractions that we use
> to build our simulations. Actually defining a common ontology amounts
> to identifying those common points ! What else could it be ?
Maybe you will only get many regional ontologies.
> I'm sure that this process might actually have a relevant feedback on
> theory building so being far more than a "technical exercise".
But maybe you get tools that work for many regional ontologies.
> Here I'm afraid I don't understand any more. Could you tell me more
> about that? How can you possibly study a phaenomenon, by the use
> of simulation, without actually running something?
Maybe a simulation implies that you run it. But ontologies don't
necessarely imply that you use them for simulations. In my environment
there are for example people working on decision support, where there
are different tasks than running a simulation. What I am not yet sure
about is, how simulations could be used in social science. On (Gilbert
and Troitzsch 99) slide among the tasks for social simulation were
"discovery" and "formulation".
Best Regards
(Menzies 95) http://www.cse.unsw.edu.au/~timm/pub/docs/kltut.zip
(Gilbert and Troitzsch 99) http://www.uni-koblenz.de/~kgt/Learn/Textbook/node4.html
--
Jan Burse
Umweltphysik, EAWAG
8600 Dübendorf
tel: +41-1-823 55 34
E-mail: [log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
