@sbarnum , there are a few points needed to finish preparing this proposal well enough for a Requirements Review vote:

• Can you please supply definitions for the new classes added in this Issue's Pull Request.
• Can you please state whether any of the freshly-rearranged classes are intended to be disjoint with any others. I've inlined my guesses on disjointedness in the proposal.
• Can you please give your response to Competency Question 1.1.

Update on the implementation: The initial PR tried inlining some anonymous sh:NodeShapes to gently warn that some additional types should be applied. Those were written on an incorrect understanding of how sh:node and sh:property work - it seems that if a supplemental shape attached by sh:node fails validation, even with sh:Info-level severity, the entire shape fails.

This patch, particularly between pre-line 8740 and post-line 13771, changes the implementation style to move all of those "gentle warning" shapes into anonymous shapes trailing at the end of observable.ttl. They are removed in the UCO 2.0.0 PR.

I moved them to anonymous nodes because it felt unhelpful to devise shape IRIs for temporary shapes, because they would no longer be relevant after UCO 2.0.0, but as introduced IRIs we might need to retain them permanently as part of backwards compatibility.

From at least how UCO's current testing infrastructure works, there is a slight difference in the validation reporting depending on whether the shape is identified with a blank node or with an IRI.

So, there is a question to address before Solutions Approval: Should these "gentle warning" shapes be given IRIs, or is it fine to have them be blank nodes? Absent requests otherwise, they will be left as blank nodes.

So, there is a question to address before Solutions Approval: Should these "gentle warning" shapes be given IRIs, or is it fine to have them be blank nodes? Absent requests otherwise, they will be left as blank nodes.

From Issue 602, I found a middle ground: The temporary shapes are blank nodes, but are linked to their associated classes with rdfs:seeAlso. I did just confirm that this will have the blank node shape render on the generated documentation page. The next-minor and next-major PRs have been updated with this implementation.

This Issue is awaiting English definitions to be added to the new classes before we consider whether the requirements are sufficiently specified.

There was some question in last week's call on the mutability of a process's parent-reference.

Here is a demonstration in macOS or Linux of a process changing its parent, using a Bash shell:

sleep 60

That command runs an idle process for 60 seconds, and the process remains the foreground of the shell. Terminating the parent shell would recursively terminate the child sleep process.

sleep 60 &

That command runs an idle process and backgrounds the process. The shell is still the process's parent - terminating the parent shell would recursively terminate the child sleep process.

nohup sleep 60 &

That command runs like sleep 60 &, except now if the shell is terminated, the root process init inherits the child. This can be seen with ps -ef | grep sleep - see the "PPID" (parent process ID) column.

@sbarnum : I was looking at the classes in this proposal and thinking of how to demonstrate them. "Service pack" is giving me some confusion versus the other classes.

How would you instantiate Windows XP Service Pack 2 (relevant for at least a lot of available forensic reference data), in these ways:

• As the software sitting on a hologrammed DVD.
• As a running operating system.

I expect in both of these cases several of the software types will apply to each node.

This Issue is awaiting English definitions to be added to the new classes before we consider whether the requirements are sufficiently specified.

Here are proposed English definitions for each of the new proposed classes as well as tweaks to a few existing definitions to better align over all and to address some issues that came about from creating clear distinct definitions for Task, ProcessThread, and Process.
Fleshing these definitions out also led to a need to slightly alter the Software class taxonomy as Task and ProcessThread are heavily related to Process but should not be subclasses.
Here is the new updated diagram:

• BuildUtility
  • A Build Utility is a software-based tool that automates portions or all of the process of creating executable software from source code
• Compiler
  • A Compiler is a software program that translates source code written in a high-level language (e.g., C++, Python, Java) into machine code that can be understood and executed by a computer processor.
• DeploymentScript
  • A Deployment Script is a software script used to deploy artifacts, packages, modules, patches, or other resources into an intended execution environment
• LinuxService
  • A Linux Service (often referred to as a daemon) is a Service running within a Linux operating system, similar to the way a Windows Service runs on Windows.
• LinuxTask
  • A Linux Task is a set of software computer instructions loaded into memory with the potential to be scheduled for execution within the Linux operating system.
• Package
  • A Pakcage is a body of software consisting of a collection of individual software (programs, libraries, files, etc.) packaged together to collectively serve a broader purpose
• Process
  • rdfs:comment "A Process is an instance of a software program that is being executed within a scope having dedicated memory, address space, execution variables, code instructions, state, security info, file handles, etc. Process execution consists of one or more component threads sharing the process resources."@en ;
