Data definitions, instance models, etc. with multiple equations

[bmaclach]

The following is an example instance model with multiple equations in the manual version of SSP:

SSP also has data definitions defined with multiple equations.

Currently we hack this instance model's equation in Drasil by connecting each equation with "=", like so:

This is clearly incorrect.

We need to find a better way to handle these situations in Drasil. Some options:

• Inline equations into others (i.e. Equations for C_num and C_den inlined in the equation for lambda)
• Create separate Data Definitions for each equation
• Add support for multi-equation definitions in Drasil.

[JacquesCarette]

The best way forward is the third option, multi-equation definitions, at least for instance models. I think inlining is not really a solution. In the short term, creating separate DDs would be better than this hack.

[smiths]

I agree with @JacquesCarette. The short-term fix can be adding separate DDs. This is consistent with how we solved other problems. Capturing small increments of knowledge is also consistent with our overall "philosophy". In the future we will want to provide a presentation (documentation) mechanism that combines the small definitions into something more suitable for human consumption.

[muhammadaliog3]

Question 1: Options for multiequations:

• Break the relations into two components: one is the final/true/defining equation, the others are the sub/intermediate relations.
• Store all relations as list, problem: In order to be an instance of the ExprRelat class you must have a singular equation, hence we should probably refer use the first option.

At what level should we store these multi-relations?
Options:

• Do we want store singular relationconcepts that have multi equations
• do we want to store multi-relation-concepts,
• do we want both.

I can express the above 3 option in more "codelike" terms

• In RelationConcept change the field _rel from type Relation to [Relation]
• change the field _rc from type RelationConcept to type [RelationConcept] a IM/TM/GD/DD

I will be working on a branch with option 2 for question 1 and option 3 for question 2.

[JacquesCarette]

ExprRelat is bad and should be eliminated. Multi-equations should be stored as a list of QDefinitions. So we first need to fix things so that we can have different 'kinds' of definitions (direction, multi, differential, etc). We do not want to have any of these as 'relations'. We will still needs relations in Drasil, but the vast majority of the ones we have now, should not be. That is the underlying problem that first needs fixed.

[muhammadaliog3]

When we eventually reach a place where we can begin solving this issue change from singular quantities to multiquantities then we will face problems from class instances.

what is the term, space, symbol, idea, named idea, and defining expr when we have MULTIPLE QDefinitions? They are well defined for singular defintions but how about for multiple definitions.

I will change definingexpr from Expr to [Expr]

For DataDefinitions:
In data definitions I will have the last equation as the "real" representative, from which we derive all the terms, spaces, etc. and all other equations as intermediates used for display purposes.

Genral Definition: Same as data definitions.

TM: Nothing, TM does not have any of its class instances based on equations.

IM: Same as Data Definition.

[JacquesCarette]

You have an 'inverted' design in mind. I see this new data-structure living at the "model" level only, so that there would in fact be no term / space / symbol / idea / etc instances. The insides of that structure would, but not the structure itself.

No, don't change definingexpr from Expr to [Expr]. That is the wrong design!

[balacij]

This is another interesting ticket. I think the discussion of "multi-equations" relate to what I was briefly discussing as an issue in #2587 (comment) -- I think this would be the "StackedModel" I discussed (definitely needs a better name, and MultiEquational sounds better from this discussion).

[balacij]

At surface-level, this seems related to #3335, #1154, and #787.