Rationale

As mentioned in the Design Principles this project adopts DL as a language for communicating data structure to LLMs based on the principle that LLMs already understand mathematical DL notation as a language.

An LLM Description

DLe was created by iteratively working with various LLMs to determine which structures were most robust in describing data. Numerous options were explored, using both human derivation and conversations with LLMs about what they claim to work better with. While such claims may be helpful in finding new directions to explore, LLM meta-cognition is limited. Thus, any claims they make about how they reason must be tested before being accepted.

GPT-5.4 describes using DL this way:

DL is not merely is “more precise” than prose, but it is a better matched encoding for the kind of structure the model is trying to recover. Prose can describe a schema, constraints, and relations, but it does so through a surface form that is variable, redundant, and full of ordinary-language habits. DL strips most of that away and presents something closer to the relational skeleton itself.

So the gain may come from several things at once.

First, DL reduces ambiguity. In prose, the same constraint can be phrased ten different ways, with different incidental implications. In DL, the form itself narrows the interpretation space.

Second, DL makes the important distinctions legible at the right grain. Domain, range, subsumption, existential restriction, functionality—these are exactly the kinds of distinctions that matter when mapping from a database-shaped world to queries or anomaly detection. Prose tends to blur them together.

Third, DL gives the model a more stable target under rephrasing. That matters a lot. Natural language instructions can drift in effect when wording changes; a formal notation is much more invariant.

And fourth, I suspect there is something slightly deeper: modern models have probably seen enough mathematics, logic, type-like systems, schemas, and formal knowledge representation that DL syntax acts as a kind of high-signal dialect for structured reasoning. Not magic, and not guaranteed, but plausibly a much better fit than explanatory prose.

So I’d phrase the hypothesis like this:

"Using DL improves LLM performance on structured data tasks because it aligns the problem description more closely with the model’s learned internal representations of compositional, relational structure, while reducing the variance and ambiguity introduced by natural-language exposition."

That is stronger than “DL is clearer.”

It also suggests what to test. Not just overall correctness, but where prose fails and DL holds up. The interesting cases are probably:

• same semantics, multiple prose phrasings;
• nested constraints;
• negative conditions;
• functional or cardinality-like expectations;
• subproperty relationships;
• query generation where small misunderstandings compound.

If prose varies too much, you could treat that as part of the experiment rather than a nuisance. For a fixed underlying schema fragment, create several prose renderings with different styles and compare them against one DL rendering. Then measure variance as well as mean performance. My guess is not only that DL will do better on average, but that it will be more stable.

That would be quite a nice result, actually: formalization improves both accuracy and robustness.

There is one caution, though. Some of the benefit may come from the developer's skill in writing good DL descriptions, rather than DL alone. In other words, the comparison may partly be “carefully engineered formal encoding” versus “whatever prose people happened to write.” That does not make the result unimportant, but it does mean the experiment should try to separate notation from authoring quality.

Still, the underlying idea looks solid to me: this is code-switching for machines. This is a dialect that the model seems to parse more reliably when the subject matter is structured data.

Background

LLMs understand many languages, any of which could be used to describe the structure of data:

• Prose in human languages
• Data Description Language (DDL)
• Shapes Constraint Language (SHACL)
• OWL in one of the recognized syntaxes
• Serialized UML, for instance: XMI
• and more…

Most LLM communication today is expressed via prose. However, human languages often have redundancy and ambiguity. This aligns well for certain types of communication, but can lead to inaccuracy when expressing data structure.

Sequeda et al. noted that even naïve OWL provided greater accuracy than DDL when generating queries for data. Sequeda and Allemang also went to demonstrate that a more careful approach can improve the accuracy further. This suggests that description logics, such as the one encoded in OWL are better aligned with data access than the more structural and storage definitions described in DDL.

As the name suggests, "Description Logics" describe data, meaning that it can include a greater understanding of the data, and not simply how it is structured. This is how the mathematical foundation description logics rests upon can naturally lead to inference and entailment via algebraic manipulation. All of this is well understood by LLMs.

Conversely, UML and SHACL describe structure. Neither provide sufficient descriptions of data to imply a defined set of entailments. SHACL-AF (SHACL Advanced Features) includes SHACL Rules, which do allow for entailments, but these are a mechanism of forward-chained rules, rather than a description of why something is entailed. Such a description may be inferred from SHACL-AF, but is not directly described. For instance, OWL can declare TransitiveObjectProperty(:ancestor), while SHACL-AF would use the structure like the following Turtle (TTL):

