...
- use existing standards for the query language (SPARQL comes and LDPath (https://marmotta.apache.org/ldpath/) come to mind)
- should support aggregation functions (e.g. sum(), count())
- should reuse existing indexes like Solr or triple store if present?
→ do not build another index, if these tools are present anyway
...
- make optional?
- will query service be part of the fedora API spec?
- does it make sense to hardcode the supported queries?
- only provide a search UI but actually use a triple store?
Answers/Remarks by Andrew Woods
- Regarding "Query service", we have gotten consistent feedback that an integrated, synchronous search index should come with Fedora. The use case is for clients to create/update a Fedora resource, then immediately be able to query Fedora with the expectation that the resource be in the index. The externalized, asynchronous indices do not satisfy this use case.
- We will certainly use the queries you have enumerated in the testing of the new query service.
Persistence
Use cases
- For our cloud infrastructure, docuteam would like to use s3 compatible object storage (provided by Ceph https://ceph.io/)
- Some docuteam clients might want to stick with a simpler storage model than OCFL to reduce storage requirements
...