Hi Chris,
Oddly, sh:group/sh:order aren't in SHACLC - they look like they got
overlooked as they fit is quite naturally into the grammar. Maybe the WG
focus was validation and these aren't "validation".
dash:editor, and your own annotations:
There was a brief discussion on the SHACL CG list about allowing RDF in
SHACL-C. I didn't see a conclusion.
It can be done, in rather ungraceful way, with IMPORTS but you have ask
"why bother" if its splitting the shapes into compact and RDF parts.
Similarly, if there is an RDF block in a SHACL-C file: at least
everything is in one file but having to wire two sections of the file by
using the shape URIs is again, to me, kind of contrary to the compact,
ease of use, aspect of SHACL-C.
It looks like it would nearly work with inline Turtle inside the compact
shape with some parser contortions; property + the compact
class/datatype constraint would be ambiguous, but otherwise I think it
could be done because most things are using keywords. Another way would
be syntax to say "here be Turtle, same subject as the node/property a
this point".
All options that allow RDF are assuming the shape writer understands the
compact syntax as a specialised way to write some RDF and also what the
RDF structure looks like if they are going to add RDF into it. So it all
may be a step too far.
What I'd like in a SHACL-C file is being able to have RDFS
subclass/subproperty declarations.
Andy
On 17/07/2020 17:27, Chris Tomlinson wrote:
Hi Andy,
I haven’t looked into SHACLC. We do use features such as sh:group, sh:order,
dash:editor and so on; as well as a few annotations of our own that are
relevant to editing and some validation controls. Off-hand it isn’t clear how
to use SHACLC and weave these other features in.
The notation is nicely compact and if there’s an integration approach for
additional features I’ll look deeper.
Thanks,
Chris
