Simplified SACM-based overlay, improving ease of use.

[carter-e-veldhuizen]

No description provided.

[glguy]

Hi @carter-e-veldhuizen ,

I haven't gone through this in detail yet or compared it to the current data using the old version of the ontology overlay. Is this intended to be a subset of what you were using before or is it a simplified model that you're going to generate a fresh dataset against?

[carter-e-veldhuizen]

It is a simplified model that will work with freshly-generated data.

[glguy]

We've been trying to put note elements on the various elements of SADL files to help people know what to make of them and how to use them.

For many of the things you've defined here, the note is unlikely to be complicated, but it's nice when it's a bit more human readable than just the SnakeCased name.

[glguy]

(Not a blocker but I'm curious)

Is it important that Notes have their own identity. Are notes going to be the target of other notes? Are they collected separately from the thing they annotate.

For example I could also imagine:

note describes SacmElement with values of type string.

as a simpler, but perhaps insufficiently powerful representation.

[glguy]

Overall this doesn't attempt to integrate into the rest of the ontology. It's would be interesting to know why it can't. ScamElement adds nothing over ENTITY, so as part of the simplification we could easily eliminate it and use ENTITY wherever ScamElement is found. SubPackage appears to be a COLLECTION. It's subtypes define custom containment relations that could easily be specializations of the content relation. Working toward between integration will allow sacm assurance case fragments to actually refer to other evidence contained in rack and will simplify the overlay itself.

[carter-e-veldhuizen]

Overall this doesn't attempt to integrate into the rest of the ontology. It's would be interesting to know why it can't. ScamElement adds nothing over ENTITY, so as part of the simplification we could easily eliminate it and use ENTITY wherever ScamElement is found. SubPackage appears to be a COLLECTION. It's subtypes define custom containment relations that could easily be specializations of the content relation. Working toward between integration will allow sacm assurance case fragments to actually refer to other evidence contained in rack and will simplify the overlay itself.

My apologies, I should have made the objective of these changes more concrete with a clear description for the PR.

The goal, here, was not to make an AC storage ontology for the RACK. I think you're right that there are ways such a schema could cleverly integrate with existing RACK concepts, expanding and integrating with them usefully. But I don't know whether that's something the GE team even wants, and it's not what I was trying to build.

Our team uses an data model based off of SACM and this overlay allows us to transmit that content largely-as-is. As before, those kinds of data are not intended to replace the use of core RACK features or the claims overlay, or to evade the need to provide evidence in the form the RACK actually expects.