Feature: Support data models

[Ramimashkouk]

Describe what you are looking for

We're looking for a database that supports data models (ontologies) along with other features that you already have on the roadmap. A data model puts constraints on nodes and edges so that they could be created only after creating their data model kinds. With code it might look something like this:

net = db.main.graph
ontology = net.ontology

ontology.add_node_kind(101) # creates a kind 101 in the ontology
net.add_node(1, kind=101) # creates a node of kind 101
ontology.add_node_kind(102)
net.add_node(2, kind=102)
net.add_node(3) # error
net.add_node(4, kind=104) # error

ontology.add_edge_kind(node_a_kind=101, edge_kind=1001, node_b_kind=102)
net.add_edge(node_a=1, edge_kind=1001, node_b=2)
net.add_edge(node_a=1, edge_kind=1002, node_b=2) # error

How soon could such a feature come to light? :)

Can you contribute to the implementation?

• I can contribute

Is your feature request specific to a certain interface?

Official Python bindings

Contact Details

[email protected]

Is there an existing issue for this?

• I have searched the existing issues

Code of Conduct

• I agree to follow this project's Code of Conduct

[ashvardanian]

Interesting suggestion. We are preparing a few things, but it may not be exactly what you describe.

1. Document schemas. You can specify what attributes members of a specific collection should have. This will allow you to compose collections of objects with vastly different contents, later combining them into "virtual" graphs. But it won't work with diverse ontologies.

2. Our Graphs are designed as Multi-Graphs. So edges can have identifiers, and multiple edges can connect the same vertices.

3. You can store the "kind" of a node as one of its attributes and later filter by them in a higher-level interface.

Please let us know if that can cover your use case.

[Ramimashkouk]

1. Great! It's like putting constraints on attributes. But, will it be a schema optional (constraining is an optional manual thing), or will these document schemas be already built as constraining schemas?
   What do you mean by “it won't work with diverse ontologies”?

2. Great! I didn't know that. It's also an interesting feature to us! :)

3. Yeah, we can even make a separate node for a kind and connect it with nodes belonging to that kind using edges. However, after working with TerminusDB, which provides a native ontology, and Neo4j, which doesn't, we noticed how working with a built-in ontology gives a better performance, and consequently, makes a stronger solution to different tasks

I believe that adding kinds to document schemas will enrich the schema as a whole and make the use cases even wider (for business data modelling as another example).