IIIF 3 Validation Snagging

[tomcrane]

A list of errors flagged by the validator (https://iiif.io/api/presentation/validator/service/) and what we want to do about them.

Many of these are where the IIIF spec meets the annotation spec.

target as Object

This is a valid construction but Mirador doesn't like it:

"target": {
    "id": "https://iiif.wellcomecollection.org/presentation/b29161630/canvases/b29161630_0002.jp2",
    "type": "Canvas"
}

Validator says "is not valid under any of the given schemas". I think it is valid, but we should serialise as a string only to keep more viewers happy (for now):

"target": "https://iiif.wellcomecollection.org/presentation/b29161630/canvases/b29161630_0002.jp2"

The downside is that we can't do this, which we have on the first anno in each text page:

"target": {
        "id": "https://iiif.wellcomecollection.org/presentation/b29161630/canvases/b29161630_0006.jp2#xywh=541,360,1720,65",
        "type": "Canvas",
        "partOf": [
          {
            "id": "https://iiif.wellcomecollection.org/presentation/b29161630",
            "type": "Manifest"
          }
        ]
      }

This allows an annotation page for a canvas to point at the manifest the canvas lives in, which is handy if the anno list is encountered out of context. We'll have to forgo that for now though.

• [x] Fixed

manifest.services

Additional properties are not allowed ('services' was unexpected)

Validator doesn't recognise the new services property: https://iiif.io/api/presentation/3.0/#services

• [x] Fixed in validator

Embedded search service

The validator doesn't like the non-IIIF3 search service, but I think this is correct as per the spec.

'Search within this manifest' is not of type 'object'

...should the label on the search service (which has the Search 1.0 @context) be a languagemap or not?

'id' is a required property

Inside this block we are in the Search 1.0 @context and therefore it's @id - see https://iiif.io/api/presentation/3.0/#service:

Implementations should be prepared to recognize the @id and @type property names used by older specifications, as well as id and type. Note that the @context key should not be present within the service, but instead included at the beginning of the document. The example below includes both version 2 and version 3 IIIF Image API services.

• [x] Fixed in validator? needs discussion

http URLs defining rights

'https://creativecommons.org/licenses/by-nc/4.0/' does not match 'http://creativecommons.org/licenses/.*'

The formal vocab uses the http form, so the assertion in the manifest should be the http form even if it gets displayed as https. If a human follows the http form they will be redirected anyway.

• [x] Fixed

label on AnnotationPage

Additional properties are not allowed ('label' was unexpected)

      "annotations": [
        {
          "id": "https://iiif.wellcomecollection.org/annotations/v3/b30575746/b30575746_0072.jp2/line",
          "type": "AnnotationPage",
          "label": {"en":["Text of page 58"]}
        }
      ]
    },

That should be valid IMO

• [x] To be discussed

[tomcrane]

Validation report:

https://iiif.io/api/presentation/validator/service/validate?format=json&version=3.0&url=https://iiif.wellcomecollection.org/presentation/b19877195

This is a simple all-open one - will get on to AV, auth etc later.

[tomcrane]

Further note on label

Spec says:

There is one property that is in direct conflict - the label property is defined by both and is available for every resource. The use of label in IIIF follows modern best practices for internationalization by allowing the language to be associated with the value using the language map construction described above. The Web Annotation Data Model uses it only for Annotation Collections, and mandates the format is a string. For this property, the API overrides the definition from the Annotation model to ensure that labels can consistently be represented in multiple languages.

"available for every resource" => label is valid here " the API overrides the definition from the Annotation model" => the label should be a language map not a string

So I think the validator is wrong.

[tomcrane]

Further note on Search Service:

The current construction is valid in the JSON-LD playground. It evaluates to:

<wc.org/presentation/b28857021> <https://schema.org/potentialAction> <wc.org/search/v1/b28857021> .
<wc.org/search/autocomplete/v1/b28857021> <http://purl.org/dc/terms/conformsTo> <http://iiif.io/api/search/1/autocomplete> .
<wc.org/search/autocomplete/v1/b28857021> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://iiif.io/api/search/1#AutoCompleteService> .
<wc.org/search/autocomplete/v1/b28857021> <http://www.w3.org/2000/01/rdf-schema#label> "Autocomplete words in this manifest" .
<wc.org/search/v1/b28857021> <http://purl.org/dc/terms/conformsTo> <http://iiif.io/api/search/1/search> .
<wc.org/search/v1/b28857021> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://iiif.io/api/search/1#SearchService> .
<wc.org/search/v1/b28857021> <http://www.w3.org/2000/01/rdf-schema#label> "Search within this manifest" .
<wc.org/search/v1/b28857021> <https://schema.org/potentialAction> <wc.org/search/autocomplete/v1/b28857021> .

(wc.org for brevity)

[tomcrane]

Have fixed the rights https issue. We'll serialise target properties as string IDs rather than canvas objects until Mirador supports this; can't really do anything else for now regardless of how "right" it is.

[stephenwf]

PR for the validator: https://github.com/IIIF/presentation-validator/pull/114

[tomcrane]

Cheers @stephenwf !

[tomcrane]

All of these validation errors are deemed errors in the validator. I think we're good to go for now.