If property can ever have multiple values, require a JSON array

[azaroth42]

From this thread:

https://groups.google.com/forum/?hl=en#!topic/iiif-discuss/ihQ3nHanh8Y

The proposal is to force all properties that can have multiple values to always be an array, in all APIs.
In the Presentation API, this would be: label, metadata, description, thumbnail, attribution, rights, logo, type, viewingHint, related, rendering, service, seeAlso, within

This is done in JSON-LD by adding @container: @set into the context document for those properties.

Note however that JSON-LD 1.0 currently prevents us from doing it for the values of LanguageMaps:

json-ld/json-ld.org#407
#755

But this is fixed in 1.1 (c.f. #1192)

An example from @workergnome:

http://evil-manifests.davidnewbury.com/iiif/garden/everything_a_list.json

[azaroth42]

I am 👍 on the proposal, other than for type which I think we should require be 1:1. Constantly type checking values to see if they're a list or a value is painful and results in hard to find bugs. Note that the current validator even incorrectly errors on the everything_a_list manifest.

[tomcrane]

👍 too. Currently @list property names are plural (e.g., canvases) or mass nouns (e.g., otherContent), but I think the @set property names should remain singular:

"label": [ "one label", "another label"] 

not

"labels": [ "one label", "another label"] 

[workergnome]

Agree with @tomcrane on nouns remaining as they are, if only for backwards compatibility.

RE: type: I think about CRM integration, for instance, and, say: http://linked.art/model/object/digital/#iiif-manifests

{
    "id": "http://iiif.example.org/presentation/1/manifest.json", 
    "type": "InformationObject", 
    "conforms_to": "http://iiif.io/api/presentation", 
    "format": "application/ld+json;profile=\"http://iiif.io/api/presentation/2/context.json\""
  }

Here, we're stating that the manifest is a CRM InformationObject, but it's also a sc:Manifest. In a world where it's trying to be both, keeping the same URI, but two different types in two different contexts seems like it would be a problem.

(Or are we distinguishing between the manifest JSON file, and the manifest itself?)

[azaroth42]

Following this pattern, and #1147 / #1176, we should also define an absolute format for first/last/next/prev references. If we ever allow more than just the URI, then they should always be a JSON object, requiring at least two properties (id and something else).

(Reason for 2 properties being that JSON-LD will compact {"id": "foo"} to just "foo")

[workergnome]

My preference would be to explicitly limit them to 1:1 URIs.

[azaroth42]

General agreement on the 7/5 technical call, and noted that type/@type and @context are special cases.

[christopher-johnson]

Good proposal. #994.

[zimeon]

I note that the addition of @container: @set in the context to define this behavior means that the change won't introduce any problems serializing from RDF.

[zimeon]

👍 agreed at Toronto WG meeting

[azaroth42]

Done throughout. Leaving open for the other specs, removing presentation tag.

[azaroth42]

Tagging principles so we can document it as a design pattern.

[azaroth42]

Removing image, via #1433