Thursday, March 23, 2017

KBE, futures

I wrote this on Wikipedia (Knowledge Based Engineering - KBE futures, KBE theory) back in 2006:
    KBE, as a particular example of KBS, is a multi-disciplinary framework that has more than practical considerations. Not only will KBE require successful handling of issues of the computational (OntologyArtificial IntelligenceEntscheidungsproblemInteractive computationCategory Theory, ...) and logic (non-monotonic issues related to the qualificationframe, and ramification problems)), it will touch upon all sciences that deal with matter, its manipulations, and the related decisions. In a sense, Product Lifecycle Management allows us to have the world as a large laboratory for experimental co-evolution of our knowledge and artificial co-horts. As noted in ACM Communications, "Computers will grow to become scientists in their own right, with intuitions and computational variants of fascination and curiosity." [19] What better framework is there to explore the "increasingly complicated mappings between the human world and the computational"?
    A continuing theme will be resolving the contextual definitions for KBE into a coherent discipline and keeping a handle on managing the necessary quantitative comparisons. One issue considers what limits there may be to the computational; this study requires a multi-disciplinary focus and an understanding of the quasi-empirical. Given the knowledge focus of KBE, another issue involves what limits there might be to a computational basis for knowledge and whether these are overcome with the more advanced types of human-machine interface.
    It is important not to treat the KBE technology in isolation, but focus more on its role in the overall Product Development Process (PDP). During development, it is important to streamline the process from knowledge capture towards software implementation. To this end, close-coupling between Knowledge Management and KBE is desired. Transitions from data and information inside a Knowledge Base towards software code is of particular relevance. The best results can be achieved by using model-driven software development principles, which includes automatic code generation and round-tripping. The use of KBE during a PDP not only requires the ability to easily set-up (existing) KBE applications from a knowledge level, but also the ability to store back the results after execution of the tool. In order to use KBE on a strategical level as decision-making and planning support mechanism, it is important to relate results back to the system engineering domain (requirements, functions, options, embodiment). From deployment perspective, a better integration with other IT tools should be realized. Couplings between KBE applications, Knowledge Bases and Simulation Workflow Management software are of particular importance. The iProd project tries to take KBE to the next level by addressing these aspects.[20] The iProd framework uses KBE technology as a reasoning mechanism to infer new product knowledge and, as a means to automate virtual execution (CAE simulation) and as MDO-enabler. On an IT level, it prototypes KB-KBE couplings (code generation, round-tripping, results storage and automatic workflow generation) and SWFM-KBE integration (on the basis of the software-as-a-service paradigm).
It still applies, though the section has disappeared.

Remarks: Modified: 03/23/2017

03/23/2017 --

No comments: