Derived Manifests

[stephenwf]

There is a general problem with importing remote content, or copying IIIF, when it comes to automated processes. A pipeline where digitised content is ingested and Manifests may be regenerated from source data.

I propose a new storage type for Manifests (initially) and their canvases.

{
  "@context": "https://tbc",
  "id": "https://example.org/editor",
  "@derivedFrom": "https://digirati-co-uk.github.io/wunder.json",
  "type": "DerivedManifest",
  "label": {
    "@replace": {
      "en": ["Miracle of inheritance"],
      "de": ["Wunder der Vererbung"]
    },
  },
  "items": [
    {
      "id": "https://digirati-co-uk.github.io/wunder/canvases/0",
      "type": "DerivedManifest",
      "annotations": [
        {
	  "@replaces": "https://digirati-co-uk.github.io/wunder/annos/0.json",
          "id": "https://example.org/correct-text.json",
          "type": "AnnotationPage",
          "label": {"en": ["Text of page -"]}
        }
      ]
    }
  ]
}

It would work in 2 parts:

• Have an unchanged copy of the Manifest on disk
• Have this derived Manifest that can change or be edited

You could serve up the Manifest either as a derived manifest (viewers could support it ☸︎) OR as a valid IIIF built from the source - so just the same as if you had copied it.

This would make things like saving adjuncts easier, if its say correcting an existing piece of content on the Manifest.

I would propose 4 properties:

@derivedFrom

A top level property to point to the original JSON document of a similar structure.

New properties in the derived resource will be added, and if you use the modifiers below they'll be merged.

@replace

The value of this will replace the whole "class" (object). So this:

{ 
  "@derivedFrom": "https://example.org/manifest.json",
  "label": {"@replace": {"en": ["New label"]} }
}

Where https://example.org/manifest.json resolves to:

{ 
  "label": {"none": ["Original label"]},
  "summary": {"none": ["Original summary"]},
}

produces:

{ 
  "label": {"en": ["New label"]},
  "summary": {"none": ["Original summary"]},
}

Without the @replace:

{ 
  "@derivedFrom": "https://example.org/manifest.json",
  "label": {"en": ["New label"] }
}

Would get merged in and produce:

{ 
  "label": {
    "none": ["Original label"]
    "en": ["New label"]
  },
  "summary": {"none": ["Original summary"]},
}

@replaces

Indicates that the object should replace an item in an array matching that ID.

{ 
  "@derivedFrom": "https://example.org/manifest.json",
  "homepage": [
    {
      "id": "https://example.org/new-homepage",
      "@replaces": "https://example.org/old-homepage",
      "label": {"none": ["The new homepage"]}
    }
  ]
}

@hides / @deletes

Indicates that the object matching the ID should be removed.

{ 
  "@derivedFrom": "https://example.org/manifest.json",
  "homepage": [
    {
      "@deletes": "https://example.org/old-homepage"
    }
  ]
}

Viewers, Editors + IIIF Presentation

If it was a fairly simple model, viewers could implement support for viewing these derived resources, IIIF Presentation could support saving and serving them as normal IIIF and tools like the Manifest editor or Outputs of a pipeline could return these objects as outputs, simplifying a great deal of problems when it comes to merging and combining properties.

[stephenwf]

Other properties for finer-grained control:

• Something to reorder items
• Insert a new object at an index, or before another item (before=null is first)

[stephenwf]

Another use case that this could be useful for (more generally) would be 2 people or institutions collaborating using annotations. If there was a property to link them:

{ 
  "id": "https://example-org-1.org/derivation-org-1",
  "@derivedFrom": "https://example.org/manifest.json",
  "@includes": [
    "https://example-org-1.org/derivation-org-2",
    "https://example-org-1.org/derivation-org-3"
  ],
  "annotations": [
    ...
  ]
}

Then the other orgs:

{ 
  "id": "https://example-org-1.org/derivation-org-2",
  "@derivedFrom": "https://example.org/manifest.json",
  "@includes": [
    "https://example-org-1.org/derivation-org-1",
    "https://example-org-1.org/derivation-org-3"
  ],
  "annotations": [
    ...
  ]
}

So it each org can write to their own derivation, and read from the others.