As mentioned above, one of the guiding principle in making GNOWSYS is to make the kernel support flexible modeling. As a result the primitive constructors of the systems are sufficiently general and are less imposing. The number of constructors are kept as low as possible, but at the same time the approach is not minimalist in kind, since such an approach may make it very abstract, difficult and inconvenient to use. Keeping in mind the motivations mentioned in the beginning the system is suitable for building systems with high degree of expressivity than closed, strictly constrained formal systems, though the latter possibility is not ruled out. Thus from unstructured data (WFF) to semistructured (ISS) and structured data (CSS) can be constructed and stored. Also since multiple ontologies can be stored in the knowledge base, the relations between them can also be expressed using various semantic matching proposals (For example[19]). This is very important for meeting the objective (b). A teacher or an automatic evaluation engine could specify the semantic matching relations between different conceptual schemes and send the reports to the students. Since matching relation is a kind of analogy, more expressive analogical reasoning techniques can be employed.
The model draws from various well known models of knowledge representation and tries to support expressibility of the common wisdom of the area. In this regard, special mention be made on the models that are taken more seriously for the core structure: standard first order logic for declarative knowledge, UML for representing object oriented modeling[20], Petri Net Markup Language[21] for procedural representation and processes, and standard upper ontology for discourse of highly abstract meta level[17].
A special mention must be made in this regard on a resource that came in handy for grasping the wisdom: John Sowa's comprehensive work on Knowledge Representation[18]. The attempt is to meet Sowa's challenge of knowledge soup (``the fluid, loosely organized, dynamically changing contents of the human mind''), on the one hand and reach dialectically the procedurally represented declarative knowledge, and declaratively represented procedural knowledge on the other.
This flexible architecture of GNOWSYS also includes data exchange modules that can support interchange of knowledge base into various standards used in the industry and academia. Notable among them are: Common Logic (CL)[22], Concept Graphs (CG)[23,18], KIF (Knowledge Interchange Format)[24], Web Ontology Language (OWL)[25,26], Topic Maps (XTM)[27], and PNML (Petri Net Markup Language)[21]. OWL and XTM support is already implemented and support for others is under development. UML, CG and Petri Nets are very convenient modes of graphical representation of knowledge, and so are of special significance to the pyGTK[28] based GUI for GNOWSYS called `gnowser'.
The ability to store active classes and functions in the knowledge base can be actually used for self-representation of GNOWSYS. This however remains a possibility that we wish to explore and experiment in future.
A communication interphase with the knowledge base is an integral part of the GNOWSYS kernel. A database without RPC interphase makes not much sense particularly at this time when Internet is driving every application design. GNOWSYS contains an RPC called Gnowledge Query Library (GQL), implemented currently using XML-RPC. Other clients and servers, independent of their implementation mode, can communicate with GNOWSYS remotely. These calls can be embedded in any language that support XML-RPC library as an integral part of their logic, and hence very convenient to develop applications using GQL. This brings us to one of the most vital implementation strategies of this application.