Provide a more user-friendly format for traces (follow up from #658)

[feret]

It would be better to use a format closer to simple operational semantics.
Action should correspond to self-content atomic transformation of graphs + side-effects.
(In particular, it requires an action for each bond that is removed explicitly in the rule, even if it occurs in an agent that is degraded).

In case of id conflict, doing

bond removal
agent degradation
agent creation (with all site implicitly free and internal state to the first value)
binding and internal state modification.
Seems to be the most appropriate to me and is consistent with the description of the operational semantics in the literature.
The main advantage, is that each action can be interpreted independently (the result of each action is a valid state).

[hmedina]

Since this is talking about changing the format, I'll post this related discussion from some years ago: #599

[feret]

#599 is quite an orthogonal issue.
@jonathan-laurent concerns is about the semantic content of the trace, whereas @hmedina ones is about its disk occupation.
Note that a trace storing just the rule id and the embeddings is likely to be even more compact (independently of any on the fly compression treatment).

[hmedina]

For a rule like: A(), B(s{one/two}) @ 0.0 {1.0}, the embedding would store a way of identifying both agents?

That sounds like it would remove the need to use the idiom I'm using (i.e. active_site, explicit bond, and infinite rate usage here). That would streamline work similar to mine, because the "publication model" does not use that idiom, but the model fit for trace analysis does.

[feret]

Yes, it is just the primal way a rule application arises in the simulation.
It has three advantages:

• it is compact
• it contains all the information
• this information can be translated into what is needed by a given tool.

I am quite surprise that you cannot get the id of CK() in the tests of the event.
This is indeed used for causal analysis, thus unless it is completely buggy, the information has to be somewhere.
(I use the Is_here predicate in causal analysis to test for the existence of an agent with a given id.).

[jonathan-laurent]

@hmedina Jérôme is correct that the trace indicates the identity of all agents that are modified or tested by any rule application and an agent being mentioned in a rule means at the very least that a presence test happening.

However, it is true that KaTie currently cannot match an event pattern such as A(), B(s{one/two}). As mentioned in the documentation, event patterns must be rooted in the sense that every mentioned agent is either modified or connected to a modified agent via a sequence of bonds. At the time, this decision was motivated by:

1. Implementation simplicity.
2. My (wrong) impression that such action at distance was a modelling antipattern.
3. The fact that two legitimate semantics can be proposed for matching A(), B(s{one/two}), possibly creating a source of confusion among users. Indeed, for every event modifying B, one could generate a single matching capturing the identity of the A agent that happened to be picked by the simulator when instantiating the underlying rule. Which agent A got picked is kinda arbitrary though and some users might expect as many matchings to be produced as there are A agents in the state before the event.

Thinking about it, I think the first semantics really is more useful and consistent and so I think there is a strong case to be made for allowing agent identity to be determined by tests in KaTie (and presence tests in particular). Any thoughts?

[feret]

@jonathan-laurent I do not get your point about the ambiguity of the semantics. .

The activity of your rule is k * |A()| * |B(s{one/two})|.
If you expect another one (as in presence of A, B can do this, but independently on the quantity of A()), you should use functional rates.

Could you clarify which semantics (trace distribution, trace replaying interpretation) are you referring two ? and what are the two propositions ?

[jonathan-laurent]

@feret My point was purely about KaTie's trace pattern semantics so this was probably not the right place for this conversation anyway. I do understand that A(), B(s{one/two}) is a valid Kappa rule.