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.
