Empty RefBy Fields

[samm82]

Split from #947. Theoretical Models, General Definitions, Data Definitions, and Instance Models have a RefBy field that is sometimes empty when it should be filled with "--" to indicate the lack of information is intentional.

TODO

• Chipmunk
  • All TMs
  • Some DDs
  • All IMs
• GlassBR
  • Calculation of Demand IM
  • Most, if not all, DDs - not empty, but missing FRs
• NoPCM
  • Newton's law of cooling GD
• SSP
  • Effective normal force GD
  • "Sums of the interslice normal forces" and "Sums of the interslice normal water forces" DDs
• SWHS (same as NoPCM - probably one change will fix both)
  • Newton's law of cooling GD
• Display "--" if RefBy field empty (once its emptiness is enforced)

[samm82]

The GlassBR IM, as well as most- if-not-all of the DDs are referenced by a functional requirement, but aren't being flagged as such. The RefBy field is generated from the ChunkDB for each example, and the functional requirements are included in the ConceptInstanceMap for GlassBR, so it seems that the FR show up in the RefBy section, but for some reason it isn't.

[Mornix]

Took a quick look at this. It’s because the lists in the requirements of GlassBR are sort of “hacked”. The lists are just Contents and not a part of the ConceptInstance as would be expected.

[samm82]

@smiths @JacquesCarette Can I make a new issue to modify FReqsSub to take a [ConceptInstance] instead of [Contents] as in #1333, #1229, etc? This will be work in a similar vein as this FIXME:

Drasil/code/drasil-docLang/Drasil/DocumentLanguage.hs

Lines 203 to 206 in ce28891

	data ReqsSub where
	FReqsSub :: [Contents] -> ReqsSub --FIXME: Should be ReqChunks?
	NonFReqsSub :: [ConceptChunk] -> [ConceptChunk] -> Sentence -> Sentence -> ReqsSub --FIXME: Remove this in favour of NonFReqsSub' when all examples have migrated over to using NonFReqsSub'
	NonFReqsSub' :: [ConceptChunk] -> [ConceptInstance] -> Sentence -> Sentence -> ReqsSub

This change will also improve consistency in the code, and will probably resolve this issue as well.

[smiths]

I'm sorry @samm82, I don't have an opinion on this. We'll have to wait for @JacquesCarette.

[samm82]

No worries @smiths - after looking around, it looks like this would be a subset of #1023, which I would be happy to work on with the blessing of @JacquesCarette and @Mornix.

[Mornix]

So there’s really a few layers to this issue.
The root of the current issue is #1001. The lists (and tables) of the table in the GlassBR requirements are more hardcoded and not /truly/ associated with the ConceptInstance.
This leads me to think ConceptInstance storing data as solely a Sentence is a little limiting. It seems like this is a situation where something like and “associated data” field is needed that can encode the idea of ordered and unordered lists (conceptually). These lists could be rendered as Contents as something such as a textual list, an enumerated list, or a table.

What #1023 is suggesting is still a good idea and should be done, but, currently this “breaks” some automated traceability “stuff” due to information not being available when we need it.
Enter #1164 which aims to, in part, tackle #1023.

TL;DR: As far as I can tell, #1023 doesn’t address this issue, rather #1001.

[JacquesCarette]

Rabbit hole! I'll return to this later, I need to finish this first pass on all the commits first.

[samm82]

There are a lot of derivations that are present in caseStudies missing in GamePhysics (DDs and IMs) that reference the TMs, so those RefBy fields would be filled in with the addition of the derivations, which shouldn't be in this issue.

[samm82]

There's actually a lot of missing information in GamePhysics, and I seem to recall that it is being redone, so I'll leave GamePhysics alone for now so that everything can be done together.