327: SHACL-SHACL shapes for SHACL-SPARQL ASK, SELECT, and Annotations

[ajnelson-nist]

• See this document rendered online here

This is an addition to (and builds upon) PR #330 . It started as drafting SHACL-SHACL for the Annotations in SHACL-SPARQL, but some of the editorial updates suggested linking to SHACL-SHACL rules for ASK and SELECT queries, which I realized weren't written. So, this PR is slight scope creep over #327, and suggests some TODOs around finishing syntax review rules, e.g. for tying sh:prefixes, and setting up CONSTRUCT and UPDATE shapes.

I suggest either this be merged into #330 , or be handled on its own to finish catch-up with SHACL-SPARQL syntax review.

[HolgerKnublauch]

Thanks. I have just merged the main issue 327 branch into the main branch, so you could pull and merge it back in, and then also perhaps add the syntax rule references that you needed and other changes you proposed in the comment?

[ajnelson-nist]

Reverting to draft. I found a few misalignments between the text, shacl.ttl, and Ask vs. Select validators.

[ajnelson-nist]

@HolgerKnublauch , I wanted to check on direction before coding more: Some of the English from 330 suggested annotations go on Ask or Select Validators, but not all of the coding suggests the same. E.g., sh:resultAnnotation lists a domain of just sh:SPARQLSelectValidator.

It'd be better for sh:resultAnnotation in this case if there were a parent sh:SPARQLValidator of sh:SPARQLSelectValidator and sh:SPARQLAskValidator, but their shared parent is sh:Validator. There isn't a sh:SPARQLValidator.

So, two questions:

• Should sh:resultAnnotation extend its domain to cover Ask Validators?
• Should a sh:SPARQLValidator class be added?

If this matter is graduating to an Issue to follow-on 327, please note so and I'll move this comment.

[ajnelson-nist]

For reference, I posted a visualization in Discussion 380.

[afs]

@ajnelson-nist -- status? (this is set as a "draft").

[ajnelson-nist]

Stepping back into this PR: I sketched out expanding result annotations to support "ASK" queries as validators, and I currently am not sure if it makes sense. The "SELECT" annotation pipeline works fine because there are variable bindings exposed in the SELECT clause. But, for an "ASK" query, the ASK clause doesn't have bindings. So, result annotations would have to reach into the WHERE clause to find variable bindings. I think this comes down to what a "solution binding" (as described in today's SHACL-SPARQL section ... 2.3.2, I suppose?) is in "SELECT" vs. "ASK" queries.

Here is an adaptation of the example in today's state of SHACL-SPARQL Section 4:

ex:AskAnnotationExample
	a sh:NodeShape ;
	sh:targetNode ex:ExampleResource ;
	sh:sparql [   # _:b1
		sh:resultAnnotation [
			sh:annotationProperty ex:time ;
			sh:annotationVarName "time" ;
		] ;
		sh:ask """
			ASK {
				FILTER (1 != 1)
				BIND (CONCAT("The ", "message.") AS ?message) .
				BIND (NOW() AS ?time) .
			}
			""" ;
	] .

[	a sh:ValidationReport ;
	sh:conforms false ;
	sh:result [
		a sh:ValidationResult ;
		sh:focusNode ex:ExampleResource ;
		sh:resultMessage "The message." ;
		sh:resultSeverity sh:Violation ;
		sh:sourceConstraint _:b1 ;
		sh:sourceConstraintComponent sh:SPARQLConstraintComponent ;
		sh:sourceShape ex:AskAnnotationExample ;
		ex:time "2015-03-27T10:58:00"^^xsd:dateTime ;  # Example
	]
] .

Is that what's expected for annotating ASK results?

Note that I left sh:resultMessage in the adapted example, as further motivation for us thinking about what bindings are to be visible from the WHERE clause.

[HolgerKnublauch]

Hi Alex, the sh:ask property can only be used in SPARQL-based Constraint Components, not individual constraints. So the example is already invalid.

In SPARQL-based constraint components, ASK queries will only bind $this (focusNode) and ?value (the value node). This is indirectly mentions in section 3.3 https://www.w3.org/TR/shacl12-sparql/#constraint-components-validation
So an annotation could only reference those two variables, not variables that are otherwise used within the WHERE clause.

[ajnelson-nist]

Hi Alex, the sh:ask property can only be used in SPARQL-based Constraint Components, not individual constraints. So the example is already invalid.

In SPARQL-based constraint components, ASK queries will only bind $this (focusNode) and ?value (the value node). This is indirectly mentions in section 3.3 https://www.w3.org/TR/shacl12-sparql/#constraint-components-validation So an annotation could only reference those two variables, not variables that are otherwise used within the WHERE clause.

Thank you, @HolgerKnublauch . I've added text to the SHACL-SPARQL document clarifying this restriction, and a shape to SHACL-SHACL enforcing it.

I found a demonstration of sh:ask in the test suite and adapted that instead of trying one of the other text examples from the SHACL-SPARQL document.

Because of the domain of sh:resultAnnotation needing to include ASK-based validators too, I added a parent class of SELECT-based validators and ASK-based validators. The class was suggested in the text, but not encoded in shacl.ttl. Doing this avoided leaving a suggested domain union as Turtle comments.

I don't intend to look at sh:prefixes any further within this PR than is already in the changes. More might be needed. The annotation bits resulted in enough change I think it's better to get this PR here and find anything else pertaining to sh:prefixes in later test development.

This PR is ready for review and merge.

[HolgerKnublauch]

The end looks weirdly placed - did you mean to wrap it around the full sentence, and how is this a syntax rule?

[HolgerKnublauch]

I am not sure this should be covered by a test case: the spec states "Implementations that support this feature" which indicates that the whole feature is optional. As such a test case cannot be made mandatory for all implementations

[TallTed]

"Implementations that support this feature" which indicates that the whole feature is optional. As such a test case cannot be made mandatory for all implementations

It seems worthwhile to me to report "unsupported" for such cases, as there's no error in such an implementation; it's expected to fail the test. This is helpful to potential deployers, beyond our chartered Success Criteria.

In my world, MUST statements MUST be tested, SHOULD statements SHOULD be tested, and even MAY statements SHOULD be tested. The latter two are not about success criteria; they'are about competitive (dis)advantage of various implementations.

[afs]

W3C tests are about showing implementability and agreement amongst implementers.

The tests are not validated and not maintained - they are not suitable for competitive issues.

[HolgerKnublauch]

My understanding is that there need to be two implementations that pass each test case. For an optional feature this is unlikely. So I don't understand why this can become a test case unless we add some flag to mark the test as optional?