Re: property searches for #+CATEGORY

[Adam Spiers <orgmode@adamspiers.org>]

On Wed, Nov 07, 2007 at 05:16:26PM +0000, Bastien wrote:
> Adam Spiers <orgmode@adamspiers.org> writes:
> >> This would let you restrict any agenda search to a group of agenda
> >> files.  I don't want to digg too far in this direction, but I think
> >> there are a few other things for which such groups might be useful 
> >> (e.g. publish agenda files per group...)
> >
> > Well, the documentation says
> >
> >    The category is a broad label assigned to each agenda item.  By
> >    default, the category is simply derived from the file name, [...]
> >
> > so I thought this use case was pretty much exactly what it was
> > intended for.
> 
> Lets say that #+CATEGORY is more oriented toward files grouping, and
> :CATEGORY: is more oriented toward tasks grouping.

I wouldn't quite say it like that.  #+CATEGORY is still about
task/appointment grouping - but categorising all entries in one file
in a convenient, single pass.  However if you only had two files, and
one file had one #+CATEGORY line and the other had a different one,
you wouldn't say you were grouping files together, would you?

> In fact, when using
> several #+CATEGORY in the same file (as it is *not* recommended to do),
> you are virtually splitting your file into several files, each of them
> corresponding to a category.

Yes - or you could describe it the other way around - enabling you to
combine multiple categories in the same file.

> Your request  was to be able to perform a search using #+CATEGORY as a
> way to search through multiple files.  

Again, at risk of being pedantic I would describe my requirement
slightly differently.  (N.B. I can already search through multiple
files.)

Let's first bear in mind the relational data model behind this:

  - There is a many:one relationship between items (TODOs,
    appointments etc.) and categories, regardless of whether the
    category comes from #+CATEGORY or a :CATEGORY: property.

  - There is a many:one relationship between items and files.

  - Consequently, there is a many:many relationship between files and
    categories.

In other words, categories are a means of grouping items, not files.
(Ditto for tags and any other properties, in fact.)

So, there are two orthogonal aspects to my requirement:

  - I want to be able to perform a search for a particular category
    across all *items* in all of my agenda files.  N.B. this search is
    essentially item-oriented (think "SELECT * FROM item WHERE
    category=..."), *not* file-oriented (in an SQL world, the
    many:many relationship between files and categories would make for
    a more complex query).

  - I want to be able to conveniently place whole files in a single
    category (this is already satisfied by #+CATEGORY), and also
    maybe be able to add further files at a later date which have
    multiple categories per file (this is already satisfied by
    :CATEGORY: properties).

> I can see to ways of doing this:
> 
> 1. implicitely add the #+CATEGORY value of a file to each entry in this
>    file,

That's what already happens, no?  Each entry in my *Org Agenda* buffer
is clearly labelled with the category which came from a #+CATEGORY
line or :CATEGORY: property.

> 2. clearly separate the group of files from the group of tasks, and
>    perform a group-restricted search.

No, as I said above, this isn't about grouping files.

> I think (1) is problematic: what if a file has a top #+CATEGORY and
> several :CATEGORY: properties?

Then the :CATEGORY: value takes precedence - this is already handled
correctly in the existing code which builds the *Org Agenda* buffer.

> What about precedence and inheritance?

This is too - the most deeply-nested :CATEGORY: value takes
precedence.  In fact, the only thing missing is that the code for
doing a property-based tag search doesn't honour #+CATEGORY, only
CATEGORY properties.

> How to build the search string if we want to search through several
> :CATEGORY: properties in a single #+CATEGORY ?

I don't think I understand the question.

> > No, I don't think it's #+CATEGORY per se which is only there for
> > backward compatibility - it's using it multiple times within a single
> > file.
> 
> The fact that only *one* instance of #+CATEGORY is allowed in a file
> calls itself for the divorce between #+CATEGORY (possibly renamed as
> #+GROUP) and the :CATEGORY: property...

What do you mean by a divorce, and why do you think this?  #+CATEGORY
and :CATEGORY: happily coexist at the moment.

> >> It's not that easy for users to understand how to user categories, 
> >> and staying with two ways of setting them might be confusing IMO.
> >
> > Surely this is an argument against introducing yet another grouping
> > mechanism!  We already have tags, properties, and categories.
> 
> But a category is just a property, even if the search interface raises
> this property above others.

I disagree on two fronts :-) (Although this is not hugely important.)
Firstly categories present the user with another interface to learn
about.  I am certainly not complaining, but you cannot discount the
extra complexity they introduce, and therefore we should be careful
about introducing yet more complexity.  Secondly, categories are more
than just properties due to #+CATEGORY - and in fact it is precisely
this oddity, or exception to the Principle of Least Surprise, which I
am trying to address in this thread.

> And besides these search considerations, I really believe that
> having several groups of agenda-files would help.

Quite possibly, though probably not for me :-)  Can you suggest a use
case or two?

> > I already have too many problems keeping a good work/life balance! ;-)
> 
> Com'on, our daily brain-sport is to feed this list! :)

Argh, way too much time spent on this list today ;-)