The word "trust" has many meanings. The cryptographic meaning of the term is very specific, and should be handled with care.
In our day to day lives, the word "trust" has a very fuzzy meaning. It generally pertains to how we feel about the other people in our lives, however, and relates to things like whether we think someone can keep a secret, pay back a personal loan, or take care of our pets while we are away on a business or vacation trip.
In other circumstances, it can mean something different. For instance, in a military context it involves your belief in the competence of a colleague and the intent and willingness of that person to safeguard your life -- even if that person might never get around to paying back a debt, tell all your friends about that time you got drunk and puked on your brother at his bar mitzvah, or sleep with your spouse. That sort of situation is where pithy rhymes like "I trust him with my life but not my money or my wife" arise. This is a much more specific, clearly defined form of trust, but it is in some respects a more intensely personal form of trust than the day-to-day variety.
In cryptography, the use of the term "trust" is generally used with even greater specificity than in a military context. It is also a thoroughly impersonal usage, however. When speaking of cryptographic keys, trust has nothing to do with personal character, or really with the person at all.
In a cryptographic context, trust is not trust in what a person will do or say; it is, instead, trust in what a cryptographic authentication mechanism has to say. Authentication is a process of testing whether an person is who he or she claims -- not trusting the person; just verifying the person. The trust is in the authentication process itself.
This difference in the use of the term "trust" between security experts, soldiers, and bartenders can create some confusion, especially where learning to effectively use cryptographic software like netpgp is concerned. People who are new to the use of public key cryptography protocols like OpenPGP tend to be eager to use all aspects of the system that present themselves, and this includes assigning trust values to various keys in an OpenPGP system's "keyring". Unfortunately, this sometimes leads to keys being trusted that should not, in fact, be trusted.
Things get more confusing when we introduce the problem of the web of trust model of key certification used by the OpenPGP protocol. In this usage, the matter of trust assigned to a given key is particular to your certainty that the owner of a given key fully understands the web of trust model and will be conscientious and careful in its use. The web of trust is a means of getting some kind of reassurance that a particular key that claims to authenticate a particular person really does, in fact, authenticate that person correctly -- that it is not being used by the wrong person. Anyone can create a cryptographic key, and use it to claim to be whoever they like, and the problem of determining that a given key authenticates something is solved by personally observing links to other identifying factors, but the web of trust model can be used to provide a next-best solution when that is not reasonable.
Absolute trust in a cryptographic key's authenticating power must be predicated upon a personal knowledge of the person's connection with that key, and upon a certainty that the key has not been compromised by some other party. A more realistic degree of trust would rely on a personal knowledge of the person's connection with the key and a reasonable belief that it has not been compromised, and in fact will not be compromised, because the person is very careful and exacting in protecting the key.
How certain are you, however, that the person on the other side of that key has not been beaten with a rubber hose until giving up the password used to access his or her private key? Only the most dedicated of people are likely to resist rubber hose cryptanalysis. Then, of course, there's always the fact that you have to trust they can effectively secure their systems, regardless of intentions. Do they use software that they are not even entirely certain does not report back to someone else, or that is prone to compromise by malicious security cracker? Do they verify security to the best of their ability with integrity auditing systems?
Because it is not always reasonable to meet someone in person and check his or her ID card when exchanging cryptographic public keys, it is not always reasonable to require such extreme levels of trust for a given key when deciding whether to communicate with someone. This requires a certain amount of acceptance of risk. One of those risks is the risk you take when you decide to accept an email as having come from a particular person based on a cryptographic signature, even if you have never met that person.
The web of trust model is meant to mitigate that risk somewhat, by providing a way to get some kind of assurance -- a lesser assurance than personal verification, but perhaps better than nothing -- of the authenticity of the key in question. This assurance comes in the form of trusting others to do a good job of making sure they only trust keys that should be trusted. You may trust someone with your money, your life, your secrets, and your wife, but that does not necessarily mean that you should trust the person's tendency to assign trust to other people's cryptographic keys. Remember that if you mistakenly trust someone in this context, you are betraying the trust anyone else places in you in that same context.
Thus, tools like netpgp and GnuPG provide a means of assigning trust to keys indicating how certain you are that the owner of that key will use it wisely when "signing" someone else's key as being verified authentic. In general, unless the key was given to you in person along with some way of providing real certainty that the person is who he or she claims to be, you should not sign that person's key; this is a certification of the narrow definition of cryptographic trust in that key's authenticity. The last thing you want to do is certify a key when you cannot be 100% certain that it was not compromised in transit by a man in the middle attack.
In general, unless you believe another person will adhere to the same standards of cryptographic trust when signing someone's key, you should not elevate the trust rating of that person's key in your OpenPGP tool's "trustdb". This is where the web of trust comes into play, as their certifications of keys can be used to provide you with a sense of whether a given key should be accepted as verified authentic.
When in doubt, the default level of trust you should assign to a given cryptographic key is always "none".