SPARQL Target Select not working as expected

[yum-yab]

Hi,

we are trying to use SPARQL-based targets in our SHACL-Tests.
Our Test should use all non-anonymous instances of owl:Class as Focus Nodes, but it seems its not working:

The Test:

@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 sh: <http://www.w3.org/ns/shacl#> .


<#LODE-class-comment-violation>
    a sh:Shape ;
    sh:target [
        a sh:SPARQLTarget ;
        sh:select """
        SELECT ?this WHERE {
            ?this <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2002/07/owl#Class> .
            FILTER ( !isBlank(?this) )
        }
        """;
    ];
    sh:severity sh:Violation;
    sh:path rdfs:comment;
    sh:nodeKind sh:Literal;
    sh:minCount 1;
    sh:name "comment not correctly specified"@en;
    sh:message "rdfs:comment is missing or is no Literal"@en .

The result conforms as true with this ontology as data graph in pyshacl (with advanced=true in the validate function), but does not conform if we try the same in the shacl play service.
Is this a bug or did we miss something?

Thanks in advance,
Denis

[ashleysommer]

Hi @yum-yab
It looks like this SHACL Shape you've written is trying to be a sh:NodeShape and a sh:PropertyShape at the same time, which is invalid. You have it declared as a sh:Shape that is not a real class. A SHACL Shape is always either a sh:NodeShape or a sh:PropertyShape, but not neither nor both.

A sh:NodeShape will have some kind of target, like sh:targetClass or implicit class target or in this case, sh:target with sh:SPARQLTarget. Whereas a sh:PropertyShape will have a sh:path, and its target will be whatever sh:property the shape is attached to.

I haven't tested it, but if you change your Shape to this, does it fix your problem?:

<#LODE-class-comment-violation>
    a sh:NodeShape ;
    sh:target [
        a sh:SPARQLTarget ;
        sh:select """
        SELECT ?this WHERE {
            ?this <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2002/07/owl#Class> .
            FILTER ( !isBlank(?this) )
        }
        """;
    ];
    sh:property [
        sh:severity sh:Violation;
        sh:path rdfs:comment;
        sh:nodeKind sh:Literal;
        sh:minCount 1;
        sh:name "comment not correctly specified"@en;
        sh:message "rdfs:comment is missing or is no Literal"@en;
    ];
    .

Note, if it helps you to understand, that is the same as this:

<#LODE-one-comment-literal>
    a sh:PropertyShape ;
    sh:severity sh:Violation;
    sh:path rdfs:comment;
    sh:nodeKind sh:Literal;
    sh:minCount 1;
    sh:name "comment not correctly specified"@en;
    sh:message "rdfs:comment is missing or is no Literal"@en;
    .

<#LODE-class-comment-violation>
    a sh:NodeShape ;
    sh:target [
        a sh:SPARQLTarget ;
        sh:select """
        SELECT ?this WHERE {
            ?this <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2002/07/owl#Class> .
            FILTER ( !isBlank(?this) )
        }
        """;
    ];
    sh:property <#LODE-one-comment-literal>;
    .

[yum-yab]

That helped a lot! Thanks for the quick answer, I was very confused since it worked in another service, but that solved my problem!

[ashleysommer]

Hi @yum-yab
Just following up on this, I think some things I said in my response above may be incorrect.

I said "sh:Shape is not a real class" actually it is, it is defined in the SHACL ontology shacl.ttl, but it is just not mentioned in the SHACL Spec document.

I also said sh:NodeShape has a target, like sh:targetClass sh:targetNode or sh:target. Whereas a sh:PropertyShape will have a sh:path. Reading the ontology I see actually sh:PropertyShape can also have sh:targetClass and sh:targetNode. However that is also not mentioned in the spec document. This is confusing, I don't have any guide or reference for how a PropertyShape with an explicit target would even work. I guess its up to the specific SHACL engine implementation.

Regardless, I believe the solution I provided to you is still correct, and should work across all SHACL implementations.