I'm new to Drupal. One of the first thing that stumbled me is the idea of node type in the context of Drupal's Taxonomy concept. (I did a quick search and found no reference on this topic.)
My understand is node type affects the "shape" of the node. i.e. what fields are available. But on a theoretical/philosophical ground, isn't node type just a vocabulary and different node types are just different terms in this vocab? Along this line of thought, shouldn't fields be associate with a term in the "node type" vocab instead?
I came across a module called "taxonomy_fields" at http://drupal.org/node/183754 which seems to do what I mentioned. (I haven't tried it yet.)
I'm thinking, theoretically, does it make sense to get rid of Node Types in Drupal... Of course, I can appreciate this may not be feasible at all in practice because this is a fundamental change to the content model. I'm just trying to go thru a thought experiment, in the context of understanding Drupal's content model and philosophy better.
Am I making sense? Have I gone completely insane?
--
John
Comments
Most people seem to argue the oppisite
Most people seem to argue the oppisite, that is make everything a node.
One big difference between nodes and taxonomy is that nodes have a much richer API and content in Drupal tends to be node centric. Make a new content type based on a node and all sorts of Drupal goodness comes for "free".
As for "different node types are just different terms in this vocab", I would argue no, a closer thought would be to see each content type as a vocabulary and each instance of content type a term with the vocabulary. But this raises another difference, node titles do not need to be unique (taxonomy terms within a vocabulary must be). And while at time one way want titles to be unique that is not always the case.
Personally I like having both taxonomy and nodes. Taxonomy provides a light weight way of categorizing content (nodes) and can be applied to one or more content types (I wish it could be applied to zero but that is another story). Nodes on the other hand allow to be build models that represent data in some fashion.
The way I think of it
Abstractly node types are "what" something is, taxonomy terms are more for describing details about that something that it shares with other things (even things of different types).
Concretely use node types when you want a class of something to have certain functionality or behaviour in Drupal eg different settings, permissions or styling etc. Use terms for grouping together nodes that share certain properties eg for categorising or tagging nodes.
Also node types are a flat list that each node can only have one of. Taxonomy terms can be arranged in multi faceted multi parent hierarchies and each node can have many of them.
In Drupal think of using node types for defining how something works, and taxonomy terms for adding descriptive metadata to it.
--
Anton
New to Drupal? | Troubleshooting FAQ
Example knowledge base built with Drupal
--
Anton
(no title)
It also affects the workflow of the node, that is, one type of nodes can be initially be published while another type needs approval, one can appear on the front page and another not, one can be accessible only to some users etc.
On a philosophical ground maybe. Probably Wittgenstein in his late years would have appreciated the language game in this.
However, Drupal's taxonomy is a bunch of PHP code which allows the user to tag nodes with categories, and then the nodes can be listed on pages as teaser lists, in combinations depending on the hierarchy. So, the current incarnation of a vocabulary involves two things. Tagging nodes (and only nodes) and listing nodes (and no other operation). It doesn't contain code for doing anything else.
Occasionally someone comes along and writes some code which can extend the implementation of a concept and sometimes that catches on. In this case the developer used a part of taxonomy to build an innovation. If people find uses for it and if it proves stable, who knows?
As I said, there is also the matter of different default workflows. Also, personally I use fields on node types mostly to make things stay put on the nodes, for example, "in this type there will be a picture and will always go up-left". More freedom to place whoatever I want on any individual node seems to mean more work for me. I used to use taxonomy a lot when node types were weak, but I am finding myself shifting closer to node types these days, at least for some tasks.
Honestly, this sounds like something an artist would think, as opposed to someone who wants to "get the job done". The kind of freedom which would favor moving sands over building blocks. But then again, I have seen many strange things starting to make sense over the years.
Honestly, this sounds like
I may sound like I'm just dreaming up stuff without any practical need. But I'm not.
To take a step back, I think what I'm struggling with is whether I should create new node types or new taxonomy. At the moment, it makes sense to use taxonomy. But what worries me is some time later some of the nodes need different fields and/or different workflow.
Take an example. I'm creating an ebay clone and i have a node type for auction items. And I use taxonomy to handle different categories (e.g. cars, digital cameras). The site goes well and some years later I realise, just like what happened to ebay, I want to have fields for number of megapixels, model/made, etc for digital cameras so that users can easily search them. Also, i want a different approval process in order to advertise expensive items like cars and houses. So, suddenly i need new node types for different categories of items... But how do I migrate my current data to the new scheme?
If node types are just taxomony and all the logic (fields, workflow, etc) currently attached to nodes are attached to terms instead, this problem won't exist in the first place.
I believe Drupal is superior to other CMS because of its flexible content model. And I see that subsuming node types into taxonomy will make it even more flexible.
Am I making sense?
--
John
--
John
(no title)
I am not sure.
You can add fields to a node type, or rearrange fields. That is one of the things it is made for, and one of the things where work is done to improve stability and options.
A category (a) can apply to nodes with totally different layouts and (b) many different categories can apply to a single node (and they might compete between them if they have anything to say about the fields).
Perhaps you are thinking of a special kind of categories, of which only one can apply to a node type?
the Achilles Heel of the open source philosophy
imo- confusion these fundamental Drupal concept issue arises on conceptual thinking of this brilliant soft (web) ware came about from the way the logic of the coders not the end user - which is understandable given the fact it is open source- and the motivations (which defines the philosophy) it is not designed -fundamentally - from what the 'end user (site developer) ''market' thinks, behaves, acts when they use it. This is the Achilles Heel of the open source.
Because its not a propietary product to make it geared to the end user and not controlled as such, if it was most of the current coding logic would remain the same but the end user (site developer) experience would turn upside down approach somehow.
-imo- that requires coherent, combined logic on node type creation (what is in essence, a body an individual) ,taxonomies (relationship to others, society), and Views -combined with the Panels how and where it expressed - the stage). Not a separate developing process on those fundamentals.
To test this in a scenario, one would take a group of 'guinea pigs' of non coder website developers and find out how they think and approach to website development and redefine the 'product' according to results of this experiment which is not feasible in this case for various reasons.
An interesting observation,
An interesting observation, ica.
A software is most useful and allows us to get think done most effectively if it matches the conceptual model of the real world. (That's why OOA&D works well.) That's why Taxonomy works better than tree structure. It's because classification in real world isn't a tree. Along the same line of thinking, it seems to me having the behaviours/fields in taxonomy will work better than having node types, because properties (workflow, what fields are available, etc) of an entity is associated to the memberships of its classifications in the real world. Very often, end users may not be aware of the underlying conceptual model.
(e.g. Rosy is a dog. She can bark (a behaviour) and has 4 legs (a field). Dog is a classification in the organism taxonomy. But Rosy is also my family member: our pet. She has a room (a field) and her food is prepared differently at dinner time (a behaviour/process). "pet" is classification in the family member taxonomy.)
Ah, we can actually look at it from the software engineering perspective. The current Node Type mechanism is like classification in a single inheritance system in OOP. A node type is analogous to a class with behaviours and fields defined in it. What I'm suggesting is to allow dynamic multiple inheritance. Taxonomy become the classes with behaviours and fields. Node can be classified under different vocabs. This is analogous to multiple inheritance. With this, the node inherits the behaviours and fields from the vocab terms. And a node can switch from one term to another another. So, this is dynamic.
--
John
--
John
(no title)
Interesting thoughts. It is true that anything in the worlds can be categorized in numerous ways. Even unique things. The universe, for example, can be categorized as a book topic (among other things). CCK fields have been already categorized in the Download section (after a node was created for each one, of course).
Drupal can categorize things in several ways, not only using Taxonomy. Everything you do which differentiates one thing from another is a categorization. Should we add everything to taxonomy then? Sure, why not... if there is some benefit.
Rosy's four leg-fields categorize Rosy, not the legs themselves. Of course you could categorize the legs themselves by labeling them dog-legs, if you have an interest in displaying them independently from Rosy.
Rosy's room looks more like a Drupal path than a field to me. But for a farmer or a football player it would definitely look more like a kind of small field which should be categorized accordingly.
We could of course rename node types to "node building vocabularies".
However taxonomy. even as a concept, has its limitations. Taxonomy is one of many tools which Librarians use. In order of increasing complexity and completeness, they use Controlled Vocabularies (the simplest), Taxonomies, Thesauri, and Ontologies. Taxonomies contain only parent-child relationships.
Additionally, they also address object properties directly (not through categories) by using tools such as metatags and topic maps. This need has been apparent in Drupal lately and several direct node-relationship tools have been developed (node reference fields and a few node relationship modules).
This article gives a good and concise account of the different methods: http://www.ontopia.net/topicmaps/materials/tm-vs-thesauri.html
Interesting. Never thought
Interesting. Never thought of the problem from a library science perspective. That's a long read. Need to take some time to through it.
--
John
--
John