> For the complete documentation index, see [llms.txt](https://docs.silvermind.art/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.silvermind.art/fundamentals/digital-asset/nft-metadata.md).

# NFT Metadata

Semantics and Non-Fungible Tokens for copyright management

### ERC fields

In the case of [ERC-721](https://github.com/ethereum/ercs/blob/master/ERCS/erc-721.md) 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](https://github.com/ethereum/ercs/blob/master/ERCS/erc-1155.md#erc-1155-metadata-uri-json-schema) respectively.

{% hint style="info" %}
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.
{% endhint %}

### 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](https://schema.org/) and [Dublin Core](https://www.dublincore.org/) as the most popular frameworks. In fact Dublin Core fields we already use in the [artwork metadata](/fundamentals/digital-asset/artwork-metadata.md), 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.

<table><thead><tr><th width="186">Field</th><th width="227">Vocabulary</th><th>Semantics</th></tr></thead><tbody><tr><td><a href="https://schema.org/name">name</a></td><td>ERC-721<br>schema.org/Thing</td><td>Identifies the asset to which this token represents.<br><br>Normally it should be inherited from the asset title, such as <em>XMP-dc:title</em> field.</td></tr><tr><td><a href="https://schema.org/description">description</a></td><td>ERC-721<br>schema.org/Thing</td><td><p>Describes the asset to which this token represents</p><p><br>Normally it should be inherited from the asset description, such as <em>XMP-dc:description</em> field. However, marketplaces allow Markdown syntax here, so the description can be more elaborate than what we see in the artwork metadata.</p></td></tr><tr><td><a href="https://schema.org/image">image</a></td><td>ERC-721<br>schema.org/Thing</td><td><p>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.<br><br>At the moment of writing <a href="https://help.foundation.app/hc/en-us/articles/6037747211547-What-are-the-technical-specs-for-minting-an-NFT-on-Foundation-">foundation.app</a> 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 <strong>PNG</strong> and <strong>JPG</strong> formats (<a href="/fundamentals/digital-asset/artwork-metadata.md">of course with metadata rectified on them</a>) of under <strong>50MB</strong> in size.<br><br>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 <em>CreativeWork:associatedMedia</em>.</p><p></p><p>It's a thumbnail of the actual artwork artefact. For now it's a URI on IPFS, hopefully in the future marketplaces will support <em>schema.org/ImageObject</em></p></td></tr><tr><td>image_url</td><td>Some marketplaces</td><td>Same URI as used for <em>image</em>. Probably legacy field.</td></tr><tr><td>image_details</td><td>Some marketplaces</td><td><p>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 <em>image</em> (preview)<em>,</em> not necessarily the artwork itself.</p><pre><code>"image_details": {
    "bytes": 2465499,
    "format": "PNG",
    "sha256": "de42ae8c5439b01319ed88a951afce37dcbdd2681123f329815a6f05d922ee7e",
    "width": 1024,
    "height": 1024
  },
</code></pre></td></tr><tr><td>external_url</td><td>OpenSea specific</td><td>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 <em>schema.org/Thing::url</em></td></tr><tr><td>attributes</td><td>OpenSea specific</td><td>Used to represent traits <a href="https://docs.opensea.io/docs/metadata-standards">for instance on OpenSea</a>.</td></tr><tr><td>properties</td><td>OpenSea specific</td><td>Used to represent various features or even traits in <a href="https://docs.opensea.io/docs/metadata-standards">marketplaces such as OpenSea</a>. Sort of equivalent to <em>attributes</em> but expressed differently.</td></tr><tr><td>*</td><td></td><td>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.</td></tr><tr><td>-</td><td>-</td><td>-</td></tr><tr><td>@context</td><td>schema.org</td><td>Exact value "https://schema.org/"</td></tr><tr><td>@type</td><td>schema.org</td><td>Should be CreativeWork, Photograph or a MediaObject (e.g. ImageObject)</td></tr><tr><td>@id</td><td>schema.org/CreativeWork</td><td>We use this instead of <a href="https://schema.org/identifier">identifier</a>. The value must be the same as identifier saved in <a href="/fundamentals/digital-asset/artwork-metadata.md">image metadata XMP-dc:identifier</a>. This id is a future-proof approach where bots would try to organise all semantically rich NFTs into a graph.</td></tr><tr><td><a href="https://schema.org/sameAs">sameAs</a></td><td>schema.org/Thing</td><td>URL pointing to the NFT on a blockchain scanner, such as Etherscan.</td></tr><tr><td><a href="https://schema.org/url">url</a></td><td>schema.org/Thing</td><td>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 <a href="/fundamentals/encrypted-digital-artefact-eda.md">EDA</a>. Same as external_url for OpenSea.</td></tr><tr><td><a href="https://schema.org/license">license</a></td><td>schema.org/CreativeWork</td><td>IPFS URI taken from <a href="/fundamentals/digital-asset/artwork-metadata.md">image metadata XMP-xmpRights:WebStatement</a></td></tr><tr><td><a href="https://schema.org/copyrightHolder">copyrightHolder</a></td><td>schema.org/CreativeWork</td><td>The owner person or organisation derived from <a href="/fundamentals/digital-asset/artwork-metadata.md">XMP-xmpRights:Owner image metadata</a></td></tr><tr><td><a href="https://schema.org/copyrightYear">copyrightYear</a></td><td>schema.org/CreativeWork</td><td>The year <a href="/fundamentals/digital-asset/artwork-metadata.md">mentioned in Exif:copyright</a></td></tr><tr><td><a href="https://schema.org/contributor">contributor</a></td><td>schema.org/CreativeWork</td><td>The contributor person or organisation as defined in <a href="/fundamentals/digital-asset/artwork-metadata.md">image metadata XMP-dc:contributor</a></td></tr><tr><td><a href="https://schema.org/creator">creator</a></td><td>schema.org/CreativeWork</td><td>The person or organisation derived from <a href="/fundamentals/digital-asset/artwork-metadata.md">image metadata XMP-dc:creator</a></td></tr><tr><td><a href="https://schema.org/encodingFormat">encodingFormat</a></td><td>schema.org/CreativeWork</td><td>MIME type of the main artefact which is available through <em>Thing:url</em>. Normally it will be a "application/zip" file comprised of <em>CreativeWork:associatedMadia</em> but in certain cases it can be an image itself (e.g. high resolution image)</td></tr><tr><td><a href="https://schema.org/publisher">publisher</a></td><td>schema.org/CreativeWork</td><td>The person or organisation derived from <a href="/fundamentals/digital-asset/artwork-metadata.md">image metadata XMP-dc:publisher</a></td></tr><tr><td><a href="https://schema.org/dateCreated">dateCreated</a></td><td>schema.org/CreativeWork</td><td>Derived from <a href="/fundamentals/digital-asset/artwork-metadata.md">image metadata Exif:CreateDate or Exif:DateTimeOriginal</a>. We ony care about the date (not date and time)</td></tr><tr><td><a href="https://schema.org/dateModified">dateModified</a></td><td>schema.org/CreativeWork</td><td>The timestamp taken from <a href="/fundamentals/digital-asset/artwork-metadata.md">image metadata Exif:ModifyDate</a></td></tr><tr><td><a href="https://schema.org/datePublished">datePublished</a></td><td>schema.org/CreativeWork</td><td>The date from <a href="/fundamentals/digital-asset/artwork-metadata.md">image metadata XMP-dc:date</a></td></tr><tr><td><a href="https://schema.org/version">version</a></td><td>schema.org/CreativeWork</td><td>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 <em>dateModified</em> changes.</td></tr><tr><td><a href="https://schema.org/associatedMedia">associatedMedia</a></td><td>schema.org/CreativeWork</td><td>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.</td></tr><tr><td><a href="https://schema.org/additionalProperty">additionalProperty</a></td><td>schema.org</td><td>Normally used on associatedMedia objects and some other very technical things.</td></tr></tbody></table>

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.