search

IIIF / iiif-stories

Community repository for documenting stories and use cases related to uses of the International Image Interoperability Framework.
21 stars 0 forks source link

Traceability/Citing of Reused Canvases #83

Open sdellis opened 7 years ago

sdellis commented 7 years ago

As a manifest creator, I want to see a "bibliography" that cites the original manifests of any canvases I've added that came from elsewhere, so I don't have to manually compile my references and allow others to easily link to the canvases in context of their original manifests.

azaroth42 commented 7 years ago

Not sure how this is a discovery use case. Seems like internal viewer functionality only to expose the URIs of canvases.

sdellis commented 7 years ago

The phrasing is perhaps not clear enough. In other words, someone makes a slideshow out of canvases gathered from various sources. How do I trace the dereferenced canvases back to discover what their original manifests were?

I guess the label depends on whether "discovery" is synonymous with "search", or if it also covers other discovery scenarios like this one.

azaroth42 commented 7 years ago

Then isn't it just the use of within? Seems like it's already solved?

aisaac commented 7 years ago

NB: https://github.com/IIIF/iiif-stories/issues/95#issuecomment-305055545 assessed that #95 is similar to this one.

sdellis commented 7 years ago

Yes within could be used loosely for this. But as far as I understand, within does not provide one with the ability to point back to the original manifest for citation purposes. And if there are multiple within statements, which is the original?

azaroth42 commented 7 years ago

Discussion on call:

Not in scope for discovery / import to viewers. The import takes place first, as per #95. #95 is information that is carried in the import event, which should include the source. The citation then needs to change the manifest to record that information for future clients -- citation needs a way to record and expose to others the provenance of the resource, which is not something we do in the Presentation API.

It could go into a metadata pair, or within, or related. The Presentation API is about presentation, not provenance :)

sdellis commented 7 years ago

This is really not about "provenance", but "attribution" which is in the Presentation API's scope. Reading up, I realized that there is already an attribution property. If the publisher expects attribution, then I imagine they should just make sure that any dereferenceable Resource has an attribution property for this purpose, right?

azaroth42 commented 7 years ago

Yes :)