Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IIIF integration (import/export) #77

Open
pleonard212 opened this issue Sep 5, 2019 · 1 comment
Open

IIIF integration (import/export) #77

pleonard212 opened this issue Sep 5, 2019 · 1 comment
Labels
enhancement yalesi2019-20 2019-2020 development cycle in conjunction with SI

Comments

@pleonard212
Copy link
Owner

pleonard212 commented Sep 5, 2019

Some thoughts on how PixPlot can integrate with IIIF repos. This is not connected to the annotation functionality - this is only about getting images in and out.

Import

  • Parse a newline-delimited list of IIIF manifests instead of a folder of images and a csv.
  • In case of multiple images per manifest: take the first image. Assume this is the "main" image of the set. (Surely a false assumption but good enough to prove IIIF functionality. We are shooting for a use case where the objects are likely to be well represented by the first image, and the second might be something like the back of the painting or an uncropped variant with color balance targets.)
  • Take the label field of the manifest as the caption or title. (I believe label is the only field guaranteed to be present in a manifest.) Do not seek to create facets yet from the metadata (requires human judgement on a per-collection basis).

Export

  • If the PixPlot was generated from IIIF manifests, show the IIIF logo image on the Lightbox view with a link either...
    • The raw IIIF manifest itself?
      • https://manifests.britishart.yale.edu/manifest/46796
    • The IIIF manifest as an argument to a Mirador instance?
      • http://mirador.britishart.yale.edu/?manifest=https://manifests.britishart.yale.edu/manifest/46796

The problem with the first option is that the manifest itself isn't useful unless you have a Mirador or other IIIF client running somewhere. The problem with the second is, there's no central, universal Mirador instance that I know of (besides something running on your localhost). It's not clear if for example YCBA would be cool with us directing all links to their Mirador...

This Export idea only lets you drag one IIIF manifest at a time, not the much-cooler export of whole subsets of the cluster.

@pleonard212 pleonard212 added the yalesi2019-20 2019-2020 development cycle in conjunction with SI label Sep 5, 2019
@duhaime
Copy link
Contributor

duhaime commented Sep 9, 2019

I suppose there wouldn't be harm in us hosting a mirador instance ourselves on GitHub or some other free static file server. Since the client would be doing the work it shouldn't tax the little server too much even if there were lots of traffic.

I'm thinking it will make sense to factor the data collection into its own module then just use that module in this codebase...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement yalesi2019-20 2019-2020 development cycle in conjunction with SI
Projects
None yet
Development

No branches or pull requests

2 participants