iiif-commons / manifesto Goto Github PK

To get the parent independent of the iiif version I am using the following code:

if (manifestoData.context === 'http://iiif.io/api/collection/2/context.json') {
  manifestData.parent = manifestoData.getProperty('within');
} else if (manifestoData.context === 'http://iiif.io/api/presentation/3/context.json') {
  manifestData.parent = manifestoData.getProperty('partOf');
}

Is there a way without the context check?

I tried manifestData.parentCollection but it was undefined.

We chatted briefly about this in Edinburgh, but I wanted to create an issue to explore possible ways to reduce the bundle size (188kB). Have you explored any avenues of doing this?

I've thought about a few options including:

• Modifying build process to provide a slimmed down version
• Changing from commonjs modules and browserify

Any other things worth trying here?

if I use IIIF v3 with the rights attribute the output of getLicense is empty. It would be nice to get rights if @context is http://iiif.io/api/presentation/3/context.json

Is it possible to get error messages if a manifest file is invalid?

For a example if the id or label is missing.

Something like:

manifesto = manifesto.create(json);
if (!manifesto.isValid()) {
 let errors =  manifesto.getErrors();
}

http://www.jbrantly.com/typescript-and-webpack/

Can this library also be used to generate a manifest files? If not is this feature planed?

Something like:

const manifest = new Manifest();
manifest.setId(...);
manifest.toJson();

Add the ability to retrieve translated labels and values in a language we ask for which could be different than the manifesto instance locale.

This use case is a metadata language switcher for Mirador

I'm not sure if this is related but we recently saw this issue in UV pop up UniversalViewer/universalviewer#652 not sure if this is related.

Canvas.getCanonicalImageUri currently falls back to the thumbnail property if it fails to find an image annotation:

https://github.com/UniversalViewer/manifesto/blob/master/src/Canvas.ts#L57

This should be moved back to canvas.getThumbUri:

https://github.com/UniversalViewer/manifesto/blob/master/src/Canvas.ts#L95

Canvas.getThumbUri should contain all logic for acquiring the thumb URI, including calls to getCanonicalImageUri.

https://gist.github.com/tomcrane/093c6281d74b3bc8f59d
https://github.com/sul-dlss/iiifManifestLayouts/blob/master/src/thumbnailFactory.js

Context should be string[] | string not string

https://github.com/IIIF-Commons/manifesto/blob/master/src/JSONLDResource.ts#L2

The warning message is shown even getRequiredStatement is used.

Version: 3.0.3

Hello guys,
Thanks for manifesto..

in latest commit, you created internal.ts as proxy for importing inside lib. now with this, bundlers like rollup cannot perform tree-shaking.
let's say we want to import only Canvas class into a project, without entire library, then as that imports exports from internal.js, and it inturn imports everything, then rollup bundles entire manifesto for one class. tree shaking is essential for smaller builds.
internal.js giving no other practical value than giving these inconviences and creating circular imports, etc.

Think this requires more than just a fudge (of adding a context check to getLogo etc), as there can be multiple

https://iiif.io/api/presentation/3.0/#provider

The code just looks for an "images" property, which is not present on a v3 manifest which has "items".

The problem shows in the UniversalViewer when using the download function on this example:
https://uv-v3.netlify.app/#?c=&m=&s=&cv=&manifest=https%3A%2F%2Fd.lib.ncsu.edu%2Fcollections%2Fcatalog%2Fnubian-message-2003-04-01%2Fmanifest%3Fv3%3Dtrue&xywh=-411%2C-106%2C5665%2C5114

umd bundle, with out minification is of size nearly 350k, and 80% of that is node js shims, for http, request, streams, buffers, urls, so on.. which are bloat for browser side. hence following proposal:

• use fetch for all network requests. it has powerful promice based api built into browsers, and have very good support across browsers. and it handles both http, and https with same interface
• on node use node-fetch, which provides full api compatability with browser fetch.
• we can easily have some 30 lines wrapper around them for uniform handle, and keep them out from bundling, thus both node and browser can be supported. we used this method in our apps in production. We used rollup for bundling, which is much powerful for library bundling.

