Graph pattern search

Bloom provides an easy and flexible way to explore your graph through graph patterns. It uses a vocabulary built from your graph and Perspective elements (categories, labels, relationship types, property keys and property values). Uncategorized labels and relationships or properties hidden in the Perspective are not considered in the vocabulary. To build a graph pattern search in Bloom, you use this vocabulary and either build the pattern step by step or type in a near-natural language phrase.

There are two different search experiences in Bloom, the default search and the classic search. To switch between the two, use the toggle in the Settings drawer.

Step-by-step pattern building with proactive suggestions

One approach to building graph patterns is to use the proactive suggestions feature of Bloom. This is useful when you need assistance with picking elements of your graph schema (e.g. relationship types from a label or categories that connect together).

When you go to the search bar, Bloom presents proactive options to begin your search. You can select from any node labels available in the Perspective or use a blank (any) node. Further, if you know which relationship you are interested in, but not which node labels it connects, you can select based on the relationship type and use the wildcard option for the node label (the (any) node). Additionally, you can filter the suggestions by Search phrases, nodes, or relationships.

But, as explained in the following section on Near-natural language and graph patterns, you can always type your own query as well.

proactive blank input

If you select a node label, Product for example, Bloom lets you choose if you want to further filter on the start node by its relationships or if you want to refine by properties and/or property values. Bloom gives you a hint about the datatype of the property value directly in the search bar.

proactive product selected

If you select Properties, you can see all properties for the Product label and if you pick discontinued for example, you can then specify the condition, for example true. This results in a pattern that starts with a discontinued product and filters all other nodes, both the ones with other labels as well as the Product nodes where the discontinued property does not equal true.

From here, you can either press the play icon to display all discontinued products, or you can continue defining your graph pattern.

When you are happy with the start node, select Relationship to see a list of available relationship types for your specified start node, both incoming and outgoing. Similarly, you can further filter on properties for the relationship, if available. If you are not interested in the type of relationship, you can use the wildcard (any) relationship.

The last step is to specify the end node, which naturally follows the same steps as the start node. The wildcard option, (any), is available here as well.

Press the play icon when you are ready to execute the search.

A note on property-value suggestions

Category, label and relationship type matches are searched in Bloom’s in-memory metadata of available graph and Perspective elements. For property matches, Bloom queries the database instead to find suggestions. To do so, Bloom relies on property indexes to be set up in the database for any properties that should be searchable in Bloom.

For bigger graphs, all properties of a node with a certain label are considered as indexed if there are less than 1000 nodes with the specific label. However, if a property has the same value on more than 10% of the nodes, it is not searchable, whether indexed or not, for performance reasons. For small graphs with low cardinality in data values (e.g. the Movies graph, found in the example data sets), Bloom is able to search for property values without requiring an index.

Depending on the search input, the number of indexes, and the speed of typing in the search box, it is possible that Bloom runs a large number of index lookup queries to find relevant matches. Optimizations are built-in to delay firing queries while waiting for user to complete the input and to cancel un-needed queries if the input is changed.

Bloom also attempts to hide pattern permutations from the suggestions list, if they are not found in the database. This may not be applicable in all situations. It is possible for database performance issues or network latency between the user’s machine and the Neo4j server to cause delays in showing search suggestions.

Near-natural language and graph patterns

Assume that you want to find Products that are connected to Orders by any relationship. Using a near-natural language search expression, you can type in the search in several different ways.

To use the full-text search, a full-text index needs to be present in the database.

For example, if you type Product Order in the search bar, you get the following suggestion:

product order

This is straightforward, a Product node connected via the wildcard (any) relationship to an Order node. You can execute or further refine by adding more relationships to the pattern, or by defining conditions based on the properties of the Order nodes.

But if you instead type order with product in the search bar and run it as a full-text search, Bloom returns seven nodes:

full text search

If you inspect these nodes individually, you can see that all of them has either order and/or product among their property values. A full-text search requires at least three characters in the search bar. Bloom matches them exactly and if you enter multiple words, the returned elements contain at least one of them.

If the results of a full-text search exceeds the node query limit, Bloom presents you with a pop-up which lets you select which elements to add to the Scene instead of blocking all results. Typing order of a product in the search bar yields many matches and if your limit is set below 1000, it results in the following:

search pop up

Case sensitivity of input

Neo4j database is case sensitive. By default, property values are matched by Bloom in a case sensitive fashion, if they begin with any of the matching tokens input by the user. If you would like search suggestions to be case insensitive, you can enable Case insensitive search and suggestions under Bloom settings.

By contrast, metadata elements like labels, categories, relationship types or property keys, are matched in a case insensitive fashion. Also, metadata elements are matched if they simply contain one of the search tokens.

Case insensitive matching of property values requires full-text indexes on all properties that will be searched. Without full-text indexes, Bloom will use case sensitive searching even with Case insensitive search and suggestions enabled.

The classic search is a little less fine-grained than the default option. It offers proactive suggestions that lets you build graph patterns step-by-step as well as use near-natural language for full-text search. It is not vastly different in functionality, but less intuitive and proactive. As mentioned, if you want to use the classic search, use the toggle in the Settings drawer.