bitwrap ontology

A music-genre ontology for the bitwrap suite: the genres a Petri-net beat sequencer can generate (tempo, scale, groove, Euclidean drum rhythms, instruments, chord progressions), the song structures and section profiles it arranges them into, and the engine concepts behind it (rhythm rings, Markov melody, control nets), linked to the pflow ontology. Namespace https://ontology.bitwrap.io/ns#, version 0.1.0, released 2026-11-11. Draft scope: 19 genres.

Explore

Graph explorer: expand a term's neighbors, walk the class hierarchy, find a path between two terms and filter by edge type. It runs in your browser from pack.json, with no queries sent anywhere.

Start with a genre: techno, jazz, drum and bass; or a concept: Bjorklund, Markov melody, four on the floor.

Documents

• /ns: content-negotiated (Turtle, JSON-LD, N-Triples, RDF/XML)
• ns.ttl · ns.jsonld · ns.nt · ns.rdf
• manifest.json: a hash for every file

These documents are the asserted ontology.

Query

• /sparql: SPARQL 1.1 protocol, read-only. SELECT, ASK, CONSTRUCT and DESCRIBE; results capped at 1000 rows and 5 seconds; rate limited.
• /mcp: the same data as an MCP server (Streamable HTTP, read-only tools).
• /genre/<slug>, /scale/<slug>, /groove/<slug>, /section/<slug>, /instrument/<slug>, /concept/<slug> and more: one term, as Turtle, N-Triples or HTML.

Queries run over the materialized graph (6434 triples): the asserted ontology plus the RDFS/OWL-RL consequences, so subclass closure is already present.

curl -H 'Accept: application/sparql-results+json' \
  --data-urlencode 'query=SELECT ?c WHERE { ?c a <http://www.w3.org/2002/07/owl#Class> } LIMIT 5' \
  https://ontology.bitwrap.io/sparql

License

The ontology is dedicated to the public domain under CC0 1.0 Universal: use it for anything, no attribution required. This covers the ontology data, not the source code of the projects it describes. The numbers come from the MIT-licensed beats-bitwrap-io generator; genre links are to Wikidata (CC0).

Download

• bitwrap-ontology-0.1.0.tar: the whole release (ontology in four formats, pack, certificate, manifest, verifier)
• pack.json: the portable pack (graph + certificate)
• SHA256SUMS: one line per file, for sha256sum -c SHA256SUMS
• verify-pack.py: recomputes the pack's digests with only the Python standard library

How the checksums are computed

• SHA256SUMS: plain SHA-256 of each file's bytes, hash␣␣path, paths relative to the release folder. The tar is deterministic (sorted members, zero timestamps, owner 0, uncompressed), so its digest is reproducible.
• manifest.json → files: the same per-file SHA-256 for every file in the build except manifest.json itself.
• Pack sha256: SHA-256 of the pack's graph text, which is sorted N-Triples, UTF-8, one triple per line.
• Pack content_sha256 (f60849dc02b67ca415a64c9c71dd5147e8b0ffc25ff44ad9efcf590638b5d085): SHA-256 over a length-prefixed framing of "oo-pack-content/1\n", the graph, then the certificate (format, claimed profile, counts, and every file's name and body in sorted order). Each length is 8 bytes, little-endian. It binds the proof to the graph it travels with, so a certificate sound over someone else's assertions cannot be swapped in.
• cert/asserted.sha256: SHA-256 of cert/asserted.tsv, the assertions the certificate rests on.

python3 -I verify-pack.py pack.json     # exit 0 = every digest above reproduces

Matching digests prove the files are intact and belong together, not that the ontology is correct. The certificate in release/cert/ can be re-checked with oo-cert without trusting this server. It covers: RDFS rules only (rdfs9, rdfs11, scm-*); OWL axioms are not covered.