Warning:
This wiki has been archived and is now read-only.
CRFO1
This is a formal objection to the decision of the RDF Data Shapes working group to close ISSUE-139 by making node shapes ill-formed if they use any of sh:minCount, sh:maxCount, sh:uniqueLang, sh:lessThan, sh:lessThanOrEquals, or sh:qualifiedValueShape.
Submitted by: Peter Patel-Schneider
Description of the issue
With this resolution node shapes and property shapes have different features. Peter believes that this difference complicates the language, making it harder to explain to users and harder to machine-generate. And because the language is more complex implementations become more complex and testing becomes more complex.
Peter is further concerned that removing these node shapes from the language may cause a drop in expressive power. He can't think of any expressivity loss in RDF per se. However, if generalized RDF (allowing literals as subjects) is considered, then there would be expressivity loss. While SHACL is only defined for RDF itself, literals as subjects has come up as a possibility for future versions of RDF.
Suitable definitions exist for node shapes that use any of the above properties.
Relevant information
Meeting minutes for the meeting that resolved issue-139
The most recent RDF WG has considered the possibility of allowing subjects to be literals and rejected it. Some background
There are no known plans for chartering another RDF WG.
Original e-mail with the objection Note that the description is no longer accurate as the WG since then made a change to allow sh:equals, sh:disjoint for node shapes.
Response: No one has been able to identify any examples of remaining expressivity loss in RDF. Even if such examples were to exist, users still have SHACL-SPARQL to express almost arbitrary scenarios. The expressivity loss for the generalized RDF has been addressed by the WG by declaring the syntax rules that disallow the use of sh:lessThan and sh:lessThanOrEqual for shape nodes to be at risk.
Furthermore, the WG disagrees with the claim that the language became more complicated and harder to explain. We believe the opposite is true: it would be very hard to explain nonsensical syntax structures to users, a first time or a casual user is very likely to misinterpret the syntax and create incorrect shapes leading to a disappointment with the language and belief that it doesn't work as expected, yet there is actual cost in implementing these cases (e.g. some of them have different SPARQL queries behind them), plus we would need to provide test cases etc. So keeping the nonsensical cases would actually drive up the costs for the WG, for users and implementers.
