Search service should provide a service description -

[tomcrane]

...along the lines of info.json for image API

What motivations do I support?
What options for granularity do I support (see, #758 #TBC)
What parameters do I support?

This allows a client to know that it can request annotation lists by word/line/para as per #758, or that it can search for annos by user.

What does this service look like? Should it be inlined by convention, or dereferenced?

[azaroth42]

Propose defer until 1.1 at this stage. It's a nice to have and we don't want to rush it and get it wrong.

[zimeon]

I agree better not to try this yet, we need more experience with the Search API.

[azaroth42]

Untagging defer as we have some good implementations of 1.0, and good to discuss this in the context of Prezi 3.0

[glenrobson]

From #754 also include language e.g. What languages do I support?

[tomcrane]

Elaborating this ticket a little from the discussion at IIIF AV TSG last week.

The use cases of #754 cannot be met by the means suggested in that issue, without an explosion of spec as detailed in @azaroth42's comment: #754 (comment)

But they are very real use cases from many people!

This issue attempts a solution by different means. It suggests a "level0" search service that can be met by static resources, with a service description document (search.json) that describes the parameter space and what level0 param combinations will produce a result.

You can't semantically describe the contents of linked anno lists, for a machine to get the "french transcriptions" only. You can only label them for UI purposes (i.e., Presentation).

But you could slot a motivation and a language into a parameterised level 0 search service, that would serve a file out of an S3 bucket (or other static source); the search.json would describe what motivations and languages are available. Text granularity could slot an extension term into the URI for its divisions of content.

It would be very easy to get this wrong and produce a monster parameter spec.

pinging @jronallo also.

[azaroth42]

See also #509 -- motivation autocomplete could just be in the service description

[azaroth42]

Should this be included in Search 3.0? (thumbs up/down on the comment please)