Skip to main content

Content Metadata

User-defined metadata is an arbitrary JSON structure that can be stored within a content object. The metadata can be modified as long as the content object has not been finalized. Query functionality provides efficient retrieval of subsets of the metadata.

Example metadata with relative and absolute links:

{
  "name": { "/": "./meta/titles/en" },
  "titles": {
    "en": "Loop the Hoop",
    "de": "Greif den Reif",
    "fr": "Le cerceau dans le berceau"
  },
  "directors": [
    { "/": "/qfab/hq__QmbWqTrE/meta/library/directors/Andrew Hooper" },
    { "/": "/qfab/hq__QmbWqTrE/meta/library/directors/Jackie Looper" }
  ],
  "assets": {
    "poster": { "/": "./files/images/poster-1080x768.jpg" },
    "trailer": { "/": "/qfab/hq__6ABbaHWb/rep/playout/default/options.json" },
    "main": { "/": "/qfab/hq__2wBPuKYi/rep/playout/default/options.json" },
  },
  "files": { ... }
}

Metadata may contain links to other metadata items, files, parts or even bitcode-generated information of the same or different content objects.

Relative links refer to information within the same content object. They are denoted with a starting ./ prefix followed by the link type, called selector. The example on the right shows a metadata link in the name element that refers to the English version of the title.

Absolute links point to items in another content object. They always start with /qfab/, followed by the hash of the target content object and the link selector. In the example, the directors' information is actually stored in another content object.

Links to other parts of a content object's metadata. Metadata links may point to other links or metdata subtrees that contain links. However, circular dependencies are not permitted.

Example File Link

{ "/": "/qfab/hq__DzmzXsZuSxfN1yttYsJPLeYs14Ef8aHvNvW376MTVMt6NtNdiNY1NqaoW1SnPr7pVxEe1wr3Dy/files/images/poster.jpg" }

Links to a file in a file bundle.

Example Rep Link

{ "/": "./rep/playout/default/options.json" }

Links to the rep API endpoint for a content object.

Example Blob Link

{
  "/": "./blob",
  "data": "Y2xlYXIgZGF0YQ==",
  "encryption": "cgck"
}

A blob link is a relative link with the blob selector, a data property that contains base64-encoded bytes, and an optional "encryption" property:

  • none (default)
  • cgck

Blob links are used to include small amounts of binary (and usually encrypted) data in metadata, and have it served in binary form (and optionally decrypted) by the fabric node just like content parts or files in a bundle. Use only in cases where the amount of data does not justify creating a separate part or a file bundle.

Example auto-update link:

{
  "/": "/qref/hq__ABC/files/images/poster.jpg",
  "auto_update": {
    "tag": "latest"
  }
}

Content objects are immutable once finalized and published. This offers many advantages like simplified content distribution management, deterministic routing, content integrity proofs, etc. However, it makes change management to inter-dependent content objects more complex: an update in a given content object (achieved by creating a new content version) requires an update (with a new version) to each content object higher up in the content hierarchy...

To simplify this task, the content fabric offers auto-update links. They provide a single, but extremely useful function: they allow to retrieve all (directly and indirectly) referenced content objects in a hierarchy that have newer versions and hence need updates. In addition, the result includes the "bottom-up" order in which updates have to be made, as well as information about all the links that form the dependency graph. See Get Object & Update Graph.

Auto-update links are regular absolute links that contain a link property auto_update - see example on the right. The value of the auto_update property is a JSON object that may be empty or contain a tag to denote the desired version of the target content. For now only the tag latest is available, and will be used automatically if not specified.