"Taxonomy" does not direct course of implementation
A taxonomy is an ordered, parent-child (or 'tree') structure, used to classify a set of data in groups and subgroups. Any relation to a subgroup implies a relation with the parent group(s). This phenomenon is also called classification, but has recently been popularly called "tagging". However, though tagging implies taxonomy, not all taxonomy is tagging. That is, after all, what implication means.
Relational models are taxonomies by definition
Of course, it makes sense to do something with this classification, but classification is not necessarily implemented relating items to a tree structure (like in Drupal) or simply tagging on-the-fly (like in Wordpress). Your relational model has an implied taxonomy. Having records in the 'news' table classifies, by definition, each record as an item of type 'news'. Each type_id foreign key referring to another table 'newstypes' classifies that record as the referred type, and the date_publish field classifies the item as an item that was published at that given moment in time.
Moreover, when you're normalizing your data structure, you're in fact applying taxonomy by defining groups (tables) and subgroups (relations) where your data belongs to.
So, whenever someone talks about a taxonomy, think of it as classifying data. However you implement that is up to the needs and requirements of the system. Whether tagging is in order or not is no other decision than what level of normalization you're applying to your data. Analyze and apply structure. You might end up with tagging. You might end up with an old fashioned relational model. You'll probably end up with something in between. Taxonomy is a buzzword. You need applied and applicable structure. Nothing else.