DKG Python SDK (dkg.py)
Python library for interacting with the Decentralized Knowledge Graph.
Last updated
Python library for interacting with the Decentralized Knowledge Graph.
Last updated
If you are looking to build applications leveraging knowledge assets on the OriginTrail Decentralized Knowledge Graph (DKG), the dkg.py library is the best place to start!
The DKG SDK is used together with an OriginTrail gateway node to build applications that interface with the OriginTrail Decentralized Network (the node is a dependency). Therefore you either need to run a gateway node on your local environment or a hosted OT-Node, in order to use the SDK.
Running a gateway node is not the same as running a full (DKG hosting) node, which requires 50 000 TRAC tokens to be posted as stake collateral. Running a gateway node requires no tokens to be posted as collateral.
The library can be used in any Python application.
Run the command to install dkg.py library using pip:
pip x:
or poetry:
Then import DKG, BlockchainProvider and NodeHTTPProvider classes inside your project:
To use the DKG library, you need to connect to a running local or remote OT-Node.
In this example, let’s create an example Knowledge Asset representing a Tesla Model X car. We will be using a Schema.org type Car for our data (detailed schema can be found on https://schema.org/Car). The sample content can be seen below:
When you create the knowledge asset, the above JSON-LD object will be converted into an assertion (see more here). When an assertion with public data is prepared, we can create an knowledge asset on DKG. epochs_number
specifies for how many epochs the asset should be kept (an epoch is equal to three months).
The complete response of the method will look like:
In case you want to create multiple different assets you can increase your allowance and then each time you initiate a publish, the step where a call to the blockchain is made to increase your allowance will be skipped, resulting in a faster publish time.
After you've finished publishing data to the blockchain, you can decrease your allowance to revoke the authorization given to the contract to spend your tokens - so if you want to revoke all remaining authorization, it's a good practice to pass the same value that you used for increasing your allowance.
Alternatively, you can set allowance to specific amount of tokens, increasing or decreasing it depending on your current allowance. To do so, you can utilize the following function:
Furthermore, you can always check your current allowance:
To read knowledge asset data from the DKG we utilize the get protocol operation.
In this example we will get the latest state of the knowledge asset we published previously:
The response of the get operation will be the assertion graph:
Knowledge assets can be updated by using the update function. In this example we will update the previously published knowledge asset to reflect the features of the Tesla S model. The updated content can be seen below:
The function call for updating a knowledge asset receives a UAL (the same one that the previous create returned) and is of same structure as for knowledge asset creation:
The returned response will contain the UAL and operation status:
After an update is finalized, a user can get the updated asset state by invoking the get operation.
Note on state finality
Similar to distributed databases, the OriginTrail Decentralized Knowledge Graph applies replication mechanisms and needs mechanisms to reach a consistent state on the network for knowledge assets. In OriginTrail DKG, state consistency is reconciled using the blockchain, which hosts state proofs for knowledge assets as well as replication commit information from DKG nodes. This means that updates for an existing knowledge asset are accepted by the network nodes (similar to the way nodes accept knowledge assets on creation) and can operate with all accepted states.
There are three phases for a state of a knowledge asset:
LATEST: which indicates the Knowledge Asset state pending for an update, awaiting commits from DKG nodes. Once commits are received, the state transitions to LATEST_FINALIZED.
LATEST_FINALIZED: latest committed state, accepted by the network.
HISTORICAL: any previously finalized state, identifiable by its state hash.
The user is able to specify if he wants to get the latest or latest finalized state. Example:
Application builders are able to get all above states, however querying the DKG (via query functions) will only return the cumulative finalized state, for consistency reasons.
Querying the DKG is done by using the SPARQL query language, which is very similar to SQL, applied to graph data (if you have SQL experience, SPARQL should be relatively easy to get started with - more information can be found here).
Let’s write simple query to select all subjects and objects in graph that have the Model property of Schema.org context:
The returned response will contain an array of n-quads:
As the OriginTrail node leverages a fully fledged graph database (triple store supporting RDF), you can run arbitrary SPARQL queries on it.
However, when it comes to querying the DKG, it is important to note that at the moment there are only options to query finalized and historical states. This means that any SPARQL queries that are run on the DKG will return data from the latest finalized state by default, or any previously finalized states, identifiable by their state hash.
To query for full (private+public data) historical states in the DKG, you need to use the repository: 'privateHistory'
option when making the SPARQL query. Here's an example of how to do that:
To query the full latest finalized state of the DKG, the 'privateCurrent'
option should be passed for the repository parameter. It's important to note that this is also the default behavior if the repository parameter is not specified in the SPARQL query.
There are 4 repositories available:
privateHistory (default) - private and public data of the historical states.
publicHistory - public data of the historical states.
privateCurrent - private and public data of the latest finalized state.
publicCurrent - public data of the latest finalized state.
Query for Historical State of the Knowledge Asset
Sometimes we want to get data of historical state of the Knowledge Asset. To do so, we can use the following query:
Create a Knowledge Asset with private data
In addition to knowledge assets with public assertions, we can add private data to our knowledge asset by creating private assertions, which will contain data that we don’t want to expose publicly.
The sample assertion content for public assertion will be the same as before, just a bit reduced:
Sample private assertion:
When assertions with public and private data are prepared, we can publish it on the DKG. It’s actually as simple as executing one function:
The complete response of the method will look like:
Get Knowledge Asset private assertion from the DKG
To read knowledge asset private assertion from the DKG we utilize the same get protocol operation as before, just now we will specify content_visibility option to be private. Keep in mind, you can only get private assertions if your node owns them. This feature is to be further extended with knowledge marketplace tools for knowledge asset monetization.
The response of the get operation will be the assertion graph:
Thanks to the blockchain representation of the Knowledge Assets it’s possible to check the owner of the Knowledge Asset by checking the ownership record of its NFT token, representing the asset on-chain.
In order to do this, we should execute the function below:
Owner of the Knowledge Asset:
It’s also possible to transfer ownership of the asset ERC721 token.
In this example we will transfer our Tesla ERC721 token to another wallet:
Result of the transfer operation:
Before actual creation of the Knowledge Asset, we can estimate how much would it cost for publisher to host Knowledge Asset on the DKG for a specific period of time.
In order to do this, we can send a request to one of the DKG nodes, which would return suggested cost of the publishing (so that Knowledge Asset is accepted by at least 8 nodes on the DKG).
In order to estimate cost of the publishing, you should know the metadata of the public assertion, such as: assertion ID (Merkle Root) and size in bytes. Additionally, you need to provide number of epochs.
Don't know how to calculate assertion metadata? Don't you worry, in the following example we will go through all the steps from having just Knowledge Asset content to having estimated price.
In order to calculate public assertion metadata, we would use assertion module:
Besides assertion ID and size, following functions are available in the assertion module:
format_graph(knowledge_asset_content) - formats the content provided, producing both a public and, if available, a private assertion and a link to it in the public assertion.
get_triples_number(knowledge_asset_content) - calculates and returns the number of triples of the public assertion from the provided content.
get_chunks_number(knowledge_asset_content) - calculates and returns the number of chunks of the public assertion from the provided content.
After calculating public assertion metadata, we can get suggested publishing cost using the network module:
We can divide operations done by SDK into 3 types:
Node API request
Smart contract call (non state-changing interaction)
Smart contract transaction (state-changing interaction)
Non state-changing interactions with smart contracts are free and can be described as contract getters and don’t require transactions on the blockchain, meaning they do not incur transaction fees. Smart contract transactions are state-changing operations, meaning that they’re changing the state of the smart contract memory and it costs some amount in blockchain native gas tokens (such as ETH, NEURO, etc.).
In order to perform state-changing operations, you need to use a wallet funded with gas tokens.
You can use default keys from the example below for hardhat blockchain:
Default keys above should not be used anywhere except in local environment for development.