In some DSpace installations, there are only few huge collections and dividing items to smaller sets is done using filters based on metadata values. Therefore it would be practical to be able to fetch items to Omeka
using DSpace 6 /rest/filtered-items -endpoint, which supports querying using metadata field values.
For an example, API call https://demo.dspace.org/rest/filtered-items?query_field[]=dc.contributor.author&query_field[]=dc.creator&query_op[]=contains&query_op[]=matches&query_val[]=Piotr retrieves all items which have string Piotr in dc.creator or dc.contributor fields.
Because query syntax is quite flexible, it is likely that building an UI for query construction is not very useful (at least in my opinion), even though there is a query construction UI in DSpace reporting tool.
This feature would not replace current functionality for fetching items based on community/collections, but add more options to the user.
In some DSpace installations, there are only few huge collections and dividing items to smaller sets is done using filters based on metadata values. Therefore it would be practical to be able to fetch items to Omeka
using DSpace 6
/rest/filtered-items-endpoint, which supports querying using metadata field values.For an example, API call https://demo.dspace.org/rest/filtered-items?query_field[]=dc.contributor.author&query_field[]=dc.creator&query_op[]=contains&query_op[]=matches&query_val[]=Piotr retrieves all items which have string Piotr in dc.creator or dc.contributor fields.
Because query syntax is quite flexible, it is likely that building an UI for query construction is not very useful (at least in my opinion), even though there is a query construction UI in DSpace reporting tool.
This feature would not replace current functionality for fetching items based on community/collections, but add more options to the user.