On descriptions of Instance Models

[JacquesCarette]

@smiths @szymczdm

So I've encountered the following, in both GlassBR and Chipmunk:

• a variable, such as demand defined as

  demand = unitary "demand" (nounPhraseSP "applied load (demand)") lQ kilopascal Rational

and then an associated RelationalConcept

calOfDe :: RelationConcept
calOfDe = makeRC "calOfDe" (nounPhraseSP "Calculation of Demand(q)")
  dedescr $ (sy demand) $= apply2 demand eqTNTWeight standOffDist

So these are associated to each other, as we see that the equation for calOfDe defines demand. But the phrase associated to one is "applied load (demand)" and the other is "Calculation of Demand(q)". The same is true for all 3 instance models in GlassBR (the first is the source of the difference between "probability of breakage" vs "probability of glass breakage"). But, to me, I don't see these as so different that their very definition should use different words. And it gets 'worse' in Chipmunk.

Note how the definition of demand uses the symbol q but doesn't use it in the noun phrase, whereas the calculation does! This is typical of the wide variation encountered between the definition of the 'unitary quantity' and its associated computation as a quantity which is derived via an equation.

It seems that, de facto, our templates make a huge difference between a quantity and its "mathematical" definition. I did not know this until now. Did you?

[JacquesCarette]

I'm assigning this to @smiths right now because this is really about the way we encode the scientific knowledge of the underlying application. I suspect that once we figure out what to do here, there will be 'implementation' issues that will come out of the discussion, and those will be assigned to someone else.

[smiths]

Great observations @JacquesCarette. This is definitely something to think about. For the example given, we could think about combining everything into one "chunk". For GlassBR, using the cited ASM standard, I don't think we need to define a variable demand separate from a concept (RelationalConcept) for calculating demand. However, the separation of concerns does serve a purpose. The definition will be stable across standards, but the calculation is something that can change. q as a concept is separate from how q is calculated, and how it is calculated can change. For instance, in the current model, q depends on wTNT (equivalent weight in TNT) and the standoff distance. What if the model changes so that q depends on the equivalent charge weight of C4? The definition of q should be stable across all versions, but we could allow the calculation of q to change from one version of the SRS to another, to reflect different standards. I don't think we would replace the current equation, since we might still want to maintain a document based on the old standard.

I think the confusion comes because we want a variable to have a defining equation that is always associated with that variable. However, that won't always be the case. Sometime there is no obvious equation, and in other cases there is an obvious equation, but it might not be the one that is used in the model, since it cannot be calculated directly.

If we think about temperature, there is no defining equation for temperature that is always true. (Maybe there is an equation that relates the vibration of the molecules to the temperature?) The specific equation to solve for temperature comes from the problem at hand. Sometime the temperature might be an input that is used to calculate something else, and sometimes something else is used to calculate temperature. We might use conservation of energy, or we might use the constitutive equation (thermal conductivity), or we might combine both of these, together with the given boundary conditions in temperature and temperature gradients.

A quantity like stress has an obvious definition. Stress IS force divided by area. (There are some differences depending on whether it is the area relative to the undeformed, deformed or some other reference state, but regardless stress does have an equation attached to the quantity.) However, in many problems stress isn't calculated using this equation. We need another equation (or set of equations) to calculate the stress.

Having a definition, possibly with an equation, and an instance model with a different equation for calculating the variable is going to come up frequently.

Maybe this isn't what you were getting at in the original issue? Maybe your concern is more about the phrase associated with the variable versus the phrase associated with the RelationalConcept? If we have two separate chunks, shouldn't we have different phrases? The purpose of one is to define q, and the purpose of the other is to calculate q. I think the problem may come down to some lingering lack of clarity on the differences between data definitions and instance models. The instance model isn't actually q, but the calculation of q. If we listed the inputs and outputs separately, as we discussed, then I think this would be more clear. The instance model isn't q, but the output of the instance model is q.

(I've never noticed before, but the GlassBR example has wTNT with units of mass (kg), even though it is called a weight, which would have units of force. I believe this inconsistency traces to the original documentation.)

[smiths]

Maybe it will help if we look at some existing scientific knowledge ontologies. They must have come up with similar problems about the distinction between concepts, equations, relations etc. Maybe there is some insight to be gained?

[JacquesCarette]

Writing it out (and it should have been about RelationConcept vs Unitary, not InstanceModel per se, as that's only the context in which it arose) also led me to the exact same conclusion: the same quantity may well be computed in different ways. And so the description of the quantity may well be different than the description of the computation associated to it.

Upshot: it is my new code (now in a branch) which needs to be adjusted, and not the examples themselves. But with some additional insight into what kinds of knowledge is being captured.

Yes, I do think we need to look at existing scientific knowledge ontologies. There are quite a few, and surely we'd learn things. Similarly, there are document ontologies (like Dublin Core) with which we'd best be compatible.

[smiths]

I figured I was not quite using the terminology of Drasil correctly (RelationConcept versus Unitary etc). I still think in terms of the SRS template. I'm looking forward to @szymczdm's paper, since that should get the current hierarchy down in a form that I, and others, can digest. 😄

[JacquesCarette]

@smiths you might want to re-look into this. I think lots of things have changed, so that it feels like it is ripe to see where we stand.

[smiths]

@JacquesCarette, yes looking again makes sense, but I'm not sure what the original issue is referring to. It is certainly possible to separate the meaning of a symbol from the definition of how to calculate the associated quantity. I don't think this is a mistake. Different documents can use the same concept, but calculate it by different means.

What I notice now from looking at GlassBR is that we use the word load for the generic concept of load (for the theoretical model; we call it Load) and the refined notion of load specific to GlassBR (for the instance model/data definitions; we call it q). The idea is that the abstract notion of Load can be reused in other contexts (we might even already be using this notion in ssp; I'm not sure), but the refined notion of q is specific to GlassBR. We could maybe use better words to reflect this refinement?

[JacquesCarette]

I think I've seen this idea crop up elsewhere in the issues as well (of refinement from a generic to a more specific description). This looks like a nice high-level feature.