`action:result` linking one `core:UcoObject` to multiple `action:Action`s

[ajnelson-nist]

Let's say we have the following graph, depicting two Actions (and they are asserted to be different) and one UcoObject.

{       
    "@context": {
        "kb": "http://example.org/kb/",
        "action": "https://ontology.unifiedcyberontology.org/uco/action/",
        "core": "https://ontology.unifiedcyberontology.org/uco/core/",
        "owl": "http://www.w3.org/2002/07/owl#"
    },          
    "@graph": [
        {
            "@id": "kb:UcoObject-1",
            "@type": "core:UcoObject",
        },
        {
            "@id": "kb:Action-1",
            "@type": "action:Action",
            "owl:differentFrom": {"@id": "kb:Action-2"},
            "action:result": {"@id": "kb:UcoObject-1"}
        },
        {
            "@id": "kb:Action-2",
            "@type": "action:Action",
            "owl:differentFrom": {"@id": "kb:Action-1"},
            "action:result": {"@id": "kb:UcoObject-1"}
        }
    ]
}

Both independent actions "result" in kb:UcoObject-1.

This graph appears, to me, to be a data error, thinking from the perspective of how I could use UCO to represent an object's creation.

Is there ever a case where this would be OK? The definition of action:result doesn't seem to be precise enough to say yes or no.

I considered that analysis:Analysis would offer an acceptable use-case, but analysis:AnalyticResult appears to enable uniqueness of "result" objects.

[sbarnum]

It is completely valid for one UcoObject to be the result of multiple Actions. Being the result of an Action does not imply only creation of such an object. UcoObjects are inherently mutable by default. In the case above Action1 may result in the creation of UcoObject1 and Action2 may result in the modification/update of UcoObject1. It is also possible that UcoObject1 may not change at all and still be the result of multiple Actions. As a really oversimplified example consider Action1 is something like action:name="Identify person in photo" with action:object=RasterPicture1 and Action2 is something like action:name="Identify person in photo" with action:object=RasterPicture2. Both of these action could have the action:result of a Person object with core:name="Sean Barnum". There are many such variations possible.

[ajnelson-nist]

@sbarnum : The example you provided could also be satisfied with analysis:AnalyticResult. The two actions could be analysis:Analysises, could each result in unique analysis:AnalyticResult objects, and those analysis:AnalyticResult result objects could point to the other object named Sean Barnum.

Are you able to think of two actions that result in the same object, but the actions are clearly not analysis:Analysises?

[sbarnum]

I think we need to be really careful not to try to over-interpret almost any action into an Analysis just so we could force its result to be an AnalyticResult. Firstly, requiring an AnalyticResult object to point to another object which is the primary result of an action rather than simply giving the other object as the result adds significant complication that is not necessary or beneficial. Secondly, there is a potentially unbounded variation of possible types of actions of which we currently only have a handful defined. There will certainly be more in the future and we cannot lock them into blocking semantics based on one current type of action (Analysis). The entire point of the Action class is to act as a consistent but flexible basis for a wide range of possible types of actions.

There are lots of potential examples that could be given. Another one is a "resolve" action for a DomainName which results in an IPAddress. You could have multiple (possibly hundreds in common cases of CTI) Actions on different DomainNames that all result in the same IPAddress.

[ajnelson-nist]

DNS resolution satisfies me as an example. An object can be the result of multiple action:Actions, without implying being created by all of them. Thank you, @sbarnum .