Give access to IIIF resource URIs

[tomcrane]

For many users, the URI of the manifest/canvas they are looking at is meaningless.

But for others, it's really important to get access to this. See https://github.com/IIIF/iiif-stories/issues/74 and similar.

Prominent access to the IIIF URIs would be offputting, so I'm not sure where it would go. But it would very useful for "power user" scenarios, and debugging. In some settings-like dialogue? Or from the settings? An unobtrusive link from the more info panel?

Crudely:

Could use the folder and document icons, display the resource labels etc. The canvas may or may not be dereferenceable - the UV could test this and offer a link or a string, or just display it.

[edsilv]

Could https://github.com/viewdir/iiif-explorer-component be useful? This has a breadcrumb trail that we could add hover titles to.

On 4 Mar 2017 10:57 am, "Tom Crane" [email protected] wrote:

For many users, the URI of the manifest/canvas they are looking at is meaningless.

But for others, it's really important to get access to this. See IIIF/iiif-stories#74 https://github.com/IIIF/iiif-stories/issues/74 and similar.

Prominent access to the IIIF URIs would be offputting, so I'm not sure where it would go. But it would very useful for "power user" scenarios, and debugging. In some settings-like dialogue? Or from the settings? An unobtrusive link from the more info panel?

Crudely:

[image: where-am-i] https://cloud.githubusercontent.com/assets/1443575/23578156/7aa81f66-00c8-11e7-9acc-6fe54a311d1d.png

Could use the folder and document icons, display the resource labels etc. The canvas may or may not be dereferenceable - the UV could test this and offer a link or a string, or just display it.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/UniversalViewer/universalviewer/issues/439, or mute the thread https://github.com/notifications/unsubscribe-auth/ABRceTyMNED9pVt_KDb_BjkMNLDktyodks5riUOJgaJpZM4MTDYK .

[tomcrane]

Yes, could take the display from the explorer component. The UV has all the info in the tree already, just need to render it. If you were in 2-up mode there'd be two canvases listed at the same level.

[tomcrane]

And also, allow access to the Image API endpoint(s) currently being rendered in the viewport.

[edsilv]

Can we use the UV's external canvasIndexChanged event to construct the image api urls and display in the containing page?

[tomcrane]

as per #562, but in event form?

At any point an external actor can ask the UV for the precise content state, down to the viewport xywh (and later, what painting annos are visible). getContentState returns something along the lines of https://docs.google.com/document/d/1LKhEWWuYF-8KLkKcW_u2GlvX0epohwc7OYOVjICie5M/edit#

But the UV could also ping this info out at a sensible interval - certainly on canvas change but possibly more often.

[edsilv]

We need to get working on that basic redux example and have #562 be a serialisation of that. I've done the ground work for what manifold would need: https://github.com/edsilv/redux-experiments I talked to @stephenwf about setting up a new project to try this out. Every time the redux store is modified the UV could fire an event with the new serialised state.

[edsilv]

https://github.com/IIIF-Commons/iiif-redux

[LlGC-szw]

All issues will be triaged for further investigation or closure by the 28 September 2023. If your issue is still relevant and would like for it be investigated further please comment by 14 September 2023.

[tomcrane]

I really like this feature (although not my mockup design for it) but I think it's now re-framed as:

• allow a user to grab the IIIF Content State for whatever they are looking at right now, including a parent trail of partOf back to the manifest, e.g., copy to clipboard. This is #562
• optionally show a visualization like the screen shot above.

[mialondon]

Also relevant to #691