I'm going to be obnoxious and raise this issue again. Please realize that I am looking at it from the perspective of a system designer who has designed large systems from punch cards to web. From the perspective of the user, when they run a recipe search they get back two results:
- a list of recipes that meet their search requirements
- an implied list of books that have no recipes that meet their search requirements - it doesn't matter how many recipes the book has
To successfully search their library, they have two additional groups of books to consider:
- books in EYB but not indexed - these can often be narrowed down by the book categories so one checks the indexes of only cookbooks likely to have the recipe (no need to search "no recipe" books - they have already been searched)
- books not in EYB - here they're totally on their own and their way of shelfing books
From the point of view of a user, when they run a search and find no matching recipes in a book, it doesn't matter whether it is because no recipe matches or because there are no recipes. Either situation says don't consider the book further. A book "indexed" with no recipes behaves just like a book indexed with recipes. This means two things:
- when applying filters books without recipes should fall into the indexed category
- the multiple editions of books with no recipes should be linked so that all editions register as having no recipes (and so people don't request indexing on a book known to have no recipes).
Yes, from the point of view of the deisgner and the adminstrator of the system, no recipes means "don't waste your resources looking for an index - there isn't one" but from the point of view of the user, no recipes means "the system has searched all the recipes i.e. zero recipes".