[data-shapes] Request: All SHACL predicates should be declared as `rdf:Property`s (#349)

ajnelson-nist has just created a new issue for https://github.com/w3c/data-shapes:

== Request: All SHACL predicates should be declared as `rdf:Property`s ==
Issue #315 (PR #340) introduced `sh:sparqlExpr` into the SHACL definition graph, but did not introduce it as a `rdf:Property`.  @HolgerKnublauch's response to me asking whether this was intentional is [here](https://github.com/w3c/data-shapes/pull/340#discussion_r2032509977).

I'd like to request that any predicate that's introduced be explicitly declared as an `rdf:Property`.  There are a few reasons for this, which I'll use `sh:sparqlExpr` to describe because it's currently the one instance of this new implementation pattern:

* Documentation-generating engines may rely on declarations of some "Property" type (whether `rdf:Property` or one of the OWL property classes).  Without a type-declaration and `rdfs:comment`, `sh:sparqlExpr` could be perceived as incompletely defined.
* "Strict" parsers may require any predicate used in the graph be "defined," e.g., having a `rdf:type`.  I've described this "Strict" testing pattern elsewhere, such as the long thread in 212 starting [here](https://github.com/w3c/data-shapes/issues/212#issuecomment-2682113541).  #246 provides OWL-specific recognition of SHACL concepts.
* The purpose and behavior of predicates should be explained in SHACL's base modeling language, RDFS, even if full usage is described in SHACL as was done with `sh:sparqlExpr`.  On what classes should `sh:sparqlExpr` be used, and to what classes should it refer?
   - Defining `sh:sparqlExpr` as a property will help with SHACL-SHACL updates to confirm its usage pattern(s).
* A policy of always defining `rdf:Property`s also helps us catch when we genuinely forget to define a property.

How I believe `sh:sparqlExpr` is currently the only property following this "semi-defined" pattern: I took today's state of `shacl.ttl`, highlighting here the parts mentioning `sh:sparqlExpr` ...

https://github.com/w3c/data-shapes/blob/62789304a0e161fd4f0dcd5b954237479f6bf6be/shacl12-vocabularies/shacl.ttl#L1385-L1410

... and checked the entire `shacl.ttl` with this shape (using just SHACL 1.0 concepts and the "disjunctive form of implication" style described in #341):

```turtle
ex:path-objects-when-iri-shape
 a sh:NodeShape ;
 sh:property [
  sh:path sh:path ;
  sh:or (
   [
    sh:not [
     sh:nodeKind sh:IRI ;
    ] ;
   ]
   [
    sh:or (
     [
      sh:in (
       rdf:first
       rdf:rest
      ) ;
     ]
     [
      sh:class rdf:Property ;
     ]
    ) ;
   ]
  ) ;
 ] ;
 sh:targetSubjectsOf sh:path ;
 .
```

(That shape could probably be more complete in its review, in light of the branches taken in [`shsh:PathShape`](https://github.com/w3c/data-shapes/blob/62789304a0e161fd4f0dcd5b954237479f6bf6be/shacl12-vocabularies/shacl-shacl.ttl#L336C1-L336C15).)

If this repository had CI, I would also suggest adding this shape to the CI, but to avoid the technology commitment issues I'd noted over on #246, I plan to just run this check in a separate monitoring repository---if the WG agrees on `rdf:Property` definition policy.


Please view or discuss this issue at https://github.com/w3c/data-shapes/issues/349 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 8 April 2025 17:17:35 UTC