All about virtual resources, virtual collections and searching.
Use-Cases for Virtual Collections
- Representing the results of a persistent search:
- in a per-session scope, e.g. the currently displayed week in KOrganizer
- in a per-application scope, e.g. user-defined persistent search folders in KMail
- in a global scope, e.g. user-defined persistent search folders shared between KMail, Mailody and LionMail.
- The Nepomuk tag resource
- Representing the entire tag-tree
Ideas on the Search Infrastructure
- Delegation to resources that support search in the back-ends
- Requires query transformation
- Requires management for live searches
- Requires the ability to report search results (needs protocol extension)
- Query language still undecided, current options: XESAM, SPARQL
- Back-end still undecided, current options: XESAM, Nepomuk
Akonadi Search Infrastructure (concept)
The following lists properties of "normal" Akonadi::Collection objects and maps them to the corresponding semantics of virtual collections:
- UID: stays the same
- RID: for application use (currently it holds the query, but that's a dirty hack) (search folders only, still used for its original purpose by the tag resource)
- Name: stays the same, for display purposes only
- Resource Id: see virtual resources
- Content mime-types: good question actually...
- ACL: extend by link/unlink operations
- Item creation: not allowed, would lack a storage location
- Item modification: in theory possible if the storage collection allows it
- Item deletion: in theory possible if the storage location allows it
- Collection creation: depends on resources, useful for the Nepomuk tag resource, not for persistent search folders
- Collection modification
- Name: no problem
- RID: not allowed once there is a actual resource behind it, not a problem when used by the application
- Query: requires special support in the server, but no principal problem
- Parent (that is moving): tricky for the tag resource, not really a problem for search folders, moving to non-virtual resources needs to be prevented.
- Any other attribute: no problem
- Collection deletion: no effects on stored items/collections, so no problem
- Query: for search folders only, should be moved into an dedicated attribute.