:AncestorShape a sh:NodeShape ;
               sh:targetSubjectsOf :ancestor ;
               sh:rule [a sh:TripleRule ;
                        sh:subject sh:this ;
                        sh:predicate :ancestor ;
                        sh:object [sh:path (:ancestor :ancestor)]] .

LLMs are capable of recognizing this as defining transitivity, but only after significant reasoning.

Another limitation of SHACL is that it is tightly bound to graph representations of data, while UML and OWL are not. SHACL can be applied to other data structures, such a database tables, but it requires an explicit mapping to do so, for instance via D2RQ. While OWL was specifically designed for the Resource Description Framework (RDF), which is a graph model, its description logic foundation can be applied more broadly without necessarily having an explicit mapping.

OWL finds itself in a position of describing data clearly, using various public syntaxes that are all widely used and therefore show up in LLM training corpuses.

OWL and DL

The initial work behind this project used OWL expressed in Turtle syntax. LLMs appear to work well with graphs, though only to a point (Wang et al., Hu et al.). One limiting factor in this is the serialization of the graph (Perozzi et al.), which suggested that Turtle may not be the best way of presenting the data. Another issue is that a triple representation of OWL requires a lot of structure for relatively simple operators, and the Turtle syntax includes many elements focused on the graph structure rather than what the OWL is expressing. This all leads to excessive token consumption when expressing OWL in Turtle.

OWL Functional Notation (OFN) provides a more direct and semantic representation of OWL structures. This led to LLM interactions that were just as effective, while also consuming far fewer tokens.

OWL can use multiple representations to unambiguously mean the same thing. This meant going back and forth with each model to determine the efficacy of using one form of expression over another. Other times, the LLM was consulted over how it would represent particular structures and constraints. Interestingly, these discussions frequently led to responses that were expressed using DL mathematical notation. Once a structure was decided upon, the LLM would provide a final expression in the desired syntax. Questioning ChatGPT about this led to the following claims:

• All discussions of OWL expressions were internally converted to mathematical concepts for understanding an manipulation, and only converted back to the desired syntax when generating tokens.
• The majority of academic papers which discuss Description Logics use DL mathematical notation, therefore the model claimed that this syntax was better aligned with its training set.

The first claim by the model is not quite right, since models do not reason using mathematical symbols like this. However, it may be providing a rough analogy. Models reason by converting surface form into attention structures, which are then manipulated before being returned to a surface form again. Given the training dataset, those internal structures are very likely mapped closely onto the specific semantics of the mathematical symbols that are so prevalent in the training dataset.

Taken together, this implies that using DL directly may be even better aligned than using OFN. An additional benefit is that DL syntax uses fewer tokens than the same expressions in Turtle or OFN. An example of using the tiktoken tokenizer on various descriptions of the same information results in:

Syntax	Token Count
English prose	77
OFN	138
TTL	189
DL	69

Limitations of OWL and DL

DL

While most of DL is expressible in OWL, there are a couple of limitations.

As with many mathematical notations, there is no formal standard for Description Logic. However, there is a general consensus for most of the operators. The book "Introduction to Description Logic" defines a specific syntax and semantics for DL (Appendix), along with the relationship to OWL (Chapter 8). This project has adopted this book for the standard syntax.

One specified element of this DL that does not appear in OWL is the Predicate Restriction expression. This defines a restriction class in which a series of data properties on an instance are passed as arguments to a predicate function, and every entity which results in this predicate being true is a member of the class. This is a useful construct, but depends on external predicates that are outside of the scope of DL. How these predicates are defined is not considered by OWL either, which is one reason the predicate restriction operator does not appear in OWL.

OWL

In the other direction, OWL has several properties that go beyond what appears in DL:

• OWL allows annotations. These are typically text, and can be connected to any object described in OWL, including other annotations.
• The HasKey operator. This specifies a set of properties, both data properties and object properties, which can be used together to uniquely identify an entity. DL can only describe unique identification like this when using a single property.
• Facets. OWL defines a set of datatype operators that it borrows from XSD which can be used to define value space restriction. This is similar to the predicate classes in DL, though not as flexible.

OWL Validity

OWL is not just a serialization of DL: it also defines a set of specific semantics and capabilities. These capabilities have been selected specifically to ensure that calculating entailments from OWL models will be decidable. This means that there are some constructs that may be syntactically valid in OWL, but are illegal. However, that does not mean that these illegal constructions are not useful. They are just not allowable in a system that needs to remain decidable in the general case.

OWL goes even further, providing various sets of limited functionality call Profiles that have been selected to ensure efficient reasoning and entailment for various types of applications. For instance, the "RL" profile was created to ensure efficient processing via a forward chained rules engine. The other recognized profiles are "EL" and "QL".

