HomeEIPs
EIPsERC-6239
ERC-6239

Semantic Soulbound Tokens

Adding RDF triples to ERC-5192 token metadata to capture social meaning
FinalStandards Track: ERC
Created: 2022-12-30
Requires: EIP-165, EIP-721, EIP-5192
Jessica Chang (@JessicaChg)
DiscussionsOriginal linkEdit
1 min read

ERC-6239 proposes to extend the ERC-721 and ERC-5192 standards by introducing Resource Description Framework (RDF) triples to Soulbound Tokens' (SBTs) metadata. SBTs represent the commitments, credentials, and affiliations of accounts, and the addition of RDF triples in metadata captures and stores the meaning of social metadata as a network of accounts and attributes. This enables the ability to query and retrieve information across multiple sources, using inference to uncover new insights from existing social relations. The proposed standard provides a foundation for publishing, linking, and integrating data from multiple sources, and supports fair governance. Burn authorization is tied to specific tokens and immutable after issuance, and an Issued event is emitted alongside EIP-721's Transfer event. The proposal is fully backward compatible with EIP-721, and there are no security considerations related directly to the implementation of this standard. The purpose of the proposed standard is to manage social metadata on-chain in a trustless manner, describing social metadata in an interconnected way, making it easy to be exchanged, integrated, and discovered. The key concepts include RDF triples, SBTs, burn authorization, Issued event, and backward compatibility.

Video
Anyone may contribute to propose contents.
Go propose
Original

Abstract

This proposal extends ERC-721 and ERC-5192 by introducing Resource Description Framework (RDF) triples to Soulbound Tokens' (‘SBTs‘) metadata.

Motivation

A Soulbound Token represents the commitments, credentials, and affiliations of accounts. RDF is a standard data model developed by the World Wide Web Consortium (‘W3C’) and is used to represent information in a structured format. Semantic SBTs are built on existing ERC-721 and ERC-5192 standards to include RDF triples in metadata to capture and store the meaning of social metadata as a network of accounts and attributes.

Semantic SBT provides a foundation for publishing, linking, and integrating data from multiple sources, and enables the ability to query and retrieve information across these sources, using inference to uncover new insights from existing social relations. For example, form the on-chain united social graph, assign trusted contacts for social recovery, and supports fair governance.

While the existence of SBTs can create a decentralized social framework, there still needs to specify a common data model to manage the social metadata on-chain in a trustless manner, describing social metadata in an interconnected way, make it easy to be exchanged, integrated and discovered. And to further fuel the boom of the SBTs ecosystem, we need a bottom-up and decentralized way to maintain people’s social identity related information.

Semantic SBTs address this by storing social metadata, attestations, and access permissions on-chain to bootstrap the social identity layer and a linked data layer natively on Ethereum, and bring semantic meanings to the tons of bits of on-chain data.

Connectedness

Semantic SBTs store social data as RDF triples in the Subject-Predicate-Object format, making it easy to create relationships between accounts and attributes. RDF is a standard for data interchange used to represent highly interconnected data. Representing data in RDF triples makes it simpler for automated systems to identify, clarify, and connect information.

Linked Data

Semantic SBTs allow the huge amount of social data on-chain to be available in a standard format (RDF) and be reachable and manageable. The interrelated datasets on-chain can create the linked data layer that allows social data to be mixed, exposed, and shared across different applications, providing a convenient, cheap, and reliable way to retrieve data, regardless of the number of users.

Social Identity

Semantic SBTs allow people to publish or attest their own identity-related data in a bottom-up and decentralized way, without reliance on any centralized intermediaries while setting every party free. The data is fragmentary in each Semantic SBT and socially interrelated. RDF triples enable various community detection algorithms to be built on top.

This proposal outlines the semantic data modeling of SBTs that allows implementers to model the social relations among Semantic SBTs, especially in the social sector.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

  • The token MUST implement the following interfaces:
    1. ERC-165’s ERC165 (0x01ffc9a7)
    2. ERC-721’s ERC721 (0x80ac58cd)
    3. ERC-721’s ERC721Metadata (0x5b5e139f)
    4. ERC-5192’s ERC5192 (0xb45a3c0e)

RDF Statement

RDF statements come in various formats, we have selected the six most commonly used formats: nt(N-Triples),ttl(Turtle),rdf(RDF/XML),rj(RDF/JSON),nq(N-Quads) and trig(TriG).

