fix: correct typo and center image tags

docs/academy/overview.mdx

@@ -9,9 +9,9 @@ Welcome to the Axone Academy, your gateway to the cutting-edge world of off-chai
 
 Throughout this concise journey, we will guide you through the core principles of the Axone protocol, providing you with a swift understanding of its functions. Prepare to immerse yourself in Axone, where the focus lies on optimizing resource sharing and creating new knowledge. Are you ready to explore the forefront of off-chain resource management? Follow us through this Academy to unravel the intricacies of Axone.
 
-<center>
+<div style={{ display: "flex", justifyContent: "center" }}>
 ![overview-1](/img/content/academy/overview-1.webp)
-</center>
+</div>
 
 ## Your learning journey
 

docs/academy/part-2/decentralized-identity.mdx

@@ -42,9 +42,9 @@ A Holder can be a person, organization, product, or object possessing a set of a
 
 A Verifier is an entity empowered to authenticate the legitimacy and veracity of a Verifiable Credential through a Verifiable Presentation submitted to it. The verifier can confirm that the information presented originates from the correct and authorized Issuer and that the Verifiable Credential has not been altered in any way. Generally, the verifier can also check that the Verifiable Credential has not expired or been revoked.
 
-<center>
+<div style={{ display: "flex", justifyContent: "center" }}>
   <img src="/img/content/academy/decentralized-identity-1.webp" alt="Decentralized Identity tryptic" style={{ maxHeight: "340px" }}></img>
-</center>
+</div>
 
 **Zero-knowledge proof** (ZKP) technology can be used to share proof of identity or authorization without revealing the complete identity of the holder. 
 
@@ -205,9 +205,9 @@ Understanding and distinguishing key roles is essential when claiming a resource
 - **Holder**: This role is assigned to the DID of the resource itself. The holder embodies the digital identity of the resource in the dataverse, thus constituting a central point for any interaction or transaction concerning this resource.
 - **Issuer**: The issuer, whose DID is linked to creating the Verifiable Credential, plays a decisive role. It ensures the authenticity and legitimacy of the resource's claim, guaranteeing its official recognition in the protocol.
 
-<center>
+<div style={{ display: "flex", justifyContent: "center" }}>
   <img src="/img/content/academy/decentralized-identity-3.webp" alt="Decentralized Identity and Axone" style={{ maxHeight: "340px" }}></img>
-</center>
+</div>
 
 In the case of the declaration of a digital resource in the Dataverse, the Provider has three roles at the same time:
 - Issuer as he declares the metadata of its resource

docs/academy/part-2/describe-resource.mdx

@@ -8,13 +8,13 @@ sidebar_position: 3
 
 Now that you know what a DID and a Verifiable Credential are, and what they mean for the Axone protocol, let's put them into practice! 
 
-You're a digital resource provider and you want to share a dataset or a service. First, you need to describe your resource and register it in the Dataverse (i.e. in the Axoneprotocol). 
+You're a digital resource provider and you want to share a dataset or a service. First, you need to describe your resource and register it in the Dataverse (i.e. in the Axone protocol). 
 
 Here are the 4 steps involved: 
 
-<center>
+<div style={{ display: "flex", justifyContent: "center" }}>
   <img src="/img/content/academy/describe-resource-1.webp" alt="Steps to describe a resource in the Dataverse" style={{ maxHeight: "340px" }}></img>
-</center>
+</div>
 
 We'll take 2 examples in this tutorial: 
 
@@ -249,7 +249,7 @@ You can see that there is a new field in the jsonld with the cryptographic proof
 
 The VC is now in the hands of the Holder. Note that it is possible that the Issuer is also the Holder. 
 
-The Axone blockchain can only register VCs in N-Quads format. Then, you must convert the jsonld files in N-Quads. You can use this tool: https://transform.tools/jsonld-to-nquads .
+The Axone blockchain can only register VCs in N-Quads format. Then, you must convert the jsonld files in N-Quads. You can use this tool: https://transform.tools/jsonld-to-nquads.
 
 ## Step 4: Register the credentials in the blockchain
 

docs/academy/part-2/describe-zone.mdx

@@ -12,9 +12,9 @@ All the workflows initiated within the Axone protocol must be defined in the con
 
 Let's see how to describe and register a zone in the Axone Protocol. Here are the four steps involved: 
 
