`action:subaction` and related actions' times

[ajnelson-nist]

Let's say we have the following graph, depicting an action that starts at 3AM (UTC) and ends at 4AM UTC, and has a recorded sub-action:

{       
    "@context": {
        "kb": "http://example.org/kb/",
        "action": "https://ontology.unifiedcyberontology.org/uco/action/",
        "xsd": "http://www.w3.org/2001/XMLSchema#"
    },          
    "@graph": [     
        {
            "@id": "kb:Action-1",
            "@type": "action:Action",
            "action:subaction": {
                "@id": "kb:Action-2",
                "@type": "action:Action"
            },
            "action:startTime": {
                "@type": "xsd:dateTime",
                "@value": "2020-01-02T03:00:00Z"
            },
            "action:endTime": {
                "@type": "xsd:dateTime",
                "@value": "2020-01-02T04:00:00Z"
            }
        }
    ]
}

Do we know the following about kb:Action-2:

1. Its start time is at or after 2020-01-02T03:00:00Z.
2. Its end time is before or at 2020-01-02T04:00:00Z.

Generally speaking, would a subaction always be time-bounded?

(Edited to fix JSON-LD typos, and clarify sentence 1.)

[plbt5]

As far as I can determine from the Action ontology, there are no constraints that limit a subaction to start before or end after its parent action. This is in conflict with the definition for the subaction: "[a subaction] References to other actions that make up part of a larger more complex action." that suggests that the parent (larger more complex) action cannot start after the first, nor end before the last, subaction.

In conclusion: whether or not it is the intention for the parts to be proper subparts of the whole, the intention of the textual definition of the parts do not match the logical construction of the whole by its parts. If anything, this conflict should be resolved one way or another.

A solution could be to move the time constraints from the whole to its parts. Since the former is constructed by its parts, it will automatically inherit the time constraints from them.

[ajnelson-nist]

@plbt5 - Does it it look like action:subaction could be a specialization of isPerdurantProperPartOf from Issue 544?

[plbt5]

Indeed it seems to look that way. We need to assure, though, that by introducing this we do not imply that isPerdurantProperPartOf is an InverseFunctionalProperty. With that I mean that while an action:subaction could be considered to be a sub-action of only one super-action, this is not the case with the proper-part relation.

At least, that is what I conclude from the supplemental principles in mereology.

[ajnelson-nist]

@plbt5 The concern on owl: InverseFunctionalProperty in subproperties is fair. My understanding is that if a property is not defined as inverse-functional, but a subproperty is, then the parent property does not become inverse-functional.

I just did a test[^1] with Protege and Robot, which both provide access to some Java-based reasoners. I confirmed my understanding with the following ontology. Protege complains of inconsistency when a reasoner is turned on, appropriately, until the commented lines are adjusted like suggested. The inconsistency is that kb:Thing-2 and kb:Thing-3 are inferred to be the same individual via an owl:FunctionalProperty, and that individual inherits both of the different ex:name values, becoming inconsistent with ex:ThingWithOneName's restriction of just one name value. kb:Thing-5 and kb:Thing-6 trigger the same kind of inconsistency via an owl:InverseFunctionalProperty. The example works if the other subproperty, ex:op2, is used instead, because the subproperties ex:op3 and ex:op4 do not induce their shared superproperty ex:op1 to become a functional or inverse-functional property.

ROBOT (1.9.5) complains appropriately[^2] with either of the following commands:

java -jar robot.jar \
      reason \
      --input asserted.ttl \
      --output reasoned-hermit.ttl \
      --reasoner HermiT
java -jar robot.jar \
      reason \
      --input asserted.ttl \
      --output reasoned-jfact.ttl \
      --reasoner JFact

@prefix ex: <http://example.org/ontology/> .
@prefix kb: <http://example.org/kb/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

ex:ThingWithOneName
    a owl:Class ;
    rdfs:subClassOf [
        a owl:Restriction ;
        owl:onProperty ex:name ;
        owl:cardinality "1"^^xsd:nonNegativeInteger ;
    ] ;
    .

