Every RDF app resolves IRI → label endlessly - for predicates, classes and entities. Do it once from a globally edge-cached CDN: rdfs:label, skos:prefLabel, schema:name and your own IRIs, resolved at the edge and never from your triplestore.
RDF Label Cache allows you to serve labels from the Cloudflare CDN. Rendering them is up to your app; it ships no rendering library.
RDF Label Cache compared to four common ways apps obtain labels today.
| Approach | Stale? | Hits the KG? | Shared? |
|---|---|---|---|
| RDF Label Cache (edge CDN) | TTL + purge policy | never | at the edge |
| Hard-coded label table | yes | no | no |
| Label joins in every query | no | heavily | no |
| Follow-up label query | no | every time | no |
| Shadow "label" named graphs | drifts | yes | no |
Requests are subject to the Free plan's daily limit; R2 includes separate monthly storage and operation allowances.
Includes 10 million requests per month; additional requests are currently $0.30 per million, plus billable CPU where applicable.
Reusable entries can be served without invoking the Worker or reading R2. Actual hit rate and latency depend on traffic.
Read the full write-up - cost, latency & the shared-cache model
Three moves, whichever path you take. It ships empty; you populate R2 once with your own IRIs and any ontologies you reference (Schema.org, DCAT etc.)
One click with the Deploy to Cloudflare button, or one command from a clone. Comes up empty — every /label 404s until you seed.
Drop RDF into the labels/ folder, or CONSTRUCT them from your triplestore — only label & description triples are kept.
A browser GitHub Action for vocabularies & small/modest sets, or the local just pipeline for large sets & frequent refreshes.
The GitHub Action path re-runs as an upsert, not a mirror, and suits small/modest RDF. For large label sets or more robust sync, use the clone + pipeline path.