manicwave

Surf the wave

Info Interop

Permalink

Long absence. Unexcused. Who's keeping track?

I have been thinking about the intellectual barriers to information interoperability. Practitioners in technology are bound, some would argue, by reality or experience, but I would argue by tradition and experience. This translates into a measurable acceptance and open-mindedness about technologies such as EJB but the same crowd dismisses technologies like JINI without a second thought. Ignore the commercialization of these for a moment and focus on their similarities. Both provide services and the ability to locate services. EJB provides this in an almost parochial manner, focusing on static_ish_ configurations with purportedly increased levels of determinism. JINI on the other hand takes a more laissez-faire approach. Not worse. Not technically inferior. Not inherently less reliable. Just not as prescribed.

Now before the masters of EJB come after me, arguing that EJB is dynamic etc, my point is really that the manner in which a problem is solved using EJB and JINI are different to the extent that each technology exposes a different model for facilitating communication, a different model for robustness and a different approach to determinisim.

I would argue that most technicians today have difficulty with accepting that the JINI way is better, much less even practical. This has everything to do with models of familiarity, not demonstrated technical superiority. People are comfortable with the CICS model where things are there. The question of them not being there is not dealt with directly. (It may very well be by DR and network and guys with short ties, but not by developers). JINI proposes that a service with certain capabilities may

exist, find out, it may not be the one that you expected, in fact it may not even be there, deal with it, sometimes bad things happen.

Whoa....my goal was not to deal with EJB vs JINI, but rather to propose that a very similar phenomenon exists with data and information representation. Developers flock to XML because on the one hand it is indeed a vast improvement in many cases for representing structured information but it retains the comfort zone of header files, copybooks, IDL definitions, etc. The epistemological boundaries of XML as data container are well understood or not deeply contemplated at all.

Moving to the next level

I would like to explore the development of a pragmatic knowledge representation model that supports automated disambiguation and seamless translation services. Users of this framework would be able to build applications that interoperate at a semantic level with other applications.

We will explore representational technologies, select an approach, construct some sample domain examples and work on a framework to support translation and interoperability.