Understanding Associative Relationships

Taxonomies are collections of facets that consist of terms that are described and made unique through connections to each other through relationships. The common relationships are equivalency, hierarchies, and associative (related) relationships.  Of these relationships, the least understood of these relationships and the least used is the associative relationship. Associative relationships are sometimes also called related terms are sometimes also called See Also relationships or sydetic  (cross-references) structures.

One of the reasons that associative (related terms) are least used is because of the confusion about how they are implemented.  Hierarchies move us up and down a category of information that share common properties.  Associative relationship help point us to other aspects of a topic.

Associative relationships can help sort topics into clear categories.  This creates more simplicity that helps both programmers and users.  For example,  might be about paper products.  If I organize one giant enterprise taxonomy with a single hierarchy, types of paper products from envelopes to toilet paper will be mashed in with other topics such as paper weight, composition, manufacturers, or activities for which product is used.

Instead by sorting terms into facet and using associative relationships, you create a clearer graphical mapping of these concepts. In the example below, a taxonomy has been sorted into multiple facets.  This hierarchy has parent/child relationships, which can also be called the abstraction and an instance as in the illustration below:

.

Middle Level or Abstraction Products Manufacturers Composite Measured By
Lower Level: Instance Envelopes Canson, Tyvek Vellum

100% recycled content

Standard Sizes

Custom Sizes

The associative  relationship can be used to connect the dots  between the columns in the table above . An associative relationship can be displayed as a See Also,  a Related term (RT) as in ANSI-Standard Thesaurus relationships, or as a semantic relationship (predicate) as in a semantic triple.

Paper Products

See Also  Manfacturers and Distributors, 100% Recycled Content, Custom Products

Envelopes

See Also Canson, Tyvek, Vellum, Standard Sizes,

Or by a thesaurus relationship as in

Paper Products

Narrow Term (NT): Envelopes

Related Term (RT):  Manufacturers, Composite, Custom Sizes,

Or by custom  semantic Relationships which could replace the See Also or RT

Paper Products

<MadeBy>Manufacturers

<ComposedOf> Composite

<MeasuredBy> Standard Sizes, Custom Sizes

This design can also be represented as simpler controlled vocabularies that are stored in fairly flat files.  If a file is hierarchical, the hierarchy would be at most 2-3 levels.  In the following example.  the top level abstraction becomes the name of the facet with specific values for each facet as follows:
Facet1: Paper Products: Office Paper, Envelopes,
Facet2
Manufacturers & Distributors ->  Weyerhauser, Tyvek, Canson, ACME, Dunder-Mifflin
Facet3: Composite:  Vellum, 100% Recycled Content,
Facet4: Standard Size:

The benefits to using associated relationships to create the connections or “predicates”   between facets are multiple, but some of the obvious benefits are

Processing Improvement: Each facet is mutually exclusive/orthogonal and recombined as needed with other facets.

Extensibility: Since the design is based on a model and add new facets such as content type  (blogs, videos), audience or customer, events (such as weddings or business)  or additional attributes such as color.

Ease of Maintenance: It simplifies long-term maintenance because you no longer have to dive into and sort through or under complex hierarchies to find related concepts.

Discover Information: By sorting these terms into facets and using associative relationships it becomes easier to browse through an information space

The very best part of this approach is that you can change the taxonomy model , without changing the content, and you can update the taxonomy with new terms, such as processes, and it is updated everywhere.  There is one important caveat in this approach.  My data shows that this predefined modeling works 80% of the time  but for about 9% of  uses cases,  you will run into glitches  because of ambiguous or co-occuring single terms   that might appear in multiple facets.  These are words such a  such as “treatment” or “process ”  or  “evaluation” which, as  single terms, are somewhat vague.  When combined in compound phrases, such as “Water-processing”  or “Chemically-treated”, the meaning is clearer.

In my practice, I typically identify and  sort these vague  guide or hub terms such as “process’, “treatment’ “’management”, “evaluation” and so forth and sort them into a separate facet.  I can then use an associative relationship to point to the more specific compound terms (which are in their appropriate facet.)  When these terms are then sorted into the right facet, the meaning becomes even clearer.  This sorting of terms into facets and linking facets with relationships, including semantic, RDF-like, relationships as shown above can be used to create more specific information spaces.   The string that results from this work is more precise than a term that stands alone with no associated relationships.

By using associative relationships, you can build a taxonomy  where it is easier to discover related facets of information, and to combine attributes to refine searchers.  For example, if I am looking to information about envelopes for a wedding invitation,  associative relationships might also help me find information about  wedding planners, or wedding destinations.  I can find videos on how to properly create an invitation.

Of course, that assumes that you define taxonomies as “collections for facets, classes or graphs that create unambiguous terms.” It is also easier to add new facets if needed and link in new data using associative relationships.  Note:  I cannot  do any of the above UNLESS I have built predefined links between facets in the background model through associated relationships between facets.  It is very hard to recognize these known relationships “on the fly.”

