Design Architecture

Overall Architecture

Relation Labs has designed and implemented an on-chain semantic storage network inspired by SBT. Through the network, Web3 developers can efficiently mint Semantic SBTs, build their own brands, and join forces to build a decentralized social graph. The network consists of three parts:

Caller Layer

Contract Layer

Off-Chain Layer

When using this semantic network, third-party projects and Web3 developers should save the schema of the data in question on certain off-chain decentralized storage infrastructures (such as IPFS and Arweave) for future processing. Then, they can call the Semantic contract to save other information on-chain and to mint SBTs. With the events defined in the contract specification, Semantic Scan can save SBT data on Relation Graph in the RDF format and exposes APIs for third-party projects and developers to use. Meanwhile, they can also conduct advanced business queries such as join and union via SPARQL.

Caller Layer

As a resource description framework, RDF in essence is a data model describing certain objects. However, its expressiveness is limited in the sense that it can not differentiate between classes and objects, let alone define and describe the relations or properties of classes. So, the caller should finalize the corresponding schema before storing RDF data. Schema describes the properties of RDF, just like the table structure in databases. Through the schema, developers can transform on-chain data and assign them with business properties. That is why developers should define RDF schema off-chain and save them to decentralized storage services such as IPFS and Arweave before calling the contract.

Below is a RDF Schema example using Staff as an object:

PREFIX : <http://relationlabs.ai/entity/>
PREFIX p: <http://relationlabs.ai/property/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

### We defined a class named “Staff” 
:Staff a rdfs:Class;
      rdfs:label "entity";
      rdfs:comment "A staff" .

### There are three properties for staff: name(string), age(integer), career(string)
p:name rdf:Property;
      rdfs:label "the name of staff";
      rdfs:range xsd:string .

p:age rdf:Property;
      rdfs:label "the age of staff";
      rdfs:range xsd:integer .
        
p:career rdf:Property;
      rdfs:label "the career of staff";
      rdfs:range xsd:string .

Contract Layer

Business Logic of the Contract

On top of ERC721 and ERC5192, the Semantic SBT contract adds the RDF data structure and method to generate such data. The logic of the contract includes:

Data Entity: It sets specification for the data objects such as Class, Subject, Predicate, and Turtle. It properly defines the units of RDF data.

Semantic Entity: Based on semantic rules, it performs instantiation and composition of relationships on data objects to form RDF data models.

Contract Method：With the semantic contract, users can leverage its methods to interact with data that fits proper specification and composition model to create and use SBTs.

The instantiation and composition of Semantic entities is crucial in the three steps. It concerns the way data is stored and directly impacts the minting process of SBT.

How to generate semantic entities

The flow to create semantic entities The composition of semantics consists of several steps below: Initialize the contract:

Define the basic properties of the token, such as its name, symbol and baseURI.

Define the instance corresponding to the subject, namely the Class.

Define the Predicate.

Define the schemaURI corresponding to the SBT so that the schema of the RDF data can be saved.

Create a Subject：After initializing the contract, we can create a new Subject based on a Class that is defined already.

Create an Object: Before Minting, we can in advance link the Object waiting to be created and an already defined Predicate together to generate a PredicateAndObject.

Generate Turtle: When minting, we should compose the incoming Subject and PredicateAndObject into Turtle format data, issue the corresponding token, and assign the corresponding Address.

Generate RDF data: Before the end of minting, the design transforms Turtle data into RDF format and notice the result to those who are listening to the contract via triggering events.

It is safe to say that in the process of Minting SBT, the composition, creation and distribution of Turtle are crucial to the process.

How to construct Turtle

1. Before initializing the contract, we should prepare a Subject, an Object, and a Predicate. The initialization process will define the Class and Predicate, and a Class Index will be generated based on Class Name. Similarly, a Predicate Index will be generated based on Predicate Name and Predicate Type. Predicate Types include: Integer, String, Address, Subject(aka. customized predicate) and BlankNode.

2. Create a Subject. A Subject consists of a Value and a ClassId. When we create a Subject, we should use the addSubject method with Subject Value and Class Name as parameters. Then, we determine if the Class was generated in the initializing process according to its Class Name. Based on the Subject Value, a Subject Index will be generated. At last, the Subject will be formed based on the Class Index and Subject Value.

3. In the process of minting the Semantic Token, link the Predicate and Object together to generate a PredicateAndObject based on the Predicate Type.

4. In the process of minting the Semantic Token, composite the Subject and PredicateAndObject into Turtle. The data of the Turtle is linked to certain Token ID and assigned to certain user (it can be the caller of the contract or a specified SBT owner)

5. Store the Subject and PredicateAndObject in RDF format. By listening to contract events, we can fetch the RDF data generated and save them off-chain.

``