Indexing thoughts

[Quanah Gibson-Mount <quanah@stanford.edu>]

Stanford has been looking into implementing the value-sort attributes 
overlay, and realized some problems with using it, if the attribute to be 
weighted is also indexed and you will be using weights.  Primarily, the 
problem stems from this:

The unweighted form of the data could look like:

suaffiliation: stanford:staff
suaffiliation: stanford:faculty

etc

The weighted form of the data looks like:

suaffiliation: {2}stanford:staff
suaffiliation: {1}stanford:faculty


This means if you use the data for indexing (in particular, in my case, eq 
indexing), it will no longer be possible to use filters of the type 
(suaffiliation=stanford:staff).  Which is problematic when many 
applications do that very thing (and internal ACL's use it as well).

I thought a potential solution (not possible at this time, per Howard) 
would to be able to support something like multiple indices (sub indices?) 
that would actually index the data in both its weighted and unweighted 
form, if the val-sort overlay was present.  It is also something I thought 
could be potentially useful for other overlays (how, I'm not sure).  But 
the ability to have indexing behave differently based on different factors 
does seem potentially useful.

In addition, things get more complicated when telephoneNumber (and things 
using its syntax) are involved.  Mostly because {}'s are not valid 
characters per its syntax, meaning you can't sort the attribute via 
weights.  The ability to tweak SYNTAX based on overlays I guess would be 
the solution, but sounds ugly.

Anyhow, just a set of thoughts, I don't know how practical implementing 
such a thing would really be.


--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html