Problem Statement

We want to support different versions of imported RDFs/ontologies and be able to upgrade it when new version came out. In order to be able to distinct different imports we decided to use a composite NODE KEY for nodes which consist of two properties: importId and uri. This also allows us to try out different versions of imported data.

Current functionality of n10s does not allow customization of node key and enforce unique constraint of uri field which is taken from imported RDF/ontology data.

Workaround we use

Currently we used patched version of NeoSemantics plugin in order to archive desired functionality and overcome mentioned above problems, but it would be highly appreciated if plugin could resolve described issues and we wouldn't need to support a separate version of it. It also seems functionality is common enough so it can be handy for others as well.

Possible proposed solutions

Add ability to disable "uri" constraint creation

One of the way of solving importing issues would to add ability be to disable constraint creation for uri property and rely on user-defined constraints and node keys. That would allow for more control on user side.

Another variation of it would be allow user to configure query for constraint creation or even fill it with empty string for the purpose of disabling constraint creation.

Drawbacks

This solutions probably looks a bit incomplete as NeoSemantics use uniqueness constraint on uri property to ensure data integrity and rely on the fact of uniqueness of uri to perform other actions.

Add ability to configure properties used in composite node key

Add ability to configure properties which are considered by NeoSemantics as a NODE KEY hence enforcing uniqueness of it or just add ability to enforce uniqueness on group of properties instead of having it only for uri.

One unobvious consequence of that solution that we need to add a way to supply values for the additional properties included into composite NODE KEY as uri can be taken from imported data but rest of the fields has to have some values as well. In our case this fields has a static values, in a sense they does not change during one import. So, they could be supplied as import parameters, for example.

Pros

This way would allow NeoSemantics to be aware about data schema and do what it did previously but using composite key instead of just uri.