Merge pull request #421 from okp4/feat/academy-sidebar

Feat/academy sidebar

LICENSE-doc

@@ -410,7 +410,7 @@ Section 8 -- Interpretation.
 Creative Commons is not a party to its public licenses.
 Notwithstanding, Creative Commons may elect to apply one of its public
 licenses to material it publishes and in those instances will be
-considered the “Licensor.” The text of the Creative Commons public
+considered the "Licensor." The text of the Creative Commons public
 licenses is dedicated to the public domain under the CC0 Public Domain
 Dedication. Except for the limited purpose of indicating that material
 is shared under a Creative Commons public license or as otherwise

docs/academy/_category_.json

@@ -1,5 +1,4 @@
 {
   "label": "Academy",
-  "position": 6,
-  "className": "hidden"
+  "position": 2
 }

docs/academy/ai-factory.mdx

@@ -1,6 +1,5 @@
 ---
 sidebar_position: 7
-sidebar_class_name: hidden
 ---
 
 import Quiz from 'react-quiz-component';

docs/academy/consume-resources.mdx

@@ -1,6 +1,5 @@
 ---
 sidebar_position: 4
-sidebar_class_name: hidden
 ---
 
 import Quiz from 'react-quiz-component';
@@ -61,7 +60,7 @@ In the following example, the dataset D1 is accessed via the service S1, and the
 
 A workflow is merely a sequence of activities, taking inputs and producing outputs. So, it can be conceptualized as a Service capable of performing specific functions, just like traditional services. This paradigm shift enables Workflows to be invoked in the protocol as a Service and to join the anything-as-a-service family.
 
-When we think of Workflows as a Service, a new perspective emerges: workflows can invoke other workflows as sub-services, forming a multi-level hierarchy to facilitate the composition and re-use of more complex treatments. Moreover, these particular services can be seen as virtual services since they consist only of the “blueprint” describing the workflow to be executed.
+When we think of Workflows as a Service, a new perspective emerges: workflows can invoke other workflows as sub-services, forming a multi-level hierarchy to facilitate the composition and re-use of more complex treatments. Moreover, these particular services can be seen as virtual services since they consist only of the "blueprint" describing the workflow to be executed.
 
 ## How are rules enforced in the Dataverse?
 
@@ -71,7 +70,7 @@ The workflow is purely declarative and merely expresses the activities to be per
 
 ![consume-resources-4](/img/content/academy/consume-resources-4.webp)
 
-In its centralized perspective, orchestration relies on a single authority responsible for taking the necessary actions to accomplish a set of activities in response to a declarative expression of needs. This authority holds the logic for execution. Let’s consider the example of Kubernetes — a well-known Container Orchestrator — its API enables the “declaration” of resources and will manage the operations and lifecycle logic associated with these resources.
+In its centralized perspective, orchestration relies on a single authority responsible for taking the necessary actions to accomplish a set of activities in response to a declarative expression of needs. This authority holds the logic for execution. Let’s consider the example of Kubernetes — a well-known Container Orchestrator — its API enables the "declaration" of resources and will manage the operations and lifecycle logic associated with these resources.
 
 By adopting a decentralized approach, one would expect the blockchain to handle orchestration. However, due to its highly constrained communication capabilities with the external environment, it cannot fulfill this role effectively. Therefore, the most suitable approach is to delegate the execution of workflows to a dedicated off-chain resource: **the Orchestration Service**. This specific resource takes on the orchestration role while the protocol maintains its position as the source of truth and ultimate authority to which it must adhere.
 

docs/academy/decentralized-identity.mdx

@@ -1,6 +1,5 @@
 ---
 sidebar_position: 8
-sidebar_class_name: hidden
 ---
 
 import Quiz from 'react-quiz-component';
@@ -119,7 +118,7 @@ A **Decentralized Identifier Document** contains key information that enables an
 1. **DID Identifier**
 This is the entity's unique identifier, typically in the form of a URI (Uniform Resource Identifier).
 
-Example : “id”: “did:key:zQ3shs7auhJSmVJpiUbQWco6bxxEhSqWnVEPvaBHBRvBKw6Q3”
+Example : "id": "did:key:zQ3shs7auhJSmVJpiUbQWco6bxxEhSqWnVEPvaBHBRvBKw6Q3"
 
 2. **DID Context**
 It provides information about the DID context or schema, usually by referencing a URL where the DID specification is defined.

docs/academy/describe-resource.mdx

