Standards work is slow: mailing lists, issue threads, and meetings where a single property name can take three sessions. So the fair question is why I spend so much of my time on it instead of writing code people can use tomorrow.
The honest answer is that I want RDF to cover a broad range of use cases. Not the range it covers well today, but the range people actually show up with. What keeps that range narrow comes from several directions: tools that don’t exist, habits in the community, and specifications. Not every specification limits anything, but some are written in a particular mindset, and that mindset is very hard to fix afterwards.
The Discussion That Made Me Write This
The W3C Data Shapes Working Group recently discussed how open SHACL UI should be. I listed a use case there: SHACL UI running on a smartwatch. It was questioned by others in the discussion.
That reaction is a regular pattern in the RDF world, and it’s well-meant. The concern behind it is that a specification promising everything might end up implemented by nobody. I rarely share that fear, and in my experience it usually doesn’t play out that way, unless a specification gets lost in details.
But notice what the reflex does: it answers a scoping question with a verdict. “Is that really a use case for this specification?” instead of “what would this specification need so that use case fits?” The first can only end in yes or no, and a no lives in a meeting log, so the person goes and solves their problem elsewhere. The second usually ends somewhere more useful, with a subset, a profile, or a small addition that makes the use case fit.
Covering A to M
People arrive with a problem and want their use cases covered from A to Z. The range is abstract, and I’m deliberately not putting a percentage on it, because then we’d argue about the number instead of the point. You show them RDF, and RDF covers A to M, better than anything else for that part of the range. For the rest, the answer is some combination of “out of scope”, “different specification”, and “that’s not really an RDF use case”.
JSON covers A to Z. It covers parts of it badly, with hand-written mappings and keys that mean different things in different services. But it covers the whole range, and it never tells anyone their problem is the wrong problem. So the real choice is not “RDF versus JSON on technical merit”, it’s “covers everything with extra work” versus “covers part of it perfectly”. Framed that way, picking the universal tool is the obvious call.
The Wrong Question
The question should not be: does my use case work with RDF? It should be: which RDF specifications, tools, and profiles do I need for my use case? The first has a yes/no answer, and every “no” is someone lost. The second assumes yes and moves straight to scoping, a conversation where nobody has to lose.
The scoping questions are concrete. Which serialization, and does this need a triplestore or is a file, a database column, or a JSON payload with a context enough? Which part of SHACL, core constraints, rules, or UI? Which profile of that specification is enough for my target, and which library implements it?
Today most of those answers exist as folklore, learned by asking the right person in the right working group. That follows from the same gap: once a use case reaches past what the specifications cover, the answer has to be put together outside them, and what gets built outside a specification rarely finds its way back into one. The answer to a use case should be a shopping list, not a verdict.
Semantics for the Agentic World
RDF is designed for exactly the problem the AI world is running into right now: multiple services stating that they mean the same field, not because their labels match but because they share an identifier. The models are not the bottleneck, they read and write Turtle, N-Triples, and JSON-LD without trouble. The standards being built around them are JSON all the way down: MCP is JSON-RPC with JSON Schema tool definitions, tool and function calling schemas are JSON Schema, structured output is JSON Schema. That layer is taking shape right now, and while it’s still moving, it won’t move forever, so this is a good moment to have something to offer.
JSON-LD can bridge the two worlds, and it will have to. But why wasn’t RDF the obvious choice for problems that are literally about describing what data means across service boundaries? Not because those people are hostile to semantics. Because they found A to M plus homework next to A to Z available today, and nobody handed them the shopping list either.
Profiles Instead of Verdicts
The comfortable explanation for all this is that the tooling isn’t there, which is true and fixable. The other part is the habit of sorting use cases into “that’s RDF” and “that’s not”. Every single instance is defensible, but the cumulative effect is a technology that is excellent at a narrowing set of problems and absent everywhere else.
I want RDF everywhere, without the complexity burden that some RDF-related specifications require, and those two wishes only conflict if every implementation must support every feature. So: cover the full range, and when that would burden the typical use case, don’t drop the coverage, scope it with profiles.
A profile is a defined subset of a specification, not a per-device flavour of RDF. A constrained implementation declares which profile it implements, a full one declares everything, and both are conformant without an asterisk. That turns “no” into “yes, this one”, and it lets the people worried about scope creep say yes without abandoning their concern: it becomes a profile boundary instead of a rejected use case, and a boundary in a specification is enforceable while a verdict in a meeting is not. A specification implementable at three sizes reaches three kinds of developer. One implementable at a single size reaches the people who already agreed with us.
As I described in Bringing Semantics to Closed-World Systems, it’s rarely one or the other. Usually it’s about where systems meet.
A Form on a Watch
The watch stands for the far end of the range: a small target, running the smallest profile of the specification, still conformant. If the minimal useful subset of SHACL UI can render a small form there, the specification scales across the whole range. Before answering that it can’t, it’s worth looking a bit further ahead. The world moves fast, and the use cases that show up two years from now are the ones a specification written today has to survive. If a use case is still out of scope after that look, no is a legitimate answer.
The use case underneath isn’t really about watches. An agent needs more details from a user and already has a shape describing what it’s missing. Instead of a bespoke JSON blob and renderer per client, it hands over the shape, and whatever is in front of the user renders it: a web page, a chat client, a terminal, a watch. The semantics travel with the request, so the next service matches on the identifier, not on a label.
And here’s the constraint I think matters most: rendering and processing that form has to work with a minimal runtime, not a full validation engine. A shape arriving from an agent is untrusted input, and a full engine brings SPARQL-based constraints and other extension points with it. That’s machinery you don’t want to execute for a stranger who sent you a form to fill in. A small, well-understood feature set is a small attack surface, and the mundane reason points the same way: the thing in front of the user can’t ship a full engine just to ask for three fields.
Same specification, different profiles of it, very different targets. That’s why the question of how open SHACL UI should be isn’t a detail.
Why I Work on RDF Standards
Libraries can be rewritten and documentation improved next week. The assumptions baked into a specification, about who will implement it, at what size, and for which use cases, outlive all of that.
As a member of the W3C Data Shapes Working Group, what I try to contribute is the perspective that isn’t in the room: the developer with 64KB of RAM, or the team building an agent that needs semantics but has never heard of a triplestore.
So that’s the whole ask: when a use case sounds unusual, ask what the specification would need for it to fit before asking whether it belongs. It costs one question, and often the answer is a profile somebody was going to need anyway.