Introduction

Current visualization strategies for knowledge graphs (KGs) either do not take into account the graph design decisions for things like reified links or spurious links that are not relevant to the task, or they provide a fully customized visualization that is difficult to repurpose for other projects. In a similar vein, most overall views of knowledge graph design are usually created by hand based on the knowledge of the KG developer and may not always reflect the state of the current graph.

We have built knowledge explorer network visualization tool in Whyis that lets developers customize the way links from specific entities are rendered. Whyis enables software developers to create knowledge graph applications (KGApps) using minimal modifications, allowing for the use of code-oriented deployment and management tools like GitHub, Docker, and other DevOps tools. This low code/no code approach allows creators of knowledge graphs to do so without coding, but if they need to add code, it would be minimal. In a previous paper [1] we illustrated the capabilities and structure of Whyis using a demonstration knowledge graph of characters and their interactions from the novel Les Miserables, as originally created by Donald Knuth and maintained by Media and Design Studio 1 We extended this demo to highlight the network visualization capabilities included in Whyis, and is available on GitHub2 .

Whyis UI and Data Views

A key feature of Whyis for visualization and knowledge interaction is the use of type-driven custom views for nodes by both the rdf:type of the node and the view URL parameter, which drives all user interface and API interactions within Whyis. Every URL in Whyis is a node in the knowledge graph, the URI of which can be linked data if the configured LOD prefix matches the server URL prefix. Additionally, other nodes can be viewed by using the URI as a URL parameter. And additional URL parameter, view, can be added to provide alternate view of the entity, which can be configured like this: : myCustomView r d f s : s u b C l a s s O f whyis : hasView ; d c t e r m s : i d e n t i f i e r " custom " .

This creates a new view type called custom that can then be rendered. Entity types can be registered with specific template to render particular views using a type view template triple. For instance, below we register a default view for foaf:Person using the person_view.html template and a custom view using the person_custom.json template: < h t t p : / / xmlns . com / f o a f / 0 . 1 / P e r s o n > a owl : C l a s s ; whyis : hasView " p e r s o n _ v i e w . html " ; : myCustomView " p e r s o n _ c u s t o m . j s o n " .

These templates are rendered using Jinja23 and can access a large collection of APIs to access the current entity, the knowledge graph as a whole, and other functions.

Whyis Data Views are Open Contracts

Design by Contract [2] is a defensive programming strategy that encourages clearly defined interfaces between software modules, so that users of a module know what to expect from it, and implementers of the module know what they are expected to provide. By specifying a clear interface, it is possible to create multiple implementations that provide the same service, which become essentially open contracts. Data views in Whyis serve as a form of open contract. By reimplementing a named view on an entity type that is different from the reference implementation, the implementer is expected to provide a compatible data structure to the orignal. This allows for customization of the content served from a given view for a user interface, but it also allows other user interfaces to be created that take advantage of that same view. UI views and data views can therefore be matrixed together in ways that would otherwise be impossible. For instance, a 𝑙𝑎𝑏𝑒𝑙 view can be used by multiple UIs (and even other data views) as-is, because it can be relied on to provide a human readable text string ready to be embedded in other content, while what counts as a label might vary from entity to entity based on its type.

This paper provides the following contributions. We developed a "design by contract"based API using Whyis typed views for node and link traversal in a knowledge graph can improve network visualization in those graphs. This approach can also support multiple ways of rendering nodes and links. Finally, we also show how graph summarization algorithms can use the same framework for visualization and exploration.

Approach

In order to implement a design by contract approach, we provide a general-purpose user interface in Javascript that iteratively requests up to two views from a given entity: outgoing Return all links for which the entity in question is a subject, or source node, in the link.

incoming Return all links for which the entity in question is a subject, or target node, in the link.

The user interface uses Cytoscape.js [3] to render and layout the network visualizations. While the UI is available within the explore view, it is implemented as an AngularJS directive and can therefore be embedded in any other view in the knowledge graph.

The incoming and outgoing views for every resource in the graph are required to implement the following JSON structure:

[ { " a r t i c l e s " : [ " [ URI ] " , . . . ] , " from " : [ " [ URI ] " , . . . ] , " l i n k " : " [ URI ] " , " l i n k _ t y p e s " : [ { " l a b e l " : " [ s t r i n g ] " , " u r i " : " [ URI ] " } ] , " p r o b a b i l i t y " : [ f l o a t : 0 − 1 ] , " s o u r c e " : " [ URI ] " , " s o u r c e _ l a b e l " : " [ s t r i n g ] " , " s o u r c e _ t y p e s " : [ " URI " , . . . ] , " t a r g e t " : " URI " , " t a r g e t _ l a b e l " : " s t r i n g " , " t a r g e t _ t y p e s " : [ " URI " , . . . ] } , . . . ]