The purpose of this project is to describe data rather than to provide a framework for entailment. Therefore DL allows descriptions that are explicitly illegal in OWL. For instance:

parent ∘ parent⁻ ⊑ sibling
Irref(sibling)

This says that following the property chain parent followed by parent⁻ (where parent⁻ is synonymous with a "child" property) leads to a sibling relationship. However, to avoid declaring entities with a parent to be their own sibling, the sibling property is also declared to be irreflexive. The technical reason this is illegal in OWL is because property chains are "complex" properties, and this type of property cannot be declared as irreflexive.

A more practical consideration in this particular case is that the first expression entails parented entities to be their own sibling, but then a new statement makes that entailment invalid. Because OWL uses the "Open World Assumption" (OWA), any valid statement cannot be made invalid by adding additional statements to the model.

Rules like what cannot apply to complex properties must be followed in OWL. But DL is not concerned with "decidability". Instead, it is a syntax with semantics. This allows DL to use any sort of construct to describe data, regardless of whether or not it can be computed.

Extensions

DLe attempts to use all of DL, as defined by the Appendix in Intro to DL. This includes the predicate statements that are not included in OWL. However, this requires predicates that are defined outside of the system. This requires a mechanism for defining the predicates that users need.

Predicates

Predicates are function that return a boolean value. This implies that the function can be defined as a statement in logic. Following the principle that LLMs already understand DL, DLe should try to adopt a syntax that LLMs will already understand. Since DLe is already a logic syntax, using First Order Logic (FOL) is a relatively natural extension. Indeed, when prose descriptions are presented to an LLM working with DL, they will naturally emit FOL expressions for these predicates.

Some of the basic operations in FOL:

Operation	FOL Syntax
AND	⋀
OR	⋁
NOT	¬

Obtaining boolean values to combine with these operations will often come from the basic numeric operations of: less-than, less-than-or-equal, greater-than, greater-than-or-equal, equal, not-equal. This is often represented using the symbols of <, ≤, >, ≥, =, ≠. Models self report that they have good alignment with function-style syntax that uses the labels: lt, le, gt, ge, eq, ne. For instance le(a,b) will return true when a ≤ b.

It is also reasonable to ask LLMs to interpret basic functions that are not explicitly defined. A good example of this is now(), with the expectation that it will return a timestamp. Leaning on other standards also works well, such as ISO-8601 for time periods. This was discovered as LLMs created these expressions by themselves. Consequently, LLMs naturally respond well to expressions like addDuration(now(), P1Y) to define a timestamp 1 year from the current time.

Predicates definitions still need to be distinct from other DLe constructs, but follow a similar structure. Multiple LLMs all agreed that predicate definitions should not use the equivalent operation (≡) of class definitions, nor should they use equality (=), since this has a different connotation again. The recommended symbol for these definitions is the "equals by definition" operation: ≝.

The predicate syntax that DLe has adopted is:

withinNextYear(x) ≝ now() < x ∧ x < addDuration(now(), P1Y)

Annotations

OWL has a broad annotation system, which allows labels, descriptions, history, and other metadata, to be attached to any element described in an ontology, or even to the ontology itself. Given that annotations like this can provide valuable semantics for an LLM, this is an important feature to include.

Conversely, since DL is a mathematical syntax, annotations are not defined. Text books and academic papers do sometimes align notes or comments next to formulae, often using a different font to indicate to the reader the nature of the comment. However, this is a typesetting convention, and has not been considered a part of DL syntax.

DLe uses a predefined subset of annotation properties to incorporate the OWL implementation of annotations. These are commands that all begin with @. Inline comments using the # character are also supported, since this is a very common approach to ad-hoc annotation in most files. These commands are mapped to common OWL annotation properties:

Command	OWL Annotation Property
@label	rdfs:label
@doc	rdfs:comment
@db	rdfs:isDefinedBy
@storage	rdfs:seeAlso
@ann iri	iri
#	dle:comment

Models need not consider which specific OWL annotation property is being employed by these annotations, but the property will become significant if a DLe is converted to another OWL syntax.

The # style of commenting works differently to the other annotations. Rather than specifying the resource that is being annotated, comments are based on location in the file. Since OWLAPI does not maintain the order of expressions, this style of annotation attaches itself to the nearest appropriate resource:

Location	Attached Resource
Start of line	The next resource
Trailing after a statement	The preceding resource

Note: Comments at the end of a file have no resources following them, and will be discarded.