Try the test viewer.
- Test schemas in ShExC (
.shex), ShExJ (.json) and sometimes SHACL (.shacl).
The ShExC and ShExJ files with the same stem name are equivalent. A ShExC syntax test consists of these steps:
- parse the ShExC version of the document with some base URI.
- parse the ShExJ, as JSON; evaluate the values of the following as relative IRIs:
- values of the
start,inclusion,predicate, anddatatypeproperties. - shape names (keys in the
shapesobject). - terms in
valuesproperties.
- values of the
- ensure that no
ValueAndorValueOrexpression containsValueAndorValueOrexpressions in the list ofvalueExprs. - the two parsed products should be equivalent, with blank node substitution.
These tests violate the ShEx2 grammar.
These tests should raise errors when parsed, noting the rule about nested ValueAnd and ValueOr expressions.
- Validation tests in a manifest (Turtle -
manifest.ttl, ShExJ (obselete primer) -manifest.json). - Input data in Turtle (
.ttl). - Validation returns a ShapeMap capturing which node/shape pairs conform. The expected conformance or non-conformance is captured in the test format as a
ValidationTestorValidationFailure.
A ShEx validator is logic-conformant when it returns success for the tests of type ValidationTest and failure for the tests of type ValidationFailure.
A ShEx validator is result-conformant (experimental) when it executes as ValidationTest and produces the same result structure as produced by this procedure:
- parse the result file as JSON.
- parse the ShExJ, as JSON; evaluate the values of the following as relative IRIs:
- values of the
node,shape,subject,predicate, andobjectproperties.
- values of the
- the two parsed products should be equivalent, with blank node substitution.
A ShEx validator is
error-conformant(even more experimental) when it executes aValidationFailureand produces the same result structure as produced by the procedure above.
One frequently wants to ask "does the test suite include X".
One way to test that is to guess by the relatively formulaic filenames and test names in validation/manifest.
Another is to "grep" through the JSON representations of the queries for something with the appropriate structure, e.g. using jq to EachOfs that include a pattern with a min cardinality of 0:
(for f in schemas/*.json; do
jq -e '.[]|..|objects|select(.type=="EachOf").expressions[]|select(.min==0)' $f > /dev/null &&
echo $f;
done
)
which yields the files which include this pattern:
schemas/1val1IRIREFExtra1Or.json
schemas/3circularRef1.json
schemas/kitchenSink.json
- Validation tests that are useful across implementations but are not attributable to the ShEx specification: error-repair recipes (
sht:Repair) and feasibility localization / structured error reporting (sht:Feasibility). - Same manifest layout as
validation(manifest.ttl,manifest.jsonld) and the same.ttldata convention; the schemas live inschemas-contrib/as ShExC only (no ShExJ/ShExR trio, no representation tests). - Entries carry only
ValidationTest/ValidationFailureplus traits. There are no reference results, so a validator can be checked for logic-conformance here but not result-conformance, and a conformant implementation is not required to run them at all.
Grammars for the three renderings of a ShEx schema, and the pieces that relate them:
ShExJ.jsg— ShExJ, as a JSON Schema Grammar.ShExR.shex— ShExR: the ShEx schema that RDF renderings of ShEx schemas are validated against. Hand-maintained, and the source forShExR.ttlandShExR.ntriples, whichbin/mkShExR.jsderives andnpm testkeeps in sync.ShExJ-context.jsonld— the JSON-LD context that turns ShExJ into ShExR. Generated fromvocab/vocab.csv, which is also the source of https://www.w3.org/ns/shex.syntax-deltas.html— where ShExC, ShExJ and ShExR disagree about what a schema may say, with the evidence for each. Notably, ShExR admits aShapeDeclasstartwhere neither of the others can express one.
