cycling problem in bi directional associations
Arda Goknil
I have a problem in assigning bidirectional associations in two rules. I have two rules that transform two model elements which have a bi-directional association.
RULE SemanticWebAgent2Agent(excplan, intfc, prc, grd, matchmaker, smtagnt, planJ, interfaceJ, un, c9, c10, c11, c12)
EXTENDS ExecutionPlan2ExecutionJPlan(excplan, intfc, prc, grd, smtagnt, matchmaker, planJ, interfaceJ, un, c9, c10, c11, c12)
FORALL Agent smtagnt
WHERE SemanticAgentPartOfPattern(smtagnt)
MAKE Class smtclass
SET smtclass.name = smtagnt.type,
smtclass.associatedClass=planJ
LINKING SmtAgnt2ClassJ WITH semanticagent = smtagnt, clsJ = smtclass
;
This rule extends ExecutionPlan2ExecutionJPlan to assign the planJ to the associatedClass reference of smtclass ( smtclass.associatedClass=planJ).
RULE ExecutionPlan2ExecutionJPlan(excplan, intfc, prc, grd, webagent, matchmaker, planJ, interfaceJ, un, c9, c10, c11, c12)
EXTENDS RootFolder(un, c9, c10, c11, c12)
FORALL Plan excplan, Interface intfc, Process prc, Grounding grd
WHERE ExecutorPlanPartOfPattern(excplan, intfc, prc, grd, webagent, matchmaker)
AND SmtAgnt2ClassJ LINKS semanticagent = webagent, clsJ = smtclsJ
MAKE Class planJ, Class discoverJ, Class enactJ, Class engageJ, Class interfaceJ,
Class processJ, Class groundingJ
SET planJ.name= join("_",excplan.name,excplan.type), planJ.associatedClass=interfaceJ,
planJ.associatedClass=processJ , planJ.associatedClass=groundingJ, planJ.hasClass=discoverJ,
planJ.hasClass=enactJ, planJ.hasClass=engageJ,
discoverJ.name=join("_",excplan.name,"DiscoverCandidateServiceFor"), discoverJ.aggregateClass=planJ,
enactJ.name=join("_",excplan.name,"EnactServiceFor"), enactJ.aggregateClass=planJ,
engageJ.name=join("_", excplan.name,"EngageWithAService"), engageJ.aggregateClass=planJ,
interfaceJ.name=intfc.name, processJ.name=prc.name, groundingJ.name=grd.name,
planJ.superClass=c9 , discoverJ.superClass=c10, enactJ.superClass=c11, engageJ.superClass=c12,
enactJ.associatedClass=smtclass
ExecutionPlan2ExecutionJPlan rule uses a tracking class named SmtAgnt2ClassJ (enactJ.associatedClass=smtclass ) to assign the association which is the inverse of the association (smtclass.associatedClass=planJ). This causes a cyclic calls and terminates the two rules. I think there is a deadlock. Is there thing to solve this?
Jim Steel
I don't think the fact that you're using bidirectional associations is
the problem. The problem seems to be more that the
SemanticWebAgent2Agent both creates and looks up SmtAgnt2ClassJ
trackings. This poses problems to do with stratification of rules -
Tefkat has to run any rules that might create a certain tracking
before it can run rules which look them up. This is more Michael's
bag, so perhaps he'll comment on that.
Its also a bit hard to follow with such a complex rule. Its tempting
to say that restructuring your transformation to have rules with fewer
parameters, and perhaps making less use of EXTENDS, would probably
solve a whole lot of your problems. Of course, without knowing the
problem, I can't really say that with any confidence - it may be that
the problem is just inherently complex.
Jim.
michael lawley
The thing that leaps out at me is the MAKE line in
ExecutionPlan2ExecutionJPlan - there are no explicit FROM clauses.
So, for the cross-product of all instances of Plan, Interface,
Process, and Grounding (filtered somewhat by the WHERE conditions) you
will be creating 7 different Class instances. Ignoring the WHERE
clause, and assuming there are p Plan instances, i Interface
instances, r Process instances, and g Grounding instances, then you
will be creating (amongst other things) i*r*g Class instances with
name = join("_",excplan.name,excplan.type), which seems a unlikely
thing to want to do.
Looking at the issue of the cyclic dependency with the tracking class,
we can see that ExecutionPlan2ExecutionJPlan will not do anything
unless at least one instance of SmtAgnt2ClassJ exists, and since
SemanticWebAgent2Agent extends this rule, it also cannot do anything
unless at least one instance of SmtAgnt2ClassJ exists. So, unless you
have some other rule that creates a SmtAgnt2ClassJ tracking instance
then neither of these two rules will do anything.
Note that there's no stratification problem here since there's no
negation involved. It's merely a chicken and egg problem:
SemanticWebAgent2Agent can't create a tracking instance because it
depends on ExecutionPlan2ExecutionJPlan which can't match anything
because it requires a tracking instance.
Regards,
michael