SSTIM
SSTIM Workbench · living knowledge reference
+
Home AI agents: contribute Report a gap or correction Graph Patch Studio Presets Published protocols SPARQL Logbook Settings Ecosystem Stakeholder directory Manual & tutorials About Ontology docs Vocabulary docs
Profile

On-device — notes, patches and your profile are kept in this browser.

Guide 06 / 06

Work with the repository

Run the Workbench, validate examples and contribute reproducibly.

Contributor · maintainer · developerGit + Node + Python

The source repository hosts the formal ontology, developer documentation, reference Workbench, validation clients and MCP adapter. Not all repository data are canonical release artifacts; ontology edits require explicit review and release procedures.

Example 01

Run SSTIM Workbench locally

Study its RDF graph and Patch Studio while iterating on reference software.

  1. Clone the canonical source and install Node dependencies.
  2. Start the dev server and use the local URL printed by Vite. Nothing you change locally alters the official ontology.
bashCopy into your editor / terminal
git clone https://github.com/w3c-cg/sstim.git
cd sstim
npm ci
npm run dev

Example 02

Run the application test and quality checks

Keep UI changes reproducible across the reference Web application.

  1. Run Svelte checks and Vitest; run the static build before publication.
  2. For ontology changes use the repository’s dedicated validation targets and review the release notes.
bashCopy into your editor / terminal
npm run check
npm test
npm run build
# For authorized changes that touch canonical ontology:
make validate

Example 03

Inspect the published vocabulary without guessing

Find where a term is defined, what belongs to its module, and whether an IRI is already used.

  1. Use the generated term index, then the locate-iri.py helper for the precise identifier.
  2. Read the appropriate documentation and module manifest before proposing a new term.
bashCopy into your editor / terminal
python3 scripts/locate-iri.py sstim:composedOfTrack
# Also consult docs/ontology/TERM_INDEX.md

Example 04

Check real interoperability with a release-pinned example

Confirm that a new example fits the profile it claims without silently using undeclared terms.

  1. Start from examples/01-stimulus-core.ttl and make your own copy.
  2. Run the example checker and the Python client validator. The example checker also includes negative fixtures that must fail for the right reasons.
bashCopy into your editor / terminal
make examples-check
python3 -m pip install sstim
sstim validate examples/01-stimulus-core.ttl --profile core --version 0.19.0

Example 05

Contribute without overwriting the canonical vocabulary

Propose edits to definitions, external alignments or new terms through human review.

  1. Read CONTRIBUTING.md and CLAUDE.md before changing code or ontology.
  2. Use the Contribution Bridge for terminology proposals; submit source changes through the established review process.
  3. Keep original historical BSC Lab IRIs and citations intact rather than mechanically renaming them.
Contribution Bridge CONTRIBUTING.md

Example 06

Understand dual remote publication (maintainers only)

Preserve identical commit histories between the legacy origin and canonical W3C repository.

  1. Public contributors normally work through issues and PRs.
  2. Maintainers with both remotes configured use make push after review; do not push independently generated commits to both remotes.
  3. Do not edit static/ontology files merely to update a manual, package README or developer example.
bashCopy into your editor / terminal
# Authorized maintainers only, from a fully validated checkout:
make push

Further reference

Repository source Contribution guidance Adopting SSTIM