The complete format of an RDF statement:

rdfStatements = {[format]}<statements>

In the following section, fragments surrounded by {} characters are OPTIONAL.

In the following section, fragments surrounded by <> characters are REQUIRED.

format: nt/ttl/rdf/rj/nq/trig

When no format is selected: statements = [ttl]statements

  • nt(n-triples)

nt uses space to separate the subject, predicate, object of a triple, and a period . to indicate the end of a triple.

The basic structure is:

subject predicate object .

In this format, the subject is in the format of IRIREF or BLANK_NODE_LABEL, the predicate is in the format of IRIREF, and the object is in the format of IRIREF, BLANK_NODE_LABEL, or STRING_LITERAL_QUOTE.

For example:

<http://example.org/entity/user1> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://example.org/entity/User> . <http://example.org/entity/user1> <http://example.org/property/name> "Alice" .
  • ttl(Turtle)

Compared to nt, ttl uses prefixes to simplify the IRIREF format, and the same predicate under the same subject can be merged without repeating it. "a" can be used to represent <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>.

For example:

@prefix : <http://example.org/entity/> . @prefix p: <http://example.org/property/> . :user1 a :User; p:name ”Alice” .
  • rdf(RDF/XML)

rdf describes RDF in XML format, using rdf:RDF as the top-level element, and xmlns to describe prefixes. rdf:Description begins describing a node, rdf:about defines the node to be described, and rdf:resource fills in the property value in the format of IRI. If the property value is a string, the property value can be directly written as the text of the property node.

The basic structure is:

<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/ 02/22-rdf-syntax-ns#"> <rdf:Description rdf:about="subject" > <predicate rdf:resource="object"/> <predicate >object</predicate> </rdf:Description> </rdf:RDF>

For example:

<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/ 02/22-rdf-syntax-ns#" xmlns:p="http://example.org/property/"> <rdf:Description rdf:about="http://example.org/entity/user1" > <rdf:type rdf:resource="http://example.org/entity/"/> <p:name >Alice</p:name> </rdf:Description> </rdf:RDF>
  • rj(RDF/JSON)

rj describes RDF in JSON format. A triple is described as:

{"subject":{"predicate":[object]}}

Note that each root object is a unique primary key and duplicates are not allowed. There will be no duplicate subjects as keys, and there will be no duplicate predicates under a single subject.

For example:

{ "http://example.org/entity/user1": { "http://www.w3.org/1999/02/22-rdf-syntax-ns#type": [ "http://example.org/entity/User" ], "http://example.org/property/name": [ "Alice" ] } }
  • nq(N-Quads)

nq is based on nt but includes a graph label that describes the dataset to which an RDF triple belongs. The graph label can be in the format of IRIREF or BLANK_NODE_LABEL.

The basic structure is:

subject predicate object graphLabel.

For example:

<http://example.org/entity/user1> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://example.org/entity/User> <http://example.org/graphs/example> . <http://example.org/entity/user1> <http://example.org/property/name> "Alice" <http://example.org/graphs/example> .
  • trig(TriG)

trig is an extension of ttl that includes a graph label to describe the dataset to which an RDF triple belongs. The triple statements are enclosed in curly braces {}.

For example:

@prefix : <http://example.org/entity/> . @prefix p: <http://example.org/property/> . <http://example.org/graphs/example> { :user1 a :User; p:name ”Alice” . }

In the contract events: CreateRDF, UpdateRDF, RemoveRDF, and the rdfOf method, the rdfStatements is used in ttl format by default. If other formats listed above are used, a format identifier needs to be added for identification.

The format identifier starts with [ and ends with ] with the format in the middle, i.e., [format].

For example, the rdfStatements in nt format should include the prefix [nt].

[nt]subject predicate object .

Contract Interface

