The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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)

Virtual Collections

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.