Inferencing use case: Refining OWL-Time `Interval`s to `ProperInterval`s based on trinary relationship

[ajnelson-nist]

This is a use case motivating retaining SHACL-SPARQL CONSTRUCT-based rules as the inferencing work proceeds. It goes a bit into OWL theory, but I try to only go as far as I see some similar expressiveness constraints from SHACL AF's TripleRules.

Relevance for related issues

• PR Initial content for 'Inference Rules' #452 introduces SHACL Rules post-SHACL-AF and Variables, which I think are necessary to satisfy this use case without SPARQL. SHACL AF's discussion around variables, aside from $this, only went as far as exposing annotation links, per Section 4.

• The long writeup is to give a case of Rules performing an inference that I believe is unavailable to OWL. There is also some implication of recurrence in pre-validation steps: Rule execution as described in this Issue would have an influence on RDFS and/or OWL inferencing, due to rule-inferred owl:Class assignments. I could have sworn this ordering matter was filed as an Issue already, but I'm having trouble finding it. Link welcome if this jogs anyone's memory.

Caveat

This example is based on an interpretation of a property time:after as it pertains to two time:Instants: That x time:after y means there is a >0-duration interval of time between x and y. This is not explicit in the current OWL-Time specification, but it appears to be implied; discussion is here.

Background: OWL-Time excerpt

OWL-Time has a few top-level classes that relate to each other in this way:

• TemporalEntity is the parent class of Instant and Interval
• Interval is the parent class of ProperInterval: intervals can be 0-duration, but ProperIntervals are non-0 duration
• Instants are disjoint with Intervals

If helpful, here is a diagram showing these classes:

flowchart

subgraph legend
direction BT
subclass -->|⊏| superclass
end

subgraph Classes
direction BT
owl_Thing[owl:Thing]
time_TemporalEntity[time:TemporalEntity]
time_Instant[time:Instant]
time_Interval[time:Interval]
time_ProperInterval[time:ProperInterval]
end

time_Instant ---|⊓=∅| time_ProperInterval
linkStyle 1 stroke:red,stroke-width:4px,color:red;
time_TemporalEntity -->|⊏| owl_Thing
time_Instant -->|⊏| time_TemporalEntity
time_Interval -->|⊏| time_TemporalEntity
time_ProperInterval -->|⊏| time_Interval

Loading

There is a property, time:inside, which denotes that an instant is inside an interval. time:inside has as part of its definition time:inside rdfs:domain time:Interval .---note this is not time:ProperInterval.

Use case

Take this example data graph:

ex:Interval-A time:inside ex:Instant-B .
ex:Interval-A time:inside ex:Instant-C .

Domain and range inferencing (either RDFS or OWL-RL) entail:

ex:Interval-A a time:Interval .
ex:Instant-B a time:Instant .
ex:Instant-C a time:Instant .

The example data graph, and even the example data graph with the inferred type triples, is insufficient information to determine whether ex:Interval-A is a time:ProperInterval. This is because:

• ex:Instant-B and ex:Instant-C could pertain to the same graph-individual, just identified by different IRI.
• ex:Instant-B and ex:Instant-C could be different graph-individuals (e.g., the independently-assigned end of some interval and beginning of some other interval), but pertain to the same temporal value (/position). This could occur with usage of time:intervalMeets.

If this statement were also in the knowledge graph ...

ex:Instant-C time:after ex:Instant-B .

... then, it should be possible to infer that ex:Interval-A is a time:ProperInterval, because it is an interval that contains two instants with a gap between them. (Reminder of caveat - this assumes time:after is a greater-than predicate, not a greater-than-or-equal-to.)

However, I don't think this is possible to infer using only mechanisms available to OWL, or SHACL Advanced Features (i.e., pre-SHACL-1.2) TripleRules. My understanding is that the matter comes down to variable binding and trinary (/3-ary) relationships not being available without SPARQL. (Though sh:disjoint / sh:equals are also trinary relators, I don't think they have enough information available to meet this use case, due to the Open World assumption sneaking in to this one particular spot of SHACL.)

I can express this in SPARQL and get the entailment I'm looking for:

CONSTRUCT {
	$this a time:ProperInterval .
}
WHERE {
	$this
		a time:Interval ;
		time:inside
			?nInstant1 ,
			?nInstant2
			.
	?nInstant2 time:after ?nInstant1 .
}

(Edited by @ajnelson-nist - fixed variable usage, h/t to @afs for catching that)

In OWL, I do not believe it is possible to write a set of owl:Restrictions that let me entail time:ProperInterval by some owl:EquivalentClass or owl:allValuesFrom on inverted properties. It's possible to come close, saying "A proper interval is an interval that contains at least two instants, and vice versa" - but it doesn't quite work because of the semantics specific to OWL-Time:

time:ProperInterval
	owl:equivalentClass [
		a owl:Class ;
		rdfs:subClassOf
			time:Interval ,
			[
				a owl:Restriction ;
				owl:onProperty time:inside ;
				owl:minCardinality "2"^^xsd:nonNegativeInteger ;
			]
		] .

owl:equivalentClass says that anonymous class's conditions are necessary and sufficient. They're necessary, but insufficient - the two time:Instants linked by time:inside could pertain to the same temporal position. They need to be asserted as one time:after the other.

