IIIF / api

Source for API and model specifications documents (api and model)
http://iiif.io/api
106 stars 54 forks source link

Context for Search/Presentation #599

Closed azaroth42 closed 8 years ago

azaroth42 commented 8 years ago

Currently search has its own context. However, as the search response can include a huge amount of information from the Presentation API, this is going to provide a challenge in inter-api versioning. For example, anything from Layer, AnnotationList, Annotation, Manifest and Canvas could legitimately be included in the search response. The Manifest features would be from within on the target canvas (see 3.3.3).

Proposal:

The search context should define only the explicit search features, and the response should have both the used Presentation API context and the Search context. 2.1 is explicit that multiple contexts are allowed, so we should use this feature.

azaroth42 commented 8 years ago

Depends on #598

azaroth42 commented 8 years ago

Implemented across paging_rels and search branches.

Specs: http://search.iiif.io/api/search/0.9/ http://paging_rels.iiif.io/api/presentation/2.1/

Contexts: http://paging_rels.iiif.io/api/presentation/2/context.json http://search.iiif.io/api/search/0/context.json

jpstroop commented 8 years ago

In some situations it may be too expensive to generate a complete set of annotations within a single annotation list, or manifests within a collection. This is especially likely to occur when the responses are dynamically generated. When an operation is too expensive is left entirely to the discretion of the server, however the server should also take care not to generate overly long responses that would be difficult for clients to process. In these situations the server may break up the response using [paging properties][paging].

  1. Broken Markdown at the end. Is it a relic? Looks like it's supposed to refer to this section.
  2. "When an operation is too expensive is left entirely" read like a typo to me at first pass.

Proposal:

In some situations, annotation lists or the list of manifests in a collection may be very long or expensive to create. The latter case is especially likely to occur when responses are generated dynamically. In these situations the server may break up the response using paging properties. The ideal length of a response is left to the server's discretion, but the server should take care not to produce overly long responses that would be difficult for clients to process.

jpstroop commented 8 years ago

Ahh, I see now that the markdown link should point to 3.5, #paging-properties

azaroth42 commented 8 years ago

Closed in #652