Closed azaroth42 closed 6 years ago
I am :+1: 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.
:+1: 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"]
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?)
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")
My preference would be to explicitly limit them to 1:1 URIs.
General agreement on the 7/5 technical call, and noted that type/@type and @context are special cases.
Good proposal. https://github.com/IIIF/iiif.io/issues/994.
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.
:+1: agreed at Toronto WG meeting
Done throughout. Leaving open for the other specs, removing presentation tag.
Tagging principles so we can document it as a design pattern.
Removing image, via #1433
From this thread:
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:
But this is fixed in 1.1 (c.f. #1192)
An example from @workergnome: