Updates to Testing ontology

[kquick]

See RACK_Ontology/Orienteering.md for a background and description of TESTING changes.

[russell-d-e]

We should add more ontology to allow the capture of higher and lower fidelity trace. For the boeing over lay this would mean there is a SBVT_TestProcedure -verifies-> {SRS_Req orSubDD} and IDD_Test -verifies->Signal. More generally this should be in the core ontology as TEST_PROCEDURE -verifies-> ENITITY, TEST_STEP -verifies-> ENTITY, and TEST -verifies-> ENTITIY. A similar structure is need for the log/results side

[russell-d-e]

We should add more ontology to allow the capture of higher and lower fidelity trace. For the boeing over lay this would mean there is a SBVT_TestProcedure -verifies-> {SRS_Req orSubDD} and IDD_Test -verifies->Signal. More generally this should be in the core ontology as TEST_PROCEDURE -verifies-> ENITITY, TEST_STEP -verifies-> ENTITY, and TEST -verifies-> ENTITIY. A similar structure is need for the log/results side

[kquick]

This PR does have a TEST--verifies-->ENTITY association at present, so that
concern is covered.

A TEST_STEP is really just the identification of a TEST, along with any
subsequent TEST_STEPs, so the TEST_STEP doesn't add any verification that isn't
already covered by the TEST it identifies and therefore shouldn't need a
"verifies" property.

The TEST_PROCEDURE has no additional context other than being a COLLECTION of
initial TEST_STEP entries, so the only additional verification claim it could
make would be relative to the aggregation of the TESTs. However, adding a
"verifies" property at the TEST_PROCEDURE level raises a concern of coherence: if
a TEST_PROCEDURE were to indicate that it verifies a high-level ENTITY but the
set of TEST entries underneath that TEST_PROCEDURE are not an exact correlation
to all of the sub-ENTITY elements of that ENTITY, which one is correct (the
TEST_PROCEDURE.verifies or the individual TEST.verifies)? This also affects
extensibility: if a TA1 determines that an additional test is needed to validate
the higher-level construct, then the TEST_PROCEDURE can no longer be said to
verify that construct. In this consideration, the intent is that in our ontology
the TEST object is the atomic unit of verification and that any implication that
higher-level elements are fully verified is a TA3 evaluation/conclusion that we
don't have enough information to supply or synthesize.

In general, the heirarchy of TEST_PROCEDURE::TEST_STEP::TEST is concerned with
describing the relationship of each TEST to any other TEST, rather than an
association of different testing importances, but there is no constraint on the
fidelity of a particular TEST, so it should be possible to define a TEST to
associate to any desired target ENTITY to capture the desired fidelity.

[kquick]

@tuxji any idea why this CI failed?

[tuxji]

@tuxji any idea why this CI failed?

I'm not certain if this is the cause, but I see the following two messages which probably indicate that shellcheck did not pass:

./assist/databin/ar:36:22: note: Double quote to prevent globbing and word splitting. [SC2086]
./assist/databin/ar:36:43: note: Double quote to prevent globbing and word splitting. [SC2086]

I noticed that the TESTING_updates_kwq branch is 5 commits ahead, 116 commits behind master. Your best bet is to rebase the TESTING_updates_kwq branch on master (there shouldn't be any conflicts), force push, and see if CI passes:

git switch TESTING_updates_kwq
git pull
git rebase origin/master
git push --force-with-lease

[kquick]

@tuxji OK, I was confused because this PR didn't touch any shell files but I think what happened is shellcheck got updated and master accomodated that after this branch, so I've merged with master and that fixed the linting problem, but now there's a docker image CI problem that I'm unsure about.

[tuxji]

but now there's a docker image CI problem that I'm unsure about

I reran the CI job and it got past that problem, so your change didn't cause that problem (probably a slow computer or network caused it). You can merge the PR anyway, @kquick

[kquick]

Thanks, @tuxji. That CI job is actually not completing and shows having run for 18h40m and counting, but I think we can chalk that up to gremlins rather than bugs.

This is ready for merging after discussion and approval in the data model decision team, @kityansiu .

[cuddihyge]

@kquick : the data model decision team will make a decision to merge after v12

[kquick]

Graphical representation of the new TESTING ontology included: https://github.com/ge-high-assurance/RACK/blob/TESTING_updates_kwq/RACK-Ontology/Graphs/TESTING_scoped.svg

[kquick]

Fully approved by DMDT.