Let's say you're considering types of search index which assign a set of values for different categories to each document. In the simple case, the categories you're using to categorise documents are words (or perhaps stems ). Given a short document text like:
"Perl on Tuesday, Python on Wednesday, Rain on Thursday, Perl on Friday."
You might get a document index that looks something like
# normalised all the index values to be in the range 0..1
# removed "stop words"
$docindex = {
'Perl' => 1,
'Python' => 0.5,
'Rain' => 0.5,
'Tuesday' => 0.5,
'Wednesday' => 0.5,
'Thursday' => 0.5,
'Friday' => 0.5
};
With one of these indexes for every document, stored somewhere, you'd have the kind of model that might be used, say in a vector space search engine. Once you've got indexes of this sort, there's no reason why you can't add keys representing categories other than the words within a document, such as "belonging to Course 11". Add keys to the per-document index that would never be words, but can be used internally to limit searches. For example:
$docindex = {
'Perl' => 1,
'Python' => 0.5,
...
'~~Course11' => 1 };
But ... all that said, since you've got a meaningful file hierarchy already ( /$course/$week/$item)I'd strongly recommend you look into something like HTdig and using it's restrict and exclude parameters to control where in the site a search is conducted. Basically, HTDig can be set to create multiple separate search indexes (perhaps 1 per course?) or create one big index, but then limit per-search results by path. It's documentation should help.
HTH
ViceRaid
update: rephrased for clarity |