Request: All SHACL predicates should be declared as `rdf:Property`s

[ajnelson-nist]

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.

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. A SHACL OWL "profile" to aid ontologies mixing SHACL and OWL #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:Propertys 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 ...

data-shapes/shacl12-vocabularies/shacl.ttl

Lines 1385 to 1410 in 6278930

	sh:SPARQLExprExpression
	a rdfs:Class ;
	rdfs:label "SPARQL expr expression"@en ;
	rdfs:comment "The class of node expressions based on SPARQL expressions (sh:sparqlExpr)."@en ;
	rdfs:subClassOf sh:NamedParameterExpression ;
	rdfs:subClassOf sh:SPARQLExecutable ;
	sh:parameter sh:SPARQLExprExpression-sparqlExpr ;
	sh:parameter sh:SPARQLExprExpression-prefixes ;
	rdfs:isDefinedBy sh: .
	sh:SPARQLExprExpression-sparqlExpr
	a sh:Parameter ;
	sh:path sh:sparqlExpr ;
	sh:name "SPARQL expr"@en ;
	sh:description "The SPARQL expression that is executed during evaluation of this node expression."@en ;
	sh:keyParameter true ;
	sh:datatype xsd:string ;
	rdfs:isDefinedBy sh: .
	sh:SPARQLExprExpression-prefixes
	a sh:Parameter ;
	sh:path sh:prefixes ;
	sh:name "prefixes"@en ;
	sh:description "The prefixes that shall be applied before parsing the SPARQL query that gets derived from the sh:sparqlExpr expression. The object should define those prefixes using sh:declare."@en ;
	sh:nodeKind sh:BlankNodeOrIRI ;
	rdfs:isDefinedBy sh: .

... 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):

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.)

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.

[HolgerKnublauch]

I have no strong opinion, but for consistency I have created a PR to add this missing global property.