-<center>
+<div style={{ display: "flex", justifyContent: "center" }}>
   <img src="/img/content/academy/describe-resource-1.webp" alt="Steps to describe a resource in the Dataverse" style={{ maxHeight: "340px" }}></img>
-</center>
+</div>
 
 We'll take the example of the Collaborative AI Zone in this tutorial.
 
@@ -178,7 +178,7 @@ You can see that there is a new field in the jsonld with the cryptographic proof
 
 The VC is now in the hands of the Holder. Note that it is possible that the Issuer is also the Holder. 
 
-The Axone blockchain can only register VCs in N-Quads format. Then, you must convert the jsonld files in N-Quads. You can use this tool: https://transform.tools/jsonld-to-nquads .
+The Axone blockchain can only register VCs in N-Quads format. Then, you must convert the jsonld files in N-Quads. You can use this tool: https://transform.tools/jsonld-to-nquads.
 
 ## Step 4: Register the credentials in the blockchain
 

docs/academy/part-2/resource-governance.mdx

@@ -10,7 +10,7 @@ sidebar_position: 4
 We recommend you first read the [Technical documentation of Governance](https://docs.okp4.network/technical-documentation/governance/introduction) before delving into practice in the Academy. 
 :::
 
-Resource Consent is an agreement associated with the use of Resources within Zones. By resources, we mean Digital Resources (e.g., datasets) or Digital Services. It goes beyond simple approval and encompasses the permissions and restrictions on resource owners' access, usage, sharing, management, and handling of their resources. It allows parties to define boundaries and establish terms for others to interact with their digital resources. This aspect is crucial aspect of governance, ensuring resources are used appropriately per the relevant parties' expressed will and intentions.
+Resource Consent is an agreement associated with the use of Resources within Zones. By resources, we mean Digital Resources (e.g., datasets) or Digital Services. It goes beyond simple approval and encompasses the permissions and restrictions on resource owners' access, usage, sharing, management, and handling of their resources. It allows parties to define boundaries and establish terms for others to interact with their digital resources. This is crucial for governance, ensuring resources are used appropriately per the relevant parties' expressed will and intentions.
 
 The materialization of a resource in the dataverse requires the creation of a Governance VP. According to a principle of self-determination, the resource itself must generate this VP, i.e., the issuer and the resource have the same identity.
 
@@ -23,15 +23,15 @@ In the protocol, governance structures are made up of two key elements:
 - A **VP** serves as proof of the existence of a governance by referencing the Codified Governance. This document plays a fundamental role in creating a resource within the dataverse.
 - **Governance as Code** is represented by a program written in Prolog. This program details and encodes the specific rules governing resource management.
 
-<center>
+<div style={{ display: "flex", justifyContent: "center" }}>
   <img src="/img/content/academy/resource-governance-1.webp" alt="Governance elements for Resources in Axone Protocol" style={{ maxHeight: "340px" }}></img>
-</center>
+</div>
 
 Here are the five steps to create the governance of a resource in the Dataverse: 
 
-<center>
+<div style={{ display: "flex", justifyContent: "center" }}>
   <img src="/img/content/academy/resource-governance-2.webp" alt="Steps to create a resource's governance" style={{ maxHeight: "340px" }}></img>
-</center>
+</div>
 
 We'll take 2 simple examples in this tutorial: 
 
@@ -134,9 +134,9 @@ partOf(subSec1, sec1).
 partOf(sec1, chap1).
 ```
 
-<center>
+<div style={{ display: "flex", justifyContent: "center" }}>
   <img src="/img/content/academy/resource-governance-3.webp" alt="Governance elements for Resources in Axone Protocol" style={{ maxHeight: "340px" }}></img>
-</center>
+</div>
 
 #### Elements of description
 
@@ -304,7 +304,7 @@ You can see that there is a new field in the jsonld with the cryptographic proof
 
 The VC is now in the hands of the Holder. Note that it is possible that the Issuer is also the Holder. 
 
-The Axone blockchain can only register VCs in N-Quads format. Then, you must convert the jsonld files in N-Quads. You can use this tool: https://transform.tools/jsonld-to-nquads .
+The Axone blockchain can only register VCs in N-Quads format. Then, you must convert the jsonld files in N-Quads. You can use this tool: https://transform.tools/jsonld-to-nquads.
 
 The final step is to register the VCs in the Axone blockchain by submitting them to the Dataverse smart contract. It's the role of the Registrant (who can be the Holder or another entity). 
 

docs/academy/part-2/verifiable-claims.mdx

@@ -21,9 +21,9 @@ A credential may contain several claims. For example, a diploma contains the cla
 
 In the [W3C standard](https://www.w3.org/TR/vc-data-model/), a credential is a set of one or more **claims** made by the same entity. Credentials include an identifier and metadata describing the credential's properties, such as the issuer, the expiry date and time, a representative image, a public key to use for verification purposes, the revocation mechanism, and so on. The issuer might sign the metadata. A verifiable credential is a set of tamper-evident claims and metadata that cryptographically prove who issued it.
 
-<center>
+<div style={{ display: "flex", justifyContent: "center" }}>
   <img src="/img/content/academy/verifiable-claims-1.webp" alt="Verifiable claims W3C" style={{ maxHeight: "340px" }}></img>
-</center>
+</div>
 
 :::info
 
@@ -41,9 +41,9 @@ A **verifiable presentation** is a tamper-evident presentation encoded in such a
 
 A government authority issues a digital passport to a citizen.
 
-<center>
+<div style={{ display: "flex", justifyContent: "center" }}>
   <img src="/img/content/academy/verifiable-claims-2.webp" alt="Verifiable claims passport example" style={{ maxHeight: "650px" }}></img>
-</center>
+</div>
 
 Use when traveling :
 
@@ -64,9 +64,9 @@ This notion is analogous to that of crypto-currency wallets. Although all addres
 
 Verifiable Credentials obey schemas that describe a particular aspect of a resource. Certain VCs apply depending on the nature of the resource. A VC describing an entity or organization does not apply to the same resource as a VC describing a dataset. This is why VCs are organized in schemas.
 
-<center>
+<div style={{ display: "flex", justifyContent: "center" }}>
   <img src="/img/content/academy/verifiable-claims-3.webp" alt="Verifiable claims attached to a resource" style={{ maxHeight: "400px" }}></img>
-</center>
+</div>
 
 ### Resource materiality
 
@@ -90,8 +90,8 @@ Once the Issuer successfully issues the Verifiable Credentials (VCs) associated
 
 Recording VPs in the blockchain, rather than individual VCs, ensures the confidentiality of specific properties by only revealing a restricted set of properties on the public chain.
 
-<center>
+<div style={{ display: "flex", justifyContent: "center" }}>
   <img src="/img/content/academy/verifiable-claims-4.webp" alt="Verifiable presentation W3C" style={{ maxHeight: "360px" }}></img>
-</center>
+</div>
 
 <Quiz quiz={quiz}/>

docs/academy/part-2/zone-governance.mdx

@@ -23,15 +23,15 @@ In the protocol, governance structures are made up of two key elements:
 - A **VP** serves as proof of the existence of a governance by referencing the Codified Governance. This document plays a fundamental role in creating a zone within the dataverse.
 - **Governance as Code** is represented by a program written in Prolog. This program details and encodes the specific rules governing zone management.
 
-<center>
+<div style={{ display: "flex", justifyContent: "center" }}>
   <img src="/img/content/academy/zone-governance-1.webp" alt="Governance elements for Zone in Axone Protocol" style={{ maxHeight: "340px" }}></img>
-</center>
+</div>
 
 Here are the five steps to create a zone governance in the Dataverse: 
 
-<center>
+<div style={{ display: "flex", justifyContent: "center" }}>
   <img src="/img/content/academy/zone-governance-2.webp" alt="Steps to create a zone's governance" style={{ maxHeight: "340px" }}></img>
-</center>
+</div>
 
 We'll take one simple example in this tutorial for the Collaborative AI zone.  
 
@@ -112,9 +112,9 @@ partOf(subSec1, sec1).
 partOf(sec1, chap1).
 ```
 
-<center>
+<div style={{ display: "flex", justifyContent: "center" }}>
   <img src="/img/content/academy/resource-governance-3.webp" alt="Governance elements for Resources in Axone Protocol" style={{ maxHeight: "340px" }}></img>
-</center>
+</div>
 
 #### Elements of description
 
@@ -283,7 +283,7 @@ You can see that there is a new field in the jsonld with the cryptographic proof
 
 The VC is now in the hands of the Holder. Note that it is possible that the Issuer is also the Holder. 
 
-The Axone blockchain can only register VCs in N-Quads format. Then, you must convert the jsonld files in N-Quads. You can use this tool: https://transform.tools/jsonld-to-nquads .
+The Axone blockchain can only register VCs in N-Quads format. Then, you must convert the jsonld files in N-Quads. You can use this tool: https://transform.tools/jsonld-to-nquads.
 
 The final step is to register the VCs in the Axone blockchain by submitting them to the Dataverse smart contract. It's the role of the Registrant (who can be the Holder or another entity). 
 

docs/faq/faq.md

@@ -10,7 +10,7 @@ sidebar_position: 1
 
 Axone is the first settlement layer for off-chain workflows using shared resources. In other words, it is an open-source and public protocol that enables the sharing and orchestration of digital off-chain resources (datasets, algorithms, storage, computation resources…) while enforcing their associated governance rules.
 
-### How does Axone works in a few words ?
+### How does Axone work in a few words ?
 
 Axone is a custom blockchain facilitating digital resource sharing with auditability and adherence to consent rules. It establishes trust through decentralization, offers a flexible incentive system, and reduces digital ecosystem fragmentation by enabling 'Anything as a Service'. The protocol introduces Zones for resource orchestration and utilizes an on-chain ontology for standardized interpretation of diverse elements. With smart contracts and modules, it is the orchestrator of workflows running on shared resources for any applications.
 
@@ -84,7 +84,7 @@ In summary, the distinction between Zones and resources enables the Axone ecosys
 The Dataverse is an ever-expanding universe comprised of all the digital resources, such as datasets, and digital services such as infrastructure services, processing services or any other digital service referenced in the Axone Blockchain.
 All resources, services and Zones are found within the same universe, the Dataverse. The on-chain Ontology is the semantic representation of the Dataverse.
 
-### How does Axone stores the resources and services?
+### How does Axone store the resources and services?
 
 As a protocol, Axone doesn't store them. It only references the resource/services where it is (wherever it is) and make it available to the network according to the permissions granted by the provider. It can be stored anywhere, with any kind of storage solution, either centralized or decentralized.
 
@@ -318,7 +318,7 @@ Axone functions as a decentralized coordinator where:
 - The workflow can be initiated in accordance with the consent rules of each resource.
 - The workflow is recorded on-chain and is subject to thorough auditing.
 
-### How does Axone ensures the execution and validation of sharing rules?
+### How does Axone ensure 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 Axone 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.
 

docs/technical-documentation/governance/governance-extent.md

@@ -48,7 +48,7 @@ The Zone Rules directly address matters that significantly impact business activ
 Here are some facets of business models in the zones:
 
 - **Retribution models**: Rules establish the economic terms resulting from the orchestration of resources within a zone. The retribution model describes the creation and redistribution of resulting value, benefitting all participating parties. The models can be diverse and significantly different from each other, and their design can either promote equity or impose constraints on it. For instance, in one specific Zone, it may be stated that Open Data does not receive remuneration, whereas other data sets receive remuneration. Conversely, each service provider may set the price associated with their service usage in another zone, with compensation arranged according to this price.
-- **Economic Incentives**: The rules specify financial incentives to promote desirable behaviours and outcomes within the Zone. This can include mechanisms such as reward systems, token incentives, or revenue-sharing models that encourage active entities to contribute to the growth and development of the Zone actively.
+- **Economic Incentives**: The rules specify financial incentives to promote desirable behaviors and outcomes within the Zone. This can include mechanisms such as reward systems, token incentives, or revenue-sharing models that encourage active entities to contribute to the growth and development of the Zone actively.
 
 ### Related to self
 

docs/technical-documentation/governance/hierarchy-of-norms.md

@@ -8,9 +8,9 @@ The hierarchy of norms refers to the hierarchical structure of rules within the
 
 In the Axone Governance framework, the hierarchy of norms establishes a clear order of precedence for rules and regulations. We thus end up with different levels of governance that allow fine-grained control of the use of the protocol.
 
-<center>
+<div style={{ display: "flex", justifyContent: "center" }}>
   <img src="/img/content/technical-documentation/governance-hierarchy-of-norms.webp" alt="Governance - Hierarchy of Norms" style={{ maxHeight: "340px" }}></img>
-</center>
+</div>
 
 <br/>