How to match all (SHACL) instances of a class in Rules?

[HolgerKnublauch]

The current Rules draft appears to limit Path expressions to those with fixed length, but zero-or-more is not supported.

I wonder how we can then match all instances of a given class and its subclasses, which is usually done using

SELECT ?instance
WHERE {
    ?instance rdf:type/rdfs:subClassOf* ex:SomeClass .
}

Among other use cases, this is important for scenarios where a property is not sufficient to distinguish class membership. For example, when you want to define a rule on rdfs:label that only applies to instances of some class but not all (although rdfs:label is used everywhere).

This topic also relates to #765.

Maybe there is a need for a construct such as INSTANCEOF, which would address the a/rdfs:subClassOf* use case at least?

RULE { ... }
WHERE {
    ?instance INSTANCEOF ex:SomeClass .
    ?instance rdfs:label ?label .
    ...
}

Other usages of zero-or-more-paths exist are probably less critical than getting the instances.

(FWIW I think something like INSTANCEOF would be nice in SPARQL in general).

[afs]

This is possible but it has consequences when writing rules that operate in the tbox (RDFS, OWL related):

Property paths can be written as rules.

There is even a suggested shorthand TRANSITIVE for discussions, which helps the user and also the implementer because there are well known algorithms for transitive closure.

RULE  { ?x rdfs:subClassOf ?z } WHERE { ?x rdfs:subClassOf / rdfs:subClassOf ?z }

and rdfs:subClassOf* then runs wild.

Also natural is:

RULE  { ?x rdf:type ?type } WHERE { ?x rdf:type / rdfs:subClassOf ?type .  }

but maybe the application wants direct instances and inferred type instances (and :directSubClassOf) at different points.

[HolgerKnublauch]

but maybe the application wants direct instances and inferred type instances (and :directSubClassOf) at different points.

Correct, globally adding transitivity to rdfs:subClassOf will not address this requirement.

[afs]

Which requirement? The one in the title or the direct case (which your proposal does not address).

[HolgerKnublauch]

The requirement is to match all instances including the indirect ones. We need to be able to iterate over them and check whether a given node is an instance. The requirement of direct rdf:type is already covered by default, by simply querying rdf:type. So my proposal doesn't need to address this.

One problem with your proposed solution using the extra rules is the distinction between direct and indirect/transitive relationships. Once the transitive rdfs:subClassOf triples have been inferred, there is no way for other rules to query the direct rdfs:subClassOf triples anymore. So for example it becomes impossible to determine the root classes, because every class will become rdfs:subClassOf owl:Thing.

Other show stoppers are performance, scalability and pollution of results:

• All of our pharma customers rely on those biomedical ontologies like SNOMED which have 100k classes and more. Inferring transitivity of rdfs:subClassOf between all those classes will take a long time and create hundreds of thousands (millions?) of extra triples.
• Even if there is just one rule that operates on all instances of a given class, the result graph of the inference will include all these unrelated triples, completely swamping the output.

What problems do you see with adding something like INSTANCEOF?

[afs]

Holger:

One problem with your proposed solution using the extra rules is the distinction between direct and indirect/transitive relationships.

I'm sorry, you misunderstood. I am not proposing extra rules as a solution to finding all SHACL instances.

This [referring to Holger's descripton] is possible but it has consequences when writing rules that operate in the tbox (RDFS, OWL related):

I showed that the other rules that may be in rule set may interact in undesirable ways with rdf:type/rdfs:subClassOf*.

RDFS is a simple case. What about a subset of OWL-RL?
Importing a rule set may start to include interating rules.

Arbitrary length property paths are worth thinking about but they do not a great solution to "all SHACL instances".

My proposal would be #781 (parameterization).
It is a separation of concerns.

This addresses attaching rules to shapes, putting the matching SHACL instances (with sh:condition like effects) with the SHACL instance engine and it can also be used to inject the :Class for example.

It also supports other selection choices - SKOS concept hierarchies, sh:targetWhere, sh:condition filtering, . . .

It isolates the selection (here, "SHACL instance") from rules in the rule set that might interact.

  [ ] :property ?type . # Find types of interest
  ?instance rdf:type/rdfs:subClassOf* ?type 

has duplicates of ?instance
See https://www.w3.org/TR/shacl12-sparql/#sparql-definition-targetClass .

All of our pharma customers rely on those biomedical ontologies like SNOMED which have 100k classes and more. Inferring transitivity of rdfs:subClassOf between all those classes will take a long time and create hundreds of thousands (millions?) of extra triples.

Did you see the TRANSITIVE keyword? It allows rules engines to apply special algorithms for transitive closure and also to cache evaluation work to share between runs. It reduces runtime to rdf:type/rdfs:subClassOf, no * then the "millions" of instances only occur if needed.

Direct is bit complicated - it is not a simple "single link" from superclass criterion - it also means no other path from super to sub.
And is a reason to have WHERE DATA #960 .

[afs]

What problems do you see with adding something like INSTANCEOF?

It is one example - SKOS is another.

SHACL has quite a few targets now and may acquire ones in the future.
Better to find a way that is a hopefully stable interface between components.

If you want swappable implementations of rules engines, finding those stable interfaces that enable different ways to use rules is essential.

[HolgerKnublauch]

Ok I am glad the extra rule was a misunderstanding! Your message #961 (comment) did print that rule so others may have had the same shock :) My follow-up comments about millions of triples were under that interpretation and can be ignored now.

Yes, the parameterization should address most of the problems here. IIRC this is how I implemented SPARQL-based rules too because it isn't easy to insert something like $this a/rdfs:subClassOf* SomeClass into the right places in general SPARQL (e.g. nested UNIONs).

And having general support for all targets sounds good and SHACL-friendly.

I guess the only "missing" case would be to check instances of other classes (beside the pre-bound one), but that is far less critical.

I assume this also means that the target nodes will be computed exactly once before the rules iterate? Or is there a way to support cases when new instances are created by other rules?

And #781 is marked as POSTPONED, so I hope this gets back on the radar now, alongside attaching rules to shapes.