How NoSQL Paid Off for Telenor by Sebastian Verheughe and Katrina Sponheim.
A presentation I encountered while searching for something else.
Makes a business case for Lucene/Solr and Neo4j solutions to improve customer access to data.
As opposed to the world being a better place case.
What information process/need have you encountered where you can make a business case for topic maps?
[…] Another Word For It Patrick Durusau on Topic Maps and Semantic Diversity « How NoSQL Paid Off for Telenor […]
Pingback by Speaking of Business Cases « Another Word For It — March 29, 2013 @ 4:35 am
There is definitely a business case for topic maps in system integration on large systems. I work in Process Control/Automation where the final customer uses a system built on stack like this:
Final user facing interface.
Project, process, or equipment specific programming.
Site specific configuration and programming practices.
Company standard or third party libraries.
One or more vendor platforms and/or software systems.
One or more national or international standards.
Each of those layers uses it’s own vocabulary, evolves at it’s own pace, has it’s own set of documentation, and enforces it’s own set of constraints on the final behavior of the system.
The end user needs a system that works 24/7 and it costs them a lot of money when it does not work as expected. Since each system connects to 100s or 1000s of real world devices and each system has multiple, simultaneous users, the system does not always behave as expected.
So, when there is a problem, how do you find the root cause? The current model is to hire expensive, trained experts who start with the final symptom, dig through the code, figure out what components are related, and work their way backward until they find the problem. If it is a software bug, they then figure out a work-around to get the plant running but but the work around can not impact any of the related functions or other equipment where that chain of components is used. Needless to say, it takes a lot of time and the user is losing money every hour. I’d bet that the right topic map could shorten the time by 80% or more.
Comment by clemp — March 29, 2013 @ 7:02 pm
That’s an excellent use case! Both from a documenting relationships perspective but also capturing what was discovered by the experts when problems arise.
That is the documentation for the system grows more complete as it is used.
And the writers would not need to be description logic experts, they could describe the “logic” of the system as it exists.
Comment by Patrick Durusau — March 31, 2013 @ 4:08 am
That is the problem that led me to start investigating Topic Maps (and your blog, which has been a great resource by the way). Yes, I started with a problem and found Topic Maps as the potential solution. Conceptually, Topic Maps seem like a perfect fit but it has been difficult on two fronts.
First, it took me a long time to understand what tools are out there, what their capabilities are, and which ones are still maintained. (As an aside, you would think the topic map community would have a central topic map based repository/wiki to make it easy for new developers to get started. )
The second problem, and the one I’m working through now, is that information modeling with topic maps is a new paradigm for me (and most people I’m sure) and the information on topic map models is widely dispersed. Techquila had some design patterns that were very useful and later those were put put in a paper by A. Kal but, in general, it is a lot more difficult to figure out the information model with topic maps than it is with SQL or NoSQL or RDF because those other technologies have a lot more open discussions of designs to cover specific use cases. If those discussions existed for topic maps, it would make it easier for non-experts like me to connect the high-level this-is-how-topic-maps-work type information (that is plentiful) with the this-is-the-problem-and-this-is-the-model-that-solves-it type information (that is hard to find for topic maps).
Specifically, the problem I’m trying to solve and many other real world problems need a semi-structured information model, not just an amorphous blob of topics and associations. There are multiple dimensions of hierarchies and sequences that need to be modeled so that the end user can query the system with OLAP type queries where they drill up and down or pan forward and back through the information until they find what they need.
Do you know of any books of Topic Maps use cases and/or design patterns?
Comment by clemp — March 31, 2013 @ 7:11 am
Last question first: No, I don’t know of any recent books on Topic Maps use cases or design patterns. (but see following)
A great statement of two problems that need to be addressed by the topic maps community.
I will split your comment into two separate posts for reply as I think your comments need more attention than is likely in a comment thread.
Both can be solved but only be a community effort.
Comment by Patrick Durusau — April 1, 2013 @ 12:24 pm