NFT Metadata

Semantics and Non-Fungible Tokens for copyright management

ERC fields

In the case of ERC-721 we have the following as a standard schema:

{
    "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."
        }
    }
}

Here's info about ERC-1155 respectively.

The json schema doesn't restrict the properties in the json file, only suggests a convention. It's up to the consumer app to interpret them. Normally marketplaces use an additional field"properties" or "attributes" for presenting different traits.

Advanced metadata structure carrying semantics

At Silvermind we leverage JSON-LD to write metadata of NFT. We do it in a way that it's compatible with ERC standard but extended with semantic vocabularies.

To make it robust, we may use generic vocabularies, but in general it all winds up to Schema.org and Dublin Core as the most popular frameworks. In fact Dublin Core fields we already use in the artwork metadata, so the transition is trivial.

Here's the example structure of how NFT metadata will look like:

{
  "@context": "https://schema.org/",
  "@type": "Photograph",
  
  "name": "...",
  "description": "...",
  "image": "ipfs://.....",
  ...... more schema.org properties ......
  
  "external_url": "ipfs://....."
  "attributes": [...]
  "properties": {...}
}

Describing NFT metadata in such a way, is backwards compatible with NFT marketplaces as well as interoperable with systems which support semantic standards (it's high-time marketplaces should do that), such as web crawlers or other robots.

Here's the summary of all the fields that Silvermind supports on a photograph art NFT.

Field	Vocabulary	Semantics
name	ERC-721 schema.org/Thing	Identifies the asset to which this token represents. Normally it should be inherited from the asset title, such as XMP-dc:title field.
description	ERC-721 schema.org/Thing	Describes the asset to which this token represents Normally it should be inherited from the asset description, such as XMP-dc:description field. However, marketplaces allow Markdown syntax here, so the description can be more elaborate than what we see in the artwork metadata.
image	ERC-721 schema.org/Thing	A URI pointing to a resource with mime type image/* representing the asset to which this token represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive. At the moment of writing foundation.app doesn't support WebP images and is suggesting images of 3000px width. However, any marketplace, whatever image one uploads, will generate a smaller preview image. To stay on the safe side, currently best is to use PNG and JPG formats (of course with metadata rectified on them) of under 50MB in size. For Silvermind this field serves as a "display image", which is good enough in many cases to be the artwork artefact itself. However, the artwork artefact we present through CreativeWork:associatedMedia. It's a thumbnail of the actual artwork artefact. For now it's a URI on IPFS, hopefully in the future marketplaces will support schema.org/ImageObject
image_url	Some marketplaces	Same URI as used for image. Probably legacy field.
image_details	Some marketplaces	Normally marketplaces do their own caching of digital assets and therefore image_details might be redundant. However, for backwards compatibility we keep this field. Note that image_details will be of the image (preview), not necessarily the artwork itself. "image_details": { "bytes": 2465499, "format": "PNG", "sha256": "de42ae8c5439b01319ed88a951afce37dcbdd2681123f329815a6f05d922ee7e", "width": 1024, "height": 1024 },
external_url	OpenSea specific	OpenSea is using it to show the original artefact. Just to be compatible with OpenSea we fill it out with the same IPFS url as the schema.org/Thing::url
attributes	OpenSea specific	Used to represent traits for instance on OpenSea.
properties	OpenSea specific	Used to represent various features or even traits in marketplaces such as OpenSea. Sort of equivalent to attributes but expressed differently.
*		NFT standards don't prevent arbitrary fields. However, at Silvermind we don't add more than the basics for backward compatibility, everything else is expressed through the schema.org vocabulary.
-	-	-
@context	schema.org	Exact value "https://schema.org/"
@type	schema.org	Should be CreativeWork, Photograph or a MediaObject (e.g. ImageObject)
@id	schema.org/CreativeWork	We use this instead of identifier. The value must be the same as identifier saved in image metadata XMP-dc:identifier. This id is a future-proof approach where bots would try to organise all semantically rich NFTs into a graph.
sameAs	schema.org/Thing	URL pointing to the NFT on a blockchain scanner, such as Etherscan.
url	schema.org/Thing	It's the URI on IPFS pointing to a single downloadable artefact representing the artwork. It can be a zip file or the large image file or any sort of EDA. Same as external_url for OpenSea.
license	schema.org/CreativeWork	IPFS URI taken from image metadata XMP-xmpRights:WebStatement
copyrightHolder	schema.org/CreativeWork	The owner person or organisation derived from XMP-xmpRights:Owner image metadata
copyrightYear	schema.org/CreativeWork	The year mentioned in Exif:copyright
contributor	schema.org/CreativeWork	The contributor person or organisation as defined in image metadata XMP-dc:contributor
creator	schema.org/CreativeWork	The person or organisation derived from image metadata XMP-dc:creator
encodingFormat	schema.org/CreativeWork	MIME type of the main artefact which is available through Thing:url. Normally it will be a "application/zip" file comprised of CreativeWork:associatedMadia but in certain cases it can be an image itself (e.g. high resolution image)
publisher	schema.org/CreativeWork	The person or organisation derived from image metadata XMP-dc:publisher
dateCreated	schema.org/CreativeWork	Derived from image metadata Exif:CreateDate or Exif:DateTimeOriginal. We ony care about the date (not date and time)
dateModified	schema.org/CreativeWork	The timestamp taken from image metadata Exif:ModifyDate
datePublished	schema.org/CreativeWork	The date from image metadata XMP-dc:date
version	schema.org/CreativeWork	NFT metadata might be updatable by the contract owner. This is useful for enriching the NFT record semantically or even changing the artwork upon a new release. So we suggest using this field as a counter, which increments when dateModified changes.
associatedMedia	schema.org/CreativeWork	Assets that are associated to the NFT. Normally these are files within the main artefact zip file which represents the contents of the artwork as a single unit. These include: certificate of authenticity, quick view html, images of different dimensions, etc. Importantly, the checksum for each media object should be available in this field for ensuring/validating authenticity.
additionalProperty	schema.org	Normally used on associatedMedia objects and some other very technical things.

Note that some of the information that we write into NFT is actually available by querying the blockchain, however, having it directly as NFT metadata saves resources when validating the authenticity.

Also we only listed the main fields that are crucial for describing the artwork, one may choose to use the whole vocabulary of https://schema.org/CreativeWork. This will eventually serve the bots and AI to include NFTs into the the global giant graph knowledgebase.