DOLA
Jump to navigation
Jump to search
Skip to content
Today
is is possible to translate owl description logic terms to lola-2?
35 seconds ago
Favicon for anthropic
Claude Opus 4.6
Translating OWL Description Logic to LOLA-2
This is an interesting but somewhat unusual question. Let me break it down.
Clarifying the Systems
OWL DL is based on Description Logics (primarily SHOIN(D) for OWL 1 and SROIQ(D) for OWL 2), with constructs like:
DL Construct Syntax Meaning
Concept Intersection C⊓D AND of concepts
Concept Union C⊔D OR of concepts
Complement ¬C NOT a concept
Existential Restriction ∃R.C some values from
Universal Restriction ∀R.C all values from
Number Restriction ≤nR.C at most n
LOLA-2 — could you clarify which system you mean? The name maps to several possibilities:
LoLa 2 (Low-Level Petri Net Analyzer) — a model checker for place/transition nets
LOLA 2.0 — a stream-based runtime verification specification language
Something else?
General Feasibility
Reasoning
The user is asking about translating OWL (Web Ontology Language) Description Logic (DL) terms to LOLA-2. Let me think about what LOLA-2 is.
LOLA-2 could refer to several things. Let me think...
LOLA-2 is likely referring to a Petri net analysis tool, or possibly a logic language. Actually, let me think more carefully.
LOLA-2 might refer to:
LoLa (Low Level Analyzer) - a tool for analyzing Petri nets
LOLA-2 as a programming language or logic specification language
LOLA 2.0, which is a stream runtime verification specification language for real-time stream processing
I'm trying to figure out which LOLA-2 the user means—it could be the temporal stream-based specification language developed by Ben d'Angelo and others, or possibly something else entirely that could express Description Logic concepts. I'm not entirely certain what LOLA-2 refers to in this context—it could be a second-order logic system or a formal language I'm not immediately placing. Rather than guess further, I should acknowledge the uncertainty and pivot to what I do know: translating OWL DL, which maps to description logics like SHOIN(D) or SROIQ(D), would require understanding the target system's expressiveness and whether it can represent the key constructs involved. Concept names (atomic classes)
Role names (properties)
Concept intersection (C⊓D)
Concept union (C⊔D)
Negation/complement (¬C)
Existential restriction (∃R.C)
Universal restriction (∀R.C)
Number restrictions (≤nR.C, ≥nR.C)
Nominals ({a})
Role hierarchies
Transitive roles
etc.
If LOLA-2 is a Petri net analysis tool, the translation would be quite unusual since Petri nets focus on concurrent systems and state reachability rather than ontological reasoning. If it's a stream specification language, it deals with temporal properties of data streams, which is also fundamentally different from description logic. I'm uncertain about what LOLA-2 specifically refers to—it could be a linear logic-based language or something else entirely—so I should be transparent about the ambiguity and discuss the feasibility of translation across the different interpretations I can think of.
Collapse reasoning
1
Lola-2: A Logic Description Language
N. Wirth, 24.4.1994 / 1.9.2015
Lola is a notation (language) for specifying digital circuits (logic). In many ways it resembles a
programming language. However, Lola texts describe static circuits rather than dynamic processes.
Objects occurring in a description can be variables representing signals or registers. Their values
are defined as expressions of other objects and operators representing gates.
0. Vocabulary
The vocabulary of Lola consists of special characters (or pairs), and so-called reserved words which
cannot be chosen as identifiers.
Special characters:
~ & | ^ + - * = # < <= > >=
( ) [ ] { } -> . , ; : := ' !
Reserved words:
BEGIN CONST END IN INOUT MODULE OUT REG TS TYPE VAR
Identifiers, integers, and comments
Identifiers are used to denote constants, variables, and types.
identifier = letter {letter | digit}.
integer = digit {digit} ["H"].
Examples: Lola begin 100 100H 0FFH
Capital and lower case letters are considered as distinct. If an integer is followed by the capital letter
H it is in hexadecimal form with digits 0, 1, ..., 9, and A ... F.
Comments are sequences of characters enclosed by the brackets (* and *), and they may occur
between any two symbols within a Lola text.
Simple types and array types
Every variable in Lola has a type. The elementary type is BIT (BInary digiT), and its variables
assume the values 0 or 1.
type = {"[" expression "]"} SimpleType.
SimpleType = identifier |."MODULE" unit ";" identifier.
TypeDeclaration = identifier "=" type .
An array type is specified by the form [n]T, where T is the type of the elements, and the integer n
specifies the number of elements. In expressions, individual elements are designated by an index.
Indices range from 0 to the array's length minus 1.
Examples: [10] BIT [8][16] BIT
The identifiers BIT, BYTE and WORD are predeclared. The latter denote arrays of 8 and 32 bits
respectively.
Constant declarations
Constant declarations serve to introduce identifiers denoting a constant, numeric value.
ConstDeclaration = identifier "=" integer ";".
2
Variable and register declarations
Variable declarations introduce registers and variables and associate a type with them. All variables
declared in an identifier list have the same type. Variables of type [n] BIT are called bitstrings.
varlist = identifier {"," identifier} ":" type.
Examples: x, y: BIT a: [32] BIT R: BIT Q (clk50): [4] BIT
If a register declaration contains an expression, this denotes the register's clock. The default is a
variable clk, which must be declared (see also Section 7).
Expressions
Expressions serve to combine variables with operators to define new values. The operators are
logical negation, conjunction, disjunction, and difference, or arithmetic sum and difference. Elements
of an array are selected by an index. (e.g. a.5, a[10]).
| logical disjunction (or)
^ logical difference (exclusive or)
& logical conjunction (and)
~ logical negation (not)
arithmetic sum
arithmetic difference
Operands are registers, variables, and constants. Whereas variables denote the value given by the
assigned expression, registers denote the value of the expression in the preceding clock cycle.
Registers are instrumental in sequential circuits. The operands of diadic operators must be of the
same type.
expression = uncondExpr ["->" expression ":" expression].
uncondExpr = simpleExpr [ ("=" | "#" | "<" | "<=" | ">" | ">=") simpleExpr].
simpleExpr = ["+" | "-"] term {("|" | "^" | "+" | "-") term}.
term = factor {"&" factor}.
factor = variable | integer | "~" factor | constructor | "(" expression ")".
variable = identifier {selector}.
selector = "." factor | "[" expression [":" expression] "]".
constructor = "{" element {"," element} "}".
element = expression ["!" integer].
The form a[m : n] denotes the range of indexed elements a[m], ... , a[n].
Constructors denote bitstrings and are sequences of elements. The length (number of bits) of every
element must be known. This length is specified in a declaration, and in this case of constants by an
explicit integer. For example 10'8 denotes the number 10 represented by 8 bits. The length of the
bitstring is the sum of the lengths of its elements. Also, an element can be followed by a replication
factor of the form !n.
A conditional expression of the form z := cond -> x : y expresses represents a multiplexer. Cond
must be of type BIT. If cond yields 1, z is equal to x, otherwise to y.
Examples: x count 1 100 a.4 a[20] operands
a[15 : 8] range
{u, a.4, a[25:20], 0'8, 15'4} constructor (20 bit)
(x & y) | (z & w) (m + n) + 10 simple expressions
a.5 -> b : c expression
Assignments and statements
Assignments serve to define a register's or a variable's value, which is specified by an expression.
An assignment must be understood as a variable's definition (in contrast to an identifier's
3
declaration). In an assignment v := x, v and x do not have the same roles, and this asymmetry is
emphasized by the use of the symbol := instead of the symmetric equal sign. v and x must be of the
same type.
assignment = variable ":=" expression..
Examples: x := y & z a := {x, y, z} R := rst -> 0 : enb -> x : R
Every variable and register can be assigned in only one single assignment statement, and the
assignment must be to the entire variable (not to elements). The only exception is the indexed
assignment to an array of registers (e.g. R[n] := x).
For example, instead of
a.0 := x; a.1 := x+y; a.2 := x-y; a.3 := xy
the single assignment
a := {x, x+y, x-y, xy)
must be used.
Statements are either assignments, or instantiations of modules (see next section), or TSgates.
statement = [assignment | instantiation | TSgate].
StatementSequence = statement {";" statement}.
A TSgate (TS stads for tri-state) is used for INOUT interface parameters.
TSgate = "TS" "(" iogate "," input "," output "," control ")".
iogate = variable.
input = variable. from interface
output = expression. to interface
control = expression. 1 for output, 0 for input from interface
Examples
TS(io, in, out, ~wr) TS(io[k], in[k], out[k], ctrl[k])
The parameters may be simple variables or arrays. They must be of the same type, except that the
control parameter may be of type BIT, even if the other parameters are arrays. In this case it
controls all elements of the arrays
Modules
A module specifies constants, types, variables, registers, and assignments to variables and
registers. Modules are specified as types, and variables can be declared of this type. This implies
that modules can be replicated.
ModuleType = "MODULE" ["*"] unit ";".
paramlist = ("IN" | "OUT" | "INOUT") varlist.
unit = "(" paramlist {";" paramlist} ")" ("^" | ";"
["CONST" {ConstDeclaration}]
["TYPE" {TypeDeclaration}]
{("VAR" | "REG" "(" expression ")") {varlist ";"}}
["BEGIN" StatementSequence] "END").
The expression after the symbol REG specifies the register's clock.
Example of a module type:
TYPE Counter = MODULE (IN clk, rst, enb: BIT; OUT data: WORD);
REG (clk) R: Word;
BEGIN data := R;
R := ~rst -> 0 : enb -> R + 1 : R
4
END Counter
Given a variable of this type (cnt: Counter), its instantiation could be
cnt (clock, reset, enable, val)
where clock, reset, enable and data are variables called actual parameters. They must be expressions
of the corresponding types.
instantiation = identifier selector "(" expression {"," expression} ")".
A "main program" has the form
module = "MODULE" identifier unit identifier ".".
Evidently, a "main program" is the combined declaration of an (anonymous) module type and of a
single instance. The identifier at the end of the module's declaration must be the same as the one
following the symbol MODULE.
21 seconds ago
Favicon for anthropic
Claude Opus 4.6
Lola-2: Logic Description Language — Summary
You've shared the complete specification of Lola-2, a hardware description language (HDL) designed by Niklaus Wirth for specifying digital circuits. Here's a structured overview:
Key Concepts
Lola-2 describes static circuits, not dynamic processes. It resembles a programming language syntactically but has fundamentally different semantics:
Concept Meaning in Lola-2
Variable A signal (combinational logic — value defined by its assigned expression)
Register A clocked storage element (value is from the previous clock cycle)
Expression A combination of operators (gates) applied to operands
Module A reusable circuit block (like a component/entity in VHDL)
Assignment := Defines (not updates) a variable's or register's value
Important Constraints
Every variable/register may be assigned exactly once (single static assignment).
Assignments must target the entire variable — not individual elements — with the sole exception of indexed register arrays like R[n] := x.
The conditional expression cond -> x : y models a multiplexer.
Example — A Counter Module
TYPE Counter = MODULE (IN clk, rst, enb: BIT; OUT data: WORD);
REG (clk) R: WORD;
BEGIN
data := R;
R := ~rst -> 0 : enb -> R + 1 : R
END Counter
This defines:
A register R clocked by clk
Output data wired directly to R
R's next-state logic: if rst is low (~ is negation), reset to 0; else if enb is high, increment; else hold
Do you have a specific question about the language, or would you like help writing a Lola-2 module, translating between Lola-2 and another HDL (e.g., Verilog/VHDL), or analyzing a particular construct?
Reasoning
could we have a lola like language for description logics?
21 seconds ago
Favicon for anthropic
Claude Opus 4.6
Reasoning
The user is asking about whether we could have a "LOLA-like" language for description logics. Let me think about what LOLA is and what description logics are, and how they might be combined.
LOLA (Logic of Logical Agents, or possibly referring to LOLA - a tool for analyzing Petri nets, or possibly another formalism) - actually, I think the user might be referring to LOLA as in a specific formal language or logic programming paradigm. Let me think more carefully.
Actually, "LOLA" could refer to several things:
LOLA - a monitoring specification language for stream-based runtime verification
LOLA - Logic of Logical Agents
Some other formalism
Given the context of "description logics," I think the user might be referring to LOLA as a stream-based specification language, or possibly to a particular kind of declarative/logical specification language. The most likely reference is probably the stream runtime verification language that allows specifying properties over streams of data in a declarative way, though it could also be a lightweight or linear logic variant.
Actually, I'm realizing there are several possibilities here. The user could mean Lola as a synchronous stream processing language for runtime verification and monitoring, where you specify output streams as functions of input streams. Or they might be referring to Lola as a hardware description language designed by Niklaus Wirth for describing digital circuits in a clean, simple way. Given the mention of "description logics," maybe they're asking about an analogous clean language but applied to description logics instead.
Description logics are formal knowledge representation languages that underpin OWL, dealing with concepts, roles, and individuals while reasoning about subsumption and satisfiability. The standard syntax uses mathematical notation with symbols like intersection, union, quantifiers, and negation. There are various ways to express them—OWL in XML, Manchester Syntax for readability, mathematical DL notation, Turtle/RDF for serialization, KRSS syntax, and fragments like DL-Lite and EL. So the user might be asking whether we could design a minimalist, elegant language for description logics similar to how Wirth designed Lola for hardware.
Collapse reasoning
given 1
Lola-2: A Logic Description Language
N. Wirth, 24.4.1994 / 1.9.2015
Lola is a notation (language) for specifying digital circuits (logic). In many ways it resembles a
programming language. However, Lola texts describe static circuits rather than dynamic processes.
Objects occurring in a description can be variables representing signals or registers. Their values
are defined as expressions of other objects and operators representing gates.
0. Vocabulary
The vocabulary of Lola consists of special characters (or pairs), and so-called reserved words which
cannot be chosen as identifiers.
Special characters:
~ & | ^ + - * = # < <= > >=
( ) [ ] { } -> . , ; : := ' !
Reserved words:
BEGIN CONST END IN INOUT MODULE OUT REG TS TYPE VAR
Identifiers, integers, and comments
Identifiers are used to denote constants, variables, and types.
identifier = letter {letter | digit}.
integer = digit {digit} ["H"].
Examples: Lola begin 100 100H 0FFH
Capital and lower case letters are considered as distinct. If an integer is followed by the capital letter
H it is in hexadecimal form with digits 0, 1, ..., 9, and A ... F.
Comments are sequences of characters enclosed by the brackets (* and *), and they may occur
between any two symbols within a Lola text.
Simple types and array types
Every variable in Lola has a type. The elementary type is BIT (BInary digiT), and its variables
assume the values 0 or 1.
type = {"[" expression "]"} SimpleType.
SimpleType = identifier |."MODULE" unit ";" identifier.
TypeDeclaration = identifier "=" type .
An array type is specified by the form [n]T, where T is the type of the elements, and the integer n
specifies the number of elements. In expressions, individual elements are designated by an index.
Indices range from 0 to the array's length minus 1.
Examples: [10] BIT [8][16] BIT
The identifiers BIT, BYTE and WORD are predeclared. The latter denote arrays of 8 and 32 bits
respectively.
Constant declarations
Constant declarations serve to introduce identifiers denoting a constant, numeric value.
ConstDeclaration = identifier "=" integer ";".
2
Variable and register declarations
Variable declarations introduce registers and variables and associate a type with them. All variables
declared in an identifier list have the same type. Variables of type [n] BIT are called bitstrings.
varlist = identifier {"," identifier} ":" type.
Examples: x, y: BIT a: [32] BIT R: BIT Q (clk50): [4] BIT
If a register declaration contains an expression, this denotes the register's clock. The default is a
variable clk, which must be declared (see also Section 7).
Expressions
Expressions serve to combine variables with operators to define new values. The operators are
logical negation, conjunction, disjunction, and difference, or arithmetic sum and difference. Elements
of an array are selected by an index. (e.g. a.5, a[10]).
| logical disjunction (or)
^ logical difference (exclusive or)
& logical conjunction (and)
~ logical negation (not)
arithmetic sum
arithmetic difference
Operands are registers, variables, and constants. Whereas variables denote the value given by the
assigned expression, registers denote the value of the expression in the preceding clock cycle.
Registers are instrumental in sequential circuits. The operands of diadic operators must be of the
same type.
expression = uncondExpr ["->" expression ":" expression].
uncondExpr = simpleExpr [ ("=" | "#" | "<" | "<=" | ">" | ">=") simpleExpr].
simpleExpr = ["+" | "-"] term {("|" | "^" | "+" | "-") term}.
term = factor {"&" factor}.
factor = variable | integer | "~" factor | constructor | "(" expression ")".
variable = identifier {selector}.
selector = "." factor | "[" expression [":" expression] "]".
constructor = "{" element {"," element} "}".
element = expression ["!" integer].
The form a[m : n] denotes the range of indexed elements a[m], ... , a[n].
Constructors denote bitstrings and are sequences of elements. The length (number of bits) of every
element must be known. This length is specified in a declaration, and in this case of constants by an
explicit integer. For example 10'8 denotes the number 10 represented by 8 bits. The length of the
bitstring is the sum of the lengths of its elements. Also, an element can be followed by a replication
factor of the form !n.
A conditional expression of the form z := cond -> x : y expresses represents a multiplexer. Cond
must be of type BIT. If cond yields 1, z is equal to x, otherwise to y.
Examples: x count 1 100 a.4 a[20] operands
a[15 : 8] range
{u, a.4, a[25:20], 0'8, 15'4} constructor (20 bit)
(x & y) | (z & w) (m + n) + 10 simple expressions
a.5 -> b : c expression
Assignments and statements
Assignments serve to define a register's or a variable's value, which is specified by an expression.
An assignment must be understood as a variable's definition (in contrast to an identifier's
3
declaration). In an assignment v := x, v and x do not have the same roles, and this asymmetry is
emphasized by the use of the symbol := instead of the symmetric equal sign. v and x must be of the
same type.
assignment = variable ":=" expression..
Examples: x := y & z a := {x, y, z} R := rst -> 0 : enb -> x : R
Every variable and register can be assigned in only one single assignment statement, and the
assignment must be to the entire variable (not to elements). The only exception is the indexed
assignment to an array of registers (e.g. R[n] := x).
For example, instead of
a.0 := x; a.1 := x+y; a.2 := x-y; a.3 := xy
the single assignment
a := {x, x+y, x-y, xy)
must be used.
Statements are either assignments, or instantiations of modules (see next section), or TSgates.
statement = [assignment | instantiation | TSgate].
StatementSequence = statement {";" statement}.
A TSgate (TS stads for tri-state) is used for INOUT interface parameters.
TSgate = "TS" "(" iogate "," input "," output "," control ")".
iogate = variable.
input = variable. from interface
output = expression. to interface
control = expression. 1 for output, 0 for input from interface
Examples
TS(io, in, out, ~wr) TS(io[k], in[k], out[k], ctrl[k])
The parameters may be simple variables or arrays. They must be of the same type, except that the
control parameter may be of type BIT, even if the other parameters are arrays. In this case it
controls all elements of the arrays
Modules
A module specifies constants, types, variables, registers, and assignments to variables and
registers. Modules are specified as types, and variables can be declared of this type. This implies
that modules can be replicated.
ModuleType = "MODULE" ["*"] unit ";".
paramlist = ("IN" | "OUT" | "INOUT") varlist.
unit = "(" paramlist {";" paramlist} ")" ("^" | ";"
["CONST" {ConstDeclaration}]
["TYPE" {TypeDeclaration}]
{("VAR" | "REG" "(" expression ")") {varlist ";"}}
["BEGIN" StatementSequence] "END").
The expression after the symbol REG specifies the register's clock.
Example of a module type:
TYPE Counter = MODULE (IN clk, rst, enb: BIT; OUT data: WORD);
REG (clk) R: Word;
BEGIN data := R;
R := ~rst -> 0 : enb -> R + 1 : R
4
END Counter
Given a variable of this type (cnt: Counter), its instantiation could be
cnt (clock, reset, enable, val)
where clock, reset, enable and data are variables called actual parameters. They must be expressions
of the corresponding types.
instantiation = identifier selector "(" expression {"," expression} ")".
A "main program" has the form
module = "MODULE" identifier unit identifier ".".
Evidently, a "main program" is the combined declaration of an (anonymous) module type and of a
single instance. The identifier at the end of the module's declaration must be the same as the one
following the symbol MODULE.
could we have a similar language as an alternative to the owl description logic syntax?
just now
Favicon for anthropic
Claude Opus 4.6
Processing
Reasoning
The user is asking me to design a language similar to Lola-2 (a hardware description language) but for OWL (Web Ontology Language) description logic. This is an interesting idea — taking the clean, concise syntax of Lola and applying it to ontology description.
Let me think about what OWL Description Logic needs:
Classes (concepts) — analogous to types in Lola
Properties (roles) — object properties and data properties
Individuals — instances/members of classes
Class expressions — intersection, union, complement, restrictions
Axioms — subclass, equivalence, disjointness
Property characteristics — transitive, symmetric, functional, etc.
Restrictions — existential (some), universal (only), cardinality
Now I'm mapping the core Lola constructs to their OWL equivalents — modules become ontologies or classes, types map to class definitions, variables become individuals or properties, and the logical operators translate directly to OWL's intersection, union, and complement operations.
For the language design, I'm considering names like OWLA or ODL, and I need to think through how to represent OWL's fundamental class expressions — intersections, unions, complements, and the various restriction types like existential and universal quantification along with cardinality constraints.
Now I'm mapping out the core components: classes with their expressions, object and data properties with their characteristics like transitivity and functionality, the main axiom types for defining relationships and assertions, and how to represent individuals with their class and property memberships.
Designing the syntax... I'm laying out the operators for axioms — subclass relationships, equivalence, and disjointness — and now I need to settle on a good name for this language. I'm considering options like DOLA or ODL, but I want something that captures the spirit of being a description logic alternative to OWL, so let me think through what would actually work well here. Defining the formal grammar... I'm looking at the property and individual declaration syntax, then reconsidering how to map this more cleanly to Lola's structure. I'm comparing the key concepts across Lola-2, OWL DL, and DOL to find better alignment—like how MODULE corresponds to ONTOLOGY, TYPE to CLASS, and so on. I'm exploring different syntaxes for property restrictions, comparing a member-access style like hasChild.SOME(Person) against a more operator-heavy approach with SOME hasChild : Person, trying to find what feels most natural and composable for the language.
The dot notation SOME hasChild . Person seems cleanest—it mirrors standard description logic notation while staying readable and concise. Now I'm settling on a final design for DOL that balances clarity with formal specification, starting with the vocabulary and special characters.
Defining the reserved words and basic syntax rules...
Now I'm laying out the grammar for class expressions, which can be unions and intersections of class factors like atomic classes, negations, restrictions on properties, and enumerated individuals. The restrictions handle existential and universal quantification over properties, cardinality constraints, value restrictions, and self-restrictions, with operators for union, intersection, and complement. Now I'm defining the structure for property declarations, which can specify inverse relationships, characteristics like functionality or transitivity, domain and range constraints, subproperty hierarchies, and property chains. Data properties follow a similar pattern but with datatype ranges instead of class expressions, while individual declarations associate instances with classes and assertions about their relationships. Continuing with the ontology structure, I need to finalize how declarations and axioms fit together. The BEGIN...END section should contain the actual statements that define relationships and constraints, separate from where classes and properties are declared. Let me work through what a concrete example would look like to make sure the grammar captures the right semantics. I'm realizing there's some structural confusion between Lola and DOL syntax. In Lola, TYPE defines types with =, VAR declares variables, and BEGIN assigns values with :=. For DOL, I should use CLASS for declarations and definitions, PROP for properties, IND for individuals, and BEGIN for additional axioms like subsumptions and disjointness constraints. The key distinction is that = in CLASS gives equivalence while <: in BEGIN gives subsumption, so I need to reorganize which definitions go where.
Now I'm thinking through the data types and built-in support—I should include predeclared datatypes like INT, FLOAT, STRING, BOOL, and DATE that map to their XSD equivalents, and I'll keep annotation properties out of the core specification for simplicity.
For the language name, I'm considering a few options: ODL is clear and descriptive, but I'm also drawn to something like Loca or Dola that feels more cohesive with the Lola-2 style. Let me settle on a name and write out the full specification document to match that style. I'm settling on DOLA — Description Ontology Language — as a clean parallel to LOLA. Now I need to write out the full specification with examples, and I'm working through the syntax for restrictions to keep things concise and consistent. I'm comparing a few approaches: a DL-style option with keywords like SOME and ONLY, versus an operator-style approach using arrows and comparison symbols.
Defining restriction syntax... I'm mapping out the class expression constructors in OWL, showing how each formal construct translates to a more readable notation—complement, existential and universal quantifiers, cardinality constraints, and enumeration of individuals.
Now I'm organizing the full specification into a logical structure, starting with vocabulary and identifiers, then moving through classes, properties, expressions, and axioms before covering individuals and ontologies.
Defining the grammar for identifiers, IRIs, and comments... Continuing with the property and data property declarations, specifying domains, ranges, and various characteristics like functionality, transitivity, and symmetry. I'm realizing this formal grammar is getting unwieldy and I should probably streamline the syntax to make it more practical.
Looking at how Lola handles variable declarations with their concise syntax, I think properties should follow the same pattern—keep the declarations minimal with just the identifier and key characteristics, then move the detailed axioms like domain and range specifications into the BEGIN section where they belong. This would let me write something like declaring properties with their characteristics inline, then defining their domains and ranges separately as axioms. Refining the property declaration syntax...
Defining the grammar for property attributes with domain, range, inverse, and characteristic modifiers, then extending it to handle data properties as well.
Now I'm thinking through how modules work in this language—whether to support instantiation like VHDL components or keep it simpler with just imports. I'm also reconsidering the dot notation for class expressions, since it conflicts with the selector syntax I've already used elsewhere, so I need to be careful about how restrictions are written. I think SOME R . C is cleanest since the dot's meaning is unambiguous in context—it always separates a property from its filler class after a restriction keyword. Now I'm writing out the complete grammar specification for the ontology language, starting with the core structure and declaration types.
Defining the grammar rules... I'm noticing some redundancy in how I've structured the class equivalence rules—the = operator for equivalence is overlapping with other parts of the grammar, so I should consolidate those definitions.
More importantly, I'm realizing the individual declarations need better separation: class assertions (declaring what class an individual belongs to) should be distinct from property assertions (assigning property values). I'm restructuring this so individual declarations use a cleaner syntax with the colon notation, while property assignments stay in the BEGIN section with the walrus operator, which feels more aligned with the Lola language style.
Refining the grammar...
Now I'm hitting a design decision about cardinality restrictions—specifically how to denote qualified number restrictions without using the dot notation, since that could get confused with the individual.property selector syntax. I'm exploring different syntactic options to keep things unambiguous.
I think the dot notation is actually fine here since the context makes it clear whether we're talking about a class or an individual. For value restrictions on individuals and reflexive properties, I can drop the dot entirely since the filler type is obvious from context.
Now I want to step back and make sure the overall language design feels coherent—thinking through how types, variables, and assignments work in Lola and how that maps to the ontology layer with classes, instances, and properties.
Writing out a complete example to validate the design... I'm noticing a potential ambiguity with the subclass operator—it works fine in the CLASS section where the left side is just a name, but I want to support it in BEGIN for more complex expressions too, which should be grammatically consistent. I'm also considering whether to allow property assertions directly in the IND section for more compact declarations, supporting both simple inline assertions and more complex ones in BEGIN.
For negative assertions, I'm leaning toward using # syntax in the BEGIN section to keep things cleaner and avoid confusion with other operators.
I'm going to skip negative property assertions in v1 to keep the language simple—I can always add that as an extension later. Now I'm ready to write out the final design, modeling it after Lola-2's document structure.
For operators, I'm settling on = for class equivalence in the CLASS section and <: for subsumption, while leaving out arithmetic comparisons since they're not core to description logic.
I'm also clarifying the syntax: = declares equivalence like Mother = Female & Parent, while bare class names like Person; just declare the class without defining it, and I'll use a DISJOINT keyword instead of trying to overload #.
For modularity, I'll keep it simple with just IMPORT statements to bring in other ontologies, skipping parameterized modules for now since OWL doesn't really have that concept anyway.
I'm also thinking through how to handle data ranges and typed literals—I'll stick with simple named datatypes for data properties rather than complex range constraints, which should cover the practical cases without overcomplicating things.
Now I'm mapping out the structure for the full document: vocabulary, identifiers and IRIs, classes and datatypes, constants, class expressions, properties, individuals, axioms, and ontologies, with a worked example at the end. I'm ready to write this up in markdown.
I'm also working through a design decision for class declarations—whether to support both equality and subclass relationships in the same syntax, or handle them separately. I think allowing Male <: Person; directly in the class declaration is cleaner for simple cases, while reserving the BEGIN section for complex general concept inclusions like (A & B) <: C or existential restrictions. I'll go with that approach and make sure the BEGIN section supports full class expressions on the left side of the subclass operator.
Now I'm working through the syntax for property assertions on individuals. Using the assignment operator pattern from Lola, I can write john.hasChild := mary for object properties and john.hasAge := 42 for data properties, which reads naturally. I'm skipping negative assertions since they're rarely used in practice.
Defining the grammar for statements in the BEGIN section... I've been going in circles on the syntax details—time to just write this up and get a complete document done. Now I'm thinking through the final piece: how the ONTOLOGY structure should work, particularly around imports. I'm considering whether to put imports in parentheses like parameters, or handle them separately in the body, and whether parentheses are even necessary when there are no imports.
Generating comparison table... Generating markdown table...
I'm noting that this covers the main OWL 2 DL features, though SWRL rules, annotations, and some advanced features aren't included in this basic version. Now I'll start writing the actual document, aiming for something comparable in length to the Lola-2 spec.
I want to include a comprehensive example at the end, similar to how Lola-2 demonstrates modules. For the example ontology, I'm considering the classics—pizza ontology, family relationships, or university structures—but I'll go with a hybrid approach using a simple family and person ontology that showcases all the key features.
Starting the document now...
Defining the vocabulary with special characters and reserved words...
Continuing with identifiers, IRIs, and comments...
Describing classes and datatypes...
Moving into constant declarations and class expressions...
I'm defining the grammar for class expressions, which combine atomic classes using set-theoretic operators. Class factors can be atomic identifiers, complements, property restrictions, enumerations, or parenthesized expressions. Restrictions let me specify cardinality constraints on properties (like "some," "only," "min," "max," "exact") or value constraints. The operators follow a precedence hierarchy where union has lowest precedence, then intersection, then complement at the highest. I'm looking at how enumeration works in DOLA—sets like {a, b, c} represent classes containing exactly those individuals, which maps to ObjectOneOf in description logics. Then I'm seeing practical examples of how these constructors combine: intersection, union, complement, and various restriction types, including nested ones like existential restrictions within existential restrictions. The key distinction is that DOLA uses set-theoretic and relational operations to define classes, whereas Lola uses gates to define signal values. Now moving into class declarations, which have a syntax where an identifier can optionally be defined as equal to or a subclass of some class expression. Now I'm defining the syntax for property declarations, which can have multiple identifiers and optional attributes like domain, range, inverse relations, subproperty constraints, and characteristic properties like functionality or transitivity. Data properties follow a similar structure but with datatype ranges instead of class expressions, and I'm also laying out a reference table for what each characteristic keyword means. I'm seeing how individuals are declared as concrete members of classes, with syntax like john, bob : Male to assert class membership. Then axioms and statements define relationships beyond declarations—including concept inclusions, disjointness constraints, property assertions, and identity statements. that individuals are pairwise distinct. Now I'm looking at some concrete examples showing how these assertions work in practice—disjoint classes, general concept inclusions with quantifiers, property assignments with both object and literal values, and identity statements. An ontology serves as the top-level container that brings together all the vocabulary and constraints, with sections for imports, constants, classes, properties, and data declarations.
Defining the complete structure... I'm reviewing the schema definition and noticing that NuclearFamily as a class constraint doesn't quite work—it's trying to define a group property on individuals, which doesn't align with how the ontology should structure family units. I should reconsider whether this should be a separate class or relationship instead.
Collapse reasoning
...