License and Attribution in Image's info.json

35 views
Skip to first unread message

Robert Sanderson

unread,
Jun 13, 2014, 2:32:26 AM6/13/14
to iiif-d...@googlegroups.com

There was some offline discussion at Open Repositories 2014 about a request to add attribution and license to the image API info.json document for reporting the license of an image, and an attribution statement that must be displayed in the fashion as in the Presentation API.

The feeling in Helsinki, after some discussion, was that:

* info.json is for the technical metadata about the image, not rights or descriptive metadata
* Start of a slippery slope to include rights. We don't have a title/label field even.
* Auth may change the requirements and be a good slot to report this information

And hence the current idea is to defer until we have a better understanding of how to apply authentication and authorization in IIIF APIs.

Any further comments on this topic would be greatly appreciated :)

Rob (& eds)

--
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305

Glen Robson

unread,
Jun 16, 2014, 7:13:47 AM6/16/14
to iiif-d...@googlegroups.com
Hi Rob,

I think we were one with this use case and if I can just give a working example. For some projects we have negotiated with a copyright holder to allow us access to show an item on a certain website for example:


(Note this isn’t IIIF yet) but this doesn’t give others permissions to reuse the image. If you click the download button you’ll get a copy of the copyright notice. Currently if somebody knew the protocol we use to display the jp2 they could crawl the tiles and build up a full size image. We don’t have any technical protection against this apart from the complications of using a none public protocol. Once we move to IIIF this obviously becomes a lot easier. 

I don’t think we are necessary looking for a technical solution to stop this, just a way to ensure a user knows what they are allowed or not allowed to do with the image. One of the options discussed was to add a rights statement to the info.json. The way we’ve implemented IIIF in Fedora at NLW it would be quite easy for us to add a rights statement to the info.json but I appreciate this wouldn’t be easy to do if you were running an image server that wasn’t connected to a repository. 

For the above website we display the copyright status prominently on the website and if we were to share the Newspaper through the Presentation API this would include the copyright status so it may be over kill to include it in the info.json of the image as well.

Cheers

Glen

 
--
-- You received this message because you are subscribed to the IIIF-Discuss Google group. To post to this group, send email to iiif-d...@googlegroups.com. To unsubscribe from this group, send email to iiif-discuss...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/iiif-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "IIIF Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iiif-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Robert Sanderson

unread,
Jun 16, 2014, 10:52:16 PM6/16/14
to iiif-d...@googlegroups.com
Thanks Glen! Especially for the link to the clear use case :)

To summarize the arguments...

In favor of doing it now or at least soon:
* As the image could be added into any Manifest by a third party, without the attribution associated with it, it could easily be displayed off-site without the copyright statements.
* Indeed, without the attribution in info.json somewhere, a third party could not be expected to have any idea what attribution to even put into their manifest.
* There are multiple, real use cases today that need this

In favor of deferring:
* If we put it into info.json now, without considering the related issue of authentication, we are going to potentially end up with a mess.
* We want to avoid backwards incompatible changes, otherwise we need a new major version.  We don't want to go to 3.0 to do authentication unless we really really have to.
* For systems generating the presentation API, it can go there already. There's minimal (if any) third parties generating manifests that include other institutions' images
* Use cases probably also include the title/name/label for the image... but we're not going to do that.
* Attribution can contain HTML, which is very far from technical metadata about the image.
* Thus we should be doubly careful about where we put it to avoid sliding into all sorts of non-technical metadata.

Rob
 


Reply all
Reply to author
Forward
0 new messages