it seems only Util.js performs networking.. if it is ok, i will try to create a PR with those changes.

I would be happy to help out on how manifesto might approach sequences in Prezi v3.

The two approaches I've thought about:

• #79 seems to try and teach Range to behave more like a Sequence is there the desire to move that direction?
• Or would we want to teach getSequences to be able to parse v3 ranges that have the behavior sequence and return Sequence?

Has anyone else been thinking about support of this?

An example of a manifest hand crafted w/ v3 range sequences: https://gist.githubusercontent.com/mejackreed/a0c7e3ce7990042b2842980d136371d7/raw/manifest.json

These changes seem to have been introduced in the Presentation 3.0.0 Beta release: https://iiif.io/api/presentation/3.0/#placeholdercanvas and https://iiif.io/api/presentation/3.0/#accompanyingcanvas (there is also some reference in IIIF/api#1836).

This might be unnecessary and a part of a larger epic comprised of "support the 3.0.0 Beta specification", but I just wanted to please identify given the current support in the Universal Viewer.

Question / feature request:

Unless I'm mistaken it seems like manifesto doesn't currently provide methods for directly obtaining embedded annotations in v3 manifests — those that exist in the annotations array at the canvas level.

Here are some example recipes from the cookbook that show the structure I'd like to access:

• Full canvas
• Tagging
• Referencing external annotation page file
• More

For my own needs I've been able to use getProperty("annotations") on a canvas to iterate and instantiate annotations with the appropriate manifesto constructors (this only covers something similar to the tagging recipe), like so:

  type RawAnnotationPage = {
    id: string;
    type: string;
    items: Array<RawAnnotation>;
  };

  type RawAnnotation = {
    id: string;
    type: string;
    motivation: string;
    body: RawAnnotationBody;
    target: string;
  };

  type RawAnnotationBody = {
    type: string;
    value: string;
    language: string;
    format: string;
  };

  function getAnnotationPages(canvases: Canvas[], options: Manifest["options"]): Array<AnnotationPage> {
    const annotationPages: Array<AnnotationPage> = [];

    if (canvases.length) {
      canvases.forEach((canvas) => {
        // "getProperty" ejects and results in raw JSON
        // We need to instantiate each level with the appropriate constructor
        const rawAnnotationPages: Array<RawAnnotationPage> =
          canvas.getProperty("annotations") || [];

        annotationPages.push(
          ...rawAnnotationPages.map((rawAnnotationPage) => {
            const rawAnnotations: Array<RawAnnotation> | undefined =
              rawAnnotationPage.items;

            return new AnnotationPage(
              {
                ...rawAnnotationPage,
                items: rawAnnotations.map((rawAnnotation) => {
                  return new Annotation(rawAnnotation, options);
                }),
                type: rawAnnotationPage.type,
              },
              options,
            );
          }),
        );
        return [];
      });
    }
    return annotationPages;
  }

But it would be really cool if there was ways of accessing these annotations with methods directly in manifesto.

See UniversalViewer/universalviewer#385

On https://iiif-commons.github.io/manifesto/ the link https://viewdir.github.io/manifesto/ is not working.

Perhaps I'm doing it wrong, but I can get a viewing direction on a manifest with the getViewingDirection() method, but I can't do the same on a Collection. Viewing direction on Collections is a Prezi 3.0 feature, along with Sequences and Ranges.

Add items getters for collections, manifests, sequences, canvases, ranges.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get

Is there a way to use the create() method without using loadManifest()? I cannot figure out how to do this. Something like:

import manifesto from '../node_modules/manifesto.js/dist/server/manifesto.js'
import manifest from './data/manifest'
const manifestation = manifesto.create(manifest)

This results in the following error (manifest is valid and loads fine asynchronously):

SyntaxError: Unexpected token u in JSON at position 0

