Attribution in image api

[jpstroop]

Cover this when we do auth

[azaroth42]

To clarify, the request was to add attribution and license to the image API info.json document for reporting the license of an image.

The feeling 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

Hence to defer until we then.

[azaroth42]

tag: mightfix

Additional feelings:

• PRO: Don't want to rely on third parties to somehow?? know to include the right attribution/license in a manifest for display
• PRO: Real use cases at National Library of Wales and Cambridge. Likely at most other institutions.
• ANTI: Not backwards compatible to remove or refactor, so if we want to put all of the rights/license/auth stuff together, we'd have to wait for 3.0 to fix it, rather than waiting until 2.1 to add it properly. And hopefully there'll never be a 3.0...
• ANTI: attribution can contain HTML (see http://iiif.io/api/presentation/2.0/#content-details ) and now the slippery slope is pretty much done

[azaroth42]

I see four options:

• include attribution and license at the top level
• include attribution and license in a "rights" block
• include them in a service, even though they're first class properties in presentation
• defer, as it's not going to be backwards incompatible and we can include during 2.1 with auth

I guess I'm in favor of defer still, as we have yet to see an explosion of third party presentation apis that include images from other implementers. In other words, while it's a real problem and deserves to be solved, it doesn't have to be solved in 2.0

[jpstroop]

Why would they be in a rights property? Feels like structure for structure's sake to me. I don't like the idea of them being a service either, so to narrow it down (from my perspective):

• Top level attributes
• Defer

I was feeling a sense of urgency from Tom about this in Helsinki.

[azaroth42]

I think our beloved managing editor would like all problems of everyone solved and trusts us to get it right. I'm more concerned that we don't #%(*@#^% it up, resulting in a 3.0 release instead of a minor changes 2.1

[jpstroop]

Fair enough. For the sake of consistency between the APIs, would we ever really want license and attribution to be anywhere other than at the top level? Between those and services I begin to see a nice superclass of both info.json and manifests.

-Js

Sent via mobile. Please excuse typos, brevity, etc.

[azaroth42]

I guess not. From an RDF perspective, it's the license and attribution of the image, not of some blank node.
Okay, license is pretty easy to add, but to put in attribution in we're going to need to spell out all the HTML recommendations from the Presentation API?

[jpstroop]

Hmmm... that does begin to sound like something we could get wrong. I could be in favor of copying the attribute practice over into the image API (would we move the escaping stuff to a central location?). I guess I need to sit with it.

Thoughts from others?

[azaroth42]

I wouldn't be averse to pointing at the Presentation API's description of best practice for HTML from the Image API, if that makes sense? It's a lot of information to duplicate, and not enough to extract into its own document.

[jpstroop]

Yeah, I guess that makes sense.

[azaroth42]

Proposal:

• Include attribution, logo and license into info.json
• Copy the HTML recommendation and similar gumf into the description of attribution to keep the two documents independent

[jpstroop]

:+1: I think; I don't love the repetition, but it seems like the practical thing to do.

[azaroth42]

Example info.json ... note the potential recursion...

{
  "@id": "http://example.edu/iiif/image/main-image",
  "height", 4000,
  "width": 6000,
  "attribution": "<span>Provided by <a href=\"http://example.edu/\">some institution</a></span>",
  "license": "http://creativecommons.org/license/cc-by-4.0",
  "logo": {
    "@id": "http://example.edu/images/logo.jpg",
    "service": {
      // I heard you like info.json, so I put some info.json in your info.json
      "@id": "http://example.edu/iiif/image/logo",
      "profile": "http://iiif.io/api/image/2/level2.json",
      "height":  150,
      "width":  150
    }
  }
}

[jpstroop]

Buh. Does logo have to be a service?

[azaroth42]

No, but it may have a service. And then that service may have a logo.

[jpstroop]

OK, but just a plain ol' URI is OK too, right?

[azaroth42]

Yup. The Presentation API text is:

A small image that represents an individual or organization associated with the resource it is attached to. This could be the logo of the owning or hosting institution. It is recommended that a IIIF Image API service be available for this image for manipulations such as resizing.

[jpstroop]

Gotcha, right.

[jpstroop]

Can my logo have a logo? :stuck_out_tongue:

[azaroth42]

Yes. :recycle:

[azaroth42]

Proposed text in: http://image-auth.iiif.io/api/image/2.1/#image-information

[jpstroop]

Bring out in spec that semantics are identical to those in the prezi API. Otherwise :+1: from tech group at GW meeting. Also cover what to do when there are rights in Prezi and rights in image.

[jpstroop]

Closed in c3a1d2efff88d3e14e32d5f2945e5d59edc6461f