RDF vocabularies and Verifiable Credential payload schemas used by the Axone protocol.
The Axone ontology
This repository defines RDF vocabularies and Verifiable Credential payload schemas used by the Axone protocol.
It provides the semantic artefacts required to name, describe, and constrain credential payloads in Axone.
Verifiable Credentials use JSON-LD contexts to map credential terms to machine-readable identifiers. Axone defines these terms with RDF-compatible vocabularies so that credential payloads can be interpreted consistently across implementations.
Axone uses RDF Schema to define reusable semantic terms. It is built on top of the Resource Description Framework, keeping the model lightweight while remaining compatible with RDF and JSON-LD tooling.
This repository defines semantic payload schemas for VCs.
These schemas describe the content carried by credentials. They are designed to remain generic and extensible. A schema should be introduced only when it captures a stable payload structure that cannot be expressed cleanly through an existing one.
Axone distinguishes between informational credentials and governance-relevant credentials.
Informational credentials carry descriptive material. They help humans, wallets, explorers, indexers, and agents discover or understand an identifiable subject. They are not intended to provide material that can directly support a governance decision.
Governance-relevant credentials carry structured information that may be evaluated by a governance process. They may express facts, rights, attestations, authorisations, or other statements with normative or evidentiary value.
Core VC schemas live under the schema/core sub-domain.
Some credentials are descriptive. They help identify, discover, and display a subject.
Other credentials are governance-relevant. They carry structured statements that may be evaluated by protocol components.
Axone credentials are not expected to carry embedded off-chain proofs when submitted to the protocol.
Authorship is established by the account that submits the credential. The transaction signer controls the abstract account that emits the credential. The credential payload therefore carries semantics; the protocol submission carries authorship.
When an Axone account is represented as a DID, examples use the did:pkh method grounded in the on-chain abstract account address, for example did:pkh:cosmos:<chain_id>:cosmos1....
In the Axone protocol, the ontology provides the vocabulary used to describe credential payloads.
Credentials may either provide informational metadata or carry governance-relevant material. Informational payloads can be discovered, indexed, and displayed. Governance-relevant payloads can be referenced or evaluated by protocol components according to their own rules.
Domain-specific facts such as licences, compliance status, authority, capability, resource properties, or identity attributes can often be represented through assertion predicates. Dedicated schemas should be introduced only when the structure has a stable and concrete use case that is not cleanly captured by the generic assertion model.
The construction of the semantic model follows a number of steps which are described below:
- Ontology scope definition (1) & knowledge acquisition (2): Identification and definition of key concepts and relationships in the domain of interest and the terms that refer to such concepts, in natural language.
- Ontology specification (3) & conceptualization (4): Formalizing of the elements identified in the previous step in the form of a knowledge representation, using the building blocks of ontologies: classes, attributes, relationships, subsumption.
- Implementation (5): Encoding the semantic model using RDF-compatible formats and JSON-LD contexts.
- Evaluation (6): Association of key concepts and terms with concepts and terms from other vocabularies when relevant.
The repository is structured in a modular way, with each schema representing a specific semantic domain while keeping credential payload schemas generic and extensible.
It contains the active Verifiable Credentials payload schemas used within the Axone protocol. These schemas are deployed as JSON-LD contexts under the schema/core sub-domain. They describe reusable payload semantics, not protocol operations.
Credential schemas should remain generic when possible. Descriptive credentials carry information about identifiable subjects. Governance-relevant credentials carry structured statements with normative or evidentiary value.
The foundational philosophy underpinning the semantic model is grounded in the Open World principle. Knowledge is not static or finite. The model is therefore not confined to a closed set of schemas or terms. It is designed to accommodate new terms and payload structures when they are justified by concrete use cases.
For robust RDF resource management, Axone uses the w3id.org service for persistent URIs. This strategy maintains both URI and content stability, which is required for web-based semantic technologies.
Persistent URI Benefits:
- Durability: w3id.org URIs are designed to be persistent, meaning they are intended to be available for a long duration. This permanence is crucial for maintaining reliable references over time.
- Redirect Capability: The w3id.org service enables redirection, allowing Axone semantic URIs to direct clients to the appropriate resource location as the repository evolves. This feature is particularly useful for versioning.
Axone semantic resources adopt the Semantic Versioning format of MAJOR.MINOR.PATCH. This approach includes incorporating the MAJOR version number into the URI. As a result, the URI structure is:
https://w3id.org/axone/ontology/v<MAJOR>/<path>
Note: by including only the MAJOR version number in the URI, significant updates that could impact compatibility are referenced through a different namespace. MINOR and PATCH updates that do not introduce breaking changes have no impact on the URI, maintaining the stability of the URI for external references.
The ontology is built with GNU make in the reproducible Nix development environment. Install Nix and direnv, then authorize the environment:
direnv allowTo build the ontology, run:
make buildThis will build the axone ontology under the target directory. The files generated have different RDF formats:
./target
├── axone-ontology-<version>.nt
├── axone-ontology-<version>.rdf.xml
├── axone-ontology-<version>.ttl
└── axone-ontology-<version>-bundle.tar.gz
The ontology is tested using Shapes Constraint Language (SHACL). To run the tests, run the following command:
make testThe documentation is generated using the following command:
make docsThis will generate the documentation under the docs directory. Don't forget to commit the generated files.
You can get the list of all available commands by running the following command:
make helpWhich will output the following:
Usage:
make <target>
Targets:
Clean:
clean Clean all generated files
clean-build Clean the .make (build) directory
clean-ontologies Clean the built ontologies
Build:
build Build all the files
build-ontology Build the ontology in all available formats (N-Triples, RDF/XML, JSON-LD)
build-ontology-ttl Build the ontology in Turtle format
build-ontology-nt Build the ontology in N-Triples format
build-ontology-rdfxml Build the ontology in RDF/XML format
build-ontology-jsonld Build the ontology in JSON-LD format
build-examples Build the examples in different formats (N-Quads, JSON-LD)
build-ontology-bundle Build a tarball containing the segments and the ontology in all available formats (N-Triples, RDF/XML, JSON-LD) plus the examples
Format:
format Format with all available formatters
format-ttl Format all Turtle files
Lint:
lint Lint with all available linters
lint-ttl Lint all Turtle files
lint-jsonld Lint all JSON-LD files
Documentation:
docs Generate all available documentation
docs-schemas Generate schemas markdown documentation
Test:
test Run all available tests
test-ontology Test the ontology (use FORCE=1 to ignore markers)
check Check if all required commands are available in the system
version Show the current version
Help:
vars Show relevant variables used in this Makefile
help Show this help.
This Makefile runs in the Nix development environment.
Run direnv allow once, or invoke nix develop.
Contributions are welcome. Please check the following guidelines:
The ontology and related assets (markdown documentation, images, etc.) are licensed under a CC-BY license.
All other code in this repository is licensed under the BSD-3-Clause license.