Documentation

# RadLex → Prolog Compiler Specification **Status:** Implementation-ready specification derived from RadLex 4.3 and design discussion **Source ontology:** RadLex 4.3 (`RadLex.owl`) **Target runtime:** SWI-Prolog **Scope:** RadLex-specific OWL dialect, not general OWL > **Design intent:** preserve RadLex's meaning; compile away RDF/OWL representational machinery. --- ## Contents 1. [Vision](#1-vision) 2. [Technical Introduction](#2-technical-introduction) 3. [Survey of Decisions and Translation Rules](#3-survey-of-decisions-and-translation-rules) 4. [Reference Appendices](#4-reference-appendices) ## 1. Vision RadLex is already a strong domain model. The full RadLex 4.3 ontology contains roughly 47,000 classes and more than 130,000 subclass axioms, but those facts are expressed through a surprisingly small and coherent logical vocabulary: named classes, class inclusion, existential class relationships, relation specialization, inverse relations, domain/range implications, a small number of unions, two relations declared as `owl:FunctionalProperty`, and lexical/documentary annotations. The purpose of this project is **not to simplify or redesign RadLex's domain model. It is to expose it.** RadLex is distributed as OWL encoded in RDF. That representation is useful to the Semantic Web ecosystem, but it introduces machinery that is not useful to the application architecture we want: RDF triples and lists, anonymous restriction nodes, OWL encoding conventions, duplicated class/individual identities, URI-heavy identifiers, and other serialization-level structures. We will build a compiler that reads RadLex OWL and emits a small, explicit Prolog ontology language. The generated Prolog should make the structure of RadLex easier to inspect, test, reason about, and use as the foundation for application-specific logic. The governing principle is: > **If removing an OWL/RDF construct changes what RadLex means, preserve its meaning. If it changes only how that meaning is encoded, compile it away.** This is a **RadLex compiler**, not a general OWL implementation. The source language is the OWL dialect actually exercised by RadLex 4.3. Unsupported source forms are compiler errors, not invitations to guess. ### 1.1 Ontology layer and application layers The compiled ontology is abstract. It describes RadLex classes, class expressions, relations, relation properties, and lexical/documentary knowledge. It does not describe a particular patient, report, image, specimen, or other concrete case. Application layers are separate consumers of the compiled ontology. An application may identify concrete referents from its own evidence and use RadLex to understand the classes and general relationships associated with those referents. The compiler does not define how an application creates individuals, resolves mentions, performs clinical reasoning, or materializes case-specific facts. ```text RADLEX ONTOLOGY ──────────────────────────────────────────────────────── right_kidney ⊆ kidney right_kidney ⊆ ∃ contained_in.right_retroperitoneal_compartment The ontology contains abstract knowledge about classes and relations. It does not assert that a kidney, compartment, patient, or report exists. APPLICATION LAYER ──────────────────────────────────────────────────────── An application may independently establish a concrete referent, for example: instance_of(k1, right_kidney). The application may consult the ontology to understand what `right_kidney` means and how that class is related to other classes. The ontology axiom above does not authorize the compiler to manufacture a concrete compartment or to assert a case-specific `contained_in(k1, ...)` relationship. ``` The compiler therefore preserves RadLex's class-level commitments without imposing a particular application-world semantics on downstream consumers. A future clinical reasoner, transcript-enrichment system, validator, or other application may build additional reasoning policies on top of the same compiled ontology. ### 1.2 What the compiler produces The target is a readable Prolog ontology rather than a generic RDF triple store. Representative target forms include: ```prolog class(rid205). subclass(rid29662, rid205). some_relation( rid29662, contained_in, rid29541 ). label(rid205, en, preferred, "kidney"). xref(rid205, fma(7203)). ``` The compiler may additionally emit executable rules when an OWL declaration is more faithfully and transparently represented as an implication than as data. For example, a simple OWL domain declaration whose meaning is ```text P(x,y) → C(x) ``` may compile directly to a Prolog rule of the form: ```prolog isa(X, c) :- p(X, _). ``` rather than to a potentially misleading `domain(p, c)` fact. --- ## 2. Technical Introduction This section establishes the empirical source boundary, notation, accepted source grammar, compiler architecture, invariants, and completion criteria. It describes the compiler as a system before the specification turns to individual translation decisions. ### 2.1 Empirical RadLex 4.3 Source Inventory The compiler specification is grounded in the actual RadLex 4.3 source, not in the full theoretical expressiveness of OWL. | Source construct | Observed count | Role | |---|---:|---| | `owl:Class` | 46,952 | Named ontology classes | | `rdfs:subClassOf` → named class | 46,900 | Direct class inclusion | | `owl:Restriction` | 83,161 | Class restrictions | | `owl:onProperty + owl:someValuesFrom` | 83,161 | **100% of restrictions** | | `owl:ObjectProperty` | 52 | Domain relation vocabulary | | `owl:inverseOf` | 19 | Explicit inverse relation pairs | | `rdfs:subPropertyOf` | 12 | Relation specialization | | object-property `rdfs:domain` | 50 | Subject classification implications | | object-property `rdfs:range` | 52 | Object classification implications | | `owl:unionOf` | 52 | Anonymous union class expressions | | unions used as domains | 48 | Most union usage | | unions used as ranges | 4 | Remaining union usage | | `owl:FunctionalProperty` | 2 | `Segment_Of`, `Tributary_Of` | | `owl:equivalentClass` | 1 | Datatype definition, not anatomical class equivalence | | `owl:oneOf` | 1 | Datatype enumeration | | `owl:NamedIndividual` | 24,092 | Punned duplicate identities; see §3.8 | The crucial observation is that tens of thousands of concrete classes are built from a very small number of abstract forms. The compiler should therefore be specified over those forms rather than over anatomical concepts individually. #### 2.1.1 Object relation vocabulary RadLex declares 52 object properties. Important families include: ```text Partonomy Part_Of / Has_Part Regional_Part_Of / Has_Regional_Part Constitutional_Part_Of / Has_Constitutional_Part Branch_Part_of / Has_Branch_Part Segment_Of Containment and boundaries Contained_In / Contains Bounded_by / Bounds Surrounded_by / Surrounds External_to Spatial ordering Anterior_to Posterior_to Superior_to Inferior_to Proximal_to Distal_to Topology and branching Continuous_With Branch_Of / Has_Branch Tributary_Of Flow Drains_Into / Receives_Drainage_From Sends_Output_To / Receives_Input_From Blood supply Blood_Supply_of / Has_Blood_Supply Lymphatics Lymphatic_Drainage / Lymphatic_Drainage_Of Innervation Innervates / Has_Innervation_Source Attachment Attaches_to / Receives_attachment_from Muscle anatomy Has_origin / Origin_of Has_insertion / Insertion_of Projection Projects_To / Receives_Projection_From Projects_From Membership Member_Of / Has_Member Causation May_Cause / May_Be_Caused_By Other Anatomical_Site Has_Entrapment_Site Related_modality ``` The relation vocabulary is fixed and small enough that the compiler can explicitly specify its treatment rather than implement a generic relation calculus. --- ### 2.2 Translation Model and Notation #### 2.2.1 Source and target notation Examples use normalized Turtle to show the semantic shape of source OWL. The actual RadLex distribution is RDF/XML; Turtle is used only because it makes the relevant RDF graph readable. We write: ```text OWL ⟹RL Prolog ``` to mean “the supported RadLex OWL form on the left compiles to the Prolog ontology fragment on the right.” Metavariables: ```text C, D, E named RadLex classes P, Q RadLex object properties x, y application individuals L literal value ``` Class expressions initially include: ```text ClassExpr ::= NamedClass | union([ClassExpr, ...]) ``` Additional class-expression forms are introduced only if required by the observed RadLex dialect. #### 2.2.2 Core distinction: class theory versus application facts The ontology layer has statements such as: ```prolog subclass(C, D). some_relation(C, P, D). ``` The application layer has statements about actual input-derived individuals: ```prolog instance_of(x, C). p(x, y). ``` These are deliberately not interchangeable. --- ### 2.3 Source-Language Grammar The compiler accepts the RadLex-specific source forms below. This grammar describes recognized source shapes; it does not itself define their semantics. ```ebnf ClassAxiom ::= NamedSubclass | ExistentialSubclass ; NamedSubclass ::= Class "rdfs:subClassOf" Class ; ExistentialSubclass ::= Class "rdfs:subClassOf" Restriction ; Restriction ::= "owl:onProperty" Relation "owl:someValuesFrom" Class ; PropertyAxiom ::= Domain | Range | SubProperty | InverseProperty | FunctionalProperty ; Domain ::= Relation "rdfs:domain" ClassExpr ; Range ::= Relation "rdfs:range" ClassExpr ; ClassExpr ::= Class | UnionExpr ; UnionExpr ::= "owl:unionOf" "(" Class { Class } ")" ; SubProperty ::= Relation "rdfs:subPropertyOf" Relation ; InverseProperty ::= Relation "owl:inverseOf" Relation ; FunctionalProperty ::= Relation "rdf:type" "owl:FunctionalProperty" ; ``` The grammar will be expanded only when an empirical inventory demonstrates another meaningful RadLex source shape. --- ### 2.4 Compiler Architecture A practical implementation can use SWI-Prolog's RDF parser as a front end without adopting its RDF graph as the application's ontology representation. ```text RadLex 4.3 RDF/XML │ │ rdf_load/1 ▼ SWI RDF graph ← parsing / namespaces / RDF syntax │ │ RadLex-aware semantic extraction ▼ RadLex compiler IR ← supported logical forms only │ │ normalization + validation ▼ Generated Prolog ontology ← readable target program │ ▼ Application reasoning layer ``` The compiler should distinguish source facts from generated semantic rules sufficiently for provenance and debugging. #### 2.4.1 Candidate directory shape ```text ontology/ upstream/ radlex/ RadLex.owl generated/ radlex_classes.pl radlex_relations.pl radlex_lexicon.pl radlex_rules.pl src/ ontology/ radlex.pl semantics.pl application/ model.pl compiler/ load.pl extract.pl validate.pl emit.pl tests/ compiler/ ontology/ application/ ``` This directory structure is illustrative, not yet normative. --- ### 2.5 Translation Invariants The following invariants are normative: 1. **The compiler produces ontology knowledge, not application individuals.** No concrete patient-, report-, image-, specimen-, or execution-specific individual is introduced by ontology compilation. 2. **No supported RadLex source axiom is silently discarded.** Every supported construct has a defined translation; unsupported constructs produce an explicit compiler diagnostic. 3. **Existential restrictions retain existential meaning without requiring named witnesses.** `C ⊆ ∃ P.D` remains a class-level proposition; compilation does not Skolemize the filler. 4. **The ontology and downstream application models remain semantically distinct.** The compiler does not define application-level closed-world policy, entity creation, clinical inference, or case-specific materialization. 5. **Class-level relationships and concrete individual relationships are never conflated.** A general RadLex relation between classes is not automatically projected onto particular application individuals. 6. **Every generated ontology assertion or rule is traceable to its RadLex source axiom or to an explicitly specified compiler inference.** 7. **The compiler is defined for the observed RadLex OWL dialect, not for arbitrary OWL.** 8. **Union expressions remain disjunctive.** `isa(X, union([A,B]))` does not imply either `isa(X,A)` or `isa(X,B)` individually. 9. **Inverse relations are translated through explicit fixed cases.** The compiler does not infer arbitrary inversions of class expressions. 10. **OWL functional-property declarations are represented by their mathematical meaning as partial functions.** `partial_function(P)` means that `P` is single-valued in its second argument for each first argument; it does not imply totality or injectivity. 11. **Lexical normalization does not mutate upstream ontology strings.** Exact source text and matching keys are separate concerns. 12. **Source identity is preserved.** Readable Prolog names may be emitted for convenience, but each generated class, relation, annotation property, and other named source entity remains traceable to its exact RadLex URI/RID. ### 2.6 Acceptance Criteria This specification is implementation-ready when the compiler and its tests satisfy all of the following: - every meaningful OWL/RDFS construct exercised by RadLex 4.3 has been inventoried; - each supported source shape has a normative translation rule; - each translation rule states the upstream meaning, target representation, formal consequence, and explicit non-consequences where ambiguity is possible; - the punning validation confirms that no source axiom depends materially on the punned `owl:NamedIndividual` interpretation; - any unsupported source construct causes an explicit compiler failure or diagnostic rather than silent omission; - the compiler test suite demonstrates that no supported source construct is silently dropped; - generated facts retain provenance sufficient to trace them to source RadLex axioms and exact source identities; - the two RadLex `owl:FunctionalProperty` declarations compile as `partial_function/1` metadata with the correct single-valued semantics; - the unused `Term_type` datatype enumeration is preserved, if retained at all, as annotation-schema metadata rather than medical class logic; - representative anatomy and relation queries against the generated Prolog ontology return the expected class-level results; - compilation does not create concrete application individuals or case-specific assertions. ## 3. Survey of Decisions and Translation Rules This section is the normative survey of the RadLex-specific translation decisions. Each subsection addresses one recurring source construct or one compiler policy that affects the meaning of the generated Prolog. The repeated structure—upstream meaning, ontology/application interpretation, translation decision, example, formal rule, and non-consequences—is intentional. ### 3.1 Named Classes #### Upstream meaning An OWL named class identifies an abstract category. A RadLex RID identifies the class; labels and synonyms are annotations on that identity. #### Ontology and application interpretation ```text RADLEX ONTOLOGY ──────────────────────────────────────────────────────── kidney is a named class identified by RID205. The existence of the class does not establish the existence of any kidney individual. APPLICATION MODEL ──────────────────────────────────────────────────────── A report-processing execution may establish: instance_of(k1, rid205). After that fact has been established, the application model contains a particular individual that is classified as a kidney. ``` #### Translation decision Each supported named RadLex class becomes one `class/1` fact. The RID is preserved as the stable ontology identity. #### Example Turtle: ```turtle radlex:RID205 a owl:Class ; rdfs:label "kidney"@en . ``` Prolog: ```prolog class(rid205). label(rid205, en, preferred, "kidney"). ``` #### Formal translation ```text C rdf:type owl:Class ────────────────────────── C ⟹RL class(C) ``` #### Entails / does not entail ```text ENTAILS C is part of the ontology's class vocabulary. DOES NOT ENTAIL Any application individual is an instance of C. ``` --- ### 3.2 Class Inclusion (`rdfs:subClassOf`) #### Upstream meaning For named classes C and D: ```text C ⊆ D ``` means every instance of C is also an instance of D. #### Ontology and application interpretation ```text RADLEX ONTOLOGY ──────────────────────────────────────────────────────── right_kidney ⊆ kidney This statement expresses an inclusion relation between two ontology classes. APPLICATION MODEL ──────────────────────────────────────────────────────── instance_of(k1, right_kidney) The class hierarchy may classify the existing individual: instance_of(k1, kidney) This derivation does not create a new application individual. ``` #### Translation decision Named subclass axioms compile directly to `subclass/2`. #### Example Turtle: ```turtle radlex:RID29662 rdfs:subClassOf radlex:RID205 . ``` Prolog: ```prolog subclass(rid29662, rid205). ``` Application inference may be defined by a separate ontology/application bridge: ```prolog instance_of(X, Super) :- instance_of(X, Sub), subclass(Sub, Super). ``` #### Formal translation ```text C,D ∈ Class C rdfs:subClassOf D ─────────────────── C ⟹RL subclass(C,D) ``` Logical meaning: ```text C(x) → D(x) ``` #### Entails / does not entail ```text ENTAILS Every C is a D. DOES NOT ENTAIL Every D is a C. Any instance of either class exists in the application. ``` --- ### 3.3 Existential Class Relationships (`owl:someValuesFrom`) #### Upstream meaning RadLex uses this construct extensively. All 83,161 restrictions observed in RadLex 4.3 are existential `someValuesFrom` restrictions. The OWL statement ```text C ⊆ ∃ P.D ``` means: ```text For every x: if C(x), then there exists at least one y such that D(y) and P(x,y). ``` The restriction identifies the **class of the required filler**. It does not identify a particular filler individual. #### Ontology and application interpretation ```text RADLEX ONTOLOGY ──────────────────────────────────────────────────────── right_kidney ⊆ kidney right_kidney ⊆ ∃ contained_in.right_retroperitoneal_compartment RadLex specifies the class of location required for instances of right_kidney. This ontology statement does not introduce an individual for a patient, a kidney, or a retroperitoneal compartment. APPLICATION MODEL ──────────────────────────────────────────────────────── instance_of(k1, right_kidney). The application model contains k1 because k1 was established from the input to this execution. If no compartment has been established from the report or by an explicitly permitted application derivation, no compartment individual exists in this application model. ``` #### Translation decision Existential restrictions compile to a class-level relation: ```prolog some_relation(SubjectClass, Relation, FillerClass). ``` The compiler does not Skolemize and does not invent application individuals. #### Example Turtle: ```turtle radlex:RID29662 rdfs:subClassOf [ a owl:Restriction ; owl:onProperty radlex:Contained_In ; owl:someValuesFrom radlex:RID29541 ] . ``` Prolog: ```prolog some_relation( rid29662, contained_in, rid29541 ). ``` #### Formal translation ```text C,D ∈ Class P ∈ Relation C ⊆ ∃ P.D ─────────────────────────── C ⟹RL some_relation(C,P,D) ``` #### Entails / does not entail ```text ENTAILS Every instance of C bears P to at least one instance belonging to D. DOES NOT ENTAIL A named D individual is available to the application. some_relation(C,P,D) does not by itself produce: instance_of(y,D) p(x,y) ``` This preservation of existential class knowledge without materializing witnesses is a foundational compiler rule. --- ### 3.4 Domain and Range: Relation Participation Implies Classification #### Upstream meaning OWL/RDFS domain and range are inference axioms, not programming-language type checks. For a simple domain: ```text domain(P) = C ``` meaning: ```text P(x,y) → C(x) ``` For a simple range: ```text range(P) = D ``` meaning: ```text P(x,y) → D(y) ``` They do **not** mean “reject P(x,y) unless x and y were already known to have the declared types.” #### Ontology and application interpretation ```text RADLEX ONTOLOGY ──────────────────────────────────────────────────────── The definition of relation P tells us something about any entity that participates in P. P(x,y) → C(x) This axiom provides classification knowledge about entities that participate in P. APPLICATION MODEL ──────────────────────────────────────────────────────── p(a,b). If this concrete relation has been established from the application input, the ontology may classify the existing individual a as an instance of C. This classification does not create a new application individual. ``` #### Translation decision For simple named domains/ranges, compile the inferential meaning directly into Prolog rules rather than preserve potentially misleading `domain/2` or `range/2` facts. Representative target: ```prolog isa(X, c) :- p(X, _). isa(Y, d) :- p(_, Y). ``` For the ontology layer, the same implication must also apply to class-level existential relations. If a class C participates as the subject of `some_relation(C,P,_)`, the source domain of P may imply a superclass or class-expression membership for C. #### Formal translation: named domain ```text domain(P) = C ──────────────────────── P(x,y) → C(x) ``` Generated application-facing rule shape: ```prolog isa(X, c) :- p(X, _). ``` Generated ontology-facing rule shape: ```prolog subclass(C, c) :- some_relation(C, p, _). ``` #### Formal translation: named range ```text range(P) = D ──────────────────────── P(x,y) → D(y) ``` Generated application-facing rule shape: ```prolog isa(Y, d) :- p(_, Y). ``` Generated ontology-facing rule shape: ```prolog subclass(D, d) :- some_relation(_, p, D). ``` #### Entails / does not entail ```text ENTAILS A participant in P receives the appropriate classification. DOES NOT ENTAIL P is a conventional typed function signature. Unknown classification invalidates an asserted P relation. C(x) and D(y) imply P(x,y). ``` > **Important:** the direction of inference is intentionally visible in generated Prolog. --- ### 3.5 Union Class Expressions (`owl:unionOf`) #### Upstream meaning RadLex 4.3 contains 52 union expressions. Forty-eight are used in property domains and four in property ranges. A union class expression ```text A ∪ B ``` means membership in at least one member class. If a property domain is a union: ```text domain(P) = A ∪ B ``` then: ```text P(x,y) → (A(x) ∨ B(x)) ``` It does **not** imply A(x) individually, nor B(x) individually. #### Ontology and application interpretation ```text RADLEX ONTOLOGY ──────────────────────────────────────────────────────── domain(P) = A ∪ B P(x,y) implies: x ∈ A ∪ B RadLex has not selected which member class applies. APPLICATION MODEL ──────────────────────────────────────────────────────── p(a,b). The ontology may classify a as: isa(a, union([a_class,b_class])) If no other fact or rule provides a more specific classification, the application must preserve the disjunction and must not select either member individually. ``` #### Translation decision Anonymous union classes become first-class Prolog class expressions wherever a class expression is expected: ```prolog union([a, b]). ``` More specifically, classification of an entity into the union is represented as: ```prolog isa(X, union([a, b])). ``` A union-valued domain therefore compiles to a rule such as: ```prolog isa(X, union([a, b])) :- p(X, _). ``` Membership in a named member class may entail membership in the union: ```prolog isa(X, union([A, B])) :- isa(X, A). isa(X, union([A, B])) :- isa(X, B). ``` The reverse implication is invalid. #### Example Normalized Turtle shape: ```turtle radlex:Anterior_to rdfs:domain [ a owl:Class ; owl:unionOf ( radlex:RID13218 radlex:RID13230 radlex:RID13389 radlex:RID50364 ) ] . ``` Prolog rule shape: ```prolog isa( X, union([rid13218, rid13230, rid13389, rid50364]) ) :- anterior_to(X, _). ``` #### Formal translation ```text domain(P) = C₁ ∪ C₂ ∪ ... ∪ Cₙ ──────────────────────────────── P(x,y) → isa(x, union([C₁,C₂,...,Cₙ])) ``` For range, the same rule applies to the second relation argument. #### Entails / does not entail ```text ENTAILS isa(x, union([A,B])) DOES NOT ENTAIL isa(x,A) isa(x,B) ``` --- ### 3.6 Relation Specialization (`rdfs:subPropertyOf`) #### Upstream meaning A subproperty assertion means every occurrence of the specialized relation is also an occurrence of the more general relation. RadLex 4.3 uses 12 such declarations. Examples include: ```text Regional_Part_Of ⊆ Part_Of Constitutional_Part_Of ⊆ Part_Of Segment_Of ⊆ Part_Of Branch_Part_of ⊆ Regional_Part_Of Branch_Of ⊆ Continuous_With Tributary_Of ⊆ Continuous_With Drains_Into ⊆ Sends_Output_To ``` #### Ontology and application interpretation ```text RADLEX ONTOLOGY ──────────────────────────────────────────────────────── regional_part_of ⊆ part_of Every assertion of the specialized relation also satisfies the more general relation. APPLICATION MODEL ──────────────────────────────────────────────────────── regional_part_of(a,b). Therefore: part_of(a,b). This derivation does not create a new application individual. ``` #### Translation decision Because the relation vocabulary is fixed, subproperty declarations may compile to explicit Prolog implication rules rather than generic runtime metaprogramming. #### Example Turtle: ```turtle radlex:Regional_Part_Of rdfs:subPropertyOf radlex:Part_Of . ``` Prolog: ```prolog part_of(X, Y) :- regional_part_of(X, Y). ``` The corresponding class-level existential implication is valid in the same direction: ```prolog some_relation(C, part_of, D) :- some_relation(C, regional_part_of, D). ``` #### Formal translation ```text P ⊆ Q P(x,y) ──────── Q(x,y) ``` and for existential class restrictions: ```text C ⊆ ∃ P.D P ⊆ Q ──────────────────── C ⊆ ∃ Q.D ``` --- ### 3.7 Inverse Relations (`owl:inverseOf`) #### Upstream meaning RadLex explicitly declares 19 inverse relation pairs. If P and Q are inverses: ```text P(x,y) ↔ Q(y,x) ``` #### Fixed inverse table ```text Attaches_to ↔ Receives_attachment_from Blood_Supply_of ↔ Has_Blood_Supply Bounded_by ↔ Bounds Branch_Of ↔ Has_Branch Branch_Part_of ↔ Has_Branch_Part Constitutional_Part_Of ↔ Has_Constitutional_Part Contained_In ↔ Contains Drains_Into ↔ Receives_Drainage_From Has_Innervation_Source ↔ Innervates Has_Member ↔ Member_Of Has_Part ↔ Part_Of Has_Regional_Part ↔ Regional_Part_Of Has_insertion ↔ Insertion_of Has_origin ↔ Origin_of Lymphatic_Drainage ↔ Lymphatic_Drainage_Of May_Be_Caused_By ↔ May_Cause Projects_To ↔ Receives_Projection_From Receives_Input_From ↔ Sends_Output_To Surrounded_by ↔ Surrounds ``` #### Ontology and application interpretation ```text RADLEX ONTOLOGY ──────────────────────────────────────────────────────── part_of and has_part are inverse relations. This specifies the relation algebra itself. APPLICATION MODEL ──────────────────────────────────────────────────────── part_of(a,b) The inverse relation therefore establishes: has_part(b,a) Both relation assertions refer to the same two concrete individuals. The inverse inference does not introduce an application individual. ``` #### Translation decision The compiler uses explicit, fixed translation cases for these 19 pairs. It does not implement a general mechanism that attempts to invert arbitrary ontology expressions. For individual relations: ```prolog has_part(Y, X) :- part_of(X, Y). part_of(X, Y) :- has_part(Y, X). ``` **Critical limit:** inversion of an individual relation does not justify naïvely flipping an existential class restriction. From: ```text A ⊆ ∃ part_of.B ``` we may **not** infer: ```text B ⊆ ∃ has_part.A ``` because “every A is part of some B” does not mean “every B has some A.” If RadLex asserts both directions at the class level, each source axiom is compiled independently. #### Formal translation ```text inverse(P,Q) P(x,y) ──────────── Q(y,x) ``` and symmetrically for Q. --- ### 3.8 Class/Individual Punning #### Empirical finding RadLex 4.3 declares 24,092 `owl:NamedIndividual` resources. Every observed `owl:NamedIndividual` resource is also declared as an `owl:Class`, and the observed individual declarations contain no independent population of domain individuals. This is treated as OWL encoding machinery rather than domain knowledge required by the target ontology. #### Translation decision The compiler **discards the duplicated individual interpretation** and represents each RID once in the ontology class/concept layer. ```text RADLEX SOURCE ──────────────────────────────────────────────────────── RID29662 is declared as an owl:Class. RID29662 is also presented through the punned owl:NamedIndividual pattern. PROLOG TARGET ──────────────────────────────────────────────────────── class(rid29662). source_uri(rid29662, 'http://www.radlex.org/RID/RID29662'). ``` The compiler MUST validate this assumption against the source being compiled. If a future RadLex source contains an axiom whose meaning depends materially on the individual interpretation of a punned RID, compilation MUST fail with an explicit unsupported-construct diagnostic rather than silently discarding that meaning. #### Non-consequences Discarding punning does not mean that downstream applications cannot contain individuals. Application individuals are created by application evidence and logic, not by the duplicated ontology identity pattern in the RadLex OWL serialization. ### 3.9 Partial Functions (`owl:FunctionalProperty`) RadLex declares exactly two object properties as `owl:FunctionalProperty`: ```text http://www.radlex.org/RID/Segment_Of http://www.radlex.org/RID/Tributary_Of ``` The source names are therefore `Segment_Of` and `Tributary_Of`, and their exact RadLex URIs MUST remain recoverable from the generated ontology. #### Upstream meaning OWL functionality means that a relation is single-valued in its second argument for each first argument: ```text P(x,y₁) ∧ P(x,y₂) → y₁ = y₂ ``` Mathematically, this is the behavior of a **partial function**: ```text P : X ⇸ Y ``` The function is partial because OWL functionality does not require every `x` to have a `P`-successor. It is not necessarily injective because distinct subjects may have the same object. #### Translation decision The compiler translates an `owl:FunctionalProperty` declaration to an explicit proposition that the RadLex relation is a partial function: ```prolog partial_function(segment_of). partial_function(tributary_of). ``` The readable relation atom MUST be connected to its exact upstream identity, for example: ```prolog relation_uri(segment_of, 'http://www.radlex.org/RID/Segment_Of'). relation_uri(tributary_of, 'http://www.radlex.org/RID/Tributary_Of'). ``` The precise name of the source-identity predicate may vary with the compiler's general provenance representation; preservation of the URI is normative. #### Formal translation rule ```text P rdf:type owl:FunctionalProperty ────────────────────────────────── P ⟹RL partial_function(P) ``` with semantic interpretation: ```text partial_function(P) P(x,y₁) ∧ P(x,y₂) ────────────────── y₁ = y₂ ``` #### Non-consequences `partial_function(P)` does **not** entail that: - `P` is total; - `P` is injective; - `P` is bijective; - the compiler must implement equality merging; - multiple observed fillers should be rejected as a database uniqueness error; or - an application must adopt any particular identity-resolution policy. The compiler's responsibility is to preserve the logical proposition. Downstream reasoning systems may build equality, validation, reconciliation, or other machinery around it as their use cases require. ### 3.10 Compiler/Application Semantic Boundary The compiler produces general RadLex ontology knowledge. It does not define the facts of a particular patient, image, report, specimen, or other application world. This boundary matters most for existential class relationships. For example: ```text right_kidney ⊆ ∃ contained_in.right_retroperitoneal_compartment ``` means that RadLex characterizes the class `right_kidney` using an existential `contained_in` relationship. The compiler preserves that class-level proposition. It does **not** produce: ```prolog contained_in(k1, invented_compartment). ``` for some downstream `k1`, because no concrete witness exists in the source ontology. #### Normative compiler rule > **The compiler MUST preserve general ontology propositions but MUST NOT convert them into case-specific assertions about application individuals.** A downstream application may independently identify concrete referents from its own evidence. It may then consult the compiled ontology to expose relevant class hierarchy and relation knowledge about the concepts involved. Whether that application performs only semantic enrichment, clinical inference, validation, or some other reasoning task is outside the compiler specification. For example, if an application independently identifies both a kidney referent and a retroperitoneal-compartment referent, the ontology may expose to that application that the identified classes participate in the RadLex relationship: ```text kidney-class context contained_in some retroperitoneal-compartment-class ``` The ontology alone does not establish that the particular kidney referent is contained in the particular compartment referent. A case-specific assertion requires application evidence or application-specific reasoning beyond the compiler. #### Compiler non-responsibilities The compiler does not specify: - how transcript mentions become application entities; - whether an application uses open-world or closed-world reasoning; - whether an application performs clinical inference; - how an application resolves identity or coreference; - when an application may assert a relationship between two concrete referents; or - how an application serializes enriched evidence for an LLM or another consumer. Those concerns belong to downstream application specifications. ### 3.11 Lexical and Documentary Knowledge RadLex is also a terminology source. These annotations are not logical class axioms, but they are first-class compiler output because the initial application goal is anatomical term recognition. Representative target predicates: ```prolog label(Class, Language, preferred, Text). label(Class, Language, synonym, Text). acronym(Class, Language, Text). definition(Class, Text). xref(Class, ExternalIdentifier). source(Class, Source). ``` Source strings should be preserved exactly. Matching normalization—case folding, punctuation handling, Unicode normalization, token/span normalization—belongs in a separate lexical index or application-facing layer, not in the ontology compiler's source-preserving facts. Example: ```prolog label(rid205, en, preferred, "kidney"). label(rid205, de, synonym, "Niere"). label(rid205, la, synonym, "ren"). ``` The ontology identity remains the RID; strings are lexical evidence pointing to it. --- ### 3.12 Unused `Term_type` Annotation-Schema Datatype RadLex 4.3 declares an annotation property: ```text http://www.radlex.org/RID/Term_type ``` whose range is the datatype: ```text http://www.radlex.org/RID/Range_val_one_of_Term_type ``` That datatype is defined by the only observed `owl:equivalentClass` + `owl:oneOf` construct in the ontology and enumerates four literal strings: ```text abbreviation anatomical clinical proper ``` This is terminology-schema metadata, not medical class logic. A source scan found no populated `<RID:Term_type>` annotations in `RadLex.owl`; the property is declared but unused in this RadLex 4.3 source. #### Translation decision The compiler does not introduce general OWL class-equivalence or enumeration machinery solely for this declaration. If annotation-schema metadata is retained, a narrow representation is sufficient, for example: ```prolog annotation_property(term_type). annotation_value_set( term_type, [abbreviation, anatomical, clinical, proper] ). ``` The exact upstream URI MUST remain recoverable if the declaration is emitted. Because no populated uses occur in RadLex 4.3, no application behavior or medical inference may depend on this construct. An implementation MAY omit this unused schema declaration from the primary generated ontology if the compiler's source-metadata/provenance output records that omission explicitly. It MUST NOT treat the construct as anatomical or clinical class knowledge. ### 3.13 Representative End-to-End Fragment This fragment illustrates the intended overall feel of the generated ontology. #### Source meaning ```text right_kidney ⊆ kidney right_kidney ⊆ ∃ contained_in.right_retroperitoneal_compartment regional_part_of ⊆ part_of part_of(x,y) ↔ has_part(y,x) ``` #### Generated ontology ```prolog class(rid205). class(rid29662). class(rid29541). label(rid205, en, preferred, "kidney"). label(rid29662, en, preferred, "right kidney"). subclass(rid29662, rid205). some_relation( rid29662, contained_in, rid29541 ). part_of(X, Y) :- regional_part_of(X, Y). has_part(Y, X) :- part_of(X, Y). part_of(X, Y) :- has_part(Y, X). ``` #### Downstream boundary (non-normative illustration) A downstream application may independently establish a concrete referent and associate it with `rid29662`. The compiled ontology then provides the class hierarchy and class-level existential relationship as available background knowledge. The compiler itself does not create that referent, does not decide which ontology consequences the application should materialize, and does not fabricate a `rid29541` individual to satisfy the existential restriction. Those choices belong to the downstream application specification. --- ## 4. Reference Appendices ### 4.1 RadLex 4.3 Inverse Relation Table | Relation | Inverse | |---|---| | `Attaches_to` | `Receives_attachment_from` | | `Blood_Supply_of` | `Has_Blood_Supply` | | `Bounded_by` | `Bounds` | | `Branch_Of` | `Has_Branch` | | `Branch_Part_of` | `Has_Branch_Part` | | `Constitutional_Part_Of` | `Has_Constitutional_Part` | | `Contained_In` | `Contains` | | `Drains_Into` | `Receives_Drainage_From` | | `Has_Innervation_Source` | `Innervates` | | `Has_Member` | `Member_Of` | | `Has_Part` | `Part_Of` | | `Has_Regional_Part` | `Regional_Part_Of` | | `Has_insertion` | `Insertion_of` | | `Has_origin` | `Origin_of` | | `Lymphatic_Drainage` | `Lymphatic_Drainage_Of` | | `May_Be_Caused_By` | `May_Cause` | | `Projects_To` | `Receives_Projection_From` | | `Receives_Input_From` | `Sends_Output_To` | | `Surrounded_by` | `Surrounds` | ### 4.2 RadLex 4.3 Subproperty Table | Specialized relation | More general relation | |---|---| | `Branch_Of` | `Continuous_With` | | `Branch_Part_of` | `Regional_Part_Of` | | `Constitutional_Part_Of` | `Part_Of` | | `Drains_Into` | `Sends_Output_To` | | `Has_Branch` | `Continuous_With` | | `Has_Branch_Part` | `Has_Regional_Part` | | `Has_Constitutional_Part` | `Has_Part` | | `Has_Regional_Part` | `Has_Part` | | `Receives_Drainage_From` | `Receives_Input_From` | | `Regional_Part_Of` | `Part_Of` | | `Segment_Of` | `Part_Of` | | `Tributary_Of` | `Continuous_With` | --- ### 4.3 Design Summary ```text KEEP THE MODEL ──────────────────────────────────────────────────────── classes class inclusion existential class relationships relation specialization inverse relation semantics domain/range implications union class expressions functional semantics (pending exact representation) lexical/documentary knowledge provenance COMPILE AWAY THE ENCODING ──────────────────────────────────────────────────────── RDF/XML syntax blank restriction nodes RDF list plumbing URI verbosity owl:Restriction wrapper structure class/individual punning, if final validation confirms no loss other serialization-only machinery KEEP THE WORLDS SEPARATE ──────────────────────────────────────────────────────── RadLex ontology: abstract class theory Application model: concrete closed world of this execution ``` --- ## Appendix D. Design Conversation and Prompt Provenance This appendix records selected parts of the human–AI design conversation that produced this specification. It is non-normative. Its purpose is to preserve design provenance and to provide a teaching record for reviewing how short prompts, objections, corrections, empirical questions, and formalization requests changed the resulting specification. The authorship represented here is genuinely collaborative. In particular, the human co-author repeatedly supplied the decisive conceptual correction when the discussion drifted toward a representation that was convenient but semantically weaker, broader, or less precise than the intended compiler. Those interventions are credited explicitly below rather than being retrospectively presented as conclusions reached by the assistant alone. This is a curated design record rather than a complete transcript. Text identified as **Original author input** is quoted only when the wording survives reliably in the available conversation record. Where the exact wording is unavailable, the entry is labeled **Context summary** and does not purport to reconstruct a quotation. ### D.1 Separating RadLex from the proposed Prolog representation **Context summary — human-led correction** The human co-author objected when an explanation of RadLex used hypothetical Prolog as though it were the source representation. The objection established that an explanation must distinguish what RadLex literally contains from the logical meaning of that source and from our proposed compilation target. **Resulting specification principle** The project now maintains three explicit representational levels: 1. the actual RadLex OWL/RDF source; 2. the logical meaning of that source; and 3. the Prolog representation selected by this compiler. **Prompt-engineering observation** This was initially a correction to explanatory presentation, but it exposed a deeper specification error: source syntax, semantics, and target syntax had been conflated. A useful prompt need not prescribe the solution. Identifying a category error can force a better architecture. ### D.2 Reframing the project as a compiler over the RadLex dialect **Context summary — human-led direction** The human co-author emphasized that the implementation is a fixed compiler for RadLex rather than a general-purpose OWL grammar or OWL reasoner. Because the source ontology exercises a small, empirically discoverable fragment of OWL, the compiler can recognize and translate those forms explicitly. **Resulting specification principle** The supported language is defined by the OWL/RDFS constructs actually exercised by RadLex 4.3. Unsupported constructs must produce diagnostics rather than trigger speculative generalization. **Prompt-engineering observation** Narrowing the problem was productive rather than restrictive. The correction replaced an open-ended language-design problem with a finite compiler specification that can be tested against a known corpus. ### D.3 Preserving RadLex while removing OWL/RDF machinery **Context summary — jointly developed, with human direction on scope** The discussion converged on treating RadLex itself as a strong domain model while treating much of its RDF/OWL surface representation as compilation machinery that the target application does not need. **Resulting specification principle** > Preserve RadLex's meaning; compile away OWL/RDF's representational machinery. The purpose of the project is not to simplify or redesign RadLex's domain model. It is to expose it in a representation that is explicit and useful to the application. **Prompt-engineering observation** A strong design prompt often supplies a criterion rather than a list of implementation instructions. The preservation criterion gives later decisions a common test: does a proposed simplification remove encoding machinery, or does it remove a logical commitment? ### D.4 Existential restrictions without invented application individuals **Original author input** > “we know the class that shows where a kidney is, but we don't claim to have a member of that class on hand.” **Context summary — human-led semantic clarification** This formulation clarified the intended treatment of `owl:someValuesFrom`. RadLex can specify that every member of one class participates in a relation to some member of another class without supplying a concrete member of the filler class to the current application execution. **Resulting specification principle** An axiom of the form `C ⊆ ∃ P.D` compiles to class-level knowledge such as `some_relation(C,P,D)`. Compilation does not Skolemize the filler and does not manufacture an application individual merely to satisfy the existential commitment. **Prompt-engineering observation** The effective move here was to restate formal semantics in concrete ontological language. The phrase “on hand” made the distinction between existential commitment and available application evidence immediately operational. ### D.5 Separating the ontology from application-world policy **Context summary — human-led direction, subsequently refined** The human co-author pushed against treating the entire Prolog program as a closed-world reinterpretation of RadLex. The key architectural correction was that RadLex remains abstract class-level knowledge, while questions about concrete individuals and case-specific facts belong to downstream applications. The conversation initially discussed a closed-world application model. Later discussion refined the point further: the compiler should not prescribe the downstream application's open-world or closed-world policy at all. **Resulting specification principle** The compiler preserves RadLex's ontology commitments without creating concrete application individuals or defining application-world inference policy. The stricter final boundary is recorded in D.10 and Section 3.10. **Prompt-engineering observation** This intervention improved the specification by locating a policy at the correct architectural boundary. Asking *which layer owns this assumption?* can be more valuable than debating the assumption in the abstract. ### D.6 Representing unions without destroying the disjunction **Context summary — human-selected target representation** The human co-author preferred representing a union class expression directly in Prolog, for example `isa(X, union([a,b]))`, rather than compiling it into either member class or hiding the disjunction behind a representation that suggested more knowledge than RadLex provides. **Resulting specification principle** `isa(X, union([A,B]))` preserves the proposition that `X` belongs to `A ∪ B`. It does not entail `isa(X,A)` or `isa(X,B)` individually. **Prompt-engineering observation** The important contribution was not merely syntactic preference. Choosing a representation that visibly retains uncertainty makes an invalid downstream inference harder to write accidentally. Representation can enforce epistemic discipline. ### D.7 Treating punning as a hypothesis to test rather than semantics to inherit **Original author input** > “some kind of garbage” **Context summary — human challenge followed by empirical verification** The phrase referred to the apparent class/individual punning in the RadLex OWL representation. Rather than accepting the OWL construct as necessarily meaningful domain semantics, the human co-author challenged us to determine whether it carried information that the compiler actually needed. The subsequent source inventory found 24,092 `owl:NamedIndividual` resources; every one is also a class, and the observed individual declarations contain no independent population of domain individuals. **Resulting specification decision** The compiler discards the duplicated individual interpretation and represents each RID once in the ontology class/concept layer. This is now normative. A validation pass remains mandatory: if a future source axiom depends materially on the punned individual interpretation, the compiler must fail explicitly rather than silently weaken the ontology. **Prompt-engineering observation** The productive pattern was **skepticism → empirical question → corpus measurement → guarded design decision**. The initial pushback was informal, but it led to a stronger specification because the response was not to rationalize the source representation; it was to inspect the ontology. ### D.8 Rejecting naïve inversion of existential class restrictions **Context summary — jointly reasoned, with human insistence on explicit fixed cases** The discussion distinguished inversion of a concrete binary relation from inversion of an existential class restriction. If `P` and `Q` are inverse properties, `P(x,y)` supports `Q(y,x)` for the same individuals. However, `A ⊆ ∃ P.B` does not imply `B ⊆ ∃ Q.A`. The human co-author also emphasized that the compiler has a fixed relation vocabulary. With only 19 inverse pairs in RadLex 4.3, explicit compiler cases are preferable to an unnecessarily general inversion mechanism. **Resulting specification principle** Concrete inverse-relation rules are compiled explicitly. Existential class restrictions are not mechanically reversed. **Prompt-engineering observation** This illustrates two useful interventions at once: test a seemingly symmetric transformation against its quantifiers, and use the actual size of the source language to resist needless abstraction. ### D.9 Translating OWL functionality into the mathematical object it denotes **Context summary — human-led naming correction followed by joint formalization** RadLex declares `Segment_Of` and `Tributary_Of` as `owl:FunctionalProperty`. The discussion first clarified that OWL functionality means “at most one object per subject,” not one-to-one correspondence, totality, or injectivity. The human co-author then rejected the vague target name `functional_relation/1` and proposed naming the preserved proposition for the mathematical object it actually denotes: a partial function. **Resulting specification decision** `owl:FunctionalProperty` compiles to `partial_function(P)`. The generated ontology preserves the exact upstream RadLex relation URI. The compiler records the single-valued logical commitment but does not implement equality merging or application-level uniqueness policy. **Prompt-engineering observation** The useful pattern was **terminology challenge → mathematical clarification → better target vocabulary**. Naming the target construct by its semantics rather than by OWL jargon made the intended meaning substantially harder to misread. ### D.10 Separating ontological enrichment from case-specific inference **Context summary — human-led scope correction** The discussion initially treated the ontology/application boundary as a general question about which ontology entailments should become application facts. The human co-author narrowed the actual use case: the planned transcript application is concerned with ontological enrichment, not diagnosis or reconstruction of the patient's physical state. A kidney mentioned in a transcript could, in principle, be an isolated specimen rather than a kidney in the anatomical location normally described by RadLex. The human co-author then added the complementary case: when two referents are independently identified from the transcript, exposing the relevant RadLex relationship between their identified classes is precisely the kind of context that is useful to an LLM. What must not happen is silently converting that class-level context into an assertion that those two particular referents stand in the relation. **Resulting specification decision** The compiler preserves general ontology propositions and never manufactures case-specific individuals or assertions. Downstream applications may use the ontology to enrich independently established referents, but application evidence or application-specific reasoning is required before a relationship is asserted between particular referents. Clinical reasoning remains a possible future layer, not a responsibility of the compiler. **Short original formulation** > “enrich the doctor's language; do not enrich the patient.” **Prompt-engineering observation** A concrete counterexample changed an abstract inference-policy discussion into a clean architectural boundary. The strongest part of the correction was not a new implementation rule; it was a sharper statement of what kind of knowledge the system is allowed to claim. ### D.11 Defining Technical Preview as a historical pre-design artifact **Context summary — human-defined document semantics** The human co-author supplied a specific meaning for **Technical Preview**: a pre-design sketch that records the problem, priorities, constraints, proposed architecture, responsibilities, exclusions, and especially the open questions that must be resolved before coding. Once those questions are resolved, the decisions belong in the specification; the preview remains a historical artifact rather than being rewritten to look prescient. **Resulting documentation principle** The current document is a specification. Decisions are recorded here as they become normative, while earlier exploratory artifacts retain their historical role. **Prompt-engineering observation** Defining the epistemic status of a document prevents exploratory suggestions from quietly becoming commitments. Prompting can govern not only *what* is written but also what authority a piece of writing is allowed to have. ### D.12 Requiring Standard Written English in explanatory prose **Original author input** > “SWE is standard written english btw not software engineering” **Context summary — human editorial correction** The human co-author had already objected to telegraphic, question-and-answer-style specification prose and requested proper SWE. The clarification established that SWE meant **Standard Written English**, not software engineering. The requested standard is complete declarative and conditional prose with explicit subjects, objects, and relationships. Formal notation may remain terse because its terseness is part of the notation; explanatory prose should not imitate slide-deck fragments. **Resulting editorial principle** The specification uses Standard Written English for explanatory material and reserves compressed syntax for actual formal rules, code, tables, and other structures in which compression is semantically useful. **Prompt-engineering observation** Small editorial corrections can affect technical precision. Replacing fragments such as “No compartment established?” with explicit conditional sentences forces the author to state the condition, actor, scope, and consequence rather than leaving those relationships implicit. ### D.13 Reorganizing the information architecture around conceptual levels **Original author input** > “Vision is top Level, all the technical intro bably is top level and then the survey of decisions and translation rules is top level, inside of that we have all of those” **Context summary — human-led structural correction** The earlier draft promoted nearly every construct to the same heading level. The human co-author identified that this flattened the conceptual architecture of the specification. The document was reorganized around four top-level sections: Vision, Technical Introduction, Survey of Decisions and Translation Rules, and Reference Appendices. The detailed construct-by-construct rules now live beneath the survey rather than competing with it. The human co-author then further constrained the table of contents to those four top-level entries. **Resulting documentation principle** Document hierarchy should express conceptual hierarchy. Navigation should expose the major intellectual divisions of the specification rather than enumerate every subsection merely because it exists. **Prompt-engineering observation** This is an example of directing an AI at the level of information architecture rather than line editing. The correction supplied a model of the hierarchy, allowing many local formatting decisions to follow from one structural instruction. ### D.14 A recurring pattern in the collaboration Across these exchanges, several of the most consequential human inputs were short. Their value came from identifying the exact assumption that had gone wrong rather than from supplying a long replacement answer. A recurring pattern was: ```text assistant proposes or explains a model ↓ human identifies a semantic or structural mismatch ↓ the mismatch is restated as a precise distinction ↓ source data or formal semantics are checked where necessary ↓ the distinction becomes an invariant, translation rule, or open decision ↓ the specification is revised so the correction applies globally ``` Examples include: - a presentation objection becoming the source/meaning/target distinction; - an intuitive description of existential knowledge becoming the no-witness-materialization rule; - skepticism about punning becoming an empirical validation requirement; - a preference for `union([...])` becoming preservation of disjunctive knowledge; - a concern about inverse relations becoming a quantified non-inference rule; - a closed-world intuition becoming an explicit ontology/application boundary; - a documentation complaint becoming an information-architecture rule; and - a prose correction becoming a Standard Written English requirement. The broader prompt-engineering lesson is that effective collaboration with a language model is often less about constructing a single comprehensive prompt than about **maintaining control of the conceptual model through precise corrective feedback**. A short pushback can be high leverage when it identifies which distinction, invariant, scope boundary, or evidentiary claim must change. ### D.15 Provenance limits This appendix intentionally distinguishes quotations from summaries. The available working record preserves several original phrases and a detailed history of the design decisions, but it does not provide a complete verbatim transcript of every earlier exchange. No reconstructed sentence is presented as a quotation. A future edition may expand this appendix if a complete conversation export becomes available. Such an expansion should preserve the same distinction between verbatim input, contextual summary, resulting specification change, and retrospective prompt-engineering analysis.