The approach used here tries to keep as much of the JSON flattened to make it easier to use as much as possible via a SPARQL query. However, this can be implemented in many different ways, including passing off the entire JSON rendering to code outside of the template. For instance, the default view uses a template filter called probit to provide most of the query, while needing to provide a query fragment. For instance, this template can be used for generic resources: { { ' ' ' g r a p h ? a s s e r t i o n { { ? s o u r c e ? l i n k _ t y p e ? t a r g e t . } } b i n d ( ? a s s e r t i o n a s ? l i n k ) minus { ? s o u r c e s i o : h a s P a r t | s i o : h a s A t t r i b u t e ? t a r g e t } minus { ? t a r g e t a s i o : Term . } f i l t e r ( ! sameTerm ( ? s o u r c e , ? t a r g e t ) && i s I R I ( ? t a r g e t ) )

' ' ' | p r o b i t ( s o u r c e = t h i s . i d e n t i f i e r ) | t o j s o n | s a f e } }

The probit filter includes that query fragment in a larger query and searches for source and target types and labels. Within the Les Miserables knowledge graph, we use the following template, which takes advantage of the schema:InteractAction instances that we use in the graph (see Figure 1): { { ' ' ' g r a p h ? a s s e r t i o n { { ? a r t i c l e schema : p a r t i c i p a n t ? s o u r c e . ? a r t i c l e schema : p a r t i c i p a n t ? t a r g e t .

? a r t i c l e a ? l i n k _ t y p e . } } b i n d ( ? a r t i c l e a s ? l i n k ) b i n d ( 0 . 6 a s ? p r o b a b i l i t y ) f i l t e r ( ! sameTerm ( ? s o u r c e , ? t a r g e t ) && i s I R I ( ? t a r g e t ) ) ' ' ' | p r o b i t ( s o u r c e = t h i s . i d e n t i f i e r ) | t o j s o n } } Conveniently, implementers can simply bind the source or the target depending on the view being rendered.

Automated Meta-Analysis

To provide a more unified view of links between entities, we distinguish between a specific link and the type of the link. For instance, each individual character interaction in the graph can be seen as evidence that any two characters know each other, but any one interaction is a weak indicator of that. Multiple interactions tend to accumulate that evidence quickly. In many scientific domains, evidence can be collected with varying levels of confidence in the evidence. Independent experiments that have the same finding (expressed as a link, interaction, type assertion, or other knowledge) need to be given a way to combine that knowledge in a meaningful way.

In Whyis, we provide a form of automated meta analysis using Stouffer's Z Method [4]. This method allows multiple experiments or observations with varying levels of confidence that produce the same results reinforce each other. For each independent observation of 𝑃 (𝐴) in 𝑃 (𝐴 1 ), 𝑃 (𝐴 2 ), ...𝑃 (𝐴 𝑘 ), we compute the 𝑃 (𝐴) as follows, where 𝜑 is the standard normal cumulative distribution function and 𝜑 −1 is the inverse CDF:

𝑃 (𝐴) = 𝜑 (︃ ∑︀ 𝑘 𝑖=1 𝜑 − 1 (𝑃 (𝐴 𝑖 )) √ 𝑘 )︃

For example, let us say that there is an ensemble of to link predictors that provide certainty scores of 𝑃 = 0.75, 0.9. The corresponding 𝑍 of each is 𝑍 = 0.7, 1.3, making the consensus 𝑍 = 1.41, and the corresponding 𝑃 = 0.92, a small improvement over either prediction. Adding additional observations will provide proportionally better probabilities, allowing evidence to accumulate.

Whyis provides the probit filter (a special form of function) that can process basic graph patterns for multiple observations and perform this sort of automated meta-analysis. A base rate probability is configurable in Whyis for assertions that do not have associated probabilities so they can also provide a baseline level of evidence.

Evaluation

We demonstrate our visualization approach using the Les Miserables graph from [1], extending it to provide additional sub-types for most characters. Figure 1 shows the structure we use to express interactions between characters, where the links are reified rather than simple (𝑠𝑢𝑏𝑗𝑒𝑐𝑡, 𝑝𝑟𝑒𝑑𝑖𝑐𝑎𝑡𝑒, 𝑜𝑏𝑗𝑒𝑐𝑡) triples. This reified interaction makes it easier to indicate that the interaction is undirected or bi-directional, but also offers the opportunity to record which chapter it occurred in, which is provided in the data. In other interaction-based knowledge graphs, like systems biology graphs [5], it allows models to provide additional provenance like locality, intensity, and how the interaction was determined, i.e. through prediction, measurement, simulation, or other means.

In Figure 2, the Knowledge Explorer is shown with all of the Stouffer-method aggregated interactions of the main characters. While completeness may be useful on a node by node basis, overall patterns are difficult to see with networks of this size. Because of this, the Knowledge Explorer is capable of filtering on the probability of each link. We showed in [5] that aggregate probability across multiple links is a useful way to focus on high quality results. In Figure 3 we filter out links with 𝑝 >= 0.75, resulting a useful graph of the main characters and the minor characters that they most frequently interact with. Note that in both cases, the nodes are color-coded by their type. The colors are auto-allocated from a 10 color palette, and adapt to the available types in the rendered graph. In addition to the modeling used for character interactions, we created an agent that can summarize links between entities of different types to show how patterns are actually used in knowledge graphs. Called Concept Maps [6], they have been used for a long time to express graph patterns among different entity types in knowledge graphs. They have most commonly been used to plan out the structure of knowledge graphs. In this case, we invert the use case of concept maps and create them from the observed relationships between entities. We created a Whyis agent that creates a set of Relation objects in a nascent Knowledge Graph Modeling Ontology (KGMO). For each owl:Class, it looks at the frequency that its instances are connected to other instances of other classes via a given predicate. Future versions of this agent may be configured to analyze subclass relations for abstraction of these summaries, property paths, and other complex constructions. That frequency is recorded as a sio:has-attribute of the kgmo:Relation of type kgmo:SyllogismConfidence. Figure 4 provides more details of kgmo:Relation structures, including links to the subject type (kgmo:hasSourceType), predicate (kgmo:property), and object type (kgmo:hasTargetType). The resulting kgmo:Relation objects are then treated as links between classes in the knowledge graph (in addition to rdfs:subClassOf links), resulting in the summary visualization in Figure 4.

Related Work

Knowledge graph visualization using network tools has a long but varied history. Here we only consider tools that focus on network visualization in large scale query-able knowledge graphs, although there are graph visualization techniques from both Linked Data and ontologies [7]. Neo4J Browser allows developers to query the graph and visualize the results. However, it requires users to provide the query, limiting the potential audience [8]. Conversely, LODLive [9] provides a general purpose graph visualization tool, but it does not allow users to customize links based on their types. Since it is focused on traversing Linked Data, it also does not support aggregated knowledge graphs. ReDrugS [5] supports complex link types, but it was hard-coded to a specific domain. This is typical of most KG visualization approaches, and the Whyis approach was created to provide a generalized solution to this.

Discussion, Limitations, and Future Work

By implementing a Design by Contract API, the knowledge graph can enforce structured interactions with its data, ensuring consistency and reliability in how information is accessed and manipulated. This structured approach extends to visualization, where typed views for node and link traversal can enhance the clarity and usability of network representations. For example different stakeholders or applications can visualize the same graph in ways that suit their specific needs (e.g., emphasizing different types of nodes or relationships), although complex interactions would require development of new queries to support them (and therefore need expertise in SPARQL). Users can also define and utilize tailored views of the graph, optimizing visualization for their particular analytical tasks.

The use of graph summarization algorithms introduces another layer of utility. Algorithms can summarize large, complex graphs into more manageable forms without losing critical information, facilitating efficient exploration and analysis. Summarization results can also be visualized using the same framework as instance data, allowing users to grasp high-level insights quickly before delving into detailed exploration.

We plan to improve the Whyis Knowledge Explorer in a number of ways. First, we plan to incorporate the multi-hop searches for entity links that were available in ReDrugS [5]. This will be useful for systems biology analysis, but also any sort of analysis of multi-hop links between entities in general. Currently, the knowledge explorer is limited to a single, hard coded layout strategy. We hope to be able to let users select and configure layouts, and selectively apply them to nodes. This can allow for more interesting visual analyses. We also hope to explore more how shape constraints in both the knowledge graph using SHACL [10] and in data views using OpenAPI [11]. Finally we hope to provide more visual approaches on top of the existing incoming and outgoing data views, especially ones that hybridize network and quantitative visualization.

Conclusion

The Whyis Knowledge Explorer represents an advancement in the visualization and exploration of large-scale knowledge graphs. By addressing the challenges associated with graph representation and navigation, this tool offers a robust framework for developers and researchers alike. The ability to customize link rendering and employ type-driven views enhances usability and flexibility, accommodating both simple and complex relationships within the graph. Through its integration of design by contract API and sophisticated graph summarization algorithms, Whyis facilitates not only detailed node and link traversal but also insightful high-level analysis. This approach not only enhances the clarity of graph visualizations but also supports informed decision-making by stakeholders across various domains.