I'm trying to understand a bit of the hows, whys, and benefits. I'm using Categories (Taxonomy) to define content, and from what everyone says, using CCK to create content type is the way to go. So I am also using the Content Taxonomy Module. Now it might be that I'm just not understanding, and there is a lot I don't understand, however I'm trying to understand why it's a good idea to have a "Tag" in a table AND as a Term (Taxonomy).

Are fields better then more Categories (Taxonomy) or should I make a Category for all the data types I want to view or search on?

Can you do something with one that you can't do with the other, and that's why you can do both with the Content Taxonomy module; Create a term (Taxonomy) and save in a table (CCK)?

I've read a ton of stuff over the last 2 weeks, and I'm still very much in the trying to understand phase. I also think I may just have hit an overload, however I'd love to have a clearer understanding for exactly what each piece is for.

Thanks for any information!
Shari

Example of use: Artists: I have a Category for them, and I want to add an Information Page (Content Type) on each Artist (Tag), I then create a CD Page (Content Type) that has a field for Artist (Category) that I add using CCK I allow adding a Tag on the fly, and select Add as a Tag (Category) & Save to table (CCK). What does this allow me to do vs just having the Category listed via adding the content type to the Category list.

Comments

nevets’s picture

If we look at your example, you have artists and CD's. An artist could be both a term and a piece of content. As a term it has a single piece of information, most likey the artist's name. As content, it can contain any amount of information we want about the artist. A CD in your case is a content type that has an artist (or maybe even more than one). If your artist is defined as a taxonomy term and you assign the CD content type to the artist vocabulary. using free tags you can use an existing term (artist) or add a new one. When viewing a CD you can click on an artist's name and you will see a page with all content that use that term/artist's name (in this case both artists (as a content type, assuming it also uses the artist vocabulary) and CD), if you where to add another content type that uses the artist vocabulary it would also be listed. The oddity is that for this to work the artist content type must use the artist vocabulary, the possible plus is you can add a new artist to a CD on the fly (though that does not give you content/details for that artist). You can also add multiple artists this way, you just type a comma separated list of names.

Another way would be to make both artist and CD content types (no artist vocabulary). In this case for the CD content type you could use a node reference field to reference content of type artist. Now when viewing a CD it will list the artist and clicking the artist's name will show you the information (content) for that artist (vs a list of all content using the term/artist name). Note you could add a node reference to the artist type that references content of type CD, so the artists page would list all CD's which have been referenced from the artist. The possible negative is you need to add an artist before you can reference them (no addiing an artist on the fly), a strong positive to me is you can mark the node reference as multiple and easily add more than one artist to the CD. Depending on your point of view and the goal of your project this approach also takes you directly to the artist information (vs indirectly through a list).

So here we have two basic approaches that achieve more or less the same thing, but the details are slightly different. The approach you choose depends on your goals and preferences.

Hope this helps

karl sf’s picture

Hmmm I may be even more confused than before now.... ;-)

For things like Artists and CDs wouldn't there be a way to use "related fields?" I am new to this and trying out my own interdependent taxonomies amongst groups, content, and forums. Isn't there a way to create "related fields" and/or "related tags" I am puzzled as to the use of node reference and that of related fields or tags.

In your example of the artists and CDs, it seesm that the node referenced by pullig the artist's name must containg references to all other nodes by that artist? I am still trying to figure out how to create a node that lists several nodes. I thought I had to use Views for this, not node reference. Correct?

Karl Erb
User Experience Architect
Information Architect, User Interface Designer
http://www.linkedin.com/in/karlerb

uNeedStuff’s picture

Now when viewing a CD it will list the artist and clicking the artist's name will show you the information (content) for that artist (vs a list of all content using the term/artist name).

Ok let me make sure I'm understanding this, in the above example.
Because a reference is used, that is what is brought up. The content that is referenced. Basically it works like a link? The reference is a link to something that exists.

In that example could I click on the artists name and see every piece of content (node) that concerned this artist, only if every piece of content type (node type) had included the artist reference (CCK Field). Does it show actual content or only a link?

So if someone added a CD that included an artist but they didn't select the reference because it didn't exist yet, that CD would not come up, and would have to be added at a later time once the artist existed?

Because of cross reference on a single content type I could see the artist information & any other information also referenced. So a single content type (page, node) would include both information on the artist & information on the CD's. A content page is created with links.

=end of that example

If it was set up in a Category (Taxonomy/Vocabulary) as a tag (term) or even added on the fly, a content type about artist information could still be created and tagged. So if you clicked on the artist name (Tag, Term) it would show ALL instances of this artist: Information Page, and each CD Page, however they would all be shown individually and not on an individual piece of content (page, node).

Because of Taxonomy I would not have a single content type (page, node) that showed both Artist information & CD information.

No content, just a listing of everything like a search.

=end of that example

So basically how it is set up will effect how you view the information. Having it set up as a table field (CCK, content type) gives you more ways to pull the data, hence why setting up a table field is "better" but it may mean dealing with unattached nodes of information. Which is also true if it wasn't tagged, but 1 is easier then the other.

Let me know if I understood the basics of that please.... Thanks!

Shari
p.s.: and this might be the intent of the Content Taxonomy module