%0 Journal Article %1 eisenstadt90 %A Eisenstadt, Marc %A Domingue, John %A Rajan, Tim %A Motta, Enrico %D 1990 %J IEEE Trans. on Software Engineering %K engineering knowledge software acquisition %N 10 %P 1164--1177 %T Visual Knowledge Engineering %U http://www.cs.toronto.edu/~nernst/papers/eisenstadt-journal.pdf %V 16 %X Abstract: Artificial intelligence software has for many years made extensive use of graphics facilities. However, knowledge engineers have not had access to visual programming tools which assist them during the critical early phases of knowledge acquisition. Moreover, during later phases of knowledge base debugging, knowledge engineers have had to work with program tracing tools (whether graphical or textual) which are inherently incapable of scaling up to the monitoring demands imposed by large, heterogeneous knowledge bases. To address these deficiencies, and to satisfy the needs of knowledge engineers throughout the software design, development, and debugging cycle, we have developed several novel visual programming and program visualization techniques aimed at knowledge engineers. Foremost among these are (i) a hypertext transcript analyser from which conceptual models can be generated; (ii) a ?direct graph manipulation? sketchpad which allows the knowledge engineer to sketch out objects and relations (including control flow and rule dependencies), from which code can be generated, and (iii) ?dependency viewers? which allow the knowledge engineer to examine and manipulate temporal and logical rule dependencies at different levels of granularity. The paper describes how these facilities are incorporated into KEATS, The Knowledge Engineer?s Assistant, and what key themes emerge from our approach to visual knowledge engineering.

@article{eisenstadt90, abstract = {Abstract: Artificial intelligence software has for many years made extensive use of graphics facilities. However, knowledge engineers have not had access to visual programming tools which assist them during the critical early phases of knowledge acquisition. Moreover, during later phases of knowledge base debugging, knowledge engineers have had to work with program tracing tools (whether graphical or textual) which are inherently incapable of scaling up to the monitoring demands imposed by large, heterogeneous knowledge bases. To address these deficiencies, and to satisfy the needs of knowledge engineers throughout the software design, development, and debugging cycle, we have developed several novel visual programming and program visualization techniques aimed at knowledge engineers. Foremost among these are (i) a hypertext transcript analyser from which conceptual models can be generated; (ii) a ?direct graph manipulation? sketchpad which allows the knowledge engineer to sketch out objects and relations (including control flow and rule dependencies), from which code can be generated, and (iii) ?dependency viewers? which allow the knowledge engineer to examine and manipulate temporal and logical rule dependencies at different levels of granularity. The paper describes how these facilities are incorporated into KEATS, The Knowledge Engineer?s Assistant, and what key themes emerge from our approach to visual knowledge engineering.}, added-at = {2006-03-24T16:34:33.000+0100}, author = {Eisenstadt, Marc and Domingue, John and Rajan, Tim and Motta, Enrico}, biburl = {https://www.bibsonomy.org/bibtex/2c758da35b11c329a0fef0d21c37a5869/neilernst}, citeulike-article-id = {111811}, comment = {knowledge engineer is only weakly supported at three critical stages in the knowledge engineering life cycle: (a) knowledge acquisition, during which problem conceptualization [5] must largely be tackled with paper and pencil; (b) knowledge encoding [5], during which it is frequently necessary to be able to navigate across a variety of knowledge representation formalisms; (c) large scale debugging, in which the graphical rule traces described above cannot cope with enormous rule sets involving hundreds or thousands of rules. - some interesting points regarding the differences between visual programming and program visualization. for example I don't think I'm looking at either necessarily, more concerned with the direct sub-area of showing the engineer what knowledge has been captured, the hidden relationships, etc. "our belief that the encoding of inter-object relations and dependencies in an evolving knowledge base should never be any more tedious on the computer than it is on an ordinary blackboard. In terms of the dimensions raised in section I, this means that we insisted on high manipulability. We observed that knowledge engineers during the early phases of knowledge acquisition spent a considerable amount of time sketching diagrams to help organise their own thoughts and to provide a first-pass problem conceptualization." - problem - claim is that these tools help and speed it up, but no proof - for scaling up, use genuinely different views, not just vis techniques "We refer to the synthesis of VP/PV tools, a sound knowledge engineering methodology, and AI programming support tools as ?visual knowledge engineering?."}, description = {sdasda}, interhash = {2f8b1ceaf3efa732b2a30fb817ae0f46}, intrahash = {c758da35b11c329a0fef0d21c37a5869}, journal = {IEEE Trans. on Software Engineering}, keywords = {engineering knowledge software acquisition}, number = 10, pages = {1164--1177}, pdf = {eisenstadt-journal.pdf}, priority = {0}, timestamp = {2006-03-24T16:34:33.000+0100}, title = {Visual {K}nowledge {E}ngineering}, url = {http://www.cs.toronto.edu/~nernst/papers/eisenstadt-journal.pdf}, volume = 16, year = 1990 }