v1.3.0 — Authoring checks, the manifest, and the fixture repo

Check authoring, the remote-endpoint manifest, and the fixture repository that found half the defects in the last two releases — now public and linked.

📄 SemOps-Manual-v1.3.0-A4.pdf — 92 pages, A4
📓 SemOps-Manual-v1.3.0-notebooks.zip — the three runnable notebooks

Writing your own checks (Chapter 8)

The manual showed a working SPARQL check and left the contract implicit. Now stated:

• The four properties a CONSTRUCT must emit — sh:resultSeverity, sh:focusNode, sh:resultMessage, sh:sourceConstraintComponent. Without the last, a finding cannot be attributed.
• The SHACL half, not previously covered at all — most registry checks exist in both formulations, which is what makes --engine native+sparql corroborate rather than merely combine.
• sh:severity goes on the shape, never inside sh:sparql. Some processors read it there and others substitute Violation, so the same shape yields different severities under different engines. If both formulations exist they must also agree on sh:resultPath and sh:value, or one finding arrives under two dedup keys and is reported twice.
• Binding several values on one result is fine and often the honest thing — they are sorted and joined. An arbitrary single pick was what made finding counts wander.
• Prove the check fires. A check that matches nothing looks exactly like a clean ontology, and the suite has shipped four of them.

The remote manifest (Chapter 13)

consistency-remote needs a manifest, and the manual showed a Python snippet without ever showing the JSON a reader actually writes. Now:

• The JSON, with a field table marking the two optional fields and the two that apply only to data graphs.
• How to discover your graph URIs — the manifest must use the store's own URIs, and a trailing-slash mismatch is the usual reason a three-way check reports nothing.
• A verified trap: role is not validated. A manifest saying "triplified-data" with a hyphen loads without complaint, contributes zero data bindings, and the run completes successfully having compared nothing. Same silent-zero shape as the --own-namespace near-miss; same defence — confirm it can fail before trusting that it passed.

The fixture repository is public

consolidated-ontology-quality-suite-python-testing — thirteen deliberately broken OWL2 ontologies and a harness asserting which registry checks each must trigger. Chapter 9 §9.8 described its practice; it now links the fixtures and harness so the tables can be read against the files.

§9.8 also gained the harness's fuller design:

Assertion	Guards against
Expected ids fired	A check silently ceasing to work
Forbidden ids did not fire	False positives — a check becoming over-eager
Severity ceiling	A finding quietly escalating
Optional-reasoner ids, only when it ran	A flaky optional dependency turning into a red build

Plus two traps — test against the library rather than scraping report.html, and a non-zero exit from a deliberately-broken fixture is the fixture working — and the fact that the stage decides which checks can fire at all. REA-010/011/012 fire only from ontology, and only with --profile, so a team running checks and concluding their ontology is EL-clean has not tested that.

Output artefacts the manual had been under-reporting

A run writes rather more than report.html and full_results.csv: also summary_by_check.md, summary_by_category.md, top_offenders.md, features/, plots/ and cucumber.json — each check a scenario with Given/Then steps and a pass/fail status, which most CI systems render natively. Chapter 8 now explains the cucumber_feature/cucumber_scenario registry fields that populate it.

Also

• Install pointer moved to the extension's latest release rather than the repository tree, which carries seven older builds alongside the current one.
• All 26 external links verified HTTP 200.

Full changelog: v1.2.0...v1.3.0