This article is crammed full with little quotes that I really should remember when I’m trying to explain what’s fundamentally wrong with trying to store your data in traditional databases. Anyone who’s ever developed a system for a customer (whether in-house or externally) knows the pain of having shifting requirements not only throughout the development process, but after go live too.
At first I would roll my eyes and tsk at the non techies who hadn’t thought through how their work was structured (so that I could design a system that fitted it) - but that makes no sense - of course the requirements change as time goes on, it’s completely natural for a business model to shift and change as it needs to - you’d bloody hope it would! If it doesn’t your working for one of those companies that refuse to do anything differently because “that’s how they did it in 1997”.. or something.
But to get back to the original point, and to quote the article:
With a Semantic Data Warehouse, there is a fundamental assumption that the schema is never finished. It evolves.
You don’t have to map out the entire organisation before you build a system for it - you just build the bits you know, and if the model changes, then you adjust your own data model accordingly and move on. You can do this because you’ve not set out your schema in concrete, with painful reconstruction needed with each change - instead you simply adjust the relationships between your objects (nodes/topics, whatever you want to call them). Simples.
It’s not about the Warehouse or Federation. It’s about a dated, inflexible model. That is why semantic technologies matter. With that flexibility you can do more, faster.