api icon indicating copy to clipboard operation
api copied to clipboard

Search service should provide a service description -

Open tomcrane opened this issue 9 years ago • 7 comments

...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?

tomcrane avatar Mar 24 '16 19:03 tomcrane

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.

azaroth42 avatar Apr 11 '16 21:04 azaroth42

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

zimeon avatar Apr 12 '16 18:04 zimeon

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

azaroth42 avatar Oct 07 '16 22:10 azaroth42

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

glenrobson avatar Feb 22 '18 15:02 glenrobson

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: https://github.com/IIIF/api/issues/754#issuecomment-341842597

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.

tomcrane avatar Feb 27 '18 10:02 tomcrane

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

azaroth42 avatar Jan 11 '22 17:01 azaroth42

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

azaroth42 avatar Jun 28 '22 16:06 azaroth42