Khoo, C.S.G., Ng, S.G., Chan, C.F., Stanley-Baker, M., Tan, E.A.L., & Cheng, W.N. (2024). Knowledge graph visualization interface for digital heritage collections: Design issues and recommendations. Information Technology and Libraries, 43(1). https://doi.org/10.5860/ital.v43i1.16719

Abstract: Digital heritage portal interfaces are generally similar to digital library and search engine interfaces in displaying search results as a list of brief metadata records. The knowledge organization and search result display of these systems are item-centric, with little support for identifying relationships between items. This paper proposes a knowledge graph system and visualization interface as a promising solution for digital heritage systems to support users in browsing related items, understanding the relationships between items, and synthesizing a narrative on an issue. The paper discusses design issues for the knowledge graph, graph database, and graph visualization, and offers recommendations based on the authors’ experience in developing three knowledge graph systems for archive and digital humanities resources …

Extracts: … we have found that graphs of 50 nodes or less are comfortable for users to understand and accomplish information tasks. Graph sizes between 51 to 100 nodes are manageable, but it is desirable to offer a filter menu for the user to reduce the number of nodes or links. Graphs of 101 to 150 nodes are manageable for experienced users, who know how to interact with the graph to extract desired information or to visually analyze the graph. We would consider graphs of more than 150 nodes to be unmanageable.

… It soon became obvious that the ontology was too complex for users to browse, and some information such as namespace URIs will just mystify the user. As the imported ontologies overlap and some classes (e.g., Person) occur in multiple ontologies, type links from entities to multiple Person classes in different imported ontologies will also confuse the user. The complete FRBR structure when applied to music and performance is too complicated for users, as they have to traverse many links to get from the MusicalWork to Expression (music score), to perhaps another arrangement of the music score, to Performance, to Sound or VideoRecording, to Manifestation (perhaps a published DVD), and finally to Item to access the AudioFile, VideoFile, ImageFile, PDF file, or webpage. To simplify the structure, we dropped Manifestation nodes, Sound and VideoRecording, and instead link the Expression nodes (i.e., music score) directly to the VideoFile and AudioFile nodes.  … in the FRBR framework and Music Ontology, the relations realization and manifestation are mystifying to the casual user. In this project, we display score instead of realization as the relation usually points to a node of type Score.

… A useful feature in Cytoscape.js is the capability to assign a group of nodes to a parent node, thereby clustering the group of nodes. We found this particularly useful when an entity-centric node has many links to neighbor nodes of the same type, which can then be clustered together in the display. This is adopted in the Polyglot Medicine graph display … When a main drug node is displayed, the region nodes are clustered together, as are the set of alternative drug name nodes.

… An interface design is not skin-deep: it must be supported by the underlying data and knowledge organization as well as the full stack of technology. In our system implementation, we have opted for lightweight and relatively inexpensive technologies that are effective, productive, and have enabled us to deliver good knowledge graph systems with a reasonable amount of effort and cost. We have recommended using the labeled property graph model for knowledge graph design, as a lightweight alternative to RDF/OWL2, and a graph database management system (available as a cloud service) that is based on this model. We have highlighted design issues in the graph visualization, as well as design issues in the knowledge graph, database, and web interface that have implications for the graph visualization and user interaction. We have also outlined the technologies used in the workflow—starting with Google Sheets as the main data store for data entry, and Neo4j graph database management for search and analytic functions.