Technical Requirements for a Graph Editor

Etienne Saliez, version 2023-01-26 /

• Introduction:
• A generic knowledge graph editor could not yet be found, at lest for projects like:
•  Healthcare organizations,
  
• AIMIG, "Assisted Intelligence in Medicine using Interactive Graphs", http://www.aimig.org/ . where both medical knowledge and patient record information should be structured as graphs.
  
• Objectives:
• Creation and maintenance of knowledge bases by domain experts.
  
• Explainable decision support.
  
• Requirements and considered solutions:
• ( 1 )  Prototype initial requirements:
• Visual representation: of attributes of nodes and edges, like:
  
• Visual representation of concepts, i.e. nodes, and of their relations, i.e. edges. Visual presentations of their attributes by means of color, shape, size, etc...
• Typical examples:
  
• "neovis" of Neo4j, https://github.com/neo4j-contrib/neovis.js/ , Open Source.
  
• "vis-network" community, Open Source,
  
• https://visjs.github.io/vis-network/examples/ , https://visjs.github.io/vis-network/examples/network/other/manipulation.html , https://visjs.github.io/vis-network/docs/network/, see the preliminary prototype in construction at https://aimig-org.github.io/neo4j-graph-editor/ .
• Navigation and selections in graphs:
• Synchronization between focus in human conscientiousness and focus in the computer graphs. The focus means here that in both cases, only a small fraction of the content of a large knowledge base can be considered at a given point in time.  In a similar way only a small fraction of millions nodes can be presented on a screen.
• The question is to move easily to related concepts and to make synthesis. This by clicking on objects and moving the focus on different  point of view and challenges. Queries with filters.
  
• Creations and updates:
• Very user-friendly interface allowing natural drag and drops for the creation and update of nodes and edges. As well simple forms in order to manage attributes.
  Knowledge depend on human experts. Textbooks of knowledge could help but are mostly available in natural language. Anyhow domain experts must at least review any graph knowledge base.
  
• Typical examples:
• "Arrows.app", https://neo4j.com/labs/arrows/ (currently not good working on Firefox but well on Chromium browser). However this excellent example of human interface do not yet allow to update a regular Neo4j database.
  For  the purpose of creating knowledge graphs, the expected advantages are more precision while taking no more time than typing text and trying to convert natural language. An example: https://arrows.app/#/local/id=oQGPTlmtocZCO14nc-R- .
• Nowadays most graph software seems intended for big data analysis. However some have limited edit capabilities for individual nodes, as for example Bloom/Neo4j, Linkurious, ...
• Of course when possible import knowledge from available databases in other formats. However reviews by experts and maintenance will remain necessary.
  
• Information processing:
• It should be possible to associate some functionality to a knowledge base. 
  
• Event based architecture. Some events should trigger other events in the graph.  Particularly allowing evaluations of likelihoods and decision support. This in function of the weight of the relations with other concepts.
• This mean the possibility to attach some code to nodes, in function of their local attributes. This by means of some code inside nodes or calls to external functions.
• Medical collaborations;
  
• A biomedical knowledge base must remain open for discussion with experts, particularly with teachers in universities. Also in the raining of medical students. Experimental start with a few chapters and potential very large extensions.
• In order to be trusted the content of medical knowledge must remain open and independent.
• Keep the knowledge available for developing regions.
  
• This means "Open Data".
  
• Technical collaborations:
  
• Seek multidisciplinary developers willing to contribute to this challenging project.
  
• Keep the freedom to adapt the software in function of evolving requirements.
• As far as possible use Open Source software tools.
  
• Economic model:
• Developments to be based on grants for applied research. Contribution from partners needing software extensions.
  
• Support services as traditional business.
  
• ( 2 )  Later stages requirements:
• Decision support:
• Development of more advanced decision support and recommendations.
  
• Natural Language Processing:
• Not a priority at the initial prototype stage, since the focus is at the logic structure of knowledge.
• Precision:
• In the initial version, coefficients will be based on common sense guesses, which will be later improved on basis of learning from research on observed facts.
  
• Confidentiality:
• Role Based Access Control. In the case of healthcare every patient has a specific "Care Team", trusted by the patient and needing access to his information.
  
• Security:
• Protection against intrusions and misuses. Initially not critical for experimental project as "proof of concept", but well when real patient will be involved.
  
• 3D representation of graphs:
• To be explored. Potentially useful for navigation in graphs.
  
• Current exploratory prototype:
• See some tests on https://aimig-org.github.io/neo4j-graph-editor/ based on "vis-network", the Javascript framework "svelte" and the community edition of "Nep4j".