Got tired of waiting for RDF1.2 to finalize as a spec, got fed up with the Java tools, needed something higher-performance in Rust that I could also use from Python and WASM.

PurrRDF was born. It's not quite a full rdflib replacement for Python, but it has built-in ShACL and ShEx for validation and speaks all the common variants. I'm spinning this out of a larger project that's building a full RDF1.2 Rust tool stack - it runs, it's fast and probably useful to anyone building high-performance RDF1.2/RDF* knowledge graphs (if you are, you'll know the pain!)

Comments, feedback, test cases, etc. welcome: https://github.com/Blackcat-Informatics/purrdf/

I’m looking for serious feedback and, ideally, a research collaborator from the Semantic Web / KG / ontology engineering community.

I’m finalizing a paper currently titled:

“An LLM Output Is a Claim, Not a Truth: A Substrate for Grounded Agent Memory”

The paper is built around GMEOW — the Global Metadata and Entity Ontology for the Web:

https://blackcatinformatics.ca/gmeow

The basic thesis is that if AI agents are going to reason over real personal, organizational, scientific, and institutional memory, model output should not be represented as truth. It should be represented as a claim: attributed, time-scoped, provenance-bearing, confidence-bearing, and open to contradiction.

GMEOW is the implemented artifact behind the paper. It is an OWL 2 DL / RDF ontology intended as a reasoning-centric upper layer for modelling digital existence: documents, contracts, people, organizations, observations, measurements, rights, identity, provenance, and contested facts.

The paper covers:

• statement-level provenance / RDF-star-style claim modelling
• standpoint-indexed facts
• contradiction-as-standpoint rather than contradiction-as-error
• suppression-based belief revision
• the “claim spine” as a substrate for grounded agent memory
• SSSOM mappings to adjacent vocabularies such as FOAF, schema.org, PROV-O, BFO, QUDT, SOSA/SSN, GeoSPARQL, ODRL, SPDX, etc.
• using a published ontology artifact, reasoned closures, mappings, and validation outputs as the basis for a research article

A full working draft exists — serious respondents get it same-day.

The practical hurdle: I’m an independent industry researcher, not currently inside an academic institution, and I do not yet have the relevant arXiv endorsement route for the likely CS categories.

I am not asking for a rubber-stamp endorsement.

I’m looking for someone with real expertise in Semantic Web, knowledge graphs, ontology engineering, provenance, KR, database theory, or AI agent memory who would be willing to review the argument, challenge the framing, help strengthen the paper, and — if there is genuine intellectual contribution and fit — potentially co-author or help route it appropriately.

I’d also welcome blunt technical feedback from this community:

• Is the “LLM output as claim, not truth” framing strong enough?
• Are standpoint-indexed claims the right way to model contradiction in agent memory?
• What prior work should this absolutely engage with?
• Is there a better venue than arXiv-first for this kind of ontology-plus-position artifact?

Thanks — pointers, criticism, and introductions are all welcome.

I have been running a multi-agent setup for a while now and this repo is the product of my frustrations and pain, enjoy!

Note: this is heavily opinionated and slanted towards Python and Golang at the moment but it's in active development and I'm taking requests 😄

https://github.com/paudley/coding-ethos

What is coding-ethos?

It's a framework that turns your engineering principles (defined in a single coding_ethos.yml file) into runnable repository policy. From that one file, it automatically generates and syncs:

• Agent instructions (GEMINI.md, CLAUDE.md, prompt add-ons)
• Static-analysis configs (Ruff, Pyright, golangci-lint, etc.)
• Git hooks (compiled Go preflight checks)
• Agent tool-use guards
• An MCP (Model Context Protocol) server
• Remediation "skills" (playbooks for the AI to fix its own mistakes)

Why it's a game-changer for Gemini CLI

coding-ethos has native, deep integration for Gemini. Here is how it supercharges your terminal agent workflow:

• Native Configuration Sync: Run make generate or uv run coding-ethos --sync-gemini-prompts and it automatically updates your .gemini/settings.json and generates Gemini prompt packs (.code-ethos/gemini/prompt-pack.json) perfectly grounded in your repo's specific rules.
• Agent Tool-Use Guards: It sets up an "Agent Hook Runtime" specifically for Gemini. If Gemini tries to bypass standard workflows (like running raw git commands instead of a protected wrapper, or tampering with hook binaries), the hook strictly blocks the tool use and returns a decision: "deny" with a system message guiding Gemini back to the right path.
• Built-in MCP Server: It exposes a local stdio MCP server backed by your compiled policy. Instead of Gemini guessing why a file failed, it can call tools like:
  • lint_check: Safely runs linters and normalizes the output.
  • policy_explain: Explains why a policy exists based on your ethos.
  • skill_lookup / skill_recommend: Recommends actionable "skills" (like agent-operating-discipline or conditional-imports) so Gemini knows exactly how to fix the code.
• Defense in Depth: The same engine that tells Gemini the rules in GEMINI.md is the exact same engine evaluating the CEL expressions and Go policies at the Git hook level. They cannot drift.

Quick Example Workflow

You define a rule in coding_ethos.yml that all critical operations must go through one path.

1. It generates a markdown reminder in GEMINI.md.
2. Gemini attempts to write a raw subprocess.run(["git", "commit"]) in a Python file.
3. The pre-commit hook catches it using a typed CEL expression policy.
4. Instead of just throwing a generic exit code 1, the hook feeds Gemini a compact skill_id hint (e.g., safe-git-workflow) and an MCP next-step action.
5. Gemini uses the MCP server to look up the skill playbook and correctly rewrites the code using your protected Git wrapper.

If you are tired of wrangling prompt files, linter configs, and agent guardrails separately, check it out. It forces your AI agents and your CI/CD pipelines to finally speak the exact same language.

Let me know what you think or if you have any questions about the implementation (especially the Go hook runtime or CEL policy engine)!