Exclude groups from search?

I’d like to exclude one or more groups from showing up when I do a Search. Is there a way now (or something in the works) that would allow groups to be excluded from Search in the same way they can be excluded from Classify?

TIA,
Robert Floyd
Durham, NC

Interesting.

There’s a way of doing that now, by replicating search results to a temporary group created for that purpose, then searching within that group for the group name(s) to be excluded in the URL/Path field. Then simply delete those replicants from the search results group of replicants and the remainder should not be from that group.

This would become simpler in DT Pro version 2, as one could use the NOT operator to exclude results associated with a certain Path.

Your suggestion of a check mark on a group to exclude its contents from searches (and others have suggested a similar check to exclude items from See Also) would involve a more straightforward decision by the user.

Any comments from you other users out there?

That more straightforward decision by the user is exactly what I have in mind. Some of the groups in one of my databases consists of indexed copies of implementation checklists. I’m keeping them here so I can use the DT database as a work hub/repository. Due to the nature of the checklists, they tend to show up in many search results and clutter things up. I’d like to keep them out of the way of searches. Hence, my suggestion of a check mark.

For me, this raises a fundamental question as to the proper use of DT Pro. I realize it can be used as a data repository. It can also be used as a knowledge base. Can the two functions be combined in a single database and still work well? My preference would be separate databases, but, until I can keep them both open at the same time (2007?), that isn’t a viable solution for me.

Is DT Pro the right tool for this?

Hi, Robert: I’ve got some very large collections of reference materials and tend to organize a number of topically-oriented DT Pro databases. And I want to have “portable” databases, so that I can work with my references whether I’m using my Power Mac or MacBook Pro.

So I don’t put all the files that I’ve got on my Power Mac into a single database. It simply wouldn’t fit on the 100 GB drive on my MacBook Pro, and it would be slow and unwieldy.

My main database contains about 20,000 documents, totaling about 24 million words. It’s quite a comprehensive reference collection reflecting my professional interests in environmental science and technology. The contents range over many disciplines, from policy, law and regulations (in several countries) to analytical chemistry, statistics, molecular biology, toxicology, risk assessment, conservation ecology and so on.

On my machines this database operates very quickly. The AI functions such as See Also work well for me, because although the contents seem very diverse, they are in fact related in many ways.

It really isn’t all that hard to design topical databases. Is there material about the history of science, food and agriculture, archaeology, anthropology and genomics in my main database? Yes there is, and it’s often useful.

But I’ve got another database for my financial and tax records. Still another database for a huge collection of information about the Apple Newton. And still others related to the health care infrastructure in Louisiana following hurricanes Katrina and Rita. And others still.

There’s really very little topical overlap between my databases, although sometimes I will “duplicate” a particular item into another database as well.

The first time I launch DT Pro after a restart it takes almost a minute to make my default database (my main database) available. Then it takes only a few seconds to switch to a different (usually smaller) database, and only a few seconds to switch back to the main database.

So even though I can’t currently run two or more databases concurrently, I gain a lot by splitting databases, and it’s no big deal to switch between them.

Like most databases, DT Pro databases need RAM to operate quickly. Although DT Pro version 2.0 will be much more efficient in memory use, some operations in big databases will still need RAM (I emphasize physical RAM, as it’s much faster than Virtual Memory swap files, which are slower because of the requirement for disk access). So even in DT Pro 2.0 I would not plan (or need to) launch all my databases concurrently.

So the practical answer to your question about marking some material to exclude it for searches is that you really recognize that such material belongs in its own database. If you’ve placed it in a database where it becomes an impediment to the searches you do in that database, take it out and put it in a separate database. You will then be able to search the material in both databases more usefully. But if you could mark it for search exclusion in the original database, you’ve made it less useful, as you could no longer search it!