[Nepomuk] Nepomuk facets

[Sebastian Trüg]

On 06/21/2010 11:52 AM, Alessandro Sivieri wrote:
> 2010/6/21 Sebastian Trüg <trueg at kde.org <mailto:trueg at kde.org>>
> 
>     The idea is that one restriction is one facet and those can be put in
>     groups. A group can be exclusive (for dates or types) or not (tags for
>     example). The a group can also have a range type which can be used by
>     the gui to create a range selection based on that type.
> 
> 
> The introduction of a range is interesting; are you sure you are not
> confusing the concept of "facet" with "term" (not Query::Term)? I mean,
> your idea of facet+group looks like the current idea of term+facet... I
> mean, currently facets can be exclusive or not, and terms are a single
> choice for each facet (for example a tag, or a temporal period, or a
> document type).

Even better. Then it is mostly about wording. :)
And you are right, my FacetGroup is actually the Facet. But I am not
happy about the Term class.
The thing is that I would like the make the facet stuff public API for
KDE 4.6. That is why I am picking on it and being a pita. :P

>     These groups could then be added to a model (the only reason for using a
>     model is that it can easily be displayed in a treeview - might be
>     overkill) which in turn could be filtered by a custom
>     QSortProxyFilterModel which hides all facets that do not change the
>     result (i.e. could of 0 or the same as the result set).
> 
> 
> Which is currently what I am already doing in the tags facet (with its
> list model and filter); the only thing that gives me some doubts, in
> your idea, is why should I put every group in a single model: each facet
> should, IMHO of course, have its visual representation, separated from
> the others... or, at least, I cannot imagine a single UI element with
> more than one facet :)

My main concern is about encoding all facets in the same way. Then they
can be serialized, compared, copied, and so on. It makes it much easier
to work with since all facets can be treated the same without any
special cases.
As far as GUI goes: one is free to do whatever one wants with the data
in a model. The advantages of a model (be it a subclass of
QAbstractItemModel or not) are
- You have one class managing and updating the facets
- You can create whatever GUI you like, the simplest being a styled
  tree view the way apple's finder does it. You can also create one
  group box for each top level item in the model (or for each facet if
  you will)
The model is a detail. It could also be some FacetManager class. I just
think that making it a model makes sense.

Do you actually want to create different representations for different
types of facets. The only exception I can see is the rating. But that
could easily be filtered out and added as a separate gui element.

Cheers,
Sebastian