consider using SHACL Compact

[VladimirAlexiev]

SHACL Compact (SHACLC) is a dedicated SHACL syntax that's a lot easier to write and understand than SHACL.
JENA includes a shacl command-line tool that can work with SHACLC.

Eg let's try it on a shape:

cd Inst4CIM-KG\source\CGMES\v3.0\SHACL\ttl
shacl.bat p -out=c 61968-13_GeographicalLocation-AP-Con-Complex-SHACL_v3-0-0.ttl

shape gl13:CoordinateSystem -> cim:CoordinateSystem {                                     
    severity=sh:Info .                                                                    
    message="The value is different from the default value: urn:ogc:def:crs:EPSG::4326." .
    cim:CoordinateSystem.crsUrn in=[ "urn:ogc:def:crs:EPSG::4326" ] .                     
}                                                                                         

The result is a lot more understandable than the original RDF
(see https://github.com/VladimirAlexiev/shaclc-mode for more examples and motivation):

gl13:CoordinateSystem
        a               sh:NodeShape ;
        sh:property     gl13:CoordinateSystem.crsUrn-epsg ;
        sh:targetClass  cim:CoordinateSystem .

gl13:CoordinateSystem.crsUrn-epsg
        a               sh:PropertyShape ;
        sh:in           ( "urn:ogc:def:crs:EPSG::4326" ) ;
        sh:description  "CoordinateSystem.crsUrn: If not specified elsewhere, the CoordinateSystem.crsUrn uses WGS84 (latitude, longitude), i.e. urn:ogc:def:crs:EPSG::4326." ;
        sh:name         "C:13:GL:CoordinateSystem.crsUrn:epsg" ;
        sh:message      "The value is different from the default value: urn:ogc:def:crs:EPSG::4326." ;
        sh:path         cim:CoordinateSystem.crsUrn ;
        sh:group        gl13:GL13 ;
        sh:order        0 ;
        sh:severity     sh:Info .

It has limitations:

• SHACLC: add name, description, group, order, defaultValue apache/jena#2853
  (SHACLC allows Turtle content, so in theory it can accommodate them.)
• SHACLC mixes up multiple PropertyShapes of the same NodeShape apache/jena#2851
• sh:target not supported in compact syntax (happens on 61970-301_Equipment-AP-Con-Complex-SHACL_v3-0-0.ttl): SHACLC: support SPARQL apache/jena#2852
• SparqlConstraint Not supported in compact syntax (happens on 61970-302_Dynamics-AP-Con-Complex-SHACL_v3-0-0.ttl): SHACLC: support SPARQL apache/jena#2852

The SHACL 1.2 CG is working on standardizing SHACLC and adding more features (I'm a member).

[Sveino]

I think this is something we can consider when we are talking about editing the SHACL rules. I assume we can do SHACLC -> SHACL so that "all" SHACL engine can execute the SHACL.

[afs]

(SHACLC allows Turtle content, so in theory it can accommodate them.)

Some implementations might but the community group note does not define mixing SHACL-C and Turtle.

It has limitations:

SHACL-C (09 January 2018) does not cover all of the SHACL-Core and none of SHACL-SPARQL; nor does it cover SHACL-AF.

It is useful for writing SHACL compactly. That could be used via import into a Turtle document with full, standard SHACL.

I assume we can do SHACLC -> SHACL

Yes. SHACL-C is defined by the SHACL RDF triples the parsing process outputs.

[bartkl]

My guts tell me this is only worth supporting if there are very convincing benefits, especially given that SHACL-C is not a mature syntax and has very limited tooling and library support.

On top of that: many SHACL users who come into touch with parts that are written in SHACL-C might not be familiar with it, which could cause confusion or at least some frustration.

However, if there are problems we currently face with the RDF-based syntaxes, and SHACL-C solves that, then it becomes interesting to consider it.

(By the way: I do agree SHACL-C is a nice syntax, especially for describing structures in vein of ShEx and LinkML, that's not a disagreement).