ex:name
    a owl:DatatypeProperty ;
    rdfs:range xsd:string ;
    .

ex:op1
    a owl:ObjectProperty ;
    rdfs:domain ex:ThingWithOneName ;
    rdfs:range ex:ThingWithOneName ;
    .

ex:op2
    a owl:ObjectProperty ;
    rdfs:subPropertyOf ex:op1 ;
    .

ex:op3
    a
        owl:ObjectProperty ,
        owl:FunctionalProperty
        ;
    rdfs:subPropertyOf ex:op1 ;
    .

ex:op4
    a
        owl:ObjectProperty ,
        owl:InverseFunctionalProperty
        ;
    rdfs:subPropertyOf ex:op1 ;
    .

kb:Thing-1
    a owl:Thing ;
    .

kb:Thing-2
    a owl:Thing ;
    ex:name "2" ;
    .

kb:Thing-3
    a owl:Thing ;
    ex:name "3" ;
    .

kb:Thing-4
    a owl:Thing ;
    .

kb:Thing-5
    a owl:Thing ;
    ex:name "5" ;
    .

kb:Thing-6
    a owl:Thing ;
    ex:name "6" ;
    .

########################################################################
# Below this line, if the ex:op3 and ex:op4 predicates are replaced with
# ex:op2, the ontology is consistent.
########################################################################

kb:Thing-1
    ex:op3
        kb:Thing-2 ,
        kb:Thing-3
        ;
    .

kb:Thing-5
    ex:op4 kb:Thing-4 ;
    .

kb:Thing-6
    ex:op4 kb:Thing-4 ;
    .

#kb:Thing-1
#   ex:op2
#       kb:Thing-2 ,
#       kb:Thing-3
#       ;
#   .
#
#kb:Thing-5
#   ex:op2 kb:Thing-4 ;
#   .
#
#kb:Thing-6
#   ex:op2 kb:Thing-4 ;
#   .

Protege provides the following explanation dialogue:

[^1]: Participation by NIST in the creation of the documentation of mentioned software is not intended to imply a recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that any specific software is necessarily the best available for the purpose. [^2]: The default reasoner in ROBOT, ELK, does not raise notice of any inconsistencies. It reviews according to the OWL 2 EL Profile, which does not support owl:FunctionalProperty or owl:InverseFunctionalProperty, so this attempted use of ELK is out of scope of its functionality.

[ajnelson-nist]

I'd be comfortable proposing (separately) that action:subaction become an owl:InverseFunctionalProperty, and seeing if counter-examples come up in discussion.

Meanwhile, there is still the original question on this Issue, of subaction times relative to the superaction. For now, I'm interested in a yes or no response on whether the superaction's and subaction's times behave in a manner analagous to, or exactly like, time:intervalIn (distinct from time:intervalDuring).

[sbarnum]

Yes, I would assert that the intent of the design of Action and subaction is that the time bounds of any sub Action would fall within the time bounds of the super Action.

[ajnelson-nist]

Thank you, @sbarnum .

This Issue will remain open while awaiting an implementation that can encode that constraint. At the present time, it is not possible to encode, because of some un-constrainable details on action:endTime and action:startTime as literals of datatype xsd:dateTime. As xsd:dateTimes, they are not required to have a time zone, and if they have one, they are not required to have any particular time zone. So the only comparison mechanism available currently, lexical (string) comparison, would only work when the time values are confirmed to have the same time zone. This is not a test-functionality available in SHACL. It is available in SPARQL with the TZ() function, but it would take some runtime inferencing and SHACL-SPARQL testing to make work---and it would likely cease to work once user data reaches several common complexities (e.g., data from two time zones, data spelling UTC as Z vs -00:00).

There are other ways to test the superaction-subaction time bounding, but they would require reified time instants. Any of the following could work, but each would be predicated on another not-yet-filed proposal:

# Assuming adoption of OWL-Time: https://www.w3.org/TR/owl-time/
action:subaction rdfs:subPropertyOf time:intervalIn .

# Assuming an outcome of Issue 544.
action:subaction rdfs:subPropertyOf core:isPerdurantProperPartOf .

(Issue 544.)