wazootech-wiki 0.1.0__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (35) hide show
  1. wazootech_wiki-0.1.0/PKG-INFO +477 -0
  2. wazootech_wiki-0.1.0/README.md +463 -0
  3. wazootech_wiki-0.1.0/pyproject.toml +25 -0
  4. wazootech_wiki-0.1.0/setup.cfg +4 -0
  5. wazootech_wiki-0.1.0/src/llm_wiki/__init__.py +5 -0
  6. wazootech_wiki-0.1.0/src/llm_wiki/__main__.py +5 -0
  7. wazootech_wiki-0.1.0/src/llm_wiki/audit.py +306 -0
  8. wazootech_wiki-0.1.0/src/llm_wiki/cli.py +395 -0
  9. wazootech_wiki-0.1.0/src/llm_wiki/config.py +152 -0
  10. wazootech_wiki-0.1.0/src/llm_wiki/format.py +168 -0
  11. wazootech_wiki-0.1.0/src/llm_wiki/format_choice.py +97 -0
  12. wazootech_wiki-0.1.0/src/llm_wiki/graph.py +391 -0
  13. wazootech_wiki-0.1.0/src/llm_wiki/infer.py +22 -0
  14. wazootech_wiki-0.1.0/src/llm_wiki/jqfilter.py +79 -0
  15. wazootech_wiki-0.1.0/src/llm_wiki/parser.py +91 -0
  16. wazootech_wiki-0.1.0/src/llm_wiki/render.py +71 -0
  17. wazootech_wiki-0.1.0/src/llm_wiki/serve.py +214 -0
  18. wazootech_wiki-0.1.0/src/llm_wiki/site.py +347 -0
  19. wazootech_wiki-0.1.0/src/mdit_py_plugins/__init__.py +1 -0
  20. wazootech_wiki-0.1.0/src/mdit_py_plugins/wikilink.py +52 -0
  21. wazootech_wiki-0.1.0/src/wazootech_wiki.egg-info/PKG-INFO +477 -0
  22. wazootech_wiki-0.1.0/src/wazootech_wiki.egg-info/SOURCES.txt +33 -0
  23. wazootech_wiki-0.1.0/src/wazootech_wiki.egg-info/dependency_links.txt +1 -0
  24. wazootech_wiki-0.1.0/src/wazootech_wiki.egg-info/entry_points.txt +2 -0
  25. wazootech_wiki-0.1.0/src/wazootech_wiki.egg-info/requires.txt +7 -0
  26. wazootech_wiki-0.1.0/src/wazootech_wiki.egg-info/top_level.txt +2 -0
  27. wazootech_wiki-0.1.0/tests/test_audit.py +213 -0
  28. wazootech_wiki-0.1.0/tests/test_cli.py +804 -0
  29. wazootech_wiki-0.1.0/tests/test_config.py +105 -0
  30. wazootech_wiki-0.1.0/tests/test_format_choice.py +170 -0
  31. wazootech_wiki-0.1.0/tests/test_graph.py +470 -0
  32. wazootech_wiki-0.1.0/tests/test_infer.py +52 -0
  33. wazootech_wiki-0.1.0/tests/test_jqfilter.py +58 -0
  34. wazootech_wiki-0.1.0/tests/test_parser.py +112 -0
  35. wazootech_wiki-0.1.0/tests/test_serve.py +232 -0
