I would like to consider this a fast-track proposal, but it may come bundled with some non-trivial ontological risk.

The rationale for considering this as a fast-track proposal is that it is "Splintered off" of another proposal on analysis actions (400).

I am aware of at least this risk with isAutomated: We need to decide whether having isAutomated true on an action means there is an entailed requirement that the action cannot have a human action:performer.

I.e. should this snippet raise a SHACL validation error?

{
    "@id": "kb:person-automated-action-c51e0065-ba55-4177-bc08-e71963c22c26",
    "@type": "action:Action",
    "action:isAutomated": true,
    "action:performer": {
        "@id": "kb:person-c6c7ccc6-2b6c-41e0-ad74-d895bd209ac8",
        "@type": "identity:Person"
    }
}

Let's say Sam the Analyst sets a cron job or ScheduledTask that triggers a one-off program at 11 o'clock some night. The action is automated. Is Sam the performer?

My opinion is no, Sam is not the performer of the program that executes. He did perform the delayed-start scheduling, but did not perform the program execution.

Per @eoghanscasey 's and my agreement on whether action:performer can reference a person for an automated action (we agree no), I've added a shape to consider such data an error. The shape follows a design pattern not yet used in UCO, applying constraints directly on sh:NodeShapes instead of in a sh:PropertyShapes, because this constraint necessarily references two properties. The pattern was shown to me in this comment.

The PR needs a PASS test alongside the XFAIL test, but otherwise it will be ready for a vote on Nov. 17. Announcement will be coming tomorrow.

Noting this issue has not been forgotten: I'm testing it over on CASE-Corpora, including sanity-checks on uco-action:subaction, a property which was not exercised in CASE-Examples or the CASE website.

The benefit to uco-action:subaction that I've seen is on non-automated case-investigation:InvestigativeActions, where someone linked by uco-action:performer uses a tool that calls internal functions, and it is beneficial for narrowly scoping chain of custody that those internal function calls also be considered investigative actions. It seems consistent with discussion on this Issue that we consider those internal functions as automated actions, with no uco-action:performer. (In the CASE PROV-O mapping, a chain of prov:Delegations can be constructed to tie internal functions to overarching tools, if the objected linked with uco-action:instrument is different between the Actions.) If anyone disagrees with this pattern for isAutomated, please say so.

As an aside with respect to isAutomated, CASE may need to clarify how ProvenanceRecords and generated non-ProvenanceRecord objects should be handled when an InvestigativeAction has a subaction link. This note will become a separate Issue on the CASE tracker.