SHACLC: support SPARQL

[VladimirAlexiev]

Version

5.2.0

Feature

Get https://github.com/Sveino/Inst4CIM-KG/tree/develop/source/CGMES/v3.0/SHACL/ttl (these are complex electrical CIM/CGMES shapes).

Try shacl.bat -out=c on two of the files and you get these messages:

• "sh:target not supported in compact syntax" (happens on 61970-301_Equipment-AP-Con-Complex-SHACL_v3-0-0.ttl)
• "SparqlConstraint Not supported in compact syntax" (happens on 61970-302_Dynamics-AP-Con-Complex-SHACL_v3-0-0.ttl, at end of output)

Are you interested in contributing a solution yourself?

None

[rvesse]

It's not clear that everything in SHACL Core is supported in the compact syntax, it specifically says at https://w3c.github.io/shacl/shacl-compact-syntax/:

This document defines the Compact Syntax for a subset of SHACL Core. The Compact Syntax offers an alternative notation to the general RDF-based notations for SHACL, aimed at human editors and readers.

So you might be asking for something that intentionally isn't in the SHACL Compact Syntax

[afs]

@VladimirAlexiev - Are you claiming something should be there and is missing? Does any other system implement the extensions?

Please provide a complete minimal example. Please show the expected SHACL-C.

As @rvesse says - SHACL-C does not have complete coverage of SHACL-Core and does not cover SHACL-SPARQL at all. sh:target isn't in SHACL - it's in SHACL-AF.

[VladimirAlexiev]

You're both right: this is a feature request not a bug report. Standardising SPARQL aspects in SHACLC is one of the ideas in the 1.2 CG (but I see no activity there).

So maybe posting this request is premature. But Jena has the best SHACLC support, so I thought I'd post it.

[afs]

With the WG starting up, I don't think Jena should add ad-hoc extension features yet because the WG may choose to go in a different direction.

AF features may not go though unchanged. The scope of SHACL-C isn't clear - will it cover all areas of SHACL? - and it may need some rethinking of SHACL-C for qualified constraints, SPARQL constraints, and whatever is coming/covered in rules/UI declaration - anything which is more than one property. I'm not convinced the current grammar can be simply extend to all SHACL features;

When the WG has a probable direction, an experimental form of SHACL-C could be done to get real-world feedback.