About a month ago I wrote about some of the real reasons why we use SharePoint. In that post, I mentioned how one of my coworkers was complaining about the fact that we haven’t been able to link three managed metadata columns together, even though there is a relationship baked into the aliases associated with the terms. I was hoping that someone would have commented to point out the cryptic instructions required to turn on “cascading metadata linkage.” Alas, no such feature exists. I did get a comment though. Marc Anderson said:
“We could probably do whatever you mean with the managed metadata columns with some script”
I won’t steal Marc’s thunder. Actually, I’m not sure I could, but I do want to talk about one of the problems he ran into; not one of the technical problems he’s so adept at solving, but one of the “shouldn’t this work better” kind.
Managed metadata is one of the features that we were really looking forward to using when Microsoft first started talking about it. The most important thing we wanted to use it for was to link the facilities we insure to their policy numbers and to the name of the entity that holds the insurance policy (Named Insurerd). The facility is easy to understand and pretty easy to remember, but there are some nuances. A simple example is Pilgrim Nuclear Power Station, the facility is known as “Pilgrim” it doesn’t get any easier. If you are talking to someone from Pilgrim or if you are inspecting Pilgrim or visiting Pilgrim, you’re pretty likely to remember “Pilgrim.” For one of those nuanced examples, we need to move west about 800 miles to Cook Nuclear Plant. You might be saying “what’s so hard about Cook?” Well, at one point, it was referred to as “D.C. Cook” and we still have documents that say that. We still have documents that say “Donald C Cook” and we have some that say “DC Cook.” All of those variations need to lead to “Cook” and that’s one thing that managed metadata does well.
If you click on either of those links, you will see that Pilgrim is owned and operated by Entergy and Cook is owned and operated by AEP; those are the named insureds and “Pilgrim” and “Cook” are aliases for those named insured respectively. Policies are another matter, because some insureds have multiple policies, but we have been able focus on the most likely one to be used with our reports.
In spite of the tricky bits, that all still sounds fairly easy to work with, so why was Marc having problems? Well, things change.
One of the things that changes is ownership; nuclear power plants actually do get bought and sold. So what would happen if “Joe’s Nuclear Power, Inc” were to buy Pilgrim from Entergy? What should happen is the “Joes Nuclear Power” should become the named insured but “Entergy” should be added as an alias. If we do that, then when someone finds a document in the future that still refers to Entergy, they will be led to Joe. One of the problems that Marc ran into was related to the fact that facilities have been sold, but aliases have not been added. He also ran into problems because the metadata terms were entered, complete with the apostrophes, commas, ‘inc’ and a couple of ampersands which SharePoint hates.
Managed metadata is a very powerful feature, but in order for it to work well, two things have to happen. The relationships between terms and aliases as well as related terms need to be defined and documented; and the terms need to be maintained as things change. The proper maintenance of the managed metadata term store needs to be somebody’s job. We had given several people the permission to manage the terms, but we hadn’t made it anyone’s responsibility – we’re going to fix that.
Advanced features like managed metadata work like magic when done well. Unfortunately, people get used to the magic and assume that the results are reliable. If they enter a term and nothing happens, or if they are led to an out-of-date answer, they may not realize that something is wrong. We were lucky that Marc stumbled onto this problem while it is relatively easy to repair. In the future, we will pay closer attention to the ongoing maintenance that is required by each solution we build.