eyelang 0.5.1 → 0.5.2

package/tools/README.md

@@ -1,10 +1,10 @@
 # RDF round-trip tools
 
-These tools translate RDF files into ordinary EyeLang and queried `rdf/4`
+These tools translate RDF files into ordinary Eyelang and queried `rdf/4`
 facts back into RDF 1.2 N-Quads. Input formats are selected automatically from
 the file extension. Supported inputs include RDF 1.2 Turtle, TriG, N-Triples,
 N-Quads and RDF/XML, plus JSON-LD, RDFa, Microdata, Notation3 and SHACL Compact
-Syntax. EyeLang remains RDF-agnostic.
+Syntax. Eyelang remains RDF-agnostic.
 
 ```bash
 node tools/rdf-to-pl.mjs --rules rules.pl data.nq -o program.pl

package/tools/extract-book-examples.mjs

@@ -48,11 +48,11 @@ for (const match of book.matchAll(/^(## \d+\. ([^\n]+)|# ([^\n]+)|```eyelang\n([
 
 const files = new Map();
 const readme = [
-  '# The Art of EyeLang — inline examples',
+  '# The Art of Eyelang — inline examples',
   '',
   'These files are generated from the complete `eyelang` code blocks in',
-  '[The Art of EyeLang](../../the-art-of-eyelang.md). They are grouped by chapter and',
-  'retain the source text from the book. Goal fragments and non-EyeLang blocks are',
+  '[The Art of Eyelang](../../the-art-of-eyelang.md). They are grouped by chapter and',
+  'retain the source text from the book. Goal fragments and non-Eyelang blocks are',
   'not extracted.',
   '',
   'Regenerate them from the repository root with:',
@@ -79,7 +79,7 @@ for (const item of chapters) {
     const heading = example.section ? ` — ${example.section}` : '';
     files.set(
       relative,
-      `% From The Art of EyeLang, Chapter ${item.number}${heading}.\n${example.source}\n`,
+      `% From The Art of Eyelang, Chapter ${item.number}${heading}.\n${example.source}\n`,
     );
     readme.push(`- [${filename}](${relative})${heading}`);
     total += 1;

package/tools/pl-to-rdf.mjs

@@ -6,7 +6,7 @@ import { fileURLToPath } from 'node:url';
 import { Program } from '../src/program.js';
 import { eyeLangQuadToNQuad } from './rdf-codec.mjs';
 
-export function extractEyeLangRdf(source) {
+export function extractEyelangRdf(source) {
   const program = Program.parse(String(source), { sourceMetadata: false });
   const lines = []; const seen = new Set();
   for (const c of program.clauses) {
@@ -20,7 +20,7 @@ async function main(argv) {
   let input = '-'; let output = '-';
   for (let i = 0; i < argv.length; i++) { const a = argv[i]; if (a === '-h' || a === '--help') return usage(); if (a === '-o' || a === '--output') output = required(argv, ++i, a); else if (a.startsWith('-') && a !== '-') throw new Error(`unknown option: ${a}`); else if (input === '-') input = a; else throw new Error(`unexpected argument: ${a}`); }
   const source = input === '-' ? await stdin() : await fs.readFile(input, 'utf8');
-  const result = extractEyeLangRdf(source);
+  const result = extractEyelangRdf(source);
   if (output === '-') process.stdout.write(result); else await fs.writeFile(output, result);
 }
 function usage() { process.stdout.write('Usage: node tools/pl-to-rdf.mjs [options] [input.pl|-]\n\n  -o, --output FILE  Write N-Quads to FILE\n'); }

package/tools/rdf-codec.mjs

@@ -1,4 +1,4 @@
-// Lossless RDF 1.2 <-> ordinary EyeLang term encoding.
+// Lossless RDF 1.2 <-> ordinary Eyelang term encoding.
 export const XSD_STRING = 'http://www.w3.org/2001/XMLSchema#string';
 export const RDF_LANG_STRING = 'http://www.w3.org/1999/02/22-rdf-syntax-ns#langString';
 export const RDF_DIR_LANG_STRING = 'http://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString';
@@ -170,15 +170,15 @@ export function fromRdfJs(term, scope = 'input') {
   throw new Error(`unsupported RDF/JS term type: ${term.termType}`);
 }
 
-export function quadToEyeLang(q, predicate = 'rdf') {
-  return `${predicate}(${toEyeLang(q.subject)}, ${toEyeLang(q.predicate)}, ${toEyeLang(q.object)}, ${toEyeLang(q.graph)}).`;
+export function quadToEyelang(q, predicate = 'rdf') {
+  return `${predicate}(${toEyelang(q.subject)}, ${toEyelang(q.predicate)}, ${toEyelang(q.object)}, ${toEyelang(q.graph)}).`;
 }
 
-export function toEyeLang(t) {
+export function toEyelang(t) {
   if (t.kind === 'namedNode') return `iri(${quote(t.value)})`;
   if (t.kind === 'blankNode') return `bnode(${quote(t.scope)}, ${quote(t.value)})`;
   if (t.kind === 'defaultGraph') return 'default_graph';
-  if (t.kind === 'triple') return `triple(${toEyeLang(t.subject)}, ${toEyeLang(t.predicate)}, ${toEyeLang(t.object)})`;
+  if (t.kind === 'triple') return `triple(${toEyelang(t.subject)}, ${toEyelang(t.predicate)}, ${toEyelang(t.object)})`;
   if (t.kind === 'literal') {
     const annotation = t.language
       ? (t.direction ? `lang(${quote(t.language)}, ${t.direction})` : `lang(${quote(t.language)})`)
@@ -190,18 +190,18 @@ export function toEyeLang(t) {
 
 export function eyeLangQuadToNQuad(term) {
   if (term?.type !== 'compound' || term.name !== 'rdf' || term.args.length !== 4) throw new Error('expected rdf/4 fact');
-  const [subject, predicate, object, graph] = term.args.map(fromEyeLang);
+  const [subject, predicate, object, graph] = term.args.map(fromEyelang);
   assertTriple(subject, predicate, object);
   if (!['namedNode', 'blankNode', 'defaultGraph'].includes(graph.kind)) throw new Error('invalid RDF graph');
   return `${toNQ(subject)} ${toNQ(predicate)} ${toNQ(object)}${graph.kind === 'defaultGraph' ? '' : ` ${toNQ(graph)}`} .`;
 }
 
-export function fromEyeLang(t) {
+export function fromEyelang(t) {
   if (t?.type === 'atom' && t.name === 'default_graph') return { kind: 'defaultGraph' };
   if (compound(t, 'iri', 1)) return { kind: 'namedNode', value: scalar(t.args[0], 'IRI') };
   if (compound(t, 'bnode', 2)) return { kind: 'blankNode', scope: scalar(t.args[0], 'blank-node scope'), value: scalar(t.args[1], 'blank-node label') };
   if (compound(t, 'triple', 3)) {
-    const [subject, predicate, object] = t.args.map(fromEyeLang);
+    const [subject, predicate, object] = t.args.map(fromEyelang);
     assertTriple(subject, predicate, object);
     return { kind: 'triple', subject, predicate, object };
   }

package/tools/rdf-to-pl.mjs

@@ -3,19 +3,19 @@ import fs from 'node:fs/promises';
 import process from 'node:process';
 import path from 'node:path';
 import { fileURLToPath, pathToFileURL } from 'node:url';
-import { parseNQuads, quadToEyeLang } from './rdf-codec.mjs';
+import { parseNQuads, quadToEyelang } from './rdf-codec.mjs';
 import { parseRdf } from './rdf-input.mjs';
 
-export function compileRdfToEyeLang(rdf, { scope = 'input', rules = '', includeSource = false } = {}) {
-  return compileQuadsToEyeLang(parseNQuads(rdf, { scope }), { rules, includeSource });
+export function compileRdfToEyelang(rdf, { scope = 'input', rules = '', includeSource = false } = {}) {
+  return compileQuadsToEyelang(parseNQuads(rdf, { scope }), { rules, includeSource });
 }
-export async function compileRdfDocumentToEyeLang(rdf, { scope = 'input', rules = '', includeSource = false, inputPath, contentType, baseIRI } = {}) {
+export async function compileRdfDocumentToEyelang(rdf, { scope = 'input', rules = '', includeSource = false, inputPath, contentType, baseIRI } = {}) {
   const quads = await parseRdf(rdf, { scope, path: inputPath, contentType, baseIRI });
-  return compileQuadsToEyeLang(quads, { rules, includeSource });
+  return compileQuadsToEyelang(quads, { rules, includeSource });
 }
-export function compileQuadsToEyeLang(quads, { rules = '', includeSource = false } = {}) {
+export function compileQuadsToEyelang(quads, { rules = '', includeSource = false } = {}) {
   const predicate = includeSource ? 'source_rdf' : 'rdf';
-  const facts = quads.map((q) => quadToEyeLang(q, predicate));
+  const facts = quads.map((q) => quadToEyelang(q, predicate));
   const parts = ['% Generated by tools/rdf-to-pl.mjs.', "% Run with: eyelang --goal 'rdf(S, P, O, G)' program.pl."];
   if (includeSource) parts.push('rdf(S, P, O, G) :- source_rdf(S, P, O, G).');
   if (facts.length) parts.push(facts.join('\n'));
@@ -39,7 +39,7 @@ async function main(argv) {
   }
   const rdf = await read(input);
   const rules = rulesFile ? await fs.readFile(rulesFile, 'utf8') : '';
-  const result = await compileRdfDocumentToEyeLang(rdf, {
+  const result = await compileRdfDocumentToEyelang(rdf, {
     scope: scope ?? (input === '-' ? 'stdin' : path.basename(input)), rules, includeSource,
     inputPath: input === '-' ? undefined : input,
     contentType: format,
@@ -47,7 +47,7 @@ async function main(argv) {
   });
   if (output === '-') process.stdout.write(result); else await fs.writeFile(output, result);
 }
-function usage() { process.stdout.write('Usage: node tools/rdf-to-pl.mjs [options] [input|-]\n\n  --format TYPE      RDF media type or extension (required for stdin)\n  --base IRI         Base IRI for relative references\n  --rules FILE       Append EyeLang rules using rdf/4\n  --include-source   Emit source and derived quads\n  --scope NAME       Set blank-node scope\n  -o, --output FILE  Write program to FILE\n'); }
+function usage() { process.stdout.write('Usage: node tools/rdf-to-pl.mjs [options] [input|-]\n\n  --format TYPE      RDF media type or extension (required for stdin)\n  --base IRI         Base IRI for relative references\n  --rules FILE       Append Eyelang rules using rdf/4\n  --include-source   Emit source and derived quads\n  --scope NAME       Set blank-node scope\n  -o, --output FILE  Write program to FILE\n'); }
 function required(a, i, o) { if (a[i] == null) throw new Error(`${o} requires a value`); return a[i]; }
 function read(f) { if (f !== '-') return fs.readFile(f, 'utf8'); return new Promise((resolve, reject) => { let s = ''; process.stdin.setEncoding('utf8'); process.stdin.on('data', (c) => { s += c; }); process.stdin.on('end', () => resolve(s)); process.stdin.on('error', reject); }); }
 if (process.argv[1] && path.resolve(process.argv[1]) === fileURLToPath(import.meta.url)) main(process.argv.slice(2)).catch((e) => { process.stderr.write(`rdf-to-pl: ${e.message}\n`); process.exitCode = 1; });

package/why-eyelang.md

@@ -1,14 +1,14 @@
-# Why EyeLang?
+# Why Eyelang?
 
-EyeLang combines ISO Prolog and W3C RDF 1.2 to turn portable rules and linked data into answers with inspectable proofs.
+Eyelang combines ISO Prolog and W3C RDF 1.2 to turn portable rules and linked data into answers with inspectable proofs.
 
 The name reflects this dual standards foundation: ISO Prolog provides the executable rule language, while RDF provides the interoperable linked-data model.
 
 Its central design choice is **composition rather than invention**: use an established international standard for the rule language, use the Web's standard graph data model, and define the smallest practical bridge between them.
 
-> **EyeLang arguably provides one of the strongest standards-based foundations for Web rules because it combines ISO Prolog as the rule language with the W3C RDF 1.2 data model and defines the missing operational bridge between them—including RDF term mappings, named graphs, triple terms, serialization, querying, and proofs.**
+> **Eyelang arguably provides one of the strongest standards-based foundations for Web rules because it combines ISO Prolog as the rule language with the W3C RDF 1.2 data model and defines the missing operational bridge between them—including RDF term mappings, named graphs, triple terms, serialization, querying, and proofs.**
 
-This is a strong architectural claim, not a claim that the complete EyeLang system is itself an ISO or W3C standard.
+This is a strong architectural claim, not a claim that the complete Eyelang system is itself an ISO or W3C standard.
 
 ## A standards-based foundation for Web rules
 
@@ -16,19 +16,19 @@ A Web rule system needs both a rule language and a data model.
 
 [ISO/IEC 13211-1](https://www.iso.org/standard/21413.html) standardizes the Prolog general core, including its syntax, semantic rules, data representation, input and output, and processor behavior. The standard is intended to promote the portability of Prolog programs and data across processors.
 
-[RDF 1.2](https://www.w3.org/TR/rdf12-concepts/) defines the graph data model used by EyeLang for linked data. It includes IRIs, blank nodes, literals, datasets, named graphs, and triple terms. RDF 1.2 is currently a W3C Candidate Recommendation, while RDF 1.1 remains the latest completed Recommendation.
+[RDF 1.2](https://www.w3.org/TR/rdf12-concepts/) defines the graph data model used by Eyelang for linked data. It includes IRIs, blank nodes, literals, datasets, named graphs, and triple terms. RDF 1.2 is currently a W3C Candidate Recommendation, while RDF 1.1 remains the latest completed Recommendation.
 
-EyeLang brings these foundations together:
+Eyelang brings these foundations together:
 
 - ISO Prolog supplies predicates, clauses, variables, unification, recursion, arithmetic, control, and standard errors.
 - RDF 1.2 supplies globally identified resources and an interoperable graph data model.
-- EyeLang defines lossless mappings between RDF values and Prolog terms.
+- Eyelang defines lossless mappings between RDF values and Prolog terms.
 - RDF files can be converted to ordinary `rdf/4` facts, queried with rules, and serialized back to RDF datasets.
 - Named graphs, the default graph, scoped blank nodes, literals, directional language strings, and nested triple terms remain distinguishable.
 - Derived answers can carry inspectable proofs.
 - The same parser, solver, term model, and proof machinery run from the command line, JavaScript, and the browser.
 
-The exact status wording matters. EyeLang is grounded in a current ISO International Standard and the W3C RDF 1.2 standards track. It should not imply that RDF 1.2 has already completed the W3C Recommendation process.
+The exact status wording matters. Eyelang is grounded in a current ISO International Standard and the W3C RDF 1.2 standards track. It should not imply that RDF 1.2 has already completed the W3C Recommendation process.
 
 ## The missing bridge
 
@@ -52,31 +52,31 @@ RDF does not specify:
 - operational query execution; or
 - proof construction for arbitrary rule derivations.
 
-EyeLang fills that gap with an explicit Prolog–RDF integration profile. The profile belongs to EyeLang's documented and tested behavior; it is not itself an ISO or W3C standard.
+Eyelang fills that gap with an explicit Prolog–RDF integration profile. The profile belongs to Eyelang's documented and tested behavior; it is not itself an ISO or W3C standard.
 
 That limitation should be stated plainly:
 
-> **EyeLang is standards-based, but its Prolog–RDF integration profile has not itself been standardized by ISO or W3C.**
+> **Eyelang is standards-based, but its Prolog–RDF integration profile has not itself been standardized by ISO or W3C.**
 
 ## Why composition matters
 
 A new rule language must establish its own syntax, semantics, implementation model, tooling, teaching material, and interoperability story. It can also become isolated if its original implementation or community disappears.
 
-EyeLang instead composes standards that remain useful independently:
+Eyelang instead composes standards that remain useful independently:
 
 - Prolog programs retain a recognizable logic-programming model.
 - RDF data remains usable by existing RDF processors and Web tooling.
 - Standard constructs keep their standard meanings.
-- EyeLang-specific behavior can be identified, documented, tested, and changed without redefining the language core.
+- Eyelang-specific behavior can be identified, documented, tested, and changed without redefining the language core.
 - The integration boundary is small enough to audit.
 
-This is why removing hidden extensions strengthens EyeLang.
+This is why removing hidden extensions strengthens Eyelang.
 
-For example, `false/0` is the ISO built-in predicate that always fails. EyeLang does not overload clauses headed by `false` as automatically executed inference fuses. Integrity checks are ordinary predicates that the host invokes explicitly. The standardized construct keeps its standardized meaning, and application policy remains visible.
+For example, `false/0` is the ISO built-in predicate that always fails. Eyelang does not overload clauses headed by `false` as automatically executed inference fuses. Integrity checks are ordinary predicates that the host invokes explicitly. The standardized construct keeps its standardized meaning, and application policy remains visible.
 
 The governing design rule is:
 
-> **Standards define the core. EyeLang extensions must be explicit, minimal, documented, and testable.**
+> **Standards define the core. Eyelang extensions must be explicit, minimal, documented, and testable.**
 
 ## Compared with alternatives
 
@@ -95,9 +95,9 @@ That design gives N3 distinctive strengths:
 
 N3 is therefore not merely an RDF serialization with rule syntax added. It offers an integrated model in which data, rules, and quoted graphs belong to the same language.
 
-Its standards position differs from EyeLang's. The W3C N3 Community Group develops language, built-in, and semantics specifications, but Community Group reports are not W3C Standards and are not currently on the W3C Standards Track. N3 also defines a complete logic notation beyond RDF, so interoperability depends on processors agreeing on that additional syntax, semantics, and built-in vocabulary.
+Its standards position differs from Eyelang's. The W3C N3 Community Group develops language, built-in, and semantics specifications, but Community Group reports are not W3C Standards and are not currently on the W3C Standards Track. N3 also defines a complete logic notation beyond RDF, so interoperability depends on processors agreeing on that additional syntax, semantics, and built-in vocabulary.
 
-EyeLang explores a complementary standards architecture:
+Eyelang explores a complementary standards architecture:
 
 - ISO Prolog is the rule language;
 - RDF 1.2 is the external graph data model;
@@ -107,13 +107,13 @@ EyeLang explores a complementary standards architecture:
 
 The trade-off is clear.
 
-N3 is stronger when rules should themselves be Web data, or when quoted formulae and graph-level metareasoning are central. EyeLang is stronger when users want conventional Prolog syntax and semantics, an ISO-defined language core, direct term-level programming, or a sharply separated interface between executable logic and RDF data.
+N3 is stronger when rules should themselves be Web data, or when quoted formulae and graph-level metareasoning are central. Eyelang is stronger when users want conventional Prolog syntax and semantics, an ISO-defined language core, direct term-level programming, or a sharply separated interface between executable logic and RDF data.
 
-The two approaches can interoperate at the language and data-model level. N3 can serve as a Web-native exchange and publication form, while compatible rules or data are translated into EyeLang for ISO-Prolog execution. EyeLang conclusions and proofs can in turn be serialized as RDF or N3.
+The two approaches can interoperate at the language and data-model level. N3 can serve as a Web-native exchange and publication form, while compatible rules or data are translated into Eyelang for ISO-Prolog execution. Eyelang conclusions and proofs can in turn be serialized as RDF or N3.
 
 In brief:
 
-> **Notation3 provides an integrated, Web-native language for data and rules; EyeLang separates an ISO-standard rule language from the RDF data model and makes the bridge explicit.**
+> **Notation3 provides an integrated, Web-native language for data and rules; Eyelang separates an ISO-standard rule language from the RDF data model and makes the bridge explicit.**
 
 ### RIF
 
@@ -126,13 +126,13 @@ RIF therefore has the stronger claim when the requirement is:
 - a normative interchange syntax and semantics; or
 - compatibility defined within one integrated W3C specification family.
 
-EyeLang takes a different architectural approach. It reuses ISO Prolog as the executable rule language and RDF as the data model instead of defining another complete family of rule dialects.
+Eyelang takes a different architectural approach. It reuses ISO Prolog as the executable rule language and RDF as the data model instead of defining another complete family of rule dialects.
 
-That may be more durable for executable Web rules because both foundations are mature and independently useful. The trade-off is that EyeLang's bridge between them is an implementation profile rather than a formally standardized interchange specification.
+That may be more durable for executable Web rules because both foundations are mature and independently useful. The trade-off is that Eyelang's bridge between them is an implementation profile rather than a formally standardized interchange specification.
 
 In brief:
 
-> **RIF is stronger as a standardized interchange framework; EyeLang may be stronger as a small executable architecture built by composing existing standards.**
+> **RIF is stronger as a standardized interchange framework; Eyelang may be stronger as a small executable architecture built by composing existing standards.**
 
 ### SHACL 1.2 Rules
 
@@ -155,26 +155,26 @@ SHACL 1.2 Rules has important advantages:
 - Stratification gives a well-defined outcome for supported rule sets.
 - It is being developed on the W3C Recommendation track.
 
-Its present limitations relative to EyeLang are different rather than absolute:
+Its present limitations relative to Eyelang are different rather than absolute:
 
 - As of August 2026, SHACL 1.2 Rules is a W3C Working Draft, not yet a Recommendation.
 - Its primary abstraction is RDF graph inference, not a general ISO Prolog programming environment.
 - Its rule language and evaluation model are deliberately constrained around RDF triple production.
-- The current specification standardizes inference and query results, but not an EyeLang-style derivation-proof artifact.
-- Applications needing arbitrary Prolog terms, reusable procedural abstractions, standard Prolog control, or direct JavaScript predicate integration may find EyeLang more natural.
+- The current specification standardizes inference and query results, but not an Eyelang-style derivation-proof artifact.
+- Applications needing arbitrary Prolog terms, reusable procedural abstractions, standard Prolog control, or direct JavaScript predicate integration may find Eyelang more natural.
 
 SHACL 1.2 Rules is therefore not merely a competitor. It is also a potential interoperability target.
 
-EyeLang could eventually:
+Eyelang could eventually:
 
 - import a useful SHACL 1.2 Rules profile;
 - export compatible RDF-producing rules where semantics align;
 - execute SHACL-derived rule sets through its RDF mapping; or
-- attach EyeLang proofs to triples inferred from compatible SHACL rules.
+- attach Eyelang proofs to triples inferred from compatible SHACL rules.
 
 The positioning should remain balanced:
 
-> **SHACL 1.2 Rules is stronger as an RDF-native rules specification on the W3C Recommendation track. EyeLang is stronger where applications need an established general-purpose logic language, direct Prolog execution, richer term-level computation, and inspectable derivations.**
+> **SHACL 1.2 Rules is stronger as an RDF-native rules specification on the W3C Recommendation track. Eyelang is stronger where applications need an established general-purpose logic language, direct Prolog execution, richer term-level computation, and inspectable derivations.**
 
 ### SPARQL
 
@@ -182,7 +182,7 @@ The positioning should remain balanced:
 
 SPARQL should be preferred when the task is fundamentally an interoperable RDF query or update.
 
-EyeLang is preferable when the task depends on:
+Eyelang is preferable when the task depends on:
 
 - recursive rules beyond property-path navigation;
 - reusable predicates;
@@ -191,7 +191,7 @@ EyeLang is preferable when the task depends on:
 - rule-level composition; or
 - proof-producing derivations.
 
-The two approaches are complementary. RDF data queried by SPARQL can also be reasoned over by EyeLang, and EyeLang results can be serialized back into RDF.
+The two approaches are complementary. RDF data queried by SPARQL can also be reasoned over by Eyelang, and Eyelang results can be serialized back into RDF.
 
 ### Full Prolog systems
 
@@ -205,7 +205,7 @@ They are preferable when an application needs:
 - mature debugging and development tools; or
 - a complete general-purpose Prolog platform.
 
-EyeLang does not need to compete on feature count. Its distinction is the deliberately small and visible combination of:
+Eyelang does not need to compete on feature count. Its distinction is the deliberately small and visible combination of:
 
 - a tested ISO Prolog core profile;
 - lossless RDF 1.2 term and dataset handling;
@@ -213,7 +213,7 @@ EyeLang does not need to compete on feature count. Its distinction is the delibe
 - JavaScript and browser embedding; and
 - one implementation path across command-line, server, and browser use.
 
-A general Prolog system can provide RDF through libraries. EyeLang makes the Prolog–RDF boundary part of its central language and interoperability story.
+A general Prolog system can provide RDF through libraries. Eyelang makes the Prolog–RDF boundary part of its central language and interoperability story.
 
 ### Custom RDF rule engines
 
@@ -221,33 +221,33 @@ Custom engines can optimize aggressively for one domain, data model, or deployme
 
 Their cost is often a proprietary semantic model.
 
-EyeLang avoids requiring users to adopt an isolated rule language. Its programs begin with recognizable Prolog, and its data begins with recognizable RDF. EyeLang-specific behavior remains concentrated in the bridge between them.
+Eyelang avoids requiring users to adopt an isolated rule language. Its programs begin with recognizable Prolog, and its data begins with recognizable RDF. Eyelang-specific behavior remains concentrated in the bridge between them.
 
-## What EyeLang should claim
+## What Eyelang should claim
 
 A concise positioning statement is:
 
-> **EyeLang combines a conformance-tested ISO Prolog profile with W3C RDF 1.2 linked data, explicit extensions, and inspectable proofs in a lightweight JavaScript implementation.**
+> **Eyelang combines a conformance-tested ISO Prolog profile with W3C RDF 1.2 linked data, explicit extensions, and inspectable proofs in a lightweight JavaScript implementation.**
 
 A stronger comparative statement is:
 
-> **EyeLang arguably provides one of the strongest standards-based foundations for executable Web rules because it composes ISO Prolog and RDF 1.2 instead of introducing another complete rule language.**
+> **Eyelang arguably provides one of the strongest standards-based foundations for executable Web rules because it composes ISO Prolog and RDF 1.2 instead of introducing another complete rule language.**
 
 Both claims require qualifications:
 
-- EyeLang implements a tested ISO compatibility profile; it is not formally certified by ISO.
+- Eyelang implements a tested ISO compatibility profile; it is not formally certified by ISO.
 - RDF 1.2 is currently a W3C Candidate Recommendation.
 - SHACL 1.2 Rules is currently a W3C Working Draft.
-- EyeLang's Prolog–RDF integration profile is not itself an ISO or W3C standard.
-- Proof production is an EyeLang capability, not a feature inherited from ISO Prolog or RDF.
+- Eyelang's Prolog–RDF integration profile is not itself an ISO or W3C standard.
+- Proof production is an Eyelang capability, not a feature inherited from ISO Prolog or RDF.
 
 These qualifications make the standards argument more credible, not less.
 
-## What EyeLang should not become
+## What Eyelang should not become
 
 The standards-based position creates a useful filter for future features.
 
-EyeLang should resist:
+Eyelang should resist:
 
 - silently changing the meaning of ISO predicates;
 - adding advisory syntax that the runtime does not use;
@@ -266,7 +266,7 @@ Syntax or semantics outside those categories should need a strong justification.
 
 ## The durable idea
 
-EyeLang's most important contribution is not a novel rule syntax.
+Eyelang's most important contribution is not a novel rule syntax.
 
 It is the proposition that Web rules can be built by joining two established foundations:
 
@@ -275,9 +275,9 @@ It is the proposition that Web rules can be built by joining two established fou
 
 RIF demonstrates the value of formal rule interchange. SHACL 1.2 Rules demonstrates renewed demand for standardized RDF-native inference. SPARQL demonstrates the value of a shared graph-query language.
 
-EyeLang occupies a complementary position: a small executable system in which standard Prolog rules operate directly over faithfully represented RDF data and produce answers that can be explained.
+Eyelang occupies a complementary position: a small executable system in which standard Prolog rules operate directly over faithfully represented RDF data and produce answers that can be explained.
 
-That is a focused and defensible reason for EyeLang to exist.
+That is a focused and defensible reason for Eyelang to exist.
 
 ## References
 
@@ -289,5 +289,5 @@ That is a focused and defensible reason for EyeLang to exist.
 - [SHACL 1.2 Core](https://www.w3.org/TR/shacl12-core/)
 - [Rule Interchange Format overview](https://www.w3.org/TR/rif-overview/)
 - [SPARQL 1.1 Query Language](https://www.w3.org/TR/sparql11-query/)
-- [The Art of EyeLang](the-art-of-eyelang.md)
-- [EyeLang README](README.md)
+- [The Art of Eyelang](the-art-of-eyelang.md)
+- [Eyelang README](README.md)