Need to represent multiple different configurations of the same tool, each referencing the same Tool object. Knowing what tool was run for each different configuration should be represented as a link in the graph, and not rely on the string name value. In addition, tool configuration needs an added property to reference an object that was provided as an argument/input to the Tool (e.g. so you could have a graph-object for NSRL-as-of-March-2022 or ClamAV signature-database version X, and show where in the graph that object had been involved in decision processes).
Requirements
Requirement 1
UCO must be able to represent how a tool was configured at the time of its invocation.
Requirement 2
A tool configuration that uses an object (such as a file or service endpoint) must be representable similar to the literal-valued tool:itemValue.
Requirement 3
UCO must be able to represent that one tool was used under multiple configurations.
Requirement 4
UCO must be able to use one tool configuration in multiple invocations.
E.g. if a tool analyzer_engine has a configuration involving calling it on the command line with the flag --auto-detect-content-type, and the tool is called once per input file for two input files, those two tool invocations should have their action:instrument objects use the same ConfiguredTool.
Requirement 5
UCO must support looking up when a tool is used with a certain flag.
E.g. if a tool analyzer_engine can take the unparameterized (0-argument) command-line flag --auto-detect-content-type, a UCO graph should be reviewable for when analyzer_engine is configured to use that flag, and in what action:Actions that configuration was used.
Requirement 6
UCO must support looking up when a tool is used with a certain flag-value. This applies to object-values (such as a file or service end-point reference), and literal-values (such as a string).
E.g. if a tool analyzer_engine can take the parameterized (1-argument) command-line flag --assume-content-type, a UCO graph should be reviewable for when analyzer_engine is configured to use that flag, and in what action:Actions that configuration was used.
Requirement 7
One tool used in multiple configurations should be linkable between those configurations and the actions using those configurations.
Risk / Benefit analysis
Benefits
Permit representation of multiple different configurations of the same tool, while maintaining link to the same Tool
Risks
The submitter is unaware of risks associated with this change
Competencies demonstrated
Competency 1
When a single tool is used in a workflow with multiple configuration sections, determine which Tool was used to obtain all observables, independent of all different tool configurations used.
Competency Question 1.1
What Tool was used to obtain all observables?
Result 1.1
Query returns a single result Tool.
Competency 2
A version of a tool known to contain a defect should be locatable within a graph, to understand the impact of results.
Competency Question 2.1
analyzer_engine version 1.0 is known to include a defect that reverses the latitudes and longitudes within JPEG EXIF metadata. What results, under any configuration of analyzer_engine, are affected by this defect?
Competency 3
When different versions of a resource (e.g., NSRL hashset, AntiVirus database) were provided in various ConfiguredTool objects, determine which resource was provided as an argument to a given ConfiguredTool object.
Competency Question 3.1
What resource was referenced in the itemObject property of a given ConfiguredTool object?
Result 3.1
Query returns a single object that was referenced in the itemObject of the given ConfiguredTool object.
Solution suggestion
Add ConfiguredTool object to UCO tool: ontology.
Add uco-tool:itemObject property for use in uco-tool:ConfigurationSettingType to reference an object that was provided as an argument/input to the ConfiguredTool.
Add new irreflexive object-property tool:isConfigurationOf, with rdfs:range tool:Tool, rdfs:domain tool:ConfiguredTool.
Unresolved implementation question: Should isConfigurationOf be restricted to have a domain that is a tool:Tool, but also not a tool:ConfiguredTool? Put another way: can a ConfiguredTool be configured further? The initial implementation will assume it is permissible to permit knowledge representations like this:
Background
Need to represent multiple different configurations of the same tool, each referencing the same Tool object. Knowing what tool was run for each different configuration should be represented as a link in the graph, and not rely on the string name value. In addition, tool configuration needs an added property to reference an object that was provided as an argument/input to the Tool (e.g. so you could have a graph-object for NSRL-as-of-March-2022 or ClamAV signature-database version X, and show where in the graph that object had been involved in decision processes).
Requirements
Requirement 1
UCO must be able to represent how a tool was configured at the time of its invocation.
Requirement 2
A tool configuration that uses an object (such as a file or service endpoint) must be representable similar to the literal-valued
tool:itemValue.Requirement 3
UCO must be able to represent that one tool was used under multiple configurations.
Requirement 4
UCO must be able to use one tool configuration in multiple invocations.
E.g. if a tool
analyzer_enginehas a configuration involving calling it on the command line with the flag--auto-detect-content-type, and the tool is called once per input file for two input files, those two tool invocations should have theiraction:instrumentobjects use the sameConfiguredTool.Requirement 5
UCO must support looking up when a tool is used with a certain flag.
E.g. if a tool
analyzer_enginecan take the unparameterized (0-argument) command-line flag--auto-detect-content-type, a UCO graph should be reviewable for whenanalyzer_engineis configured to use that flag, and in whataction:Actions that configuration was used.Requirement 6
UCO must support looking up when a tool is used with a certain flag-value. This applies to object-values (such as a file or service end-point reference), and literal-values (such as a string).
E.g. if a tool
analyzer_enginecan take the parameterized (1-argument) command-line flag--assume-content-type, a UCO graph should be reviewable for whenanalyzer_engineis configured to use that flag, and in whataction:Actions that configuration was used.Requirement 7
One tool used in multiple configurations should be linkable between those configurations and the actions using those configurations.
Risk / Benefit analysis
Benefits
Permit representation of multiple different configurations of the same tool, while maintaining link to the same Tool
Risks
The submitter is unaware of risks associated with this change
Competencies demonstrated
Competency 1
When a single tool is used in a workflow with multiple configuration sections, determine which Tool was used to obtain all observables, independent of all different tool configurations used.
Competency Question 1.1
What Tool was used to obtain all observables?
Result 1.1
Query returns a single result Tool.
Competency 2
A version of a tool known to contain a defect should be locatable within a graph, to understand the impact of results.
Competency Question 2.1
analyzer_engineversion 1.0 is known to include a defect that reverses the latitudes and longitudes within JPEG EXIF metadata. What results, under any configuration ofanalyzer_engine, are affected by this defect?Competency 3
When different versions of a resource (e.g., NSRL hashset, AntiVirus database) were provided in various ConfiguredTool objects, determine which resource was provided as an argument to a given ConfiguredTool object.
Competency Question 3.1
What resource was referenced in the itemObject property of a given ConfiguredTool object?
Result 3.1
Query returns a single object that was referenced in the itemObject of the given ConfiguredTool object.
Solution suggestion
tool:ontology.ConfiguredTool.tool:isConfigurationOf, withrdfs:range tool:Tool,rdfs:domain tool:ConfiguredTool.isConfigurationOfbe restricted to have a domain that is atool:Tool, but also not atool:ConfiguredTool? Put another way: can aConfiguredToolbe configured further? The initial implementation will assume it is permissible to permit knowledge representations like this:Coordination