search

IIIF / api

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

Search service should provide a service description - #762

Open tomcrane opened 8 years ago

tomcrane commented 8 years ago

...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 commented 8 years ago

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 commented 8 years ago

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

azaroth42 commented 8 years ago

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

glenrobson commented 6 years ago

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

tomcrane commented 6 years ago

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.

azaroth42 commented 2 years ago

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

azaroth42 commented 2 years ago

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