Replies: 2 comments
-
Thread here from @jbaiter has some details on the limitations of various client-side search implementations: https://twitter.com/jbaiter_/status/1683927009993584648 SQLite could be another option - could be an agreed schema and simply attached with a dump of the SQL. |
Beta Was this translation helpful? Give feedback.
0 replies
-
If a level0 search service is of interest plus add a thumbs up to this comment: IIIF/api#762 (comment) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
At the moment IIIF search works only over HTTP, with a service definition like:
However, this makes searching of digital material require a server. When you load a PDF, you are able to search through the text. Similarly for other formats. With IIIF, the resources are typically quite large and the format breaks these large resources into easily loadable chunks (like IIIF Image tiling).
There is no level0 search service option that could be hosted on a static hosting or in an S3 bucket. However there are libraries that support pre-generation of search indexes that can be consumed by client applications (such as flexsearch)
If there was a library/set of helpers to consume these, and a registered extension to IIIF to support these, it would be a compelling alternative to large search services. Flexsearch, for example, allows you to create larger or smaller indexes with varying performance.
In their benchmarks they use the plaintext of "Gulliver's Travels" (benchmark). At the low end, a 2.1Mb index and on the high-end a 21.5Mb index.
I don't think Flexsearch should be the only format supported, but an extension that allowed for multiple formats for a "Search bundle" would let us get the ball rolling on the tools in IIIF Commons.
Beta Was this translation helpful? Give feedback.
All reactions