@@ -1,6 +1,5 @@
 ---
 sidebar_position: 10
-sidebar_class_name: hidden
 ---
 
 # Describe a resource

docs/academy/describe-zone.mdx

@@ -1,6 +1,5 @@
 ---
 sidebar_position: 12
-sidebar_class_name: hidden
 ---
 
 # Describe a Zone

docs/academy/overview.mdx

@@ -1,6 +1,6 @@
 ---
 sidebar_position: 1
-sidebar_class_name: hidden
+
 ---
 
 # Academy overview 
@@ -182,7 +182,7 @@ Now you have a basic understanding of OKP4, let's delve into the core concepts b
         >
           <h2>Zone's governance</h2>
         </a>
-        <p class="card-text">reate the resource governance</p>
+        <p class="card-text">Create the resource governance</p>
       </div>
     </div>
   </div>

docs/academy/protocol-concepts.md

@@ -1,6 +1,5 @@
 ---
 sidebar_position: 5
-sidebar_class_name: hidden
 ---
 
 # Protocol concepts

docs/academy/resource-governance.mdx

@@ -1,6 +1,5 @@
 ---
 sidebar_position: 11
-sidebar_class_name: hidden
 ---
 
 # Create the resource's governance

docs/academy/resources.mdx

@@ -1,6 +1,5 @@
 ---
 sidebar_position: 2
-sidebar_class_name: hidden
 ---
 
 import Quiz from 'react-quiz-component';

docs/academy/rules.mdx

@@ -1,6 +1,5 @@
 ---
 sidebar_position: 3
-sidebar_class_name: hidden
 ---
 
 import Quiz from 'react-quiz-component';

docs/academy/verifiable-claims.mdx

@@ -1,6 +1,5 @@
 ---
 sidebar_position: 9
-sidebar_class_name: hidden
 ---
 
 import Quiz from 'react-quiz-component';

docs/academy/who-is-it-for.mdx

@@ -1,6 +1,5 @@
 ---
 sidebar_position: 6
-sidebar_class_name: hidden
 ---
 
 import Quiz from 'react-quiz-component';

docs/academy/zone-governance.mdx

@@ -1,6 +1,5 @@
 ---
 sidebar_position: 13
-sidebar_class_name: hidden
 ---
 
 # Create the zone's governance
@@ -25,13 +24,13 @@ In the protocol, governance structures are made up of two key elements:
 - **Governance as Code** is represented by a program written in Prolog. This program details and encodes the specific rules governing zone management.
 
 <center>
-  <img src="/img/content/academy/resource-governance-1.webp" alt="Governance elements for Zone in OKP4 Protocol" style={{ maxHeight: "340px" }}></img>
+  <img src="/img/content/academy/zone-governance-1.webp" alt="Governance elements for Zone in OKP4 Protocol" style={{ maxHeight: "340px" }}></img>
 </center>
 
 Here are the five steps to create a zone governance in the Dataverse: 
 
 <center>
-  <img src="/img/content/academy/resource-governance-2.webp" alt="Steps to create a zone's governance" style={{ maxHeight: "340px" }}></img>
+  <img src="/img/content/academy/zone-governance-2.webp" alt="Steps to create a zone's governance" style={{ maxHeight: "340px" }}></img>
 </center>
 
 We'll take one simple example in this tutorial for the Collaborative AI zone.  

docs/faq/_category_.json

@@ -1,4 +1,4 @@
 {
   "label": "Frequently Asked Questions",
-  "position": 4
+  "position": 6
 }

docs/faq/faq.md

@@ -232,9 +232,9 @@ The Law-Stone is a highly versatile smart contract designed to apply and enforce
 
 The smart contract has two sides:
 
-The side of the “Law”: Indeed, the smart contract interprets the law, i.e. makes a judgement on what is legal, permissible or prohibited according to the result of execution of the rules of governance informed by the knowledge available at the time of this interpretation.
+The side of the "Law": Indeed, the smart contract interprets the law, i.e. makes a judgement on what is legal, permissible or prohibited according to the result of execution of the rules of governance informed by the knowledge available at the time of this interpretation.
 
-The side of the “Stone”: The instantiation of the smart contract engraves in stone the rules to be interpreted, and these are immutable, irrevocable, and indisputable unless the stone is broken.
+The side of the "Stone": The instantiation of the smart contract engraves in stone the rules to be interpreted, and these are immutable, irrevocable, and indisputable unless the stone is broken.
 
 ### What is the Pactum smart contract in a few words?
 
