QSR Forum: Avoiding duplication of nodes - QSR Forum

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Avoiding duplication of nodes

#1 User is offline   Paul Murty Icon

  • Casual Member
  • Pip
  • Group: Members
  • Posts: 6
  • Joined: 27-August 05

Posted 02 September 2005 - 01:48 PM

I read a Powerpoint presentation by Tom Richards advocating a technique to eliminate duplicated nodes; ie. when nodes on different tree branches with the same name. It looks like a good "relational" approach to use. However I haven't been able to find an explanation of the procedure, on the NVivo web site, or in two 1998 QSR Nudist books I have. Do you have any suggestions?
0

#2 User is offline   Paul Murty Icon

  • Casual Member
  • Pip
  • Group: Members
  • Posts: 6
  • Joined: 27-August 05

Post icon  Posted 06 September 2005 - 09:45 AM

I would very much like to hear from anyone about this query.

The idea of not duplicating makes sense to me theoretically, but what I don't know is this:
1. Assume a tree has two stems (nodes) A & B and each stem has leafs (nodes) 1 & 2
2. As I understand it, with the "relational" approach you will create "stem" nodes A & B and you will create separate "leaf" Nodes 1 and 2
3. What I am unclear about, is the coding of an item for (say) node A-1. When you code an idem for this node do you need to nominate A as an attribute? Otherwise, how else should it be signified that a particular "1" (or "2") is a sub-set of either "A" or "B"

I have a sizeable tree and would like to be clear about how to proceed before I start work with the chain saw.
0

#3 User is offline   Sue Bullen Icon

  • Advanced Member
  • PipPipPip
  • Group: QSR Staff
  • Posts: 286
  • Joined: 16-September 04
  • Gender:Female
  • Location:QSR International, Melbourne

Posted 08 September 2005 - 12:05 PM

Hi Paul,

It might pay to do a bit more reading on nodes systems before tackling the chain saw. But one point worth noting is that you don't always have to code at the stems (what we call Parent Nodes) and the leaf (child nodes). In fact there are probably many times when your parent nodes may be empty but your children have lots of coding.

When it is time to get the chainsaw and do some node-housekeeping, you can move your nodes around into more relevant categories and merge nodes (which also takes coding) if you find you have two nodes that mean the same thing, and...of course you can delete the unwanted ones.

How to do this housekeeping is detailed in the software's online help and there's lots of reading out there on nodes and coding - as a start, check out the Using NVivo or N6 in qualitative research texts which you would have got when you purchased the software.

Readers of this Forum who are experienced researchers may have some ideas!

Hope mine helps,

Sue
Sue Bullen
Training and Research Consultancy
Regional Manager, Asia Pacific
QSR International Pty Ltd
http://www.qsrinternational.com
0

#4 User is offline   Lyn Lavery Icon

  • Advanced Member
  • PipPipPip
  • Group: Trainers
  • Posts: 86
  • Joined: 12-October 04
  • Gender:Female
  • Location:Auckland, New Zealand

Posted 09 September 2005 - 03:03 PM

Hi Paul,

Firstly, I’d like to re-iterate what Sue has suggested above about doing some more reading before tackling the chainsaw (and of course, always make sure you have a back-up copy to return to in case the chainsaw misfires!).

Secondly, in regards to your query about the relational approach – I think I can see what your query is with this but am not completely certain, so let me know if I’ve gone off on a tangent and haven’t quite answered your question below. I’m also not sure if you’re using N6 or NVivo so may have confused matters by trying to be as generic as possible in my reply.

When I discuss this issue in my N6 and NVivo classes, I usually give an example from my very first project using QSR software (which was back in the days of NUD*IST version 4). This was before I knew much about the software and I cringe when I think back as to how I approached this! The study involved a series of individual interviews with reading teachers. We were looking at 4 schools – within each school we looked at 2 teachers and then 3 reading groups for each of those teachers. Within each reading group we had eight main themes that we were interested in. So – I built four trees for each school, each of which had children for the teachers and then grand-children for the reading groups. I then had great-grandchildren for each of the themes (within each reading group). This resulted in 156 nodes (I think – it’s a Friday afternoon here in NZ and that’s a lot of nodes to count up!) and meant that my set of eight nodes for the themes was repeated 24 times within my tree). At the time, I felt very efficient, but there were several problems with approaching it this way – quite apart from the fact that there were lots of levels to click down when I wanted to code (i.e. coding was hard work!), when I came to start searching, a lot of the questions I wanted to ask were impossible because of the very specific nature of the way I had coded.

