5 Replies Latest reply: Apr 18, 2014 2:08 PM by Matt Sevin RSS

    Question about inferred entity creation


      Hey guys I have a question to see if anyone else has seen this behavior with inferred entity creation.


      I have a colleague who found a way to create entities with a rule loop. It requires two different relationships the first to create the initial entity and the second to create the rest of the entities based upon the first with a rule loop.


      This way of creating entity's though seems to have the effect of not allowing implicit scoping and also making it so that the containment relationship goes to unknown. I am thinking this is because the relationship made to create the entity is not the containment relationship for some of them.


      Wondering if anyone else has run into this? If they have found a way around this, I am thinking I could just define the containment relationship though I haven't tried that yet since i haven't had time to try it. 

        • 1. Re: Question about inferred entity creation

          Why was a rule loop used to create interred entities.

          Inferred entities behave different from 'normal' entities.

          • 2. Re: Question about inferred entity creation

            Well the reason we were considering using a rule loop was because we had a number of entity instances that needed to be created depending on how many entity instances we had of other entities.  Like say for instance we have entity A, B, C where C is a sub entity of B and we need to create as many instances of C as there are of A.  We never really know how many instances of A there will be until we run the rulebase, we can and did end up using the rules table version to create the entity.  I just don't really like the fact that there wasn't another way to create dynamic entities based upon certain conditions one of them being the amount of instances in another entity and I was wondering if anyone found a way to do it.


            Edit: I would rather prove these things based upon 3 or 4 different rules rather than a gigantic 50 row table.

            • 3. Re: Question about inferred entity creation
              Matt Sevin

              You should not need a rule loop to create entities in your scenario.  True, you would need to if you were only working with "the number of A's that exist", but when you have the actual entities you can use a standard rule.  For example, assume A has an attribute "the A's name"  which is unique identifier.  If you want a new entity "the C" you can use a rule similar to the following:


              the C (the A's name) is a member of all instances of the Cs


              The part in parens specifies the value to be used as the unique identifier for each instance of C to be created.  "all instances of the Cs" is assumed to be the phrase for the containing relationship from global to the C. The "is a member of" phrase is used to determine that an instance of "the C" must exist for each unique value of "the A's name" and that instance participates in the referenced relationship.


              Note that the rule will evaluate for all instances of A, but this isn't really a "loop" in that there is no defined order required for checking instances of A and determining whether another instance of "the C" is required.  Also note that this approach works for creating a smaller number of entities based on any attribute.  (e.g.  I want an instance of "the pet type" for each unique instance of "the person's pet type" in which many people may specify "dog", "cat" etc., but I only want one instance of dog, cat, goldfish, etc.


              See some of the examples in the documentation such as creating instances of "the tax year" based the year from another entity, etc.

              • 4. Re: Question about inferred entity creation

                I may not be completely understanding you but what you showed was the first thing we tried and this is what we found out.  That since C is a sub entity of B and A is right underneath global we need to scope to the A entity and then if we use any kind of scoping mechanism at least as far as I was able to see we need to decide which instance of A entity we are looking for.  Take for example what you said :


                     the C (the A's name) is a member of all instances of the Cs

                the only way to so do that correctly would be to do something like

                     the C (InstanceValueIf((all instances of A, the A's name, condition to evaluate)) is a member of all instances of the Cs

                In a quick example I just put true for the instanceValueIf condition so it would get all of Entity A but that makes it ambiguous so it makes it go to uncertain.  I made a mock up of what happens and I can confirm that if there is more than one instance of the entity A value goes uncertain and no C entity's are created.  Since I don't know what the values are before the rulebase is ran I cannot really put a condition on there unless I do something crazy like a rule loop.  And here is the rule I used to infer the C entity:

                the C Entity for the B Entity(InstanceValueIf(all instances of the A Entity,the A entity’s id,true)) exists

                Also here is a quick visual of data model


                          |_Entity A

                          |_Entity B

                               |_Entity C

                • 5. Re: Question about inferred entity creation
                  Matt Sevin

                  I am assuming when you say C is "subentity" of B that you mean there is a containing relationship from B to C (perhaps with a phrase such as "the B's instances of Cs" or "the person's children").  If that is the case, you must provide a specific scope within the rule for which B entities should have an instance of C exist and be a member of the containing relationship.  To illustrate I am changing the example to the following:



                    Global -> the person ("all instances of the persons")

                    Global -> the tax years ("all instances of the tax years")  (an entity to represent the concept of a year (not just a value, but something that can have attributes such as "the tax year's start date", etc. )

                    the person -> the tax return ("the person's tax return")   (to be inferred an inferred entity)


                  The only way to determine inferred instances of the tax return in the above scenario is to create a unique identifier for each COMBINATION of an instance of a person and an instance of "the tax year" in order to have unique identifiers across all instances of "the tax return". You must have a unique identifier for each instance of the tax return (thus neither the person nor the tax year's identifier can be used in isolation).


                  In addition the rule should follow the pattern:   the tax return (<generated id>) is a member of the person's tax returns if ... <conditions as necessary to determine which persons this should be true for and any other applicable conditions> (e.g. "the person is a member of all instances of the persons" - would be true for all persons).


                  Note how the example infers the existence and membership in the containment relationship.