Meta-validation file (shsh)

[wouterbeek]

The SHACL standard links to a file (shsh) that can be used to validate SHACL files with. The file makes assumptions about which syntax is used to encode the validated SHACL file with. As such, it makes assumptions about term types (blank nodes / IRIs / literals) that are not substantive.

Because of this, the shsh file can be used to validate some but not all SHACL files. Specifically, SHACL files that legitimately choose to use IRIs for intermediate terms in RDF lists do not validate correctly, because the shsh file assumes that these terms are blank nodes.

Specifically, the shsh file cannot be used to validate SHACL files that use well-known IRIs as blank node replacements. (The approach to consistently replace blank nodes by well-known IRIs is part of the RDF 1.1 standard.)

Expected

I expect the shsh file to distinguish between different kinds of property paths based on substantive/structural properties and not based on non-substantive/syntactic properties.

Example

An example of the use of syntactic constraints by the current shsh file is shown in the following snippet:

shsh:PathNodeShape
  sh:xone
    ( # 2.3.1.1: Predicate path
      [ sh:nodeKind sh:IRI ]
      # 2.3.1.2: Sequence path
      [ sh:nodeKind sh:BlankNode;
        sh:node shsh:PathListWithAtLeast2Members ]
      ... ).

^ Notice that predicate paths are assumed to be represented by IRIs. This assumption is valid: while blank nodes can be used to denote properties, such property-denoting blank nodes cannot appear in the predicate position of a triple in regular RDF 1.1 syntax.

^ Notice that sequence paths are assumed to be represented by blank nodes. This assumption is not valid: a sequence is represented by an RDF 1.1 list. The only syntactic restriction on intermediated terms in an RDF list is that they are subject terms (blank nodes or IRIs).

[wouterbeek]

Issue #121 touches on this issue and even includes an alternative to the shsh file that fixes the here observed shortcoming in some but not all cases.

[HolgerKnublauch]

I think the shsh graph should become its own document instead of being an appendix to SHACL. Then the future maintainers of that graph could implement the suggested changes. It was really just rushed through at the very end of the data shapes WG and would benefit from a more comprehensive solution.

I'll mark this as SHACL 1.1 to see if we can split this off from the main spec.