...
- use existing standards for the query language (SPARQL comes 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
Questions/Comments
Currently it's rather unclear for us, how this query service would be integrated into fedora and what are the use cases that such a service would support. We are skeptic that a query service would support all our use cases and that it adds an additional index for information, that would already be present in a triple store and/or Solr index. Therefore we think such a query service should be either an optional component that can be installed along Fedora6 (similiar to a fixity service) or be able to use existing technologies like a triple store or Solr/Lucene index as a backend.
However we would see a use case, to extend the existing simple web UI of Fedora5 with a possibility to search for objects (similiar to the search interface that what was available in fedora3 when accessing the endpoint /fedora/objects). As mentioned above, such a UI could leverage existing indexes.
- make optional?
- if integrated into fedora: make optional
- possibility to query persistence layer for used storage and free storage
- will query service be part of the fedora API spec?
- does it make sense to hardcode the supported queries?
- use a real SPARQL endpoint in the background and only deliver a UI/APIonly provide a search UI but actually use a triple store?
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
...