Change "license" to map to dct:rights

[azaroth42]

@kestlund, @anarchivist, @aisaac e.g. rightsstatements.org

[aisaac]

Note that the current 'license' field in the presentation API says "describes the license or rights statement " (http://iiif.io/api/presentation/2.0/) so it's more permissive than what the label hints at. Maybe a quick fix would be to change the JSON context at http://iiif.io/api/presentation/2/context.json and have 'license' mapped to dc:rights or edm:rights instead of dc:license

(btw I'm still wondering why the license is only for the presentation API not the image API. To me that's not only about presentation...)

[jpstroop]

@aisaac Coming to Image API in 2.1: http://iiif.io/api/image/2.1/#rights-and-licensing-properties

[aisaac]

@jpstroop excellent! This new development actually makes the issue spotted by @kestlund even more relevant to solve :-)

[kestlund]

I think dc:rights would be better. edm:rights would be good, too, but folks in the U.S. are much more familiar with DC, and it works.

I still think the label is problematic and will cause problems especially with legal counsel.

[anarchivist]

As @kestlund notes, I think it's also worth noting that part of my initial confusion/concern was the use of license as the property name in the APIs as well. I realize that's a little more complicated and could be a breaking change if the property were renamed.

As for the mapping in the @context, I'd be fine with dc:rights. I was considering dct:rights but the range expectation (dct:RightsStatement) is probably overkill.

[aisaac]

Your points for DC make much sense. About dc vs dct, I'm actually ok with the range: IIIF expects it to be a URI, that's the only thing that matters. Classifying the resource as dct:RightStatements feels alright.

[anarchivist]

Sounds good to me, then. :+1:

[kestlund]

dct:rights probably is better. It does add the additional emphasis that a URI is really wanted, as well.

[aisaac]

The wording of the current presentation API is quite explicit that this is a URI. The thing is that it could be the URI of a document, like http://www.example.org/license.html. But this is actually compatible with dct:RightsStatements, I think.

[kestlund]

I've noticed in practice during the week that usage is not necessarily consistent with the wording of the API, which is why I was thinking "additional emphasis." :-)

[aisaac]

Good point, @kestlund. As part of a concerted action to get more/better rights in IIIF, more/better wording could be useful. By the way reacting to @anarchivist's point on potential breaking change, I'm wondering how much 'license' is used in already existing implementation. Maybe people wouldn't be bothered about changing this field - esp. if they don't use it.

[anarchivist]

Related, then, would it make sense to propose a modification to license that the value associated with the property MUST be a URI?

[aisaac]

+1

[kestlund]

:+1:

[kestlund]

After further discussion, proposal on the table is to:

• change dct:license to dct:rights in both Image and Presentation API
• create new issue to change label from "license" to "Rights" or "Rights Statement" (TBD) for new versions of the APIs, as this results in a breaking change

@azaroth42 @zimeon @anarchivist @aisaac @jpstroop

[anarchivist]

:+1:

[zimeon]

To clarify, the change of JSON key from "license" to "rights" can happen at the next major version of the Image and Presentation API specs (it seems likely that will be the next version in both cases as we will probably go from 2.1 -> 3.0)

:+1:

[jpstroop]

:+1: to @zimeon's clarification

[anarchivist]

:+1:

[azaroth42]

:+1: (change @context to dct:rights now, change key to rights in 3.0 for both image and prezi)

[aisaac]

late +1!