/** * @title Semantic Soulbound Token * Note: the ERC-165 identifier for this interface is 0xfbafb698 */ interface ISemanticSBT{ /** * @dev This emits when minting a Semantic Soulbound Token. * @param tokenId The identifier for the Semantic Soulbound Token. * @param rdfStatements The RDF statements for the Semantic Soulbound Token. */ event CreateRDF ( uint256 indexed tokenId, string rdfStatements ); /** * @dev This emits when updating the RDF data of Semantic Soulbound Token. RDF data is a collection of RDF statements that are used to represent information about resources. * @param tokenId The identifier for the Semantic Soulbound Token. * @param rdfStatements The RDF statements for the semantic soulbound token. */ event UpdateRDF ( uint256 indexed tokenId, string rdfStatements ); /** * @dev This emits when burning or revoking Semantic Soulbound Token. * @param tokenId The identifier for the Semantic Soulbound Token. * @param rdfStatements The RDF statements for the Semantic Soulbound Token. */ event RemoveRDF ( uint256 indexed tokenId, string rdfStatements ); /** * @dev Returns the RDF statements of the Semantic Soulbound Token. * @param tokenId The identifier for the Semantic Soulbound Token. * @return rdfStatements The RDF statements for the Semantic Soulbound Token. */ function rdfOf(uint256 tokenId) external view returns (string memory rdfStatements); }

ISemanticRDFSchema, an extension of ERC-721 Metadata, is OPTIONAL for this standard, it is used to get the Schema URI for the RDF data.

interface ISemanticRDFSchema{ /** * @notice Get the URI of schema for this contract. * @return The URI of the contract which point to a configuration profile. */ function schemaURI() external view returns (string memory); }

Method Specification

rdfOf (uint256 tokenId): Query the RDF data for the Semantic Soulbound Token by tokenId. The returned RDF data format conforms to the W3C RDF standard. RDF data is a collection of RDF statements that are used to represent information about resources. An RDF statement, also known as a triple, is a unit of information in the RDF data model. It consists of three parts: a subject, a predicate, and an object.

schemaURI(): This OPTIONAL method is used to query the URIs of the schema for the RDF data. RDF Schema is an extension of the basic RDF vocabulary and provides a data-modelling vocabulary for RDF data. It is RECOMMENDED to store the RDF Schema in decentralized storage such as Arweave or IPFS. The URIs are then stored in the contract and can be queried by this method.

Event Specification

CreateRDF: When minting a Semantic Soulbound Token, this event MUST be triggered to notify the listener to perform operations with the created RDF data. When calling the event, the input RDF data MUST be RDF statements, which are units of information consisting of three parts: a subject, a predicate, and an object.

UpdateRDF: When updating RDF data for a Semantic Soulbound Token, this event MUST be triggered to notify the listener to perform update operations accordingly with the updated RDF data. When calling the event, the input RDF data MUST be RDF statements, which are units of information consisting of three parts: a subject, a predicate, and an object.

RemoveRDF: When burning or revoking a Semantic Soulbound Token, this event MUST be triggered to notify the listener to perform operations with the removed RDF data for the Semantic SBT. When calling the event, the input RDF data MUST be RDF statements, which are units of information consisting of three parts: a subject, a predicate, and an object.

Rationale

RDF is a flexible and extensible data model based on creating subject-predicate-object relationships, often used to model graph data due to its semantic web standards, Linked Data concept, flexibility, and query capabilities. RDF allows graph data to be easily integrated with other data sources on the web, making it possible to create more comprehensive and interoperable models. The advantage of using RDF for semantic description is that it can describe richer information, including terms, categories, properties, and relationships. RDF uses standard formats and languages to describe metadata, making the expression of semantic information more standardized and unified. This helps to establish more accurate and reliable semantic networks, promoting interoperability between different systems. Additionally, RDF supports semantic reasoning, which allows the system to automatically infer additional relationships and connections between nodes in the social graph based on the existing data.

There are multiple formats for RDF statements. We list six most widely adopted RDF statement formats in the EIP: Turtle, N-Triples, RDF/XML, RDF/JSON,N-Quads, and TriG. These formats have different advantages and applicability in expressing, storing, and parsing RDF statements. Among these, Turtle is a popular format in RDF statements, due to its good human-readability and concision. It is typically used as the default format in this EIP for RDF statements. Using the Turtle format can make RDF statements easier to understand and maintain, while reducing the need for storage, suitable for representing complex RDF graphs.

Backwards Compatibility

This proposal is fully backward compatible with ERC-721 and ERC-5192.

Security Considerations

There are no security considerations related directly to the implementation of this standard.

Copyright and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve Ethereum Builders, Scale the Community.
Resources
GitHub
Supported by