#212: Added sh:ShapeClass #254
Conversation
Co-authored-by: Andy Seaborne <[email protected]>
shacl12-core/index.html
Outdated
| <div class="def"> | ||
| <div class="def-header">TEXTUAL DEFINITION</div> | ||
| The class <code>sh:ShapeClass</code> is an <code>rdfs:subClassOf</code> of both <code>sh:NodeShape</code> and <code>rdfs:Class</code>. | ||
| <code>sh:ShapeClass</code> has itself as its <code>rdf:type</code>. |
There was a problem hiding this comment.
This is not true.
sh:ShapeClass rdfs:subClassOf rdfs:Class , sh:NodeShape. # true
sh:ShapeClass a rdfs:Class. # true
sh:ShapeClass a sh:NodeShape. # FALSE!
There was a problem hiding this comment.
But the triple sh:ShapeClass rdf:type sh:ShapeClass is explicitly stated in the TTL file:
There was a problem hiding this comment.
In the textual definition, the sentence
sh:ShapeClasshas itself as itsrdf:type.
has two readings: as part of the definition and being an authoritative statement, or as stating a consequence of the first part. Replace the preceeding . with ; and it does make it part of the definition.
The class sh:ShapeClass is an rdfs:subClassOf of both sh:NodeShape and of rdfs:Class; sh:ShapeClass has itself as an rdf:type.
("an rdf:type" - it has unrelated ones as well)
The current 3rd sentence, which is definitely not adding to the definition, and is stating a consequence of "SHACL instance":
If s is a SHACL instance of sh:ShapeClass in a shapes graph SG then the set of SHACL instances of s in a data graph DG is a target from DG for s in SG.
could be moved to after the textual definition box so the definition box is all definition.
There was a problem hiding this comment.
Why should sh:ShapeClass rdf:type sh:ShapeClass be true?
There was a problem hiding this comment.
As I read it - because the definition says it is.
If it is the other reading where sh:ShapeClass rdf:type sh:ShapeClass is an implication, it does not need to be in the definition box. I don't see the implication path that concludes that fact but maybe I've missed it.
There was a problem hiding this comment.
Ok, what about I just remove that sentence? We do not make these assertions explicit in the spec of other things (e.g. we don't say that sh:NodeShape rdf:type rdfs:Class. This information is present in the sh: namespace TTL and that's probably good enough?
There was a problem hiding this comment.
I have removed the offending sentence and made sh:ShapeClass a rdfs:Class in the TTL file as this was not really necessary. I hope this addresses the concern here and will ask for another review
There was a problem hiding this comment.
Are you saying it is a natural conclusion from the rest of SHACL? What path leads to that?
If on the other hand, it is a necessary additional requirement about sh:ShapeClass then it should be in the definition. (i.e the definition should be complete and self-contained without the namespace document.)
Concretely - what requires sh:ShapeClass rdf:type sh:ShapeClass to work?
There was a problem hiding this comment.
what requires sh:ShapeClass rdf:type sh:ShapeClass to work?
Nothing really, so I have taken it out and made it rdfs:Class only. Maybe our messages crossed paths.
I know this issue has not been discussed yet, but I have prepared this branch to implement it in case it gets accepted, and also to illustrate how the process for future changes could/should look like. The PR includes the changes to the HTML text, adds at least one test case and updates the TTL file.