Skip to content

Commit

Permalink
Merge f0746f4 into 307d3b4
Browse files Browse the repository at this point in the history
  • Loading branch information
@JessicaChg
JessicaChg committed Apr 5, 2023
2 parents 307d3b4 + f0746f4 commit fa5cedb
Showing 1 changed file with 323 additions and 0 deletions.
323 changes: 323 additions & 0 deletions EIPS/eip-6239.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,323 @@
---
eip: 6239
title: Semantic Soulbound Tokens
description: Adding RDF triples to ERC-5192 token metadata to capture social meaning
author: Jessica Chang (@JessicaChg)
discussions-to: https://ethereum-magicians.org/t/eip-6239-semantic-soulbound-tokens/12334
status: Draft
type: Standards Track
category: ERC
created: 2022-12-30
requires: 165, 721, 5192
---

## Abstract

This proposal extends [ERC-721](./eip-721.md) and [ERC-5192](./eip-5192.md) 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](./eip-721.md) and [ERC-5192](./eip-5192.md) 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](./eip-165.md)’s `ERC165` (`0x01ffc9a7`)
1. [ERC-721](./eip-721.md)’s `ERC721` (`0x80ac58cd`)
1. [ERC-721](./eip-721.md)’s `ERC721Metadata` (`0x5b5e139f`)
1. [ERC-5192](./eip-5192.md)’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：

```text
rdfStatements = {[format]}<statements>
```

{}：OPTIONAL

<>: MUST

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

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

- `nt(n-triples)`

[`nt`](http://www.w3.org/ns/formats/N-Triples) 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:

```text
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:

```text
<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`](http://www.w3.org/ns/formats/Turtle) 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:

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

- `rdf(RDF/XML)`

[`rdf`](http://www.w3.org/ns/formats/RDF_XML) 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
<?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
<?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`](http://www.w3.org/ns/formats/RDF_JSON) describes RDF in JSON format. A triple is described as:


```text
{"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:

```json
{
"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`](http://www.w3.org/ns/formats/N-Quads) 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:

```text
subject predicate object graphLabel.
```

For example:

```text
<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`](http://www.w3.org/ns/formats/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:

```text
@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]`.

```text
[nt]subject predicate object .
```


### Contract Interface

```solidity
/**
* @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.

```solidity
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);
}
```

`ISemanticSBTUpdate` is an extension interface, that is **OPTIONAL** for this standard, used to update the RDF data for the Semantic Soulbound Token.

```solidity
interface ISemanticSBTUpdate{
/**
* @notice RDFData is a set of RDF statements that are used to represent social information about wallet addresses in the graph model.
* RDFData allows customized data schema, and developers can define data structures according to their needs. Here we provide a generic example of the structure of RDFData, using string types to define subject, predicate, and object.
* Typically, each token points to one SPO triple, and the following data structures can be used:
* struct RDFData{
* string subject;
* string[] predicate;
* string[] object;
* }
* For scenarios where multiple predicates are used to describe the same subject.
* Note: In general, the arrays of predicate and object only store one piece of data each, which, together with the corresponding subject, forms a triple of RDF data.
*/
function updateRDF(uint256 tokenId, RDFData memory rdfData) external;
}
```

### 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.

`updateRDF (uint256 tokenId, RDFData rdfData)`: This **OPTIONAL** method is used when it needs to update the RDF data for Semantic SBT. Use this method to find the RDF data for Semantic SBT by `tokenId` and perform the update. The input RDF data **MUST** conform to W3C RDF standards. When implementing this method, **SHALL** assign updaters as needed, for example, the token issuer can be assigned as an updater. When calling this method, the `UpdateRDF` event **MUST** be triggered to notify the listener for performing relevant business update.

`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](./eip-721.md) and [ERC-5192](./eip-5192.md).

## Security Considerations

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

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).

0 comments on commit fa5cedb

Please sign in to comment.