Pure File

A Pure File is a Document whose content is a non-Sparqdown file — a PDF contract, an engineering drawing, a CAD model, an office document. The Index records only metadata about it; the bytes live wherever the organisation puts them, addressed via sdg:sourceAddress.

What the Index stores

The Version graph of a Pure File carries:

  • sdg:contentHash "sha256:…" — the SHA-256 content hash
  • sdg:contentSize <N> — byte size
  • sdg:mimeType "application/pdf" — the content type
  • sdg:originalFilename "contract.pdf" — a display hint
  • sdg:sourceAddress <iri> — where the bytes actually live
  • plus all the usual doc-level metadata: labels, type(s), dependencies, authorship, version chain

What the Index does NOT store

The bytes. Content hosting is out of scope for the core Registry — organisations bring their storage (local FS, S3, Azure Blob, their existing CMS) and register the Pure File with a sdg:sourceAddress pointing at it. An organisation that wants turnkey deployment can stand up a blob store next to the Registry and point at it; that is deployment topology, not core Registry scope.

Versioning

Each re-registration publishes a new Version with a new content hash. The content-addressed storage layer (when present) deduplicates identical uploads so multiple Versions can share a single physical blob.

Multi-typing

A Pure File almost always carries one or more domain Types alongside sdg:PureFile — org:Contract, org:Drawing, org:TechnicalSpecification. Renderer hints on those Types drive the viewer's preview UX (PDF preview, image display, download link).

Cross-linking

Pure Files participate in the dependency graph like any other Document. A Sparqdown document's Binding or Claim can reference a Pure File; a Workspace can contain a Pure File as an item.

Later-phase additions

Full-text extraction via an aux-script pipeline (Tika / pdf.js), making Pure Files searchable at body-content granularity, ships in Phase 4+.

Pure File — Sparqdown Docs