# Knowledge Graph Management
# Schema Management
The Schema consist of mainly 3 elements :
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:
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:
- no other special characters
Both Classes and Relationships can have attributes. Attributes have a mandatory label and type.
The following types are valid :
- 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
true if the node has the label,
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
Select a Resource
And click on
Apply Indexes, this will create the necessary indexes from the information of the Hume Schema.
# Perspectives Management
Perspectives define a
view of the schema against a particular database. By default, when creating a Knowledge Graph, a
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 also need to define the
Neo4j Resource before it can be used in visualisations.
# 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
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.
# 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
Once done, you can boost the relevance of classes as a whole or on particular attributes.
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.