Guidance/examples of how you envision assurance case construction code interfacing to RACK?

[ANogin]

Do you have any RACK best practices guides and/or examples (e.g., "hello world") explaining your vision for how the assurance case construction code would use RACK programmatically?

Some specific questions on how you intend RACK to be used by the assurance case construction code (we asked the 2ii one in early Feb, but wanted to check whether the answer is still the same):

1. We are currently using semtk-python3 to interface with RACK from Python code - just to confirm, is that still the recommended way for the assurance case construction code to "talk" to RACK?

2. How do we access the data model programmatically (rather than just “exploring the model” interactively in a browser)?

   1. Short-term need: how do we access field names in data returned in response to predefined queries? Following the example from https://github.com/ge-semtk/semtk-python3/blob/master/semtk3/demo.py, and along the lines of https://github.com/ge-semtk/semtk-python3/blob/master/semtk3/demo.py#L88 we are using numerical column sequence numbers to look up information from the specific columns. This is unpleasant and error-prone – we would much rather use names rather than numbers, but lacking an example of how one is supposed to go about it.
   2. Right now we are exploring the ontology manually, and then hardcoding the specific ways to query specific RACK data in a configuration file. The more we do it, the more unsatisfactory it seems - eventually we want at least some semi-automatic way of creating that configuration. (Use case: at an assurance planning stage, a user is creating a new assurance case fragment template interactively in our tool, and the tool queries RACK ontology and helps the user to [semi-]automatically create the mapping between the concepts (and dependencies!) in the template to RACK data model - perhaps even creating custom "predefined" queries that capture the intended relationship between the template and the RACK data model.) Do you provide/plan to provide an API for this?

3. [Somewhat minor, but would help us clarify our understanding of the intended use mode] When data is re-uploaded to RACK (either because we make small changes to it for testing, or just creating a new instance for testing), the order of items returned by nodegroup queries changes. This means that things get reordered in our assurance case, which makes it a bit unpleasant for debugging (harder to see the meaningful changes). While it trivial for us to sort the data on our end (and we do it), it would seem that the right way to do it would be to ask RACK to return things ordered by a particular key. Is there a way to do it (from semtk-python3, or whatever the answer is to the first question)?

Note that realistically what we actually need for questions 2i and 3 is a way to build on top of existing predefined queries and then ask RACK to augment them with a request for specific fields, request further sorting, filtering, joins, etc. Note that these are not hypothetical - these are all the things we already ended doing in an ad-hoc way on our end (To get to things like: given a test T and a requirement R, give me all sub-requirements S of R that T tests for; given a requirements of R, give me all tests procedures P that are used for any test T that tests for any sub-requirement S of R; then for each of those Ps also give me the list of the relevant Ts. And these are just for one particular fragment template we are experimenting with). Each one ad-hoc thing seemed like not a big deal to add, but by now we almost ended up treating RACK as just a source of raw data, and implementing our own way of doing all kinds of ad-hoc queries on top of it (in a way that's nearly impossible to debug :( ). Now we are realizing that this path is kind of insane and definitely not sustainable...

[Edited to add] P.S. For the examples in the previous paragraph, the point is that we want the user to at most just separately map "S is a sub-requirement of R", "T tests for S", etc constraints to RACK ontology, and the resulting "joined" queries should then be created automatically by the software.

[cuddihyge]

I can help with a few of these I hope:

1. Yes. semtk-python3 is a great way to go
2. i - the return from a query in python is a SemtkTable. You'll see in semtktable.py functions like get_column_names(),
   get_column_index(col_name) These should help you navigate the returns.
   2.ii - this mapping process sounds complex enough I'd hesitate to start tossing out ideas before we do a working session. I think we can help with this process with functionality that we already have or could build for you. I'd be happy to learn more.
3. The nodegroups have an ORDER BY function. Look for the "Order" button SPARQLgraph then re-save the nodegroup to the store. If you're using nodegroups generated by TA2 (and not your own) then please let us know. We may be able to strictly order returns in the "stock nodegroups" This is a bit of a performance hit, so we won't be offended if you use:

import pandas as pd
table = semtk3.select_by_id("MyNodegroup")
df = pd.DataFrame(table.get_pandas_data())

... and go to town on the tabular data in pandas. Most pythonic folks like pandas.

I hope this get's you started. It looks like there are a conversation or two we can follow up with. @kityansiu normally coordinates these if needed.

[ANogin]

@cuddihyge, Thanks! For the ORDER BY function, how do we make that change programmatically from our semtk-python3 code, rather than by hand?

[cuddihyge]

There isn't currently a way to change the ORDER BY on the fly from python.
So right now it needs to be edited in the nodegroup and saved in the nodegroup store.
It would be a straight-forward feature to add to an upcoming release.

[ANogin]

@cuddihyge, I would imagine if the plan would be to add more features, then perhaps the discussion about the overall approach to TA3 auto-creating custom queries on top of existing one might be in order first (as I described, "ORDER BY" is just the most trivial example of the kinds of things that we'd want to do on top of predefined queries).

[cuddihyge]

Moving from Email. Alesky writes:
To follow up on my previous question (#400), If I understand correctly, one of the things that RACK provides is a nice structured json representation for sparql queries. It there a way to programmatically:

1. [Optional] Query RACK for JSON representation of a nodegroup (optional because we can always fall back on grabbing from RACK source code or some such)
2. Use a python library to manipulate the queries (e.g. joining two queries, adding a filter, adding a sort, etc)?
3. Upload the new json query back to RACK (as a brand new nodegroup, perhaps?)
4. Run the new query as needed

[ANogin]

@cuddihyge , that was not email - that was a separate Q&A entry I added :) (#415).

[cuddihyge]

1. semtk3.get_nodegroup_by_id() will in-fact return the JSON. We highly discourage manually editing it though.
2. Mixed answers. We should discuss implementing these for the next release:
   join - not available. unlikely feature for various reasons. better to reformulate the nodegroup in SPARQLgraph or run each separately and use pandas or semtkTable functions to combine.
   adding a filter - yes. available now if "runtime constrained" box is checked when the nodegroup is created.
   sort - not available yet in python but straight-forward to implement
3. store_nodegroup() is already available, but not of much use until we expose nodegroup-editing functions
4. select_by_id() of course is already available

I'll summarize/reiterate that we should walk back through all these comments and decide the best approach to adding things for the next release. We hadn't intended on programmatic nodegroup editing in python, but thought that would be done in the GUI. If we truly understand the use-case we can come up with the right feature set.

[cuddihyge]

@ANogin sorry about the #400 / #415 confusion. I think one thread will be easier to review but we may already be stuck with two.