A more in-depth example may help us to provide advice.
There are a couple things to consider for this.
If the entity ought to be some kind of single value, some kind of option or choice, it may be better to model it as a node, especially if there's value in looking up these values by index, and even more especially if your other option is to store these as a list property on your nodes. If there's additional info that should be present with this, then that's another sign that it should be a node, with associated properties or additional connected nodes.
For example, consider a movies graph with genres. We could model these as a list of genre strings within :Movies nodes, but this removes the possibility of an index lookup by genre (currently schema indexes don't consider list values), and it allows the possibility of misspelling or inconsistencies of values. If we wanted to store some additional info about genres, such as a textual description, we couldn't easily store it this way.
However if we model :Genre nodes instead that are connected to :Movie nodes, then these values are normalized, and we can quickly get counts of movies for a genre via a degree check of relationships to a genre node (without having to actually expand to connected nodes). We can have additional related data, such as a textual description, on the nodes themselves. Additionally we can use the node in alternate contexts, such as as genres for :Book nodes or other media.
Modeling things as nodes gives more flexibility overall.
If these kinds of considerations don't apply to your case, then using properties should be just fine.
