Reuse of SHACL predicates for profiles

[ashleysommer]

As per the docs page for building profiles, https://github.com/RDFLib/prez/blob/main/docs/development.md
the multiple property paths can be defined for a profile to use, by apply a value to sh:path that is a sh:union.

<ex:profile> a prof:Profile, sh:NodeShape ; 
  sh:property [
    sh:path (
        sh:union (
          dcterms:publisher
          reg:status
          ( prov:qualifiedDerivation prov:hadRole )
          ( prov:qualifiedDerivation prov:entity )
        )
      )
    ]
.

It is unclear whether the usage of these predicates in the profile is designed to mimic the use of SHACL Node Expressions (from the SHACL-AF spec), or the SHACL Path Expressions (from the SHACL base spec). sh:path is used in both features, but sh:union is only used in Node Expressions. It seems to be a hybrid of both.

The use of sh:path within the profile's top-level sh:property predicate (and given the Profile itself is a NodeShape) it appears that profiles are following the pattern of SHACL Path expressions, however the use of sh:union is not allowed in Path expressions.

The purpose of a profile is to define the paths that need to be queried from the graph, to place into the result subgraph. This is similar to the way Nodes are expressed in the context of Node Expressions. The use of union to join sets of nodes from different paths supports this. However, the use of paths within the sh:union list is not specified correctly according to SH Node Expressions.

If the intention is for the profile to say "Give me the set of nodes that is the result of these Node Expressions", it should look like this:

<ex:profile> a prof:Profile, sh:NodeShape ; 
  sh:nodes [
    sh:union (
      [ sh:path dcterms:publisher ]
      [ sh:path reg:status ]
      [ sh:path ( prov:qualifiedDerivation prov:hadRole ) ]
      [ sh:path ( prov:qualifiedDerivation prov:entity ) ]
    )
   )
 ]
.

Otherwise, if the intention is to say "Give me a resulting data shape to corresponds to this property shape", it would look something like this:

<ex:profile> a prof:Profile, sh:NodeShape ; 
  sh:property [
    sh:path (
        [ 
          sh:alternativePath (
            dcterms:publisher
            reg:status
            ( prov:qualifiedDerivation prov:hadRole )
            ( prov:qualifiedDerivation prov:entity )
          )
        ]
      )
    ]
.

However I don't know if sh:alternativePath is actually correct in this case, because it implies the Node at the end of each of the paths would share a varname (eg, multiple paths to get a value for a single variable).
Maybe if we think of the unnamed endpoint variable as ?o and each alternative property path is ?p, and every alternate expresses ?focus ?p ?o then that matches the behaviour of the current sh:union implemenation in profiles anyway.