# 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

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
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 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 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.

# 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
.

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

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.