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.

Juan Sequeda, Dean Allemang, and Bryon Jacob noted that even naïve OWL provided greater accuracy than DDL when generating queries for data. Juan and Dean 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:

: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.