Home

Note 2: independence of infrastructure

While ontology operations can be demonstrated within conventional infrastructure, such infrastructure is poorly suited to such operations and limits them in the following ways:

• Scaling. We have become accustomed to thinking that web standards promote scaling, but only of a type and only in contrast with the past. It has been pointed out, for instance, that XML-based systems arent always better than EDI systems, merely that they have a different exchange standard.

• Speed. There are many conversions and dependencies, which are tolerable for transaction processing but are a severe limit on ontology operations which, ideally, run continuously and globally.

• Biases. Accommodation to weak infrastructure biases development to sub-optimal fixes.

• Innovation adoption. Accounting and permissions are weak, and dominant market players dictate self-serving standards. The environment thus lacks a set of rules that would create incentives for both continuous and disruptive innovation.

Each of these limits, taken alone, can easily observed to cripple ontology operations.

Taken together, they keep ontology operations as a perpetual laboratory curiosity. For example, the infrastructure of J2EE or .NET makes differential ontology hopelessly burdened by unnecessary transaction baggage. The use of stratified number theory, what is called referential bases, and the use of a patented construction (patented by one of the team members, ATS) called CCM is ideally suited for ontology production and transformation. The use of the relational database with SQL does not have agile metadata transformations except through the addition of meta modeling and SchemaLogics.

The path needs to be cleared if DARPA’s goals of speed, scale, and generative potential are to be responded to with more than partial and local measures, such as code optimization, or with more than lip service about future potential. Theorem proving in the context of OIL (Ontology Inference Language) is particularly ominous, and can be bypassed using common sense and the human in the loop reification process.

While we cannot ourselves build a new infrastructure within the confines of this focused research, a disruptive infrastructure development methodology has become newly available that is well suited to ontology operations. Our use of this disruptive methodology will be able to develop and demonstrate a complete and proper system rather than components that have to be expressed within .NET or J2EE.

This infrastructure is CoreTalk. The bibliography offers ample explanation of its principles and benefits and current state. In particular, very informative Macromedia type interactive presentations are available at:

http://www.ontologystream.com/area2/review/CoreTalk

While the developer’s interface is not finished and the system is not yet offered for sale, the basic tools are available and fully tested. The primary developer of the system is a member of the team and will train and supervise those who will develop the ontology operations. A suitable trainee has been selected and special agreement made.

We want to be clear on two points. CoreTalk is not merely an interesting tool. It is essential to removing crippling constraints imposed on reasonable ontology operations. On the other hand, use of the tool does not mean that we are opening a second and potentially distracting front in our development program.

We will end up adding a structure that will be available to CoreTalk users, but we are not directly contributing to the development of CoreTalk. Moreover, the use of our structures with CoreTalk and with other tools does not preclude interoperation with conventional tools and infrastructure. Specifically, we are targeting a conversion to and from OWL and Topic Maps, which will allow other complementary portions of the “reasoning pipeline” to work with ours.