• ProcessThread
  • rdfs:comment "A Process Thread is the smallest sequence of programmed instructions that can be managed independently by a scheduler on a computer, which is typically a part of the operating system. It is a scheduled running instantiation of one or more tasks (including CPU flags, counters, timers, stack, etc.) as a component of a process. Multiple threads can exist within one process, executing concurrently and sharing resources such as memory, while different processes do not share these resources. In particular, the threads of a process share its executable code and the values of its dynamically allocated variables and non-thread-local global variables at any given time. based on [https://en.wikipedia.org/wiki/Thread_(computing)]"@en ;
• Script
  • A Script is a software consisting of computer instructions that can be interpreted and executed in real-time (typically by an interpreter rather than directly by a computer processor) without requiring advance compilation
• Service
  • A Service is a process that runs in the background rather than under the control of an interactive user. Services are typically long-running and can be configured to start when the operating system starts and continue as long as the operating system is running.
• ServicePack
  • A Service Pack is a software consisting of a collection of software updates or fixes (patches) for a software delivered as an aggregated single package for ease of installation
• SoftwareBuild
  • A Software Build is a particular executable version of software that has been created from source code and is ready for testing or deployment
• Task
  • A Task is a set of software computer instructions loaded into memory with the potential to be scheduled for execution
• WindowsService
  • rdfs:comment "A Windows Service is a Service running within a Windows operating system, similar to the way a UNIX daemon runs on UNIX). based on [https://en.wikipedia.org/wiki/Windows_service]"@en ;
• WindowsTask
  • rdfs:comment "A Windows Task is a set of software computer instructions loaded into memory with the potential to be scheduled for execution within the Windows operating system."@en;
• WindowsThread
  • rdfs:comment "A Windows thread is a Process Thread within a Windows process."@en ;

Thank you, @sbarnum, I've incorporated the definition updates.

@sbarnum : I'm looking at some class-pairings.

• I suspect Compiler is a subclass of Application. Do you have an example where some Compiler is not an Application?
• Is there an example of a Library that is not a File? I suspect yes, when considering in-process-memory objects, but we haven't delved into modeling that to date.

• Can you please state whether any of the freshly-rearranged classes are intended to be disjoint with any others. I've inlined my guesses on disjointedness in the proposal.

I think it is very tricky and risky in defining disjoint between classes of software as there is a large amount of inherent potential overlap.
I am not sure I see significant value in trying to tease apart this issue.
That being said, if I had to take a cut at disjoint assertion that could likely be safe I would go with something like:

• Process disjoint from
	○ Code
	○ Application
	○ Script
	○ Library
	○ ProcessThread
	○ Task
	○ Compiler
	○ BuildUtility
	○ SoftwareBuild
	○ OperatingSystem
	○ ServicePack
• ProcessThread disjoint from
	○ Code
	○ Application
	○ Script
	○ Library
	○ Process
	○ Task
	○ Compiler
	○ BuildUtility
	○ SoftwareBuild
	○ OperatingSystem
	○ ServicePack
• Task disjoint from
	○ Code
	○ Application
	○ Script
	○ Library
	○ Process
	○ ProcessThread
	○ Compiler
	○ BuildUtility
	○ SoftwareBuild
	○ OperatingSystem
	○ ServicePack
• Application disjoint from 
	○ OperatingSystem
	○ Library
• BuildUtility disjoint from
	○ Library
	○ OperatingSystem
• Library disjoint from
	○ OperatingSystem
	○ Compiler
	○ BuildUtility
• ServicePack disjoint from
	○ Application
	○ Library
	○ Compiler
	○ BuildUtility
	○ OperatingSystem
• OperatingSystem disjoint from
	○ Compiler

@sbarnum , I will agree on tricky, but I do think we will find benefits from trying to specify these disjointedness statements. For instance, this helped catch a specification issue with one of the requirements over on Issue 626 (described here).

@sbarnum : Also in light of Issue 626 (constraining observable:cpeid), it looks like your disjointedness statements work out so that these subclasses of Software (as proposed in the current Issue) can't have CPEs associated, because they are disjoint with both Application and OperatingSystem.

Per this SPARQL query:

PREFIX uco-observable: <https://ontology.unifiedcyberontology.org/uco/observable/>
SELECT ?nClass
WHERE {
  ?nClass
    rdfs:subClassOf* uco-observable:Software ;
    owl:disjointWith
      uco-observable:Application ,
      uco-observable:OperatingSystem
      ;
    .
}
ORDER BY ?nClass

Task, Process, and ProcessThread, I see no controversy. I still need your help understanding ServicePack. But what about Library? A vulnerability in a library would be a significant point of interest in supply chain review.

Could you perhaps illustrate how a Library fits into the composition of an Application?