Hi there Ethereum Magicians,
My name is Tim Daubenschütz and I’m one of the co-authors of the COALA IP
specification (https://github.com/COALAIP/specs). I’m currently working with a
client that wants to put film rights on the Ethereum blockchain and thought of
using ERC721 to tokenize the rights and COALA IP for modeling a right’s
metadata. I did some research into ERC721 and found out that there
is an optional metadata extension that specifies name, symbol and
tokenURI. That’s great, I thought, but when I looked more closely into the
specification I noticed that tokenURI expects a very specific JSON schema of
the form:
{
"title": "Asset Metadata",
"type": "object",
"properties": {
"name": {
"type": "string",
"description": "Identifies the asset to which this NFT represents",
},
"description": {
"type": "string",
"description": "Describes the asset to which this NFT represents",
},
"image": {
"type": "string",
"description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive.",
}
}
}
As we’ll see later, this JSON schema will lead to problems defining a COALA IP
right as an ERC721 tokenURI. But first, let’s introduce COALA IP.
COALA IP is a blockchain-ready licensing protocol for intellectual property.
It’s based on the LinkedContentCoalition’s Right Reference
Model, a model that existing IP
standards are drafted upon (e.g. DDEX for music, PLUS for stock photos).
At COALA IP’s core are data models that can be used to model an ontology using
JSON-LD. There are data models for an entity creating a work (the Party entity),
the work itself (Creation and Manifestation entity) as well as an entity for
representing copyright and licensing rights (the Right entity). These models
are then linked to build an ontology using JSON-LD (and IPLD - a minor detail).
A specialty of COALA IP is that it maps the LCC’s “RightAssignment” entity -
which represents a transfer of copyright or licensing rights from one Party to
another - to blockchain transfers. The idea behind it is to make as many
blockchains compatible with COALA IP as possible as they only need
to have the following features:
- Need to allow for an entity to be stored on the substrate (I’m saying
substrate because it can include tech like IPFS) - Need to allow an entity to be transferred natively.
So when I first heard of ERC721 I got excited, especially because it
would mean that we can tokenize COALA IP Rights as ERC721 tokens and transfer
them between wallets seamlessly. However, a COALA IP Right looks like this:
{
"@context": "http://coalaip.schema/",
"@type": "Right",
"@id": "<URI pointing to this object>",
"usages": "all|copy|play|stream|...",
"territory": "<URI pointing to a Place>",
"context": "inflight|inpublic|commercialuse...",
"exclusive": true|false,
"numberOfUses": "1, 2, 3, ...",
"share": "1, 2, 3, ..., 100",
"validFrom": {
"@type": "Date",
"@value": "2016-01-01"
},
"validTo": {
"@type": "Date",
"@value": "2017-01-01"
},
"source": "<URI pointing to a Copyright>",
"license": "<URI pointing to a license on an immutable ledger>"
}
My initial excitement deflated once I saw the JSON schema that ERC721
optionally recommends. It’s totally incompatible.
How can we reconcile this? A few ideas I had so far are:
1. Change COALA IP to make it fit ERC721
Hardly possible. We can try to squeeze COALA IP information into name,
description and image, but that will ultimately only confuse wallet end users.
A COALA IP’s right’s essence is that the license is linked as a PDF and that
certain crucial values like share, exclusive, etc. are contained in the
data model. Making COALA IP fit ERC721 would erase most of COALA IP’s positive
properties and only add a half-baked tokenized right into users’ wallets.
2. Define name, description and image, but also define COALA IP Right’s properties
Probably the easiest solution out there. Instead of changing anything in COALA IP and ERC721, I’ll just add more metadata to the JSON schema. In fact, some websites like Opensea.io have gone ahead already and support additional properties in the tokenURI. The problem with this is the challenge for wallet developers. Will they care about COALA IP properties enough to implement them separately? Likely not.
3. Write an EIP that supports a COALA IP Right as JSON schema
More difficult than 1. and 2… To create an EIP one needs to gather use cases,
reference implementations, etc. In the end it’s also highly unlikely that an
EIP solely for the purpose of tokenizing IP rights is gonna stand out enough
for wallet developers to implement it.
4. Write a standard to allow arbitrary data to be included into an ERC721 tokenURI (e.g. using JSON-LD)
Definitely the most difficult thing to do. Not only is some of the tech
controversial (e.g. JSON-LD), it’s also unclear to me if wallet developers
would adopt such a way more complicated standard.
So now what?
After all of these thoughts, I’m now here, looking for the council of the
Ethereum Magicians. What do you think is the best option to go with? Is there
options that I missed? Specifically, what do you think of options 3. and 4., and
do you think they’re viable.
Additionally: Are you an ERC721 implementer and have encountered the issues
described in this post? If so, I’d like to hear from you. After all, we’re
calling these things non-fungible tokens, but so far they can hardly be more
than in-game items. There are so many more use cases to be explored!
Best,
Tim
