DTDL or SHACL

RealEstateCore was originally designed as an OWL ontology for RDF-based knowledge graphs. After six+ years of development and use of REC, we have found a vanishingly small interest for directly using that OWL ontology. Instead, in practically every case, big or small, customers have used the REC definitions, but rebuilt the ontology in a language that better suits their development and deployment needs; whether that be POJOs/POCOs, JSON schemas, various graph DB schema languages, or most prominently, the Digital Twin Definition Language.

In engineering REC4, we decided to try and support our users by dropping the somewhat academic/esoteric OWL in favour of serializations that developers are hopefully more comfortable with: SHACL (RDF Shapes Constraint Language) and DTDL.

SHACL is a new language for defining schemas over RDF graphs. It defines types as NodeShapes, which have associated PropertyShapes indicating the allowed outbound edges, their types, cardinalities, etc. E.g., a REC Space is defined as a shacl:NodeShape with several shacl:PropertyShapes for the outbound edges rec:isLocationOf, rec:hasPart, rec:isPartOf, rec:geometry, etc. By running a SHACL processor over an RDF graph, one can confirm that graph's adherence to the SHACL models, or get error reports in case the graph is not consistent with the model. Like RDF, SHACL uses URIs as identifiers for both types and outgoing edges. The REC SHACL identifiers are in the namespace https://w3id.org/rec#, e.g., https://w3id.org/rec#Building or https://w3id.org/rec#hasPart.

DTDL, the Digital Twin Definition Language, is developed by Microsoft and used in several of its Azure platform components. It is not primarily intended for RDF graphs, but rather is a generic property graph model that can be implemented on top of a graph engine of choice (most notably, we have the Azure Digital Twins product). DTDL defines types as Interfaces, which can contain Relationships (edges to other nodes in the graph) and Properties (data values). So, in a DTDL model, a REC Space is an Interface that has Relationships for isLocationOf, hasPart, and isPartOf, and a Property for geometry. DTDL uses DTMI identifiers (Digital Twin Model Identifier) for types, e.g., dtmi:org:w3id:rec:Building;1.

A key differentiator is that in DTDL contents are declared locally on interfaces; that is to say, those Relationships and Properties do not have a name in the global namespace, instead they are scoped to their containing Interface (and it's subtypes). Another key difference is the property graph model: it allows for Relationships to in turn have nested Properties on them, that might model for instance the start and stop date of a certain Relationship, or the substance that is carried over a certain pipe connection expressed as a Relationship.

Both SHACL NodeShapes and DTDL Interfaces can have parent to child inheritance links, such that child types inherit their parent types contraints, while adding their own. In this way, an ontology subsumption hierarchy can be constructed.

The similarities between SHACL and DTDL are substantial enough that automated translation between them is feasible (with some minor shoehorning to account for the differences mentioned above). When we develop and release RealEstateCore, we ensure that both DTDL and SHACL variants are valid and usable. Which models you prefer to use depend heavily on what your tech stack and your developer team preferences look like. If you are on a .NET / Azure platform, then DTDL is a strong contender; if you are using RDF graphs and tooling, then SHACL is likely preferable.

Footnote: Formally DTDL Interfaces can also contain Telemetries (properties updated based on data flow from, e.g., a sensor), and Commands (represents the ability to call an action on a given node) -- however, RealEstateCore only uses the former two content types, deferring to Brick Points for representation of Sensor and Command flows.