Adding Fields to Relationships

[QDATRAINING Admin]

Question Posed by David Walker

Adding Fields to Relationships

Is it possible to add fields to relationship types? For example I would like to have a relationship "employs" between two Person nodes, but I would also like to track a person's employment over time, so I would like to have a start date and end date on the employs relationship.

 

Initial response from me:

Ben Meehan – QDATRAINING • Hi David, 
The only field you can add to a relationship is the relationship type. However, if you fully understand the concept of the person node (case node where the person is the unit of analysis) then there are limitless possibilities to track anything about the person including dynamic information such as who the person employs now or has employed in the past and for what period this relationship sustained. 
Kind regards, 
Ben

 

Added to by Veronique:

Véronique Gosselain • Ben, 
Can you explain in more details, perhaps with an example, how to create dynamics relationships that include a diachronic dimension (and thus changes of relationships along time). 
Thanks a lot! 
Véronique

 

My response:

Hi Véronique,

Sure! To do this you need to understand two core concepts. First, a relationship node is just another node in NVivo that has two permanent additional fields attached known as ‘relationship type’ and ‘From and To’. However, apart from these two additional pieces of information attached to all relationship nodes, it is just like any thematic node in your database. You can code content to it which stacks up the relationship as defined by the researcher. Queries are often used for this purpose but it can be done manually as well. The second concept is the often misunderstood case node. Since version 9, there is no longer a prescribed folder for case nodes. Nevertheless, the concept still exists exactly as before. Put simply, this concept is that the case contains everything the person said, and this is physically linked through classifications and attributes to who the person is. The person’s words are inside the node and their identity, who they are, is linked to the node; tangible things such as demographics and wider profiling information.

Many people do not set up case nodes correctly. They will attach fields to sources and/or thematic nodes. There are valid reasons for attaching fields to sources such as metadata attached to a scholarly article if you were using NVivo to manage your literature review as just one example. But for case nodes, you need to attach this information to the case node and nowhere else. The case node represents the unit of analysis and may be one of several such units. In this simple example, the person is the case. So let’s assume that both concepts are understood and the database is fit for purpose.

David wished to track the person’s employment in a field called ‘Employs’. So he creates a field (attribute in NVivo) called ‘Employs’ and the values will be other participants’’ names. So Case ‘A’ employs Case ‘B’ and so on. Let’s assume this relationship is dynamic and Case ‘A’ employs Case ‘B’ in 2011, Case ‘C’ in 20012 and Case ‘D’ in 2013. We can have as many attributes as we like and we can control the time span using date fields as well. There are several ways to do this but to keep the example simple let’s create just three fields: ‘Employs – 2011’, Employs – 2013’ and Employs – 2014’.

Of course, we can create a ‘relationship type’ using these same fields (Classifications->Relationship Types->New Relationship Types)  but this is not the same as tracking this information across attitudinal or thematic nodes so using the case nodes is still our best bet. Now I can right click on any node, anywhere in my database (including relationship nodes) and correlate employment information for anyone coded in that particular node. I can use visualizations, coding queries, compound queries and matrices to track and report this information. I can spot patterns in the data which may not be obvious from reading the nodes alone. I can filter information. Show me content in a given thematic node, but only from those who employed Cases B or C and in 2011 for example. Now rerun the query to compare what people said about these same cases in 2012. Has the attitude changed over time? And all we need to do this is have our content correctly coded to the theme and our case nodes set up correctly and working for us in the background.

Case nodes allow me to cross reference tangibles such as demographics and profiling information with intangibles such as attitudes, beliefs and behaviours which have been carefully coded line-by-line from my qualitative interviews, focus groups or open ended questions in my questionnaire. David’s employment information is just one example of a myriad of pieces of relevant information that I may want to track, not just in relationship nodes, but in any node.  The beauty of using case nodes is that once a pattern is identified, it could not have been put there or influenced by the researcher because she was coding for meanings and not profiling information. If the pattern is there, it’s there because it exists in the data.

Anybody seeking to optimise their data is well advised to learn how to correctly deploy case nodes in their study.

Let me know if you need clarity on this!

Kind regards,

Ben

[Author]

Posts