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 
};
[download]

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 };
[download]

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