TerminusDB has a very expressive schema language compared to other databases, for example fully typed referential integrity enforcement (i.e. the SQL equivalent of defining a type that a foreign key can refer to), class hierarchies with multiple inheritance and the ability to define complex business logic in the schema.
This topic is for discussion of schema, the TerminusDB schema language (OWL), and anything else schema or data modelling related.
If you are interested in one of our schemas as written in OWL, you can see how we store information about our databases in our server which is also written in OWL.
Could you explain this in more detail? You do not really support OWL, or a flavor of it, or only indirectly / implicitly (like entering via WOQL only)?
Yes, I should clarify in the intro as it is confusing. For schema design, TerminusDB uses the OWL language with two modifications to make it suitable as a schema language. Namely, we dispense with the open world interpretation and insist on the unique name assumption. This provides us with a rich modelling language which can provide constraints on the allowable shapes in the graph.
We really support OWL as it is logically expressive.
I started a topic on the Solid community forum Aligning efforts in LD schema / ontology design + adoption (where I mention TerminusDB) and in my latest post mentioned VOWL as a clean and good-looking way to visualize OWL. This may be interesting for Terminus, I think. I find the current visualization to be quite basic and sorta âmessyâ (btw, this is true imho for most graph visualizations I stumble upon on the web).
The new release now has opened up the internal schema architecture to give you full control of the owl. There is now inference graphs as well as schema graphs - both of which speak OWL, the difference being that the schema graph is interepreted with closed world semantics, while the inference graphs use normal OWL open world inference approaches. The kicker is that the rules in the inference graph are evaluated dynamically not materialised which allows you to create things like calculated properties and property chains and so on.
Is it possible to export the scheme from Protege OWL and load it into TerminusDB?
How do you recommend creating really complex schemes?
Itâs really very desirable to have a visualisation tool for multiple inheritance that can lay out the class hierarchy as a Haase diagram for when the size of the inheritance graph gets very large. The Seshat ontology is a good example of where it gets fairly difficult to manage without visualisation tools.
It is possible to load schemata from Protege into TerminusDB provided that the OWL is sufficiently simple. We donât support all of OWL 2, particularly we donât yet have support for equivalence.
Previously we had a schema builder within TerminusDB, but due to architectural changes required to bring out the collaboration features we had to rip it out for the time being. Weâre planning to bring it back as soon as we can feasibly do so. I think itâs a few months down the line in our road map.
Currently the best way to build a complex schema is actually in WOQL. It tends to be a lot less verbose than writing it directly in OWL, especially when cardinalities are used.
Also, from experience, if you are using protege to compose ontologies, you need to be careful because it tends to add various predicates - annotation properties and so forth - to make the output readable with some of the old RDF tools out there but this is not helpful semantically. Also we found that protege does not deal well with multiple inheritance and stuff like cardinality restrictions which it treats like first class classes at the top of the hierarchy, meaning that the vizualisation view that it gives you isnât all that helpful in practice. Now we tend to use either WOQL or OWL directly - terminusdbâs schema validation is very helpful here though - it is good at spotting your mistakes and these are really easy to make in big complex ontologies.
As Gavin says, we have a very nice graphical Haase diagram visual ontology editor which we plan to roll out soon - the next wave of features that we will bring out after the full release of hub on September 1st will include this model building tool as well as our frame vizualisation tool (which is effectively a graphical document editor) - the combination of these two tools is what we think is really needed for an effective ontology editor - the first provides a view of all the classes and their relationships, the second lets you look inside a class to see what it looks like as a form that you can fill in.
Whatâs the difference between âDocumentsâ and âObjectsâ? Itâs really confusing and I canât find any information about that anywhere.
The difference relates to how JSON LD documents are formed from the graph - when objects are embedded inside other objects and when they are linked.
Objects can be embedded inside other objects but documents are never embdded, only linked.
So, for example, a Person document type might have an address object embedded inside it, but have links to other Person document.
So itâs a JSON-LD idea then?
From the JSON-LD standard:
A JSON-LD document is a serialization of a collection of graphs and comprises exactly one default graph and zero or more named graphs.
An object is a node in a linked data graph with at least one incoming edge. See RDF objectin [RDF11-CONCEPTS].
Is this the same as what youâre describing, or is this a different idea?
Our JSON-LD documents are formed from subgraphs which are directed by the schema. They are still JSON-LD standard documents, but the manner in which they are extracted as a subgraph is novel.
Iâm sorry, Iâm still confusedâŚ
Sounds like thereâs a lot more to Terminus Documents than meets the eye (and more than can be explained quickly). If thereâs an article or a podcast on this topic, please link it and Iâll watch it. 
Basically you can see a graph as the union of JSON documents. We âclipâ the documents anytime we encounter a link to an identifier of another document (something which is a subclass of the Document class). This allows you to have arbitrary webs of complex documents in the graph.
Weâll put together an article that gives an introduction to the idea.
