Is it possible to create graph by non-fixed number of properties?

The scenario is I crawled data from wikipedia and some entities have different properties, even though they are in the same type, i.e. the same neo4j label. In this case, the data is in the json format, not excel, and most importantly, it's infeasible to decide a set of properties given an entity.

Is it possible to create neo4j database without a fixed set of entity properties defined beforehand? The number of properties will depend on a particular data instance.

Yes, you can create a node without adding any property and later you can add properties with MATCH and SET.

Suppose a node is created with two properties: MERGE (a:Test {name: "xy", value: "test"}).

Add another node with same label with three properties:
MERGE (b:Test {name: "xy", value: "test", result: "negative"})
This will create a new node because of the third property.

@ameyasoft, in this case, there shouldn't be a new node to be created. I should end up with one node only:
b:Test {name: "xy", value: "test", result: "negative"}

Because you just add new properties to the same node. In order to ensure the same identity, probably a unique ID is used to identify that?

Also, based on what you describe, for non-fixed properties of entity, it seems it should go like this:
create a node with only an ID, without any other properties:
b:Test {ID: "001"}

Then use match/merge ... set to add any number of properties you want.

The question is, all the 'loading data' documentation examples use "known properties" in cypher statements from a CSV or JSON file, because they are fixed. In the above example, field names like 'value', 'result' are unknown.

Yes, you can create a node with ID as a property and later on your can keep on adding/deleting more properties with MATCH (b:Test{ID: "001"}) set = "vv" like that. Also, you can set properties any time. It may be good to have a unique constraint on ID.

Regarding 'MATCH (b:Test{ID: "001"}) set = "vv". If you don't know 'name' beforehand, can you still do this? In such a case, 'name' will be a variable read from the json file. For a typical set statement like below, the value could be a variable, i.e. '$firstName'. What about if the key is also a variable, which will be parsed from a json file? That's my point of this question.


MATCH (p:Person {firstName:$firstName, lastName:$lastName})

SET p.hobbies = $hobbies, p.favoriteColor = $favColor