GraphAware Hume

# Knowledge Graph Management

# Schema Management

The Schema consist of mainly 3 elements :

  • Classes
  • Relationships
  • Attributes

# Classes

Classes describe entities relevant to your domain. For example in a movies domain you'll find classes such as Actor, Director, Movie, Genre, ...

Classes are unique in a Schema and their naming convention is the following :

  • the class name start with an uppercase letter
  • they can include digits
  • they shouldn't contain special characters
  • in case they comprise of two words, then the CamelCase format is recommended (eg: RocketLauncher)

# Relationships

Relationships describe the connection between entities. Again in a movies domain you'll find relationships such as ACTED_IN, RECORDED_AT_LOCATION, ...

Relationships are unique in a triple context, meaning the uniqueness of a relationship is formed from her start class name, end class name and relationship type.

Relationship types have the following naming convention :

  • all uppercased
  • should start with a letter
  • in case a space is needed, it should be replaced by the underscore (eg: COMBINED_WITH)
  • no other special characters

# Attributes

Both Classes and Relationships can have attributes. Attributes have a mandatory label and type.

The following types are valid :

  • STRING
  • INTEGER
  • FLOAT
  • BOOLEAN
  • NODE_LABEL
  • LARGE_TEXT
  • DATE
  • NUMBER (Deprecated in 2.8, will be removed in 3.0)

String, Integer, Boolean and Float can be also marked as being a List of them.

Attributes also have additional flags depending on their type :

  • Primary Key : defines if this attribute should be used as unique key reference
  • Full-Text-Search : defines if this attribute should be used for Full Text Search

# NODE_LABEL Attribute

This special attribute type is used when an additional label on nodes existing in Neo4j should be mapped to something relevant in the domain schema.

For example, a User can be active if it has the additional :Active label. In Hume, additional labels are represented as NODE_LABEL attributes which behave like a boolean : true if the node has the label, false otherwise.

# LARGE_TEXT

This special attribute type is used to describe we expect very large strings for this attribute in the database. Hume knowing this, will optimise how it handles such attributes in the visualisation by lazy loading it on demand rather than returning those values by default.

# Schema Design Best Practices

It is recommended to follow the naming conventions as well as to avoid using the same relationship for two different relationship on the same pair of nodes.

The following example of a schema is not recommended :

(Article)-[:MENTIONS]->(Person)
(Article)-[:MENTIONS]->(Organization)
(Article)<-[:AUTHORED_BY]-(Author)

While the following schema is aligned with our recommendations :

(Article)-[:MENTIONS_PERSON]->(Person)
(Article)-[:MENTIONS_ORG]->(Organization)
(Organization)-[:REFERS_TO]->(StockExchange)
(Article)-[:REFERS_TO]->(Article)

# Setting up Indexes for Search and Performance

The search in visualisations will benefit from Full Text Search indexes for STRING attributes and constraints for other kinds of attributes in order to make lookups performant.

The easiest way to setup those indexes is to use the Index Manager.

Head to the menu in the Schema and select Index Management

Perspectives

Select a Resource

Perspectives

And click on Apply Indexes, this will create the necessary indexes from the information of the Hume Schema.

Perspectives

# Perspectives Management

Perspectives define a view of the schema against a particular database. By default, when creating a Knowledge Graph, a default Main Perspective is created and is synchronised with the Schema.

synchronised means that any addition made to the Schema will be made visible in the Perspective, as such a synchronised perspective cannot define the visbility of particular elements.

Perspectives

Perspectives also need to define the Neo4j Resource before it can be used in visualisations.

Perspectives

# Defining visibility of elements

Perspectives can define the visibility of classes, relationships and attributes on them.

To do so, double click either a class or relationship and check or uncheck the visible flag.

When making a class hidden, the relationships connected to that class become automatically hidden as well. Also, non synchronised perspectives will not mark newly created elements in the schema as visible, as such the Knowledge Graph Manager will have to individually mark them as visible when needed.

Perspectives

# Search Relevance in Perspectives

Managers can customise the importance of classes and attributes on them for the search experience in visualisations.

It is useful when Perspectives are used to represent different views of the graph to different group of users, where the most important domain entities (classes) might differ from one group to another.

For example, a group of users dedicated to Customer experience might want to have Customers and Product ranked higher by default when searching with a simple string while a group of users dedicated to Warehouse stocks might find useful that the ranking would be more towards products and line items.

To edit the Search Relevance of a particular perspective, click the menu icon in the top left corner of the Perspectives editor and select Search Relevance.

Perspectives

Once done, you can boost the relevance of classes as a whole or on particular attributes.

Perspectives

TIP

Setting a relevance factor of 0 will make the attribute or the class non-searchable. This is handy in order to improve search performance when the schema contains a lot of classes and attributes on them.

← Visualising Graphs →