The ontology used @axone to describe knowledge data, services and processes in the Axone protocol.
The Axone ontology
This ontology defines and specifies the various schemas and vocabularies employed in the Axone protocol, utilizing a formal and standardized methodology.
Essentially, the Axone ontology is structured around two primary dimensions.
An Ontology, as defined by the W3C, is a foundational and broad concept of the Semantic Web. It connects various data elements, providing a conceptual semantic framework about them. Typically, an ontology consists of concepts, relationships, properties, axioms, and instances.
The knowledge representation language chosen for Axone is RDF Schema, and SKOS for thesauri, both of which are built on top of the framework Resource Description Framework.
In this framework, the Axone ontology is dedicated to constructing a semantic network that encapsulates various resources, such as Zones, Digital Resources, Digital Services, to name a few. It focuses on semantically defining these entities and elucidating the interconnections they share.
This particular aspect of the ontology addresses the representation of information related to resources using Verifiable Credentials (VCs). VCs play a critical role in asserting properties about subjects, which, within the framework of this ontology, are considered resources. These resources can be varied, like Zones, Digital Resources or Digital Services.
In the context of the Axone ontology, each resource is uniquely identified by Decentralized Identifiers (DIDs). DIDs are a key component in the decentralized identity ecosystem, providing a mechanism for establishing and verifying the identity of a resource without centralized control. This identification system is integral to the structure and function of the ontology, ensuring that each resource is distinct, easily identifiable and easily traceable.
The use of VCs in this framework brings several advantages. Firstly, VCs allow for the assertion of specific properties about a resource. This means that each resource can carry with it a set of verifiable information, detailing its characteristics, and any other relevant attributes. Secondly, because VCs are inherently designed to be tamper-evident and cryptographically secure, they enhance the reliability and transparency of the information they convey, ensuring integrity and clarity in both off-chain and on-chain contexts.
This approach results in a more reliable and robust system, where the data about resources, backed by the claims from Verifiable Credentials, can be shared and used with confidence. These claims, being trusted sources of information, are instrumental for decision-making in established on-chain Governance rules.
In the Axone protocol, the ontology is crucial, especially as key data is introduced to the blockchain in the form of Verifiable Presentations (VPs). VPs, often a selected subset of VCs with a verifiable chain, serve as the medium for conveying knowledge to the blockchain.
This process is integral in ensuring that the semantics of nearly all transactions, which describe the Dataverse on the blockchain, are captured within this ontology framework. As a result, significant activities within the Axone ecosystem βsuch as the establishment of a Zone, the announcement of a Digital Service, or the description of a Datasetβ are communicated through these Verifiable Presentations.
The use of VPs in this context is not merely a procedural step; it introduces a profound layer of semantic precision and trust. This is crucial for the blockchain environment, where clarity and verifiability are paramount. Furthermore, the data presented on-chain through VPs become vital resources for on-chain governance decisions. They provide a reliable basis for the formulation and execution of governance rules, ensuring that decisions are made on the basis of verified and accurate information. Thus, the integration of VPs into the Axone protocol's ontology enhances both the functionality and the integrity of the system.
The construction of this ontology 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.
- Ontology implementation (5): Encoding the ontology according to the OWL grammar.
- Ontology evaluation (6): Association of key concepts and terms in the ontology with concepts and terms of other ontologies.
This ontology is structured in a modular way, with each part representing a specific domain of knowledge, providing a clear separation of concerns and a maximum of extensibility.
At the root, the ontology is divided into two main parts:
-
Thesaurus Part: This part contains all controlled vocabularies integral to the ontology. The thesaurus adheres to the SKOS standard, which is instrumental in ensuring compatibility with other thesauri and simplifying the ontology's integration into various systems.
-
Schema Part: This part encompasses diverse Verifiable Credentials schemas utilized within the Axone protocol. These schemas are deployed as JSON-LD contexts, a format that maximizes their usability in the Web3 ecosystem and promotes interoperability with existing Digital Credentials Wallets.
The foundational philosophy underpinning the ontology of the Axone protocol is grounded in the Open World principle. This principle operates on the premise that knowledge is not static or finite; rather, it acknowledges that understanding and information can continuously evolve and expand. In practical terms, this means that the ontology is not confined to a predefined or limited set of schemas and thesauri. Instead, it is inherently designed to accommodate and integrate new and diverse contributions.
For robust RDF resources management, the Axone ontology uses the w3id.org service for persistent URIs. This strategy is fundamental in maintaining both URI and content stability β an essential feature 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, which is crucial for the Axone ontology's long-term accessibility and usability.
- Redirect Capability: The w3id.org service enables redirection, allowing the Axone ontology to direct clients to the appropriate resource location as it evolves. This feature is particularly beneficial for versioning, where changes to the ontology structure or content might necessitate updates to the resource location.
In managing RDF resources, it is essential to balance the stability of URIs with the stability of their referenced content:
- URI Stability: URIs must remain constant over time. This ensures that each URI consistently references the same resource, providing a reliable point of reference in web-based knowledge systems.
- Content Stability: The content accessed via these URIs should be stable and avoid introducing breaking changes. This stability is crucial for 3rd party systems referencing these URIs, ensuring that their interactions remain consistent.
The Axone ontology adopts the Semantic Versioning format of MAJOR.MINOR.PATCH
. This approach includes incorporating the MAJOR
version number into the ontology's URI. As a result, the structure of the ontology's URI is:
https://w3id.org/axone/ontology/<MAJOR>/<path>
Note: by including only the MAJOR
version number in the URI, significant updates that could impact compatibility gives a new ontology version being referenced with a different namespace. MINOR
updates and PATCH
(which do not result in breaking changes) have no impact on the URI, maintaining the stability of the URI for external references.
The ontology is built using GNU make and Docker. To build the ontology, run the following command:
make build
This 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 can be deployed in a local triple store using Docker. The triple store used is Apache Jena Fuseki.
To start the triple store, run the following command. This will start the triple store and wait to be ready.
make fuseki-up
Then, you can load the axone
ontology in the triple store using the following command:
make fuseki-load
You can now play with the ontology using the Fuseki UI - http://localhost:3030/.
Conversaly, to stop the triple store, run the following command:
make fuseki-down
The ontology is tested using Shapes Constraint Language (SHACL). To run the tests, run the following command:
make test
The documentation is generated using the following command:
make docs
This 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 help
Which will output the following:
Usage:
make <target>
Targets:
Clean:
clean Clean all generated files
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
Fuseki:
fuseki-up Start a Fuseki server and wait for it to be ready
fuseki-down Stop the Fuseki container
fuseki-load Load the ontology in Fuseki server
fuseki-log Show Fuseki server logs
Misc:
cache Download all required files to cache
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 depends on docker. To install it, please follow the instructions:
- for macOS: https://docs.docker.com/docker-for-mac/install/
- for Windows: https://docs.docker.com/docker-for-windows/install/
- for Linux: https://docs.docker.com/engine/install/
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.