Modeling "Also Known As" (AKA) Relationships?

Hello world!

I need guidance on how to best model a scenario where I have hundreds of products, many of which are known by a local or regional name as well. Should these "AKA Names" be modeled as an attribute of the node (Where there could be many different values) or is it best to model this with many 'AKA' relationships?

What downstream performance data maintenance issues should I prepare for?

Much thanks!


I'd go with something like :ProductAlias nodes, each node representing an alias, with relationships pointing to the product they refer to. The actual :Product node could have the "main" name, and this node could also have the :ProductAlias label.

This should allow you to lookup the product given any alias:

MATCH (:ProductAlias {name:$nameInput})-[:ALIAS_FOR*0..1]->(p:Product)

The lowerbound of 0 allows for a match when the name input is the name on the :Product node itself (which is also a :ProductAlias) when no relationship traversal is necessary.

1 Like

Canonicalization is a tricky beast.

@andrew.bowman's suggestion will be the most flexible, and most accurately represent reality.

That said, the pattern you chose to implement should be informed by how you intend to use the data. What will you use these aliases for, and how might you want to retrieve them in queries?

Thanks tons! The goal is to be able to due quick forensic analysis on vulnerabilities aligned with (and across) multiple products. I have to allow for the aliases because the data is so ‘dirty’ and the products are know by so many different names (varying by how long you’ve been with the company or what new acquisitions have been occurring).

Thanks again for the quick response!


Then, Andrew's pattern is the only way to go:

Keep in mind, that if you're working with dirty data, you'll also likely encounter relationships connecting to an alias, and need to move them:

In particular, .from and .to will allow moving rels from an :Alias to the correct :Product.