|
On 2/14/14 8:19 PM, David Eddy wrote:
Kingsley -
On Feb 14, 2014, at 7:47 PM, Kingsley Idehen wrote:
I have spent more than 20+ years
of total dedication to making new and emerging
technologies work with existing (so called legacy)
systems. I founded OpenLink Software to enable integration
of data across artificial data silos, created by *myopic*
applications.
But that's the DATA the systems produce.
Systems consume, manipulate, and output data i.e., the manipulate
the state of data. Thus, if the data is inaccessible the system
doesn't work, or at best it impedes other systems that need to
access its data.
I trying to talk about the SYSTEMS, that produce the data.
The SYSTEMS & the DATA are not the same thing.
I have never insinuated that they are. What's the MVC pattern about,
for instance? It breaks a system down into constituent parts that
deal with: presentation, orchestration, and data representation.
That said, nothing stops description of the presentation,
orchestration, and data representation using a language that's
inherently platform independent.
The SYSTEMS are the machine tools that produce the end
product, DATA.
See my comments above, you are misunderstanding me, repeatedly, and
simply refusing to accept this fact.
I am reminded of wisdom from the 1840s when industrial America
was learning how to make things. It was noticed that building
quality into the manufacturing process is far more efficient
than inspecting defects out.
Fine, but I don't see how this point is relevant i.e., there's no
new insight in the comment above, from my vantage point.
Just handling the data—the manufactured product—is an
exercise in futility until a firm understanding of the upstream
manufacturing process is fully understood.
If one doesn't know which systems, programs, logic, data
structures & rules are producing the data, how will one know
when the data suddenly changes?
You are looking at this whole affair from the inside out. I actually
look from the outside in, because we have new technologies
constantly being introduced in an innovation continuum; as a result,
its all about interfacing with existing systems via the data they
produce or manipulate. Basically, we work with data at addresses be
it a local app. or a Web-scale service.
In a nutshell, its ultimately all about lego-like infrastructure for
data access and state orchestration.
The sort of data dictionary product I'm talking of—decidedly
not a list of data elements—enables organizations to do impact
analysis—what's connected to what—so that we're not constantly
repairing down-stream errors.
I am not talking about a "Data Dictionary Product" .
I am talking about how data is defined.
integration of data across
artificial data silos,
Integration is not possible with silos. You mean
interoperable. There's a huge difference.
Integration is possible when one is in command, owns the
budget & has a blank sheet of paper, otherwise the only
option is interoperability.
The silos are not necessarily artificial.
An artificial silo is one that (by design) ignores the concept of
data fluidity by not adopting relevant open standards.
They were built that way for valid reasons... available
skills, limits of technology, budget, vision, deadlines,
organizational boundaries, etc.
We are in a continuum, nothing is static. Change is good. Change and
adaptation to change are critical success factors.
Silos are a complex reality we're going to have to learn to
deal with... as John Sowa points out, these systems are going to
be with us for decades.
Again, you are simply failing to understand my point, completely! Of
course, you can make a play on the generic term "silo" but in
reality I am specifically referring to systems that make their data
inaccessible by failing to evolve with the times.
Any DBMS system can implement an open standard for data access
circa. 2014.
Understanding language & meaning across Silos would be an
extremely useful application for Ontologies if they can be
commercialized.
That's what Ontologies do. And this already works. The challenge is
getting people to actually look at what's working instead of
constructing endless conjecture laden threads .
--
Regards,
Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
|
smime.p7s
Description: S/MIME Cryptographic Signature
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (01)
|