Feature: implicit targets of SPARQL-based constraints

[fkleedorfer]

(Apologies if this has been addressed)

SPARQL-based constraints can take a long time to evaluate if the query is complex and there are many targets. Usually, evaluating the query without pre-binding ?this is much faster.

It would make things easier if SHACL allowed a sparql based constraint to interpret the binding for ?this in each solution as the focus node for the validation result.

One way to achieve this would be to add a shape property, say, sh:allowSparqlQueryTargets (true|false), which would cause the engine to evaluate the query once without pre-binding ?this, requiring that ?this be projected, and using ?this as the focus node for the validation result

[HolgerKnublauch]

Do you mean a SPARQL constraint that only gets executed once?

Would it work to use it as a "global" constraint with a shape that has a single (dummy) sh:targetNode?

[fkleedorfer]

Do you mean a SPARQL constraint that only gets executed once?

Yes

Would it work to use it as a "global" constraint with a shape that has a single (dummy) sh:targetNode?

Whichever way this can be made to work. If I understand correctly, you suggest something like

my:shape sh:targetNode sh:ImplicitSparqlQueryTarget .

That would be fine.

[HolgerKnublauch]

Yes I have applied that technique in the past, as a "singleton" constraint. Note however that these will all get the same focusNode in the results, so you would need to return ?value in your query.

[fkleedorfer]

I thought I was suggesting possible features for an upcoming version of SHACL, in that case, this could be easily defined as a magic target that sets the focusNode to the value of ?this in the reports.

Not the right place for such a suggestion?

... or are you saying that by returning ?value I would get exactly that result?

[HolgerKnublauch]

Yes you may have a point there. Let's leave the ticket open.

Meanwhile, would you have an example TTL snippet to illustrate the requirement and possible syntax?

[fkleedorfer]

I don't want to bring in a whole data model in which I have this problem, but imagine having many individuals of type ex:Person and an ex:knows relationship between them.

I'm sure evaluating this would not scale well:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix ex: <http://example.com/ns#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .

ex:ExampleGlobalShape
  a sh:NodeShape ;
  sh:sparql [
    a sh:SPARQLConstraint ;
    sh:message "{$this} knows nobody, be sure to double-check" ;
    sh:prefixes ex: ;
    sh:select """
      SELECT $this
      WHERE {
          FILTER NOT EXISTS {
            $this ex:knows ?someoneElse .
            ?someoneElse a ex:Person .
        }
      }
      """ ;
    sh:severity sh:Warning ;
  ] ;
  sh:targetClass ex:Person.

Whereas this would be much more efficient:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix ex: <http://example.com/ns#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .

ex:ExampleGlobalShape
  a sh:NodeShape ;
  sh:sparql [
    a sh:SPARQLConstraint ;
    sh:message "{$this} knows nobody, be sure to double-check" ;
    sh:prefixes ex: ;
    sh:select """
      SELECT $this
      WHERE {
          $this a ex:Person .
          FILTER NOT EXISTS {
            $this ex:knows ?someoneElse .
            ?someoneElse a ex:Person .
        }
      }
      """ ;
    sh:severity sh:Warning ;
  ] ;
  sh:targetNode sh:ImplicitSparqlQueryTarget .

[fkleedorfer]

I haven't given it too much thought, maybe this query is not a problem in either case, but it should convey the idea. Complex queries do exist ;-)

[HolgerKnublauch]

Yes and I think you can currently express this with a dummy sh:targetNode (e.g. ex:Person itself) and then return the violating nodes using ?value because $this is already used for ex:Person:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix ex: <http://example.com/ns#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .

ex:ExampleGlobalShape
  a sh:NodeShape ;
  sh:sparql [
    a sh:SPARQLConstraint ;
    sh:message "{$value} knows nobody, be sure to double-check" ;
    sh:prefixes ex: ;
    sh:select """
      SELECT $this ?value
      WHERE {
          ?value a ex:Person .
          FILTER NOT EXISTS {
            ?value ex:knows ?someoneElse .
            ?someoneElse a ex:Person .
        }
      }
      """ ;
    sh:severity sh:Warning ;
  ] ;
  sh:targetNode ex:Person .

I am not saying this is the ideal solution here, but it's the current work-around.

[fkleedorfer]

... you'd have to use a different variable in the query, not ?this, though, but then it would work

Drawbacks:

• If you depend on the value of sh:targetNode in the validation result, this will not work (it will be ex:Person for all results)
• If you want to report the problem node and the problem value as distinct properties, this will not work (sh:targetNode is always ex:Person, so you'll report either the problematic value or the actual problematic node as sh:value.