@@ -0,0 +1,477 @@
1
+ Metadata-Version: 2.4
2
+ Name: wazootech-wiki
3
+ Version: 0.1.0
4
+ Summary: Clean, pure, idiomatic Python CLI for managing a semantic LLM wiki
5
+ Requires-Python: >=3.12
6
+ Description-Content-Type: text/markdown
7
+ Requires-Dist: click>=8.1.7
8
+ Requires-Dist: rdflib>=7.0.0
9
+ Requires-Dist: pyshacl>=0.25.0
10
+ Requires-Dist: pyyaml>=6.0.1
11
+ Requires-Dist: owlrl>=6.0.2
12
+ Requires-Dist: beautifulsoup4>=4.14.3
13
+ Requires-Dist: markdown-it-py>=3.0.0
14
+
15
+ # LLM Wiki (`wazootech-wiki`)
16
+
17
+ An elegant, pure, and idiomatic Python command-line interface for managing a semantic knowledge base of markdown documents with SHACL validation and SPARQL reasoning.
18
+
19
+ Repository: [github.com/wazootech/llm-wiki](https://github.com/wazootech/llm-wiki). PyPI package: `wazootech-wiki`. CLI command: `wiki`.
20
+
21
+ Starter template repo: [github.com/wazootech/llm-wiki-template](https://github.com/wazootech/llm-wiki-template) (use GitHub’s “Use this template” button).
22
+
23
+ ## Key features
24
+ - **Modern Packaging**: Configured cleanly with standard `pyproject.toml` optimized for `uv` or `pip`.
25
+ - **Pure Python CLI**: Comprehensive command suite — `check`, `query`, `render`, `build`, `serve`, `export`.
26
+ - **Flexible Frontmatter Parsing**: Supports YAML and JSON frontmatter blocks with standard triple-dash `---` boundaries.
27
+ - **RDF Context Support**: Supports JSON-LD `@context` style namespace, prefix mappings, and settings.
28
+ - **Deductive Reasoning**: Full OWL-RL deductive reasoning expansion powered by `owlrl`.
29
+ - **SHACL Validation**: Rich conformance testing of markdown files against loaded shapes powered by `pyshacl` with JSON and text reporting.
30
+ - **Dynamic SPARQL Rendering**: Scan and execute embedded SPARQL query blocks in markdown files, injecting updated results back into the documents inline.
31
+
32
+ ## Installation
33
+
34
+ ### From PyPI
35
+
36
+ ```bash
37
+ pip install wazootech-wiki
38
+ ```
39
+
40
+ ### From within this repo (editable)
41
+
42
+ ```bash
43
+ # Using uv (fastest)
44
+ uv pip install -e .
45
+
46
+ # Using standard pip
47
+ pip install -e .
48
+ ```
49
+
50
+ ### Global install (use from any directory)
51
+
52
+ ```bash
53
+ # From the repo root
54
+ uv pip install -e /path/to/llm-wiki
55
+ ```
56
+
57
+ Once installed globally, the `wiki` command is available in any directory that has a `wiki.yaml` configuration file. You can also point to a config explicitly with `-c <path>`.
58
+
59
+ ## Quickstart
60
+
61
+ ```bash
62
+ mkdir my-wiki
63
+ cd my-wiki
64
+
65
+ # Interactive scaffold: creates wiki.yaml and wiki/ starter files
66
+ wiki init
67
+
68
+ # Run unified checks (silent on success)
69
+ wiki check
70
+
71
+ # Start a local server (default: http://127.0.0.1:8080/wiki/)
72
+ wiki serve
73
+ ```
74
+
75
+ ## Subcommand guide
76
+
77
+
78
+ ### `check`
79
+ Perform unified validations of your wiki, including strict SHACL schema validations and soft style/hygiene audits (kebab-case filenames, broken internal wikilinks). Under the "silence is golden" philosophy, `check` exits silently with code 0 on success.
80
+
81
+ ```bash
82
+ # Run unified checks on the entire wiki silently (default)
83
+ wiki check
84
+
85
+ # Check a single file specifically
86
+ wiki check wiki/gregory.md
87
+
88
+ # Autofix hygiene issues (rename non-kebab-case files + update wikilinks)
89
+ wiki check --fix
90
+
91
+ # Run with verbose output to show style/guideline warnings
92
+ wiki check -v
93
+
94
+ # Run in strict mode (warnings become errors and fail with non-zero exit code)
95
+ wiki check --strict
96
+ ```
97
+
98
+ ### `query`
99
+ Execute any SPARQL SELECT or CONSTRUCT query against the loaded and reasoning-expanded RDF graph.
100
+
101
+ ```bash
102
+ # Execute direct query string and output as ASCII table
103
+ wiki query "SELECT ?s ?p ?o WHERE { ?s ?p ?o } LIMIT 10"
104
+
105
+ # Query and output as Turtle (for CONSTRUCT queries)
106
+ wiki query "CONSTRUCT { ?s ?p ?o } WHERE { ?s ?p ?o }" -f turtle
107
+
108
+ # Run query from stdin and write results to a file
109
+ cat my_query.sparql | wiki query -f markdown -o results.md
110
+
111
+ # Extract specific fields from JSON output (automatically selects -f json)
112
+ wiki query "SELECT ?name WHERE { ?s schema:name ?name }" --jq 'results.bindings[].name.value'
113
+ ```
114
+
115
+ ### `render`
116
+ Identify all embedded SPARQL blocks in your markdown files, run their queries against the reasoning-expanded RDF graph, and replace the outputs inline. Under the "silence is golden" Unix philosophy, this command exits silently with code 0 upon success.
117
+
118
+ ```bash
119
+ # Render silently (default)
120
+ wiki render
121
+
122
+ # Render with verbose summary output
123
+ wiki render -v
124
+
125
+ # Check if any files are stale without modifying them (non-zero exit on stale)
126
+ wiki render --check
127
+ ```
128
+
129
+ An embedded SPARQL block is defined in your markdown files like this:
130
+ ````html
131
+ <!-- sparql:start -->
132
+ ```sparql
133
+ SELECT ?name ?email WHERE {
134
+ ?person a schema:Person ;
135
+ schema:name ?name ;
136
+ schema:email ?email .
137
+ }
138
+ ```
139
+
140
+ | Name | Email |
141
+ | --- | --- |
142
+ | Gregory | gregory@example.com |
143
+ <!-- sparql:end -->
144
+ ````
145
+
146
+ ### `build`
147
+ Generate a static HTML site from your wiki markdown files for deployment to GitHub Pages or any static host.
148
+
149
+ ```bash
150
+ # Build site (default: <slug>.html style)
151
+ wiki build
152
+
153
+ # Build with pretty directory URLs (<slug>/index.html)
154
+ wiki build --url-style dir
155
+
156
+ # Build to a custom directory with verbose output
157
+ wiki build --output-dir docs -v
158
+
159
+ # Build for a project site under /my-wiki/
160
+ wiki build --base-url /my-wiki --output-dir _site
161
+
162
+ # Build with pages at root level (no prefix)
163
+ wiki build --base-url '' --output-dir docs
164
+
165
+ # Automatically update all dynamic SPARQL blocks in source files before building
166
+ wiki build --render
167
+ ```
168
+
169
+ The `--url-style` flag controls how pages are written to disk and linked:
170
+
171
+ - `file` (default): `_site/wiki/alice.html` on disk, `.html` in generated links
172
+ - `dir`: `_site/wiki/alice/index.html` on disk, clean `/wiki/alice` in links
173
+
174
+ The `--base-url` flag controls the URL prefix for wiki pages. Default is `/wiki`, so pages are accessible at `/wiki/{slug}`. Set it to an empty string for root-level URLs.
175
+
176
+ Output structure (default `--base-url /wiki` + `--url-style file`):
177
+ ```
178
+ _site/
179
+ └── wiki/
180
+ ├── index.html # Wiki index at /wiki/
181
+ ├── alice.html # Page at /wiki/alice.html
182
+ ├── bob.html
183
+ └── bob/
184
+ └── early-life.html # H2 section at /wiki/bob/early-life.html
185
+ ```
186
+
187
+ With `--url-style dir`:
188
+ ```
189
+ _site/
190
+ └── wiki/
191
+ ├── index.html # Wiki index at /wiki/
192
+ ├── alice/
193
+ │ └── index.html # Page at /wiki/alice
194
+ ├── bob/
195
+ │ └── index.html
196
+ └── bob/
197
+ └── early-life/
198
+ └── index.html # H2 section at /wiki/bob/early-life
199
+ ```
200
+
201
+ With `--base-url /my-wiki` + `--url-style dir`:
202
+ ```
203
+ _site/
204
+ └── my-wiki/
205
+ ├── index.html # Wiki index at /my-wiki/
206
+ ├── alice/
207
+ │ └── index.html # Page at /my-wiki/alice
208
+ └── ...
209
+ ```
210
+
211
+ #### GitHub Pages deployment
212
+
213
+ Create `.github/workflows/deploy-pages.yml` in your wiki repository:
214
+
215
+ ```yaml
216
+ name: Deploy Wiki to Pages
217
+
218
+ on:
219
+ push:
220
+ branches: ["main"]
221
+ workflow_dispatch:
222
+
223
+ permissions:
224
+ contents: read
225
+ pages: write
226
+ id-token: write
227
+
228
+ concurrency:
229
+ group: "pages"
230
+ cancel-in-progress: false
231
+
232
+ jobs:
233
+ deploy:
234
+ environment:
235
+ name: github-pages
236
+ url: ${{ steps.deployment.outputs.page_url }}
237
+ runs-on: ubuntu-latest
238
+ steps:
239
+ - name: Checkout Repository
240
+ uses: actions/checkout@v4
241
+
242
+ - name: Set up Python 3.12
243
+ uses: actions/setup-python@v5
244
+ with:
245
+ python-version: "3.12"
246
+
247
+ - name: Set up uv
248
+ uses: astral-sh/setup-uv@v5
249
+ with:
250
+ enable-cache: true
251
+
252
+ - name: Install Dependencies
253
+ run: uv sync
254
+
255
+ - name: Run Docs Wiki Style and SHACL Audits
256
+ run: uv run wiki -c docs/wiki.json check --strict -v
257
+
258
+ - name: Build Static Site
259
+ run: uv run wiki -c docs/wiki.json build --output-dir _site --base-url /llm-wiki
260
+
261
+ - name: Upload Pages Artifact
262
+ uses: actions/upload-pages-artifact@v3
263
+ with:
264
+ path: "_site/llm-wiki"
265
+
266
+ - name: Deploy to GitHub Pages
267
+ id: deployment
268
+ uses: actions/deploy-pages@v4
269
+ ```
270
+
271
+ Then enable **GitHub Pages > Source: GitHub Actions** in your repo settings.
272
+
273
+ ### `serve`
274
+ Start a local development HTTP server that renders wiki markdown files as HTML (wikilinks, backlinks, ToC included). Uses the same rendering engine as `build` but serves pages on-the-fly without writing files to disk.
275
+
276
+ ```bash
277
+ # Default: http://127.0.0.1:8080
278
+ wiki serve
279
+
280
+ # Custom host and port
281
+ wiki serve --host 0.0.0.0 --port 3000
282
+
283
+ # Watch wiki files and auto-reload the browser on rebuild
284
+ wiki serve --watch
285
+ ```
286
+
287
+ ### `init`
288
+ Interactively scaffold a new wiki workspace (`wiki.yaml` + starter `wiki/` content) in the current directory.
289
+
290
+ ```bash
291
+ wiki init
292
+ ```
293
+
294
+ ### `export`
295
+ Compile and export parsed **Frontmatter** blocks of documents in a supported RDF format.
296
+
297
+ When run without a file argument, exports all documents in the wiki directory.
298
+
299
+ **Note:** When using the default `dict` format or `json-ld`, each file's output is wrapped in a JSON object with `name` (the filename) and `rdf` (the content). For raw RDF formats (`turtle`, `xml`, `n3`, `nt`, `trig`, `nquads`), single-file export outputs raw serialized RDF directly (no JSON wrapper). Multi-file bulk export with raw formats still uses the JSON wrapper for structure.
300
+
301
+ ```bash
302
+ # Export parsed frontmatter of the entire wiki as dict (default)
303
+ wiki export
304
+
305
+ # Export a single file
306
+ wiki export wiki/gregory.md
307
+
308
+ # Export as expanded JSON-LD
309
+ wiki export wiki/rdf.md -f json-ld
310
+
311
+ # Export in other RDF formats (turtle, xml, n3, nt, trig, nquads)
312
+ wiki export wiki/rdf.md -f turtle
313
+
314
+ # Write to a file
315
+ wiki export -f json-ld -o wiki-export.json
316
+ ```
317
+
318
+
319
+ ### Global options
320
+
321
+ These flags can be used on any subcommand:
322
+
323
+ | Option | Description |
324
+ |---|---|
325
+ | `-c, --config <path>` | Path to `wiki.yaml` config file or directory containing one (default: `.`) |
326
+ | `--input-dir <path>` | Directory containing wiki markdown files or RDF data files (can be repeated) |
327
+
328
+ ### Printing and piping
329
+ Following the Unix philosophy of pipes and filters, `wiki` works seamlessly with native system utilities. Outputs from query execution or document inspection can be easily formatted and spooled directly to your printer.
330
+
331
+ #### Unix/macOS
332
+ * **Format and Print a Document:**
333
+ Use `pr` to add headers, margins, and page numbers before sending to `lp`:
334
+ ```bash
335
+ cat wiki/gregory.md | pr -h "Gregory Document" | lp
336
+ ```
337
+ * **Format and Print Query Results:**
338
+ Run a query and print its tabular results:
339
+ ```bash
340
+ wiki query "SELECT ?s ?p WHERE { ?s ?p ?o }" | pr -h "SPARQL Graph Query" | lp
341
+ ```
342
+
343
+ #### Windows
344
+ * **Print a Document:**
345
+ ```powershell
346
+ Get-Content wiki/gregory.md | Out-Printer
347
+ ```
348
+ * **Print Query Results:**
349
+ ```powershell
350
+ wiki query "SELECT ?s ?p WHERE { ?s ?p ?o }" | Out-Printer
351
+ ```
352
+
353
+ ### Obsidian integration
354
+
355
+ While the LLM Wiki CLI operates as a standalone tool, it pairs naturally with Obsidian. You can seamlessly trigger operations directly from within your vault using the **Shell Commands** community plugin.
356
+
357
+ Recommended workflows:
358
+ * **Check on save**: Bind `wiki check` to execute whenever a file is modified to receive instant feedback on SHACL validations and formatting.
359
+ * **Trigger re-rendering**: Map a hotkey or command palette item to `wiki render` to automatically update all dynamic SPARQL blocks in the vault.
360
+
361
+ ### Declarative modeling & full-text SPARQL
362
+
363
+ The LLM Wiki CLI natively turns your folder of Markdown files into an active logical ontology and validation graph.
364
+
365
+ #### Defining OWL classes and SHACL shapes recursively in frontmatter
366
+ Because our frontmatter parser natively supports nested dictionary conversion to RDF blank nodes, you can define complete validation shapes and ontological classes inside any document's frontmatter:
367
+
368
+ ```yaml
369
+ # wiki/dog-shape.md
370
+ ---
371
+ id: wiki:DogShape
372
+ type: sh:NodeShape
373
+ sh:targetClass: wiki:Dog
374
+ sh:property:
375
+ sh:path: schema:name
376
+ sh:datatype: xsd:string
377
+ sh:minCount: 1
378
+ ---
379
+
380
+ # Dog Shape
381
+ Requires that all `wiki:Dog` documents must declare a name.
382
+ ```
383
+
384
+ #### Native microdata via HTML attributes
385
+ You are not limited to YAML headers! For rich semantic embedding directly inside your content flow, you can simply use standard **HTML5 Microdata** (`itemscope`, `itemtype`, `itemprop`) anywhere in your markdown body. The CLI parses the DOM tree via `BeautifulSoup` and injects assertions natively into the graph pool.
386
+
387
+ ````markdown
388
+ # Product X Overview
389
+ Product X is state-of-the-art.
390
+
391
+ <div itemscope itemtype="https://schema.org/Product">
392
+ Our latest model is the <span itemprop="name">Quantum Processor X</span>.
393
+
394
+ <div itemprop="offers" itemscope itemtype="https://schema.org/Offer">
395
+ Price: <span itemprop="price">999.99</span>
396
+ Currency: <meta itemprop="priceCurrency" content="USD" />
397
+ </div>
398
+ </div>
399
+ ````
400
+
401
+ #### Decentralized OWL inference
402
+ Because the tool integrates a full `owlrl` engine over the entire wiki graph, you can scatter ontological rules across disparate markdown pages and the CLI will automatically compute the logical closure.
403
+
404
+ Define a class hierarchy inside a shape file:
405
+ ```yaml
406
+ # wiki/engineer-definition.md
407
+ ---
408
+ id: wiki:Engineer
409
+ type: owl:Class
410
+ rdfs:subClassOf: schema:Person
411
+ ---
412
+ # Engineer
413
+ An Engineer is a specialized subset of Person.
414
+ ```
415
+
416
+ Declare an instance somewhere else:
417
+ ```yaml
418
+ # wiki/gregory.md
419
+ ---
420
+ id: wiki:gregory
421
+ type: wiki:Engineer
422
+ name: Gregory
423
+ ---
424
+ ```
425
+
426
+ When you run queries, the reasoner **automatically infers** the implicit connection:
427
+ ```sparql
428
+ # This returns Gregory, even though his type is "Engineer", NOT "Person"!
429
+ SELECT ?name WHERE {
430
+ ?entity a schema:Person ;
431
+ schema:name ?name .
432
+ }
433
+ ```
434
+
435
+ #### Opt-in full-text SPARQL over markdown content
436
+ By enabling `contentPredicate` in your `wiki.yaml`, the unstructured markdown body (everything after the frontmatter) is automatically loaded as a literal under your configured predicate (e.g. `schema:text`). This allows you to perform hybrid logical and full-text searches inside a single SPARQL query:
437
+
438
+ ```sparql
439
+ PREFIX schema: <https://schema.org/>
440
+
441
+ SELECT ?doc ?content WHERE {
442
+ ?doc a wiki:Dog ;
443
+ schema:text ?content .
444
+ FILTER(CONTAINS(LCASE(?content), "swimming"))
445
+ }
446
+ ```
447
+
448
+ ## Workspace configuration (`WikiConfig`)
449
+
450
+ The CLI automatically detects and loads configurations from `wiki.yaml`, `wiki.yml`, or `wiki.json` in your current working directory. The configuration file holds CLI parameters and custom checking severities, with an embedded `@context` or `context` block defining prefix mappings:
451
+
452
+ ```yaml
453
+ # wiki.yaml
454
+ inputDirs:
455
+ - wiki
456
+ contentPredicate: schema:text # Opt-in full-text markdown body auto-injection
457
+
458
+ check:
459
+ filenameStyle: warning # "error" | "warning" | "off"
460
+ internalLinks: warning # "error" | "warning" | "off"
461
+
462
+ context:
463
+ schema: https://schema.org/
464
+ wiki: https://book.etok.me/wiki/
465
+ foaf: http://xmlns.com/foaf/0.1/
466
+ ```
467
+
468
+ ## Glossary and decisions
469
+ To understand the domain terminology (such as **Wiki**, **Document**, **Context**, **Validation**, and **Shape**), please refer to:
470
+ * [CONTEXT.md](https://github.com/wazootech/llm-wiki/blob/main/CONTEXT.md) — Glossary and Domain Model mapping.
471
+ * [0001-context-centric-configuration.md](https://github.com/wazootech/llm-wiki/blob/main/docs/adr/0001-context-centric-configuration.md) — Architectural Decision Record (ADR) on context naming.
472
+ * [0002-userland-printing.md](https://github.com/wazootech/llm-wiki/blob/main/docs/adr/0002-userland-printing.md) — Architectural Decision Record (ADR) on adopting userland printing filters.
473
+ * [0003-silence-is-golden.md](https://github.com/wazootech/llm-wiki/blob/main/docs/adr/0003-silence-is-golden.md) — Architectural Decision Record (ADR) on silent default behaviors.
474
+ * [0004-unified-check-and-wikiconfig.md](https://github.com/wazootech/llm-wiki/blob/main/docs/adr/0004-unified-check-and-wikiconfig.md) — Architectural Decision Record (ADR) on unified check command and WikiConfig.
475
+ * [0005-streamlined-cli-architecture.md](https://github.com/wazootech/llm-wiki/blob/main/docs/adr/0005-streamlined-cli-architecture.md) — Architectural Decision Record (ADR) on streamlined CLI architecture.
476
+
477
+