Improve clarity of what `rights` applies to

[azaroth42]

Although improved in 3.0, the rights property description still has some issues.

• "resource" should be made more explicit as both IIIF resources and Content resources -- the representation that can be retrieved from the id of the resource that has the rights property.
• Remove the note about it being "informative". The intent (IIRC) was to avoid implying that the client needed to enforce the license, only display it.
• Clarify that JSON objects within the document can have different rights (annotation with different rights to the manifest) and how the inheritance works.

Note -- to be determined how rights are calculated with mixed content and iiif resources, such as:

{
  "type": "Manifest",
  "rights": "cc0",
  "provider": [{
    "type": "Agent",
    "logo": {
      "id": "foo.png",
      "type": "Image",
      "rights": "cc-by",
      "service": {
        "id": "https://example.org/iiif/logo",
        "type": "ImageService3",
        "label": {"en": ["Some Text Here"]}
    }
  }]
}

What rights govern the text "Some Text Here"? cc-by inherited from the Image, or cc0 inherited from the Manifest?
Similarly, you can dereference the service to get pixels ... are those pixels cc-by or cc0?

Thanks to @zimeon @tomcramer at the IIIF Conference for bringing up the issue

[zimeon]

Thanks @azaroth42 ! Two more thoughts:

First, to add on to you comment on clarification of resource:

"resource" should be made more explicit as both IIIF resources and Content resources -- the representation that can be retrieved from the id of the resource that has the rights property.

I think the key thing will be to explain that a particular rights property will apply to either an IIIF resource (say a manifest if it is placed on the top level Manifest resource in a manifest.json -- the most common use case) or to a content resource (say a set of image pixels if placed in an Image API response or its parallel in a manifest; or a video if on a video resource in the manifest, etc.)

Second, I think the inheritance properties are "interesting" and need some discussion. There is a mismatch between semantics when considered in terms of JSON documents vs when considered in RDF, and it is not clear that either is obviously what we want. In the case of the JSON document interpretation, the CC0 statement would apply to the whole document but I don't think that is what we want, especially if there were embedded scholarly annotations where CC-BY might be more appropriate.

In the case of the RDF interpretation, we probably would think of rights statements hanging off individual resources which doesn't have the inheritance we want. Expand the example above we'd have something like:

:manifest a iiif:Manifest ;
    iiif:rights cc:cc0 ;
    iiif:provider !some-complications-with-array! _:bnode_provider .

_:bnode_provider a iiif:Agent ;
  iiif:logo :foo.png .

:foo.png a iiif:Image ;
  iiif:right cc:cc-by
  iiif:service ex:logo .

ex:logo a iiif:ImageService3 ;
  iiif:label !some-complications-here! "Some Text Here" .

At first glance that would have rights applying only to the immediate context resource.

In the Image API we have the rights on the ImageService3 resource whereas in prezi it seems more natural on the enclosing Image resource (which doesn't exist in the Image API info.json). Repeating on both resources in the prezi response would be ugly, inheritance would be nicer.

I think the other issue with inheritance is that with an RDF mindset we might imagine adding values (so Image would have rights CC0 and CC-BY) but the result is conflicting and clearly not what we want.

However, I think the rights semantics that would be most useful would be:

• inheritance to IIIF resources (as opposed to content-resources) in the same JSON document (including bnode, fragment or other URIs)
• no inheritance to content-resources
• new statements override (replace, rather than add to) inhertited rights

[azaroth42]

I agree with Simeon's "most useful semantics". One issue...

Drawing on the Getty biography example, mapping into IIIF would potentially put it into metadata...

"rights": "cc0",
"metadata": [
  {"label": {"en": ["Title"]}, "value": {"en": ["Uncopyrightable Name Of Object"]}},
  {"label": {"en": ["Summary"]}, "value": {"en": ["Long copyrightable creative content"}, "rights": "cc-by"} 
]

If we can't put rights on the label/value pairs, then they necessarily inherit the higher order rights.

But ... who (in this case) is the required attribution to? The provider of the manifest? But what if that CC-BY statement is then re-aggregated into another resource? Is the client expected to display the CC-BY icon with the metadata entry directly?

[azaroth42]

For the Image API, is the "info.json" document a IIIF Resource or a Content Resource?

e.g. in
https://iiif.io/api/image/3.0/#56-rights
it says that it's the rights for the "contents of this image", meaning a Content Resource. How can you say that the service metadata is cc0 ?

If you embed all of the ImageService3 into the Manifest, then the rights must still apply to the content of the image, making ImageService3 treated like a Content Resource... and there's no way to assert a license about the service metadata? :(

[zimeon]

I have always assumed that info.json is an IIIF resource (ie. ImageService3), like Manifests and Collection resources. One essentially includes a pared down info.json in a manifest. To me a the content resource is just the image (including all derivatives from the image service), or a video, audio, 3d model.

[zimeon]

There seems to be an extensive literature on using RDF to construct license statements (e.g. https://www.w3.org/submissions/ccREL/ — ccREL about building RDF license statements and applying to whole documents/works) but in a relatively quick look I do not find much about application of rights information to RDF:

• https://ceur-ws.org/Vol-1034/RodriguezDoncelEtAl_COLD2013.pdf - talks about statement, resource and file level statements but not sure anything informs for our use case
• https://cosasbuenas.es/blog/license-rdf - straightforward use of license terms on local RDF resources and about remote resources

[tomcrane]

I also think of the info.json or rather the image information response as a IIIF Resource that tells us about the Content Resources it can return.

There is a parallel here in Auth 2:

Content Resource video1 has probe service p1 which has auth services
Image Service imgSvc1 has probe service p2 which has auth services

... which doesn't help because p1 tells the client about your auth relationship with video1, but p2 tells the client about your auth relationship with the content resources returned by imgSvc1, not imgSvc1 itself.

We got round that with this language:

An access-controlled Content Resource has a probe service. An image information document (info.json) also has a probe service, if the image responses it produces are access-controlled.

Could the same interpretation be used for rights on an image service? It's a bit woolly unless rights in the Image API context means something different: means a rights statement applying to the derivatives of the service rather than the service itself.

[zimeon]

I note that currently Mirador displays the content of rights as "License" (from v2 terminology) suggesting that it has semantics of being about the content:

With the incorrect Cookbook rights recipe it doesn't matter because the license is the same for content and manifest:

With the correct Yale Peabody example the Mirador displayed "License" is not what is intended:

[zimeon]

Same issue as Mirador in Annona, Clover, Glycerine, and IIIF Curation Viewer.

Much as I hate to say it, this makes we wonder whether the ship has sailed and fixing the semantics according to original intent would lead to too many wrong presentations for too long. Perhaps one has to make rights be about the content resources represented by the IIIF Resource it is attached to. And if we want the intended semantics about IIIF Resources, add a new property for that?