If I were to approach this project again (hindsight is a wonderful thing!) I would instead use the ‘Divide and Conquer’ strategy that Tom Richards advocates. I would have a sub-tree for my 8 themes and separate sub-trees for my schools, teachers, and reading groups. This would give me something in the vicinity of 48 nodes – quite a few branches chopped off with the chainsaw here! When I came to code, to make the most of this system I would need to code my text at the node for the theme it belonged to, as well as at the node for the school, the teacher, and the reading group. This may seem at first glance like much more work but there are quick ways to do this in both N6 and NVivo (e.g. importing tables to automatically code all my school, teacher, and group characteristics, leaving me to focus on my themes).

I realise that the example I’ve given is partly ‘demographically’ based but I’m hoping that this gives you a basis for understanding how such an approach could be applied to your own project. I’m not sure which of Tom’s PowerPoint presentations you were reading, but the one entitled “Why Qualitative Computing is Radically Changing Qualitative Research” (available on the QSR website) is particularly good at explaining this.

Good luck!

Kind regards, Lyn
Lyn Lavery
Director, Academic Consulting
Auckland, New Zealand
Email: lyn.lavery@academic-consulting.co.nz
URL: http://www.academic-consulting.co.nz/
0

#5 User is offline   Paul Murty Icon

  • Casual Member
  • Pip
  • Group: Members
  • Posts: 6
  • Joined: 27-August 05

Posted 16 September 2005 - 12:16 PM

Lyn and Sue

Thanks for your replies. I just wrote a detailed response but it seems the page timed out. My file was apparently saved but I don't know where. It's easier to start again. I used Wordpad this time.

Lyn, your example is on target. Your reading teacher example is analogous to mine, and in the following passage you have given me a vital clue, missing from both "Not just a Pretty Node System" and “Why Qualitative Computing is Radically Changing Qualitative Research”

"I would instead use the ‘Divide and Conquer’ strategy that Tom Richards advocates. I would have a sub-tree for my 8 themes and separate sub-trees for my schools, teachers, and reading groups. This would give me something in the vicinity of 48 nodes – quite a few branches chopped off with the chainsaw here! When I came to code, to make the most of this system I would need to code my text at the node for the theme it belonged to, as well as at the node for the school, the teacher, and the reading group. This may seem at first glance like much more work but there are quick ways to do this in both N6 and NVivo (e.g. importing tables to automatically code all my school, teacher, and group characteristics, leaving me to focus on my themes)."

You refer to "eg. importing tables to automatically code ..." Is this just an example of one technique (among others) or is it the recommended way? Is there an explanation of how to do it somewhere? Is it in one of the books. Can you say more about this? I want to try it but I don't know how. By the way I am using NVivo2.

Speaking generally, for what seems like an important aspect of using NVivo, this is a very obscure aspect of the application, like some dark tribal secret. I see no sense in advocating this approach without guidance, as it is not intuitive. No one is likely to choose to duplicate codes to eliminate nodes unless they can see a method that looks simple and effective.

Paul
0

#6 User is offline   Lyn Lavery Icon

  • Advanced Member
  • PipPipPip
  • Group: Trainers
  • Posts: 86
  • Joined: 12-October 04
  • Gender:Female
  • Location:Auckland, New Zealand

Posted 16 September 2005 - 02:26 PM

Hi Paul,

Glad to hear you found my response helpful. Importing tables is just one technique for coding. When I referred to table import in my earlier example I was actually thinking of this being suitable for demographic data. I gather now that you are using NVivo - in NVivo tables are imported as 'attributes' rather than nodes. There is a detailed section on attributes in the NVivo manuals and also the help files. Good luck!

Kind regards, Lyn
Lyn Lavery
Director, Academic Consulting
Auckland, New Zealand
Email: lyn.lavery@academic-consulting.co.nz
URL: http://www.academic-consulting.co.nz/
0

#7 User is offline   Paul Murty Icon

  • Casual Member
  • Pip
  • Group: Members
  • Posts: 6
  • Joined: 27-August 05

Posted 20 September 2005 - 06:52 PM

Thanks Lyn. I have agonised about this for a while and decided that priority one is to devise ways of using NVivo that are appropriate to my current knowledge. Right now I have a thesis to complete and must put the issue aside, since I haven't resolved it.

Instead I have devised a simpler method, basically coding in bigger chunks. I can use NVivo to augment an Excel spreadsheet which I started to build with my data, before aquiring NVivo. The spreadsheet has great sorting and filtering features. It's fantastic for giving an overview. It's main weaknesses are the very primitive cell comments facility and absence of support for hierarchical data.

I can see myself using NVivo a lot over the next few years and I expect I will learn to use it in more sophisticated ways, hopefully with the aid of a research assistant.
0

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users