api
api copied to clipboard
Limit Searches to specific resource types within targeted object
To extract one use case from #502, should the search within scope include annotations on non-canvas targets? For example, commentary on a range or layer? Or annotations on annotations on canvases? This will be enabled in Prezi 2.1, so we should be clear whether it's intended to be part of search within or not.
As this is outside of the scope of the original charter for search (search within the text of a work), and we don't know how frequently non-canvas annotations will be implemented, we're deferring until at least 1.0 for this functionality. It could be added by having a targetType parameter, that defaults to all types, and otherwise scopes the search to only objects of those types. For example to search for annotations on Manifests only, one would do ...&targetType=manifest
Should this be included in Search 3.0? (thumbs up/down on the comment please)
This seems to already be supported in Search 1.0 and 2.0 (searching on resources other than Canvases), so are we missing something about this ticket or should it be closed? Perhaps this issue is referring to targeting a search on a specific type of resource?
Agree with Dawn - we already have this functionality (as written in the first post), and the preamble to the Content Search API specifically calls out searching resources other than canvases:
The scope of the specification is searching annotation content within a single IIIF resource, such as a Manifest, Canvas, Range or Collection.
The useful functionality / new use case is for the user to limit which types of resource are returned in a search result (e.g a search service is targeted at a collection, but the user only wants results that target a canvas, not any other structure)
Well... no ... the search services are searching within annotations scoped to the resource that has the service (e.g. manifest, canvas, etc). That's different from the annotations having targets of things other than Canvases.
That said, I don't believe that we currently limit where the annotations can come from, or the sorts of resources that can be their targets... so I do agree that the ticket is not about allowing the functionality, but about making it more explicit with API affordances to manipulate it, such as the targetType
param in the comment from 2015. If a client is unable to do anything with annotations that target Manifests (for example) it would be a waste of time to return them.
I think a targetType param, that took a comma separated list of class names would be sufficient. e.g. ?targetType=Manifest,Canvas,Range&q=...
would then let the client filter the annotations by the types that it can process.