David,
I know IBM 360 Assembler – do you have a job for me?? Just kidding (not about the Assembler, though).
I do agree with your comment on data integration vs data interoperability. While some may use these terms interchangeably, my take has always been that integration is something you do with things you control, while interoperability is something you do with things you don’t control (or don’t want to spend the resources on controlling). Another way to look at this is that systems/enterprises have differing degrees of autonomy with respect to each other, not to mention alignment of domains, interests/motivations, operational context/scope, and frames of reference they use to describe reality. While there are certainly a lot of accidents of history and arbitrary decisions for representing entities in a computer model/data base, most data elements used in such systems have lots of good rationale for why they are what they are, at least for the time frame when the system/enterprise was first built/created. And changing to a more modern design doesn’t necessarily help the interoperability problem because they will still have to work with a broad variety of other enterprises and systems that made different decisions regarding representation of reality – and will continue to do so to stay in business.
I also agree that ontologies and semantic technology is well suited for addressing the data interoperability problem, although it will still take a lot of human intervention to arrive at reasonable mappings of some data elements in one representation and frame of reference to another, especially those dealing with enumerated value sets and entity identifiers in different and overlapping name spaces. And there is a business model for doing this as a third party business model to bring down the cost of using semantic technology by amortizing it over a much broader customer set that any individual legacy system owner is likely to be able to do. I’ve attached a short white paper I wrote a while back on this point.
A last point – there will always be this problem and there will always be “legacy systems”. New ones are being built every day, with brand new technologies that will be next year’s or next decade’s legacy system and old technology (what were those system developers thinking back in 2012!!). We now live with a networked ecosystem of systems and enterprises that will contain elements of a broad diversity of technologies and representation conventions/standards of varying ages and stages in the overall evolutionary life cycle for such technologies and representation standards. We need to deal with this reality of inherent diversity of perspectives, contexts, scopes, and frames of reference. Trying to eliminate this inherent diversity is a fool’s errand. That’s not to say that eliminating gratuitous or accidental diversity isn’t possible, useful, and desirable. But my experience with lots of real world systems is that once you manage to get rid of the gratuitous diversity you are still left with a lot of inherent/essential diversity.
Hans
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of David Eddy
Sent: Wednesday, February 29, 2012 7:11 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] What goes into a Lexicon?
Matthew -
On Feb 29, 2012, at 1:48 PM, Matthew West wrote:
There is more money to be made by those with ontological skills in data integration than in all the other possible applications put together, multiplied by a large number.
If I can swap "data integration" to "data interoperability" I'll strongly agree. Unfortunately I do concede these terms are used interchangeably.
As you say earlier "it's a global business"—which I'd guess pretty much describes most of the Fortune 1000. Delaying data flows is clearly a huge issue.
Moving this to "legacy systems maintenance"... the legacy systems are in place. They're not moving. They're not going to be replaced. The real challenge is that the people who understand these systems are going to be retired in the next 5-10 years. I'm searching for a company that's retraining it's Java programmers to Assembler.
Someone at a disaster recovery/business continuity seminar made the comment that systems are relentlessly becoming more closely tied. I'd be willing to bet that by the time we get to iPad v13 they're going to be doing real work that reaches back through multiple layers to decades old legacy systems. And every layer will have different language to describe the business problem.
Clearly rich terminology ground.