@@ -320,7 +320,7 @@ OKP4 functions as a decentralized coordinator where:
 
 ### How does OKP4 ensures the execution and validation of sharing rules?
 
-The protocol itself is primarily an infrastructure that allows a resource “provider” to reference and define usage rules (in Prolog, which offers better expressiveness compared to other languages), and for a "consumer" to make usage requests based on these rules. What the protocol guarantees is the transparency of the rules and the correct assessment (validation or not) of these rules. However, there is indeed the question of verifying the actual "real" sharing action. The current approach is an open-source off chain "orchestrator" developed by the OKP4 Association team that provides access to resources (based on requests validated onchain) and then reports the successful execution back on chain. So, yes, there’s an element of centralization! We aim to have multiple orchestrators, deployed by external entities, and even decentralize that process at some point. Both "providers" and "consumers" will be able to choose the one they "trust" or deploy their own.
+The protocol itself is primarily an infrastructure that allows a resource "provider" to reference and define usage rules (in Prolog, which offers better expressiveness compared to other languages), and for a "consumer" to make usage requests based on these rules. What the protocol guarantees is the transparency of the rules and the correct assessment (validation or not) of these rules. However, there is indeed the question of verifying the actual "real" sharing action. The current approach is an open-source off chain "orchestrator" developed by the OKP4 Association team that provides access to resources (based on requests validated onchain) and then reports the successful execution back on chain. So, yes, there’s an element of centralization! We aim to have multiple orchestrators, deployed by external entities, and even decentralize that process at some point. Both "providers" and "consumers" will be able to choose the one they "trust" or deploy their own.
 
 More info [here](https://docs.okp4.network/whitepaper/architecture#trusted-parties-considerations)
 

docs/index.mdx

@@ -19,6 +19,14 @@ Welcome! OKP4 is a public PoS layer 1 blockchain built for trust-minimized data
         <p class="card-text">What is OKP4? What is it for? What is the technical architecture?</p>
       </div>
     </div>
+    <div class="col">
+      <div class="card card-body h-100 d-flex flex-column">
+        <a href="/academy/overview" class="card-title card-link stretched-link">
+          <h2>Academy</h2>
+        </a>
+        <p class="card-text">Start your journey through the OKP4 Academy.</p>
+      </div>
+    </div>
     <div class="col">
       <div class="card card-body h-100 d-flex flex-column">
         <a href="/nodes/introduction" class="card-title card-link stretched-link">
@@ -27,24 +35,24 @@ Welcome! OKP4 is a public PoS layer 1 blockchain built for trust-minimized data
         <p class="card-text">Everything that an OKP4 validator should know.</p>
       </div>
     </div>
+  </div>
+</div>
+<div class="docs-card-container">
+  <div class="row row-cols-1 row-cols-md-2a g-3">
     <div class="col">
       <div class="card card-body h-100 d-flex flex-column">
         <a href="/technical-documentation/overview" class="card-title card-link stretched-link">
-          <h2>Technical Documentation</h2>
+          <h2>Technical documentation</h2>
         </a>
         <p class="card-text">Deep dive into the OKP4 Protocol.</p>
       </div>
     </div>
-  </div>
-</div>
-<div class="docs-card-container">
-  <div class="row row-cols-1 row-cols-md-2a g-3">
     <div class="col">
       <div class="card card-body h-100 d-flex flex-column">
         <a href="/tutorials/overview" class="card-title card-link stretched-link">
           <h2>Tutorials</h2>
         </a>
-        <p class="card-text">Get started with OKP4 Protocol.</p>
+        <p class="card-text">Additional resources.</p>
       </div>
     </div>
     <div class="col">
@@ -249,4 +257,4 @@ import IconOKP4 from '/img/socials/logo-okp4-round.svg'
 >
   <IconTwitter />
 </a>
-</div>
+</div>

docs/nodes/_category_.json

@@ -1,4 +1,4 @@
 {
   "label": "Nodes & Validators",
-  "position": 2
+  "position": 3
 }

docs/technical-documentation/_category_.json

@@ -1,4 +1,4 @@
 {
   "label": "Technical documentation",
-  "position": 3
+  "position": 4
 }

docs/tutorials/_category_.json

@@ -1,4 +1,4 @@
 {
   "label": "Tutorials",
-  "position": 4
+  "position": 5
 }