Weave what already exists, wikis, databases, APIs, published bundles, so an agent can reason across all of it. And unlike a presentation slide, this one runs.
A deep dive from the Center for Research Computing, and the concrete half of the data-fabric picture.
The group's data-fabric appendix makes the case for a woven integration layer. This page is its concrete half: the machine-readable spine that layer needs, built, published, and queried, with three real participants and a live endpoint.
eco: ontology over 6 standardsEverything below is either running today or marked plainly as pending. Nothing here is a projection. Where the appendix describes an aspiration, this page points at the artifact that realizes it.
A research group already holds its knowledge in many shapes: an llm-wiki as durable memory, a database behind an app, a live API like the Paper Analytical Devices service, published knowledge bundles. Each is useful alone; none can answer a question that spans them, and the classic fix, aggressively merging everything into one heavy content graph, is exactly the fragile, over-committed engineering the vision argues against. Entity resolution breaks, and formal ontologies over-commit provisional structure.
Don't merge the content. Connect the participants.
The fabric adds a thin, structural layer that records what each participant is, what it can answer, who made it, and whether you can trust it, and leaves the meaning inside each source where its own small ontology already lives.
Every plane of the fabric already has a W3C standard. Reusing them buys interoperability and federation for free. The only new vocabulary is a small eco: glue layer for what the standards leave out, and it stays structural: it describes the shape of the ecosystem (participants, capabilities, provenance, trust), never the meaning of any domain.
the eco: glue over composed standards
wasDerivedFrom pinned to a commit.Catalog; a DB or API is a DataService; bundles and pages are Datasets.eco:Capability. Read as a descriptor now; a live-invoke binding later.Each plane maps to an adopted standard, which turns the persuasion diagram into a build spec. It is ledger-free by design, with no blockchain.
The whole of it is 19 classes and 17 properties, every term earned by a competency question. A trimmed excerpt of the real eco.ttl, the shape an agent's discovery tools traverse:
# Participants: anything with a DID that plays in the fabric eco:Connector rdfs:subClassOf eco:Participant , dcat:DataService . # an API / DB, read-only eco:Bundle rdfs:subClassOf eco:Participant , dcat:Dataset . # published knowledge; the ask target eco:Federation rdfs:subClassOf eco:Participant , dcat:Catalog . # a seed catalog peers harvest # Capabilities: what a participant advertises (what fabric_find walks) eco:Capability a owl:Class . eco:hasCapability owl:inverseOf eco:providedBy . eco:hasMaturity rdfs:range eco:Maturity . # only Production is authoritative # Provenance: authority propagates along the chain (what fabric_authority walks) eco:Answer rdfs:subClassOf prov:Entity . # carries a provenance chain + commit pin # a beta node reached via prov:wasDerivedFrom+ taints the synthesis # The trust rule, as controlled vocabulary (SKOS), not code eco:Production a eco:Maturity ; skos:prefLabel "production" . eco:Beta a eco:Maturity ; skos:prefLabel "beta" .
The full ontology dereferences at la3d-llm-agents.github.io/ns/eco.ttl. It types the participants and their trust, and leaves the meaning inside each source with the source.
One "resolution" claim, held to its grain. DIDs retire entity alignment at the participant level, one canonical IRI per bundle or source, so the fabric never reconciles fuzzy concepts.
It does not touch the concept-level amalgam problem that content retrieval faces; that stays the job of the per-source walk. The fabric queries a layer where identity is already given, and never reintroduces the pattern-matching-over-entities the vision set out to avoid.
The fabric decides what carries identity rather than leaving it vague. The published bundle gets one DID; the agent that reads it is deferred to a provenance label for now; a runtime gets none. Federation is clone-and-invoke: resolve a bundle's DID, git-clone it, and run a local agent over the clone, so the knowledge stays distributed while the compute runs locally, with no always-on server and no relay.
And the DIDs are cryptographically verifiable rather than merely resolvable: each participant carries an Ed25519 key published as a verificationMethod, and its self-description is signed as a JWS the harvester checks. A forged descriptor fails verification instead of quietly entering the graph. A did:web with no key is a naming convention, not an identity.
The prototype wires three real participants, and the federation org that binds them, into a single queryable graph. Drag any node; the layout settles.
The real assembled graph: a rare-disease wiki bundle, a rare-disease DB connector, and the PAD live-API connector, all memberOf one federation org, each advertising capabilities colored by their real maturity. Identity, ontology, and this graph are all published and loaded into a live SPARQL store.
The ontology isn't sketched top-down. Its requirements are competency questions an agent poses mid-task, and every one becomes a SPARQL acceptance test. No question, no term: the discipline that kills over-modeling. Six stages, mirrored between a producer publishing itself and a consumer discovering it.
enroll → find → identify → understand → trust → reach → file‑back
Turning those into a running graph is a four-step pipeline over static, published artifacts, an "active metadata graph" rather than a crawl:
did:web and verify its signature.graph-full.ttl to GitHub Pages as text/turtle, beside the DIDs and the ontology.LOADs the graph straight from its live URL and answers over SPARQL.The reason to unify at all is a question no single source can answer. With maturity, provenance, and access in one graph, "can I trust this?" becomes a traversal, not a human judgement. An answer built from a beta capability inherits not-authoritative, and a synthesis inherits the taint from anything it drew on.
Authority propagates transitively. The synthesis is flagged because one of its inputs traces to a beta recipe, computed, not asserted. A sibling check catches an institutional-source answer filed into a public bundle: a visibility leak.
The graph is SPARQL-queryable, but an agent shouldn't hand-write SPARQL. A small MCP server (fabric_mcp.py) exposes the fabric to any MCP host, Claude Code, Claude Desktop, Cursor, as five read-only tools, so an agent can discover resources by asking in plain language. Each tool is one competency stage made callable, and fabric_authority is the payoff query above:
| Tool | What an agent discovers | Stage |
|---|---|---|
fabric_find | capabilities matching a need, each with its maturity, provider, and whether it is gated | find |
fabric_identify | a participant's service endpoints (clone / card / OpenAPI) and whether its signed self-description verified | identify |
fabric_authority | whether a filed answer is authoritative, by walking its provenance chain and naming the beta source that taints it | trust |
fabric_gate | which capabilities are credential-gated: the scope a VC must grant and the issuer trusted to grant it | gate |
fabric_sparql | anything: a read-only SPARQL escape hatch, with update verbs refused | escape hatch |
Registered with one command (claude mcp add fabric). The server queries the live published graph by default, falls back offline, and refuses every write. So "what clinical-trial capabilities exist, and is anything they produce authoritative?" is a two-tool traversal the agent runs itself.
eco: ontology, published; the namespace dereferences.LOADed into a live Fuseki store.fabric.crc.nd.edu endpoint and moving key custody there.The prototype is not an alternative to the data-fabric vision; it is a concrete instance of it. Every layer of the canonical diagram maps to something running, deliberately swapped for our own substrate, or still open:
Our build against the canonical data-fabric diagram. Green: running today. Amber: swapped for our substrate (entity alignment retired by DIDs; zero-trust and the blockchain audit log replaced by ledger-free did:web + VC). Red: not built. Click to enlarge.
The fabric is the discovery, identity, and trust layer, the topology questions, roughly one in twenty of what an agent asks. It is not the content-retrieval engine: reading within a source is the job of the distribution-based walk. The two compose, the walk answers "what did we find about X," the fabric answers "which participant can answer this, is it trustworthy, and how do I reach it." SPARQL earns its keep here precisely because everything it binds is DID-resolved and structurally typed, never a fuzzy concept.
This page pulls together threads told separately across the WGRA Nuggets: data fabrics, decentralized identifiers, connectors, ontologies, knowledge bundles, agent federation, and the marketplace.
The aspiration is the data-fabric appendix; this is the running proof. The prototype (eco: ontology, harvest/validate/publish pipeline, live DIDs and graph) is versioned in git, and every figure above traces to a real artifact.
Contact: Chris Sweet · csweet1@nd.edu · CRC, University of Notre Dame