Associative relationships are the least understood, but when you take the time to learn how to create them,  it becomes  one of the best arguments for taking the time to build a faceted taxonomy and in adapting data modeling techniques as part of taxonomy development.  If you are designing associative relationships for online systems, whether it is for managing content, e-commerce, or search, you might want to be attentive to how you create associative relationships because there are implications for implementation in improving user navigation and in machine-to-machine processing.

–      Marlene Rockmore

NOTE: In future posts, I’ll put up a reference table to show the relationship between  kinds of associative (related terms) and semantic labels for predicates in a “triple.”  Look for that in future posts.

Reblog this post [with Zemanta]

How to Teach Taxonomies

On several occasions   Heather Hedden, one of our authors,  gives full-day workshops on how to create taxonomies and other controlled vocabularies, and it’s interesting how different issues or problems arise in different sessions. It may be just one individual who has difficulty grasping a concept and asks lots of questions, but in answering the questions, it turns out that others have similar questions. It then becomes apparent that some principles, while simple on the general abstract level, can get muddled when we start looking at specific examples.

Here are Heather’s strategies that she’s  learned to help train new taxonomists in building taxonomies:

1. Use different methods of explanation to serve different backgrounds and mindsets

In one session I gave, an exercise on creating correct polyhierarchies had some people perplexed. The exercise was to propose two or more broader terms for “Paint Brushes.” Had I asked the participants to suggest just a single broader term, I probably would have gotten mostly correct answers, such as “Painting tools” or “Brushes.” But when having to propose two broader terms at once, many taxonomy students had gotten off-track and proposed a pair such as “Artists tools” and “Contractors’ tools.” This, of course, is not correct, since not all paint brushes are used by artists, and not all paint brushes are used by contractors. In one session, several minutes of attempted explanation to one individual were insufficient.

For the trainees who are more mathematical, an analogy with Boolean logic might make more sense. In such a case, we can say that the polyhierarchy represents the Boolean AND, rather than OR. The narrower concept must always belong to both Broader Term A AND Broader Term B, and thus the narrower term in a polyhierarchy represents the intersection or union of its two broader terms. For others with a reference searching or indexing background, however, it is necessary to explain the search and retrieval implications of the hierarchy. For example, “Paint brushes” is a term indexed to documents on all kinds of paint brushes, including those for commercial exterior painting. Thus, it would be incorrect to retrieve the latter documents with the broader term for “Artists’ tools.”

2. Teach the standards in the most practical sequence

At a recent corporate training I gave, the topic that was most challenging for the participants was associative relationships. The specific issue was what kinds of term pairs could legitimately use this kind of relationship. Listing all the possible types of term pairs for associative relationships as described in the ANSI-NISO Z39.19 standard (13 of them!) can add more confusion than needed. Training participants wanted to refer to this list when completing an exercise on proposing related terms. As a result, they proposed some rather unconventional related terms, that, while legitimate, were not entirely practical.

Teaching principles from the ANSI-NISO standard, I realized, should not necessarily rely on the same sequence or emphasis as written in the standard. It is probably better to present the list of 13 associative relationship types at the conclusion of an explanation on the associative relationship, rather than at the beginning. Similarly, I found that the ANSI-NISO standard’s order of presenting relationships between terms belonging to the same hierarchies followed by term terms belonging to different hierarchies may also not be best, since relationships between terms belonging to different hierarchies are more common.

3. Simplify demonstration exercises

Setting up a practice card-sorting exercise for classifying things can be a part of training session, but the card-sorting exercise should be modified. I had attempted once to create a number of cards (at least 25) considered desirable for a card-sorting exercise, only to find that the training participants only want to spend a few minutes on it, rather than the more intense 10-20 minutes that actual card-sorting participants would be expected to devote. Thus, a demonstration card-sort should be a much small set, along with the clear statement that an actual card-sorting exercise would be larger.

4. Revise sample exercises

Finally, the exercises included in training workshops may need to be tweaked after they are tried out. For example, asking for suggested broader terms for the term “Financial Management” obtained such varied and questionable results, that I had to remove that example and replace it with another. What I had in mind as broader terms were quite simple “Finance” and “Management,” but my audience was looking for other, more specific meanings of the term. Examples should not be ambiguous.

Conclusions

Even if you are not a professional taxonomy trainer, a lot of training is needed in the taxonomy field, and a lot of people learn how to create taxonomies on the job. Thus, if you are a taxonomist, you may find yourself required to teach taxonomy principles to others. Although some of it may come naturally to you and those you teach, other taxonomy principles will be more difficult to teach, and creative strategies are needed.

– Heather Hedden

Heather can be contacted for more information about her workshops and upcoming presentations at  Hedden Information Management.