Context Conduction in cyclic RIM graphs

Introduction

All the context conduction rules we have presently defined assume that they apply within the context of a DAG (directed acyclic graph). However there's no implicit rule that all uses of the RIM must be in a DAG, and indeed, there are several rational uses this. And RIMBAA already have this as a possibility.

The RIM ITS will allow serialisation of a cyclic RIM graph.And this raises the question, what does it mean if a class appears in two different places in a RIM graph where the conducted context is different?

Analysis

• resolution to be documented here..

Discussion

Keith says: This can be defined, the key question is whether context is accumulated via all references, or only through the appearance by value of the RIM class. Interestingly enough, the same RIM class appearing in a document or message using the XML ITS in two different places with the same identifier is the same instance, and so inherits context from both placements. It’s simply a matter of whether the context is navigable at both locations at the same time, which is usually not the case (implementation defined). I would apply this rule: that a reference or value representation of a RIM class inherits context at its point of placement, and that context SHALL be navigable from that location, but need not be navigable across all locations.

• Grahame says: Actually, it's no different to the two classes with the same identifier, where the two classes appear in different documents. So this is something that already happens, but I'm not aware of any ruling on the matter.

Ewout: I have the feeling that context-conduction is defined in terms of "child" ("descendent") and "parent" Acts in the RIM specification and even more so in Charly Bishops document. Charly even calls context-conduction a wire-format optimization technique. Since Charlies document seems to be well read and supported on the M&M wiki it looks like this view is generally accepted. This means the definition is bound to the directed acyclic graphs of the serialized form, so its semantics should be resolved and "denormalized" before storing it in an "object net" health-record. I still see a bit of room for optimization here too: most data in our EHR are still hierarchical in nature, so there is a sense of context propagating from above. Most links which would make it non-directed or possibly cyclic are associations of the "replaces" or "reason" type of links. These links feel like "crosslinks" between hierarchical blocks of data. If you'd interpret your EHR data this way, there is still a way to interpret context conduction.

Rene: The big question is:

• is conduction limited to a snapshot of a particular sutuation (a snapshot of an object tree), in which case 'denormalization upon import in a RIMBAA application' (see Context Conduction in RIMBAA Applications) is a valid implementation, OR
• is context conduction a long-lived semantic thing, i.e. if one specifies that all participations conduct from Act1 to Act2, does that also mean all participations that are added to Act1 (even if the object tree in question doesn't use nor mention Act2 at all) at any any future points in time? In the latter case the denormalization-upon-receipt method won't work, and cyclic references will become a real challenge.

Dan Russler: The original context-conduction attributes simply simplified the models and the wire format. The information relationships were only designed to be correct for the single object instance modeled and communicated, not all future instances of the objects in which changed attributes values and associations might exist. Therefore, if persisting the object instances, the receiving system must implement methods for instantiating and updating the object instances that are persisted that keep the evolving set of information relationships correct at all times.

Peter: I suppose I always just assumed it is a snapshot of a particular situation.

Rene: If I have persisted Act1 and Act2, and I have persisted the fact that 'all participations' conduct accross the act relationship between them .. "Does that mean that all partciptaions that are added to Act1 (at some future point in time) are also conducted to Act2" ?

• It is difficult to oversee the repercussions of it. Even if a CIM is taken from the RIM, an implementer who creates a CIM-based object graph, if they use conduction, will probably do so in the limited context of the CIM. They won't consider the wider impact - their scope is the CIM.
• That, to me, would be the main reason to continue to view 'context conduction' as an optimization of serialized object graph, i.e. to reduce the size of the on-the-wire format - and for the human reader: to make the CIM more readable.
• To anser the question phrased above with yes implies opening up a whole can of worms - and a requirement to create lots new methodology.