Range of is signifies relation

[YoucTagh]

Why is the range of :signifies sh:NodeShape and not sh:Shape?

With the examples given in the motivating scenario sh:NodeShape, sh:Shape and sh:PropertyShape seem to work fine.

[danaivach]

Hi @YoucTagh, could you provide an example where :signifies is used to signify a sh:PropertyShape that specifies a description of an expected behavior execution?

[YoucTagh]

Hi @danaivach, I tested with the shape and data suggested in the comment: https://github.com/HyperAgents/hmas/issues/116#issuecomment-1609123326

To get an invalid graph, I simply removed the ^^xs:integer from the value of ex:hasGripperValue.

If I replace sh:NodeShape with sh:PropertyShape or sh:Shape I get the same results.

[danaivach]

Thanks @YoucTagh. As far as I understand you used the following:

@prefix ex: <http://example.org/> .
@prefix hmas: <https://purl.org/hmas/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix xs: <https://www.w3.org/2001/XMLSchema#> .
@prefix hctl: <https://www.w3.org/2019/wot/hypermedia#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

ex:moveGripper a sh:PropertyShape;
    sh:targetClass hmas:ActionExecution ;
    sh:property [
        sh:path prov:used ;
            sh:minCount 1;
            sh:maxCount 1 ;
            sh:or (
            [ sh:hasValue ex:httpForm ]
            [ sh:hasValue ex:coapForm ]
         ) ;
    ] ;
    sh:property [
        sh:path hmas:hasInput;
            sh:qualifiedValueShape ex:gripperJointShape ;
            sh:qualifiedMinCount 1 ;
            sh:qualifiedMaxCount 1 
    ] .

ex:gripperJointShape a sh:NodeShape ;
    sh:targetClass ex:GripperJoint ;
    sh:property [
        sh:path ex:hasGripperValue ;
        sh:minCount 1;
        sh:maxCount 1 ;
        sh:datatype xs:integer
    ] .

I am concerned with the following: ex:moveGripper is declared as a SHACL instance of sh:PropertyShape, but does not have any value for the property sh:path. This appears to be inconsistent with the definition of a Property Shape as well as the SHACL shape of sh:PropertyShape. Am I missing something?

[YoucTagh]

I agree with you @danaivach, yet it seems to be valid against the shape to validate shapes (cf. C. SHACL Shapes to Validate Shapes Graphs)

After some investigation, it seems that this is indeed a problem (cf. https://github.com/w3c/data-shapes/issues/121) and the version of Jena I was using did not include the updated shape.

I think a shape like this one is needed:

shsh:PropertyShapeShapee
    a sh:NodeShape ;
    sh:targetClass sh:PropertyShape;   
    sh:property [
        sh:path sh:path ;
        sh:maxCount 1 ;                 # path-maxCount
        sh:minCount 1 ;                 # PropertyShape-path-minCount
        sh:or ( shsh:PathShape [ sh:nodeKind sh:IRI ] ) ;        # path-node
    ] .

As far as we are concerned, even if a sh:PropertyShape must have a sh:path, the shape graph:

...
ex:moveGripper
    a              sh:NodeShape ;
    sh:targetClass hmas:ActionExecution ;
    sh:property    [ sh:path     prov:used ;
                     sh:minCount 1 ;
                     sh:maxCount 1 ;
                     sh:or       ( [ sh:hasValue ex:httpForm ]
                                   [ sh:hasValue ex:coapForm ] ) ; ] ;
    sh:property    [ sh:path                hmas:hasInput ;
                     sh:qualifiedValueShape ex:gripperJointShape ;
                     sh:qualifiedMinCount   1 ;
                     sh:qualifiedMaxCount   1 ] .

becomes:

ex:moveGripper
    a              sh:PropertyShape ;
    sh:targetClass hmas:ActionExecution ;
    sh:path        prov:used ;
    sh:minCount    1 ;
    sh:maxCount    1 ;
    sh:or          ( [ sh:hasValue ex:httpForm ]
                     [ sh:hasValue ex:coapForm ] ) ;
    sh:property    [ sh:path                hmas:hasInput ;
                     sh:qualifiedValueShape ex:gripperJointShape ;
                     sh:qualifiedMinCount   1 ;
                     sh:qualifiedMaxCount   1 ] .

Do you think it is acceptable in this form?

[danaivach]

The latter form shouldn't be acceptable because the range domain of sh:property is sh:NodeShape (SHACL Core and SHACL ontology). (At the same time, sh:path must have exactly one value for an instance of sh:PropertyShape, so we cannot collapse the remaining sh:property).

Other than this, and assuming that there is no second sh:path, is there really no difference between the two representation approaches? And if they are equivalent, are there any cases where one would be preferred over the other?

ex:moveGripper
    a              sh:NodeShape ;
    sh:targetClass hmas:ActionExecution ;
    sh:property    [ sh:path     prov:used ;
                     sh:minCount 1 ;
                     sh:maxCount 1 ] .

ex:moveGripper
    a              sh:PropertyShape ;
    sh:targetClass hmas:ActionExecution ;
    sh:path        prov:used ;
    sh:minCount    1 ;
    sh:maxCount    1 .

[YoucTagh]

According to the links you provided the range of sh:property is not sh:NodeShape but rather sh:PropertyShape

sh:property
    a rdf:Property ;
    rdfs:label "property"@en ;
    rdfs:comment "Links a shape to its property shapes."@en ;
    rdfs:domain sh:Shape ;
    rdfs:range sh:PropertyShape ;
    rdfs:isDefinedBy sh: .

According to the definition, yes, only one value is possible. But additional sh:property(s) can be used when needed.

If there are any subtle differences, I am afraid I am not aware of them.

In this case, if it is also possible to use sh:PropertyShape to specify a description of an expected behaviour execution, should the range of :signifies be changed?

[danaivach]

Sorry, I meant that the domain of sh:property is sh:NodeShape. However, this checks out with the SHACL class diagram, but not the SHACL Ontology which sets the domain of sh:property to sh:Shape. This seems to be intentional based on https://github.com/w3c/data-shapes/issues/122 to keep sh:property generic through symmetry, even if it's unclear whether that is "relevant (or even helpful) in practice".

In this case, I will suggest to update the range of hmas:signifies from sh:NodeShape to sh:Shape. Thanks @YoucTagh for the investigation!

[YoucTagh]

Thank you @danaivach for your quick reaction and great feedback.

[FabienGandon]

One possibility discussed at heartbeat meeting 24/10/2023 is to remove the range of :signifies and leave it open to cover several possible usages including instances of :NodeShape or just URIs identifying well-known specifications.

[danaivach]

In addition to the proposal mentioned by @FabienGandon, the Recommendations section within the scenario on the Discovery of Behavior Specification could be extended to explicitly state that the use of SHACL shapes in the scenario represents a specific implementation choice.

[YoucTagh]

@FabienGandon, @danaivach this option also addresses the issue.

[smnmyr]

I support this (i.e., the removal of the range of :signifies together with the extension of the scenario description) but in addition propose that the comment of :signifies is then extended to reflect that "For instance, SHACL shapes (i.e., sh:Shape) can be used to specify descriptions of expected behavior executions". My point is that I don't want' to make the interactions ontology seem detached from practical deployments.

[FabienGandon]

this removal of the range is now addressed in PR #186 ; @danaivach you may want to open an issue for the extension of the scenario description