To my understanding, OWL was consciously designed to not have a way to say "Not only are there two time:Instants linked by time:inside, but those two instants are also linked together by time:after"---more generally, to not have trinary restrictions available. This SPARQL path can be followed in OWL spelling with a lot of owl:Restriction nesting (which I'll skip typing out), but nInterval1 doesn't get to know anything about how it relates directly to nInterval2, due to the Open World assumption.

?nInterval1 time:inside/time:after/^time:inside ?nInterval2 .

Resolution

SHACL-AF had provided sh:SPARQLRule, which can satisfy this use case with a SPARQL CONSTRUCT query. I suggest sh:SPARQLRule carry forward, though there is an interesting question of the concept's home between the SPARQL Rules and SHACL-SPARQL documents.

(And/or)

This seems like a good opportunity to test the Variable work going on in the Inferences Rules PR #452 .

[ajnelson-nist]

Also, I hope it didn't come across this way, but I did not intend this as a criticism of OWL. I understand that there were logic reasons that the trinary restrictions were restricted from the language design.

[HolgerKnublauch]

I have removed the SPARQL label as this doesn't affect the SPARQL spec. The labels should IMHO be used to indicate who is supposed to work on an issue.

[ajnelson-nist]

I have removed the SPARQL label as this doesn't affect the SPARQL spec. The labels should IMHO be used to indicate who is supposed to work on an issue.

I'd added the SPARQL Label in case sh:SPARQLRule might get a section in the SPARQL specification like sh:SPARQLConstraintComponent did - Section 2, today (today's live render, link not necessarily stable; today's source, link stable).

I could reasonably see sh:SPARQLRule being owned by the inferencing document. No complaints with the SPARQL label being removed.

[afs]

I can express this in SPARQL and get the entailment I'm looking for:

How do you trigger that rule? (it does not have a $this)

CONSTRUCT {
	?nInterval a time:ProperInterval .
}
WHERE {
	?nInterval
		a time:Interval ;
		time:inside
			?nInstant1 ,
			?nInstant2
			.
	?nInstant2 time:after ?nInstant1 .
}

Have all the OWL Time inference been materialized before query? or is this with OWL-time-entailment at query time?

That's a well-behaved CONSTRUCT and has a rule equivalent.

RULE { ?nInterval a time:ProperInterval }
WHERE {
	?nInterval a time:Interval ;
                 time:inside ?nInstant1 , ?nInstant2 .
	?nInstant2 time:after ?nInstant1 .
}

dealing with the calculation properties the same way.

I suggest sh:SPARQLRule carry forward

It is not necessary to put anything in the spec. An engine can provide SHACL-AF and SHACL 1.2 Rules.

It might be nice to include a section somewhere in SHACL 1.2 - in rules or in a note "migrating form SHACL-AF").
SHACL triple rules and SPARQL Rules can marked as legacy. For backwards compatibility, they will need to run separately else new RULEs may interfere with legacy CONSTRUCT.

There is also the idea of explicit declaration of transitive,symmetric, inverse

INVERSE(time:after, time:before)

to help have engines with special handling for this cases. They can be written in plain RULEs, but custom implementation is an advantage at scale and clearer to the user.

[ajnelson-nist]

Whoops, ?nInterval should be $this.

[ajnelson-nist]

Have all the OWL Time inference been materialized before query? or is this with OWL-time-entailment at query time?

All the OWL-Time OWL inference might be attempted before the CONSTRUCT query, but I think this CONSTRUCT recipe does inference that is beyond OWL inference and could trigger different effects in an OWL inference run afterward.

[ajnelson-nist]

Now that #452 merged, I see this use case may be straightforward to address with the RULE syntax, per the Outline section. I had thought Rules would delegate to CONSTRUCT from SPARQL, but that's a conversation for outside this Issue.

[ajnelson-nist]

There is also the idea of explicit declaration of transitive,symmetric, inverse

INVERSE(time:after, time:before)

to help have engines with special handling for this cases. They can be written in plain RULEs, but custom implementation is an advantage at scale and clearer to the user.

I think this would not be necessary in cases when OWL is already in use, such as with OWL-Time. time:before and time:after are already defined as inverses in OWL, so a general rule for owl:inverseOf would catch this.

In cases when OWL is not already in use, then yes, this would cover a feature-gap beyond RDFS. For legibility's sake, both in graph serializations and user interfaces, how would you tie a Rule denoting inverse properties to the ex:p a rdf:Property ; rdfs:domain ex:Foo ; ... "graph paragraphs"?

[afs]

Rules would delegate to CONSTRUCT

The rule syntax is "tamed CONSTRUCT". It keeps the rules, without assignment, inside datalog and also analysable as to dependencies for "rules depending on rules" without requiring order annotations.

Other features can go on top - we have to understand whether they step outside datalog into a more "production rules" pattern.

For legibility's sake, both in graph serializations and user interfaces, how would you tie a Rule denoting inverse properties to the ex:p a rdf:Property ; rdfs:domain ex:Foo ; ... "graph paragraphs"?

INVERSE is nothing more than syntactic sugar for something that can be written with RULE.
It is not required to use it to have an inverse property. Use OWL-RL prp-inv1, prp-inv2 if you want to.