ge-high-assurance / RACK

DARPA's Automated Rapid Certification of Software (ARCOS) project called Rapid Assurance Curation Kit (RACK)
BSD 3-Clause "New" or "Revised" License
20 stars 6 forks source link

RACK - ARP/DO/MIL standards not accessible / not loaded #484

Open Robert-Adelard opened 3 years ago

Robert-Adelard commented 3 years ago

The RACK includes ontologies for ARP-4754A, DO-178C, DO-330, and MIL-STD-181D - however, these don't seem to be loaded or are not accessible via SPARQLGraph.

In particular, ARP-4754A, DO-178C and DO-330 are defined in terms of SECTIONs and OBJECTIVEs - however, according to SPARQLGraph, the RACK contains no SECTIONs or OBJECTIVEs.

SELECT (COUNT(*) as ?count) 
FROM <http://rack001/data>
FROM <http://rack001/model>
{
    select distinct ?SECTION ?SECTION_type where {
    ?SECTION a DOCUMENT:SECTION .
    }
}

Similarly, MIL-STD-181D is defined as a SPECIFICATION with a number of SECTIONs, but there is no MIL-STD-181D specification in the RACK according to SPARQLGraph.

Robert-Adelard commented 3 years ago

A quick search of the triple store via the Fuseki interface reveals various PROCESS#satisfiedBy predicates relating to DO-178C, but no predicates relating to the other standards:

SELECT ?subject ?predicate ?object
FROM <http://rack001/data>
{
    ?subject ?predicate ?object
         FILTER regex(str(?subject), '178C') 
}
Robert-Adelard commented 3 years ago

I found the DO-178C triples in a graph called http://rack001/do-178c - I have no idea what happened to the standards.

Ptival commented 3 years ago

Is this actually an issue?

Or are you just missing data that is loaded in other data-graphs, such as http://rack001/do-178c, http://rack001/mil-std-881d, etc.

Robert-Adelard commented 3 years ago

I think there are two issues:

  1. Whether the various standards ontologies are loaded or not
  2. How to access them if they are loaded

With respect to (1), I found some commented-out code at the end of cli/setup-arcos.sh that indicated that these standards are not loaded by default, but I don't think it's reasonable to expect the user to discover this by reading the script file:

### Applicable Standards ### copy any of these to the instance data load script and use when applicable
# rack data import --clear ../RACK-Ontology/OwlModels/ARP-4754A.yaml     # from datagraph http://rack001/arp-475a
# rack data import --clear ../RACK-Ontology/OwlModels/DO-330.yaml        # from datagraph http://rack001/do-330
# rack data import --clear ../RACK-Ontology/OwlModels/DO-178C.yaml         # from datagraph http://rack001/do-178c
# rack data import --clear ../RACK-Ontology/OwlModels/MIL-STD-881D.yaml  # from datagraph http://rack001/mil-std-881d

I would expect anything defined in RACK-Ontology to be loaded as part of setup-rack.sh, so I suggest these standards should be moved out of RACK-Ontology and defined in a separate ontology, with their own load scripts.

With respect to (2), the DO-178C ontology is loaded by the Turnstile example, but unless you examine the load scripts, you won't discover that it gets loaded into its own data graph. The rationale for doing this is not clear - it might indicate that these standards are conceptually separate from the RACK data, but it makes them difficult to access from SPARQLgraph because these graphs are excluded from the default RACK data connection. Given that the standards are modelled in terms of RACK entities, it would not be unreasonable to load them into the default RACK data graph.

So I think there are definitely some documentation issues here, but perhaps some organisational issues too.