There are a number of use cases where this would come in handy, particularly server-side when you have a bunch of manifests on the file system and don't need to fetch externally. It could also be useful in the client for general purposes. I'm currently just working on a prototype to demo managing state with Redux. I have a bunch of fixtures in my code and fetching external data is unnecessary for my purposes.

Line 371 expect both to be well formed, I would recommend inserting a line

if (!on || !target) { return undefined; }

which would act as a safe-keeper.

I am using https://github.com/dbmdz/mirador-textoverlay and this seems to be provoked by a bad line in my ALTO (I suppose ?), but it still feel like some safety here would avoid a complete throw.

UniversalViewer/universalviewer#85

UniversalViewer/universalviewer#87

Add a manifesto.hasServiceDescriptor helper method. This is used to determine via @profile and type whether a resource will have an info.json associated with it. This can then be used by the UV to know whether to issue a HEAD (no info.json) or GET (has info.json).

I thin Manifesto/Canvas is returning quality "native" in the following lines

For a manifest which has an image context of 2.0, so I'm not sure why manifesto is returning "native"

The manifest I'm testing with is here: https://scta.info/iiif/graciliscommentary/lon/manifest

(maybe there is something wrong with the manifest. I'm not sure. Let me know if you see something.)

See the issue I've created here ProjectMirador/mirador#1831

The current implementation of method Canvas.getMaxDimensions only returns a Size object for images with api 2.0. It checks for a profile where maxWidth and maxHeight are located, while these properties are located in the root in 3.0.

The question is: should IExternalResource be extended with properties in the root (I cannot check canvas.externalResource.data.maxWidth without resetting the type first to any), or should these
properties from image api 3.0 also be put in the same place (profile), even though that api version
never locates them there.

In the recipe provided at https://iiif.io/api/cookbook/recipe/0064-opera-one-canvas/, one Canvas has two AnnotationPage objects.

{
  "id": "https://iiif.io/api/cookbook/recipe/0064-opera-one-canvas/canvas/1",
  "type": "Canvas",
  "width": 1920,
  "height": 1080,
  "duration": 7278.422,
  "items": [
    {
      "id": "https://iiif.io/api/cookbook/recipe/0064-opera-one-canvas/canvas/1/annotation_page/1",
      "type": "AnnotationPage",
      "items": [
        {
          "id": "https://iiif.io/api/cookbook/recipe/0064-opera-one-canvas/canvas/1/annotation_page/1/annotation/1",
          "type": "Annotation",
          "motivation": "painting",
          "target": "https://iiif.io/api/cookbook/recipe/0064-opera-one-canvas/canvas/1#t=0",
          "body": {
            "id": "https://fixtures.iiif.io/video/indiana/donizetti-elixir/vae0637_accessH264_low.mp4",
            "type": "Video",
            "format": "video/mp4",
            "height": 1080,
            "width": 1920,
            "duration": 3971.24
          }
        }
      ]
    },
    {
      "id": "https://iiif.io/api/cookbook/recipe/0064-opera-one-canvas/canvas/1/annotation_page/1",
      "type": "AnnotationPage",
      "items": [
        {
          "id": "https://iiif.io/api/cookbook/recipe/0064-opera-one-canvas/canvas/1/annotation_page/1/annotation/2",
          "type": "Annotation",
          "motivation": "painting",
          "target": "https://iiif.io/api/cookbook/recipe/0064-opera-one-canvas/canvas/1#t=3971.24",
          "body": {
            "id": "https://fixtures.iiif.io/video/indiana/donizetti-elixir/vae0637_accessH264_low_act_2.mp4",
            "type": "Video",
            "format": "video/mp4",
            "height": 1080,
            "width": 1920,
            "duration": 3307.22
          }
        }
      ]
    }
  ]
}

Canvas.getContent() does not seem to be able to get the second AnnotationPage content.

const manifesto = require('manifesto.js/dist-commonjs/');

manifesto.loadManifest('https://iiif.io/api/cookbook/recipe/0064-opera-one-canvas/manifest.json').then((data) => {
  const manifest = manifesto.parseManifest(data);
  const sequence = manifest.getSequenceByIndex(0);
  const canvas = sequence.getCanvasByIndex(0);
  const content = canvas.getContent();
  console.log(content);
});

Currently, this output goes as follows.

// The Annotation in the second AnnotationPage object is missing.
[
  Annotation {
    __jsonld: {
      id: 'https://iiif.io/api/cookbook/recipe/0064-opera-one-canvas/canvas/1/annotation_page/1/annotation/1',
      type: 'Annotation',
      motivation: 'painting',
      target: 'https://iiif.io/api/cookbook/recipe/0064-opera-one-canvas/canvas/1#t=0',
      body: [Object]
    },
    context: undefined,
    id: 'https://iiif.io/api/cookbook/recipe/0064-opera-one-canvas/canvas/1/annotation_page/1/annotation/1',
    options: {
      defaultLabel: '-',
      locale: 'en-GB',
      resource: [Manifest],
      pessimisticAccessControl: false
    }
  }
]

This seems to be because only the first element is processed in the line shown below.
https://github.com/IIIF-Commons/manifesto/blob/master/src/Canvas.ts#L150

I don't know if this is an issue that the recipe needs to be fixed or Canvas.getContent() needs to be improved.
If the modification of Canvas.getContent() causes backward compatibility issues, you might consider creating new methods, such as Canvas.getContents(), Canvas.getContentByIndex(), etc.
If the recipe should be modified, please let me know. I'll report it to the recipe repository.

Hi all,

This isn't quite related to the Manifesto codebase but I just wanted to flag that the tutorial link is returning a 404. The specific error is DEPLOYMENT_NOT_FOUND.

Is there somewhere else I can view a live version of this?

Thanks,
Joshua

I switched my project to react-scripts version 5.0.0-next.47 because of the many unpleasant warnings the latest stable version of react-scripts throws these days. This works good enough for me, however manifesto causes a lot of warnings because it could not find/parse source maps. Because manifesto seems to be the only package causing these warnings I'm bringing this up here.

WARNING in ./node_modules/manifesto.js/dist-esmodule/Thumbnail.js Module Warning (from ./node_modules/source-map-loader/dist/cjs.js): Failed to parse source map from '/Users/seige/seige.digital/strollview-editor/node_modules/manifesto.js/src/Thumbnail.ts' file: Error: ENOENT: no such file or directory, open '/Users/seige/seige.digital/strollview-editor/node_modules/manifesto.js/src/Thumbnail.ts' @ ./node_modules/manifesto.js/dist-esmodule/internal.js 25:0-28 25:0-28 @ ./node_modules/manifesto.js/dist-esmodule/index.js 1:0-27 1:0-27 @ ./src/components/ImportLoader.js 10:0-37 102:18-37 @ ./src/App.js 8:0-56 35:39-51 @ ./src/index.js 7:0-24 14:8-11

Not sure if the implementation of Utils.getServices() is right.

I'm working with mirador viewer (uses manifetso.js)

With the new version I have a problem. If I ad a Search Service to the manifest, it will also been loaded for the Image Service.

If I read the iiif docs right, the Top Level Service (https://iiif.io/api/presentation/3.0/#service) should not be loaded. There should only be a way to load from Services (https://iiif.io/api/presentation/3.0/#services)

viewingHint in v3 are in "behavior", and is a manifest object list (no longer in sequences). manifesto should check for "paged", etc. there.

Serialise the parsed manifest back into jsonld.

In the v3 API, service profiles can be non URIs. eg. ("level2"). I started testing the UV with v3 manifests. What happens is that if a service profile is not in the predefined service enumeration, then it tries to dereference the resource id, and that does not work. I would suggest using a context to validate a service profile rather than maintaining a static list, (but the v3 context does not define them).

There could perhaps be a global registry for service providers that would be served as an independent context, or have a standard service context name for manifesto to check these profiles against.