DEV Community: DecDEPO

Distributing an open dataset across 12 platforms in one day: a playbook

DecDEPO — Fri, 17 Apr 2026 16:00:22 +0000

We shipped the Swedish Construction FAQ dataset (503 bilingual Q&A pairs, CC BY 4.0, DOI 10.5281/zenodo.19630803) yesterday. By end of day it was on twelve platforms.

This is the checklist, in order. Each step takes 10-30 minutes. Most are scriptable.

The 12 platforms

#	Platform	What it gives you	Effort
1	GitHub	Canonical source, issues, Pages	base
2	Zenodo	DOI, Scholar indexing, archival	10 min
3	Hugging Face Datasets	ML audience, `load_dataset()` UX	15 min
4	PyPI	`pip install` for Python users	20 min
5	Kaggle	Data-science audience	10 min
6	Wikidata	Knowledge graph, LLM indexing	30 min
7	GitHub Pages	Static landing page, SEO	5 min
8	Colab notebook	One-click "try it" UX	15 min
9	Hugging Face Space	Live interactive demo	20 min
10	Awesome-list PRs	Organic discovery	15 min/list
11	Dev.to / Mastodon / HN	Human announcement reach	10 min each
12	LinkedIn / Medium	Longer-form professional reach	15 min each

What to ship before you announce

Before posting anywhere, finalize these files in the repo:

[x] README.md with badges (license, DOI, language, format)
[x] LICENSE (CC BY 4.0 for data, MIT for any code)
[x] CITATION.cff with the DOI and a preferred-citation block
[x] .zenodo.json so Zenodo picks up rich metadata on release
[x] llms.txt at repo root — tells LLMs where to find the canonical metadata
[x] Data files in multiple formats: JSON, JSONL, CSV, Alpaca, ShareGPT

If you skip these, every downstream platform will have thin, inconsistent metadata.

The scripting order

1. GitHub first

Create the repo, push everything, tag a release. Zenodo listens for GitHub releases via webhook.

gh repo create myorg/mydataset --public --source=.
git push -u origin main
gh release create v1.0.0 --title "Initial release" --notes "..."

2. Zenodo — before anything else downstream

Because the DOI becomes part of every downstream card. Don't mirror first and then retrofit the DOI everywhere.

Link your GitHub account to Zenodo
Flip the switch on your repo
Cut a release → Zenodo mints a DOI automatically
.zenodo.json in the repo controls metadata (creators, keywords, related_identifiers)

3. Hugging Face Datasets

# Create the dataset repo via API
curl -X POST https://huggingface.co/api/repos/create \
  -H "Authorization: Bearer $HF_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type":"dataset","name":"mydataset","organization":"MYORG"}'

# Then it's just git
git clone https://USER:$HF_TOKEN@huggingface.co/datasets/MYORG/mydataset
# Add your data/, add README.md with the YAML card, push

The dataset card YAML matters. Use configs: with split paths — it unlocks the in-browser dataset viewer.

4. PyPI wrapper

Ship a tiny Python package that just bundles the data and exposes a loader:

# pyproject.toml + one module that does:
import json, importlib.resources as r
def load(): return json.loads(r.files(__package__).joinpath('faq.json').read_text('utf-8'))

Publish with python -m build && twine upload dist/*. Users get pip install your-dataset-name.

5. Kaggle mirror

One-time manual upload via the web form, then the Kaggle API for updates:

kaggle datasets version -p . -m "Update to v1.0.0"

Tag generously. Kaggle's search weights tags heavily.

6. Wikidata

This is where most datasets stop — and why their metadata never gets into LLM training pipelines. The MediaWiki API is a bit arcane but the full flow is ~30 lines of Node. I wrote the how-to here.

Create at minimum:

The dataset entity (P31 → Q1172284 "dataset")
The publisher entity (your company / yourself)
P123 (publisher) + P170 (creator) links between them
P275 (license), P356 (DOI), P407 (language), P856 (official website)

7. GitHub Pages

A one-page static landing site helps human discoverability and SEO. Enable it on the repo's main branch.

8. Colab notebook

Drop a notebooks/quickstart.ipynb that loads the raw JSON from GitHub and does three example queries. Add the Colab badge to README:

[![Open In Colab](https://colab.research.google.com/assets/colab-badge.svg)](https://colab.research.google.com/github/ORG/REPO/blob/main/notebooks/quickstart.ipynb)

People click it. Dramatically lowers the "try it" barrier.

9. Hugging Face Space (Static)

A static Space is HTML + JS + CSS, no backend. Three files:

index.html — the UI
app.js — fetch dataset from GitHub raw, render
README.md with sdk: static in the YAML frontmatter

Cost: zero. Traffic: HF Spaces is indexed, browsable, trending. Ours is at DecDEPO/swedish-construction-faq-search.

10. Awesome-list PRs

awesome-X repos are still the organic-discovery hack of 2026. Find the relevant ones:

gh search repos "awesome-YOUR-TOPIC" --json fullName,stargazersCount --limit 50

Fork, add your entry under the matching section, open a PR. Keep the line format aligned with existing entries — maintainers reject inconsistent PRs fast.

11. Dev.to + Mastodon + HN

Three short announcements, roughly same copy, different lengths:

Mastodon: 500 chars, one link, 3-5 hashtags. Warning: em-dash (—) triggers HTTP 400 on the API. Use hyphens.
HN: Show HN: <name> — <one-line>. Wait for karma before spamming.
Dev.to: a proper blog post with frontmatter. The API accepts the whole markdown file in one POST. Use canonical_url if the same content lives elsewhere.

12. LinkedIn / Medium

Last, because they're manual. Write once for LinkedIn (short), once for Medium (long-form tutorial). Crosslink both back to the canonical GitHub.

Lessons from this particular rollout

The DOI is the glue. Once the DOI exists, every platform accepts the same metadata block. Mint it first, copy-paste everywhere.
Wikidata moves the needle more than expected. Google, Siri, Perplexity, and LLM training pipelines all read from Wikidata. A single QID gets your dataset into places you can't even list.
Write a tutorial article mid-rollout. We wrote the Wikidata how-to between rolling out to other platforms. It became its own distribution channel (and ranked for "wikidata open dataset tutorial" in under 24 hours).
Static Spaces > gradio Spaces for demos. No build step, no dependencies, no cold-start. Instant load.
Don't forget CITATION.cff for companion datasets. We did it for the flagship only. Had to go back and enrich four companions a day later. Do them all at once.

The scorecard

From our own rollout:

17 GitHub repos, all topic-tagged
1 flagship + 5 companion datasets on Hugging Face
6 Wikidata entities in a connected graph
1 DOI, auto-updated on each release
1 Colab notebook, 1 Static Space demo
8 awesome-list PRs open
4 Mastodon toots, 3 Dev.to posts, 1 HN submission, 1 LinkedIn post

All of it in 36 hours, mostly automated. Not a single paid channel.

The one step everyone skips

Cross-linking. After you've shipped to 12 platforms, go back and add the other 11 links to each one's metadata. Wikidata's P856, HF's homepage:, PyPI's project_urls, Kaggle's description. This is what makes the graph a graph.

That's it. One day, twelve platforms, zero spend. Go ship.

Swedish Construction FAQ is maintained by Zaragoza AB, Helsingborg. All datasets CC BY 4.0. Try the live demo: Space.

How I put my open dataset on the Wikidata knowledge graph (and why you should too)

DecDEPO — Fri, 17 Apr 2026 15:48:30 +0000

Last week we released the Swedish Construction FAQ — 503 bilingual Q&A pairs, CC BY 4.0, DOI 10.5281/zenodo.19630803. The dataset got onto Hugging Face, Zenodo, Kaggle, PyPI — the usual distribution stack.

But one step moved the needle more than the others: putting it on Wikidata as a first-class entity.

This post is a practical walkthrough. No philosophy, just what we did and why.

What a Wikidata entity gets you

A stable identifier — Q139393633 is the QID for our dataset. It'll outlive our GitHub account, our domain, our company.
Machine-readable citability — Wikidata is the knowledge graph that Google, Siri, Alexa, OpenAI, Anthropic, Perplexity, and basically every LLM training pipeline reads from.
A place for the DOI and license to live together — P275 (license) + P356 (DOI) + P407 (language) + P1476 (title) as proper RDF triples.
Free cross-linking — every related entity (the company, the companion datasets, the subject matter) shows up in the Special:WhatLinksHere graph.
It costs nothing — no API key, no app registration, no fees. Just a SUL account.

The entities we created

For the FAQ dataset alone, we ended up with six connected entities:

QID	Entity	What it is
`Q139393633`	Swedish Construction FAQ	The flagship dataset
`Q139393658`	Zaragoza AB	The publisher/creator (our company)
`Q139393817`	Construction Terminology Glossary	Companion trilingual glossary
`Q139393818`	Building Materials Specifications	Companion spec dataset
`Q139393819`	Construction Inspection Templates	Companion template dataset
`Q139393821`	Renovation Timeline Reference	Companion timeline dataset

Each companion dataset has P123 (publisher) and P170 (creator) pointing to Q139393658, which means the company's entity automatically aggregates everything we publish.

The minimum viable dataset entity

Here's the shape we used — it's the minimum that actually gets you into the graph in a way that indexers respect.

{
  "labels": {
    "en": { "language": "en", "value": "Swedish Construction FAQ" },
    "sv": { "language": "sv", "value": "Svensk byggbransch FAQ" }
  },
  "descriptions": {
    "en": { "language": "en", "value": "open bilingual Q&A dataset on Swedish construction" }
  },
  "claims": [
    {"property": "P31",  "value": "Q1172284"},       // instance of → dataset
    {"property": "P275", "value": "Q20007257"},      // license → CC BY 4.0
    {"property": "P356", "value": "10.5281/zenodo.19630803"}, // DOI
    {"property": "P407", "value": "Q9027"},          // language → Swedish
    {"property": "P407", "value": "Q1860"},          // language → English
    {"property": "P123", "value": "Q139393658"},     // publisher → Zaragoza AB
    {"property": "P170", "value": "Q139393658"},     // creator → Zaragoza AB
    {"property": "P856", "value": "github.com/..."}, // official website
    {"property": "P1324", "value": "github.com/..."},// source repo
    {"property": "P577", "value": "+2026-04-17"}     // publication date
  ]
}

Calling the MediaWiki API from Node

The API takes three requests: get a login token, log in, get a CSRF token. Then you can wbeditentity.

const API = 'https://www.wikidata.org/w/api.php';
const jar = new Map();
const cookie = () => [...jar].map(([k,v]) => `${k}=${v}`).join('; ');

async function call(params, method = 'POST') {
  const body = new URLSearchParams({ ...params, format: 'json' });
  const opts = {
    method,
    headers: { 'User-Agent': 'your-app/1.0', 'Cookie': cookie() },
  };
  if (method === 'POST') {
    opts.headers['Content-Type'] = 'application/x-www-form-urlencoded';
    opts.body = body;
  }
  const res = await fetch(method === 'GET' ? `${API}?${body}` : API, opts);
  // Parse cookies into the jar so subsequent calls are authenticated
  (res.headers.get('set-cookie') || '').split(/,(?=[^;]+=)/).forEach(c => {
    const [kv] = c.split(';'); const [k,v] = kv.split('=');
    if (k && v) jar.set(k.trim(), v.trim());
  });
  return res.json();
}

// 1. Login token
const lt = await call({ action: 'query', meta: 'tokens', type: 'login' }, 'GET');

// 2. Login (SUL credentials work — no bot password required on Wikidata)
await call({
  action: 'login',
  lgname: process.env.WIKI_USER,
  lgpassword: process.env.WIKI_PASS,
  lgtoken: lt.query.tokens.logintoken,
});

// 3. CSRF token for the edit
const ct = await call({ action: 'query', meta: 'tokens', type: 'csrf' }, 'GET');

// 4. Create the entity
const r = await call({
  action: 'wbeditentity',
  new: 'item',
  data: JSON.stringify(entity),
  token: ct.query.tokens.csrftoken,
  summary: 'Create entity for Swedish Construction FAQ (CC BY 4.0)',
});

console.log(r.entity.id); // → "Q139393633"

That's the whole thing. About 30 lines of code, one HTTP session, and your dataset has a permanent identity in the global knowledge graph.

Gotchas we hit

Abuse filter 11 ("badwords") will flag entities with the word "Awesome" in the label. We had to rename one repo's entity description. Doesn't matter what the actual word is — if the filter warns, your write fails with abusefilter-warning and you have to retry with different wording.
CAPTCHAs appear on newer accounts when you add external links. On sv.wikipedia.org, we had to strip URLs from our first edit. On wikidata.org, none of our edits hit a CAPTCHA — the Wikibase API is more permissive here.
SUL (Single User Login) isn't automatic across all projects. Our account worked on wikidata.org from day one but not on sv.wikipedia.org (login failed with "wrongpassword"). If you want to edit multiple projects, expect one manual login per project to "attach" your SUL.
Rate limits are generous. We created six entities in under five minutes with a 2-second sleep between them. No throttling.

Connecting the graph

Once the entities exist, the real value comes from linking them. We made the dataset a "work by" the company entity:

Q139393633 (dataset) — has P123 and P170 → Q139393658 (company)
All companion datasets do the same
The company entity itself has P31 (aktiebolag), P17 (Sweden), P159 (Helsingborg), P452 (construction industry)

Run SPARQL on query.wikidata.org and the whole graph falls out:

SELECT ?dataset ?datasetLabel WHERE {
  ?dataset wdt:P123 wd:Q139393658 .
  ?dataset wdt:P31 wd:Q1172284 .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en,sv" }
}

That's how external tools find everything we've published — one query.

What changed after we did this

Small, obvious things:

The Hugging Face dataset card now links to six Wikidata QIDs — readers click through.
Our Zenodo record has related_identifiers pointing at the Wikidata URI — so when someone cites the DOI, the graph picks up the citation.
Wikidata's own "What links here" page now serves as a free backlink-monitoring tool for us.

None of this is rocket science. But it's the one layer most open datasets skip.

Go do it

Your dataset already has a DOI, probably a GitHub repo, probably a Hugging Face mirror. Putting it on Wikidata takes ~30 lines of Node and one afternoon.

The entity you create today will outlive your current URLs. That's worth the afternoon.

Swedish Construction FAQ is maintained by Zaragoza AB, Helsingborg. All datasets CC BY 4.0. Explore the graph: Q139393633 · Q139393658.

Building an Open Bilingual Q&A Dataset for Swedish Construction Law (503 entries, CC BY 4.0)

DecDEPO — Fri, 17 Apr 2026 13:31:37 +0000

I spent the last few weeks building something that felt missing in the Swedish AI ecosystem: an open, bilingual, legally-grounded Q&A dataset for the construction industry.

Just released v1.2.1 with 503 question-answer pairs across 39 categories, in both Swedish and English, under CC BY 4.0. Here's what I learned building it, how it's structured, and how to use it.

The problem

Swedish construction law (PBL, BBR, ABS 18, AB 04) is dense, fragmented, and lives in PDFs scattered across municipal websites, Boverket, Skatteverket, and court archives.

If you've ever tried to answer "do I need a bygglov for this renovation?" you know the pain — three websites, two PDFs, one Skatteverket hotline, and maybe an answer.

This is exactly the kind of problem LLMs can help with — but only if there's grounded training data. Most open multilingual datasets barely include Swedish at all, and when they do, construction/legal Swedish is a rounding error.

So I built the data.

What's in the dataset

503 Q&A pairs × 2 languages = 1,006 entries

39 categories covering:

Permits: bygglov, attefallshus, tillbyggnad, marklov
Taxes: ROT-avdrag, RUT-avdrag, F-skatt, omvänd moms, personalliggare
Trades: takläggning, fasadrenovering, köksrenovering, badrumsrenovering, isolering, VVS, elinstallation, ventilation, värmesystem
Legal: dolda fel, verifiera byggfirma, ABS18/AB04/ABT06 contracts, arbetsmiljö (AFS)
Regulation: BBR, PBL, Miljöbalken, Energideklaration
Costs & disputes: kostnader, offerter, ARN, dispute resolution

Each answer:

30–150 words
Grounded in a specific Swedish statute or authority guidance
Cites the source (PBL § 9:2, BBR 6:5321, Skatteverket handledning)
Hand-reviewed for factual accuracy

Design choices (and mistakes I learned from)

1. Don't translate legal terms

Early attempt: I translated "bygglov" to "building permit" everywhere in the English set. Bad idea. A Swede reading the English set wants to see bygglov (building permit) so they can map to the original. And an English-speaking researcher working on Swedish legal NLP wants the Swedish term preserved.

Rule I landed on: keep Swedish legal terminology in the English set, with English gloss in parentheses the first time it appears.

2. Cite sources inside the answer, not just a metadata field

Initial structure had a separate sources: [...] array. Worked for humans, but when fine-tuning, the model doesn't always learn to carry the citation into its output.

Now: citations appear inline in the answer text ("Enligt PBL 9 kap. 2 §...") AND in the metadata field. The model learns to cite, not just to answer.

3. 30–150 words per answer

Tested with shorter (15 words) and longer (500 words). Shorter loses grounding; longer drifts. 30-150 is the sweet spot for factual legal Q&A.

4. Multi-format release

Shipped in 5 formats:

faq.json — master with metadata
faq.jsonl — HuggingFace-native (one record per line)
faq-alpaca.jsonl — Alpaca instruction format
faq-sharegpt.jsonl — ShareGPT conversation format
faq.csv — for non-ML users (Excel / Google Sheets)

Same data, 5 pipelines, zero conversion friction.

How to use it

Via HuggingFace datasets:

from datasets import load_dataset
ds = load_dataset("DecDEPO/swedish-construction-faq")
# Swedish: ds["train"] (503 rows)
# English: load_dataset(..., "english")

Via pip:

pip install zaragoza-construction-faq

import zaragoza_construction_faq as zcf

zcf.load()                    # 503 SV Q&A as list of dicts
zcf.load(lang="en")           # 503 EN
zcf.load("bygglov")           # filter by category
zcf.categories()              # all 39 categories

# Iterators for LLM fine-tuning
for rec in zcf.iter_alpaca():
    # rec = {"instruction": "...", "output": "..."}
    train(rec)

for rec in zcf.iter_sharegpt(lang="en"):
    # rec = {"conversations": [{"role": "user", ...}, {"role": "assistant", ...}]}
    train(rec)

Via Kaggle / CSV:

Kaggle dataset page — download as zip, drop into your notebook.

Academic citation (DOI assigned)

Zenodo assigned a permanent DOI, so it's citable:

@dataset{zaragoza_swedish_construction_faq_2026,
  author    = {{Zaragoza AB}},
  title     = {Swedish Construction FAQ — Open Q\&A Dataset (SV + EN)},
  year      = {2026},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.19630803}
}

DOI: 10.5281/zenodo.19630803

License

CC BY 4.0 — free for commercial and research use, attribution required.

Intentionally chose BY over BY-SA because I want this in commercial products (fine-tune a chatbot for a construction firm, build a RAG system for a municipal permit office, whatever) with no copyleft friction.

Where it lives

🐙 GitHub: zaragoza-ab/swedish-construction-faq-1000
🤗 HuggingFace: DecDEPO/swedish-construction-faq
📦 PyPI: zaragoza-construction-faq
📊 Kaggle: decdepo/swedish-construction-faq
📜 Zenodo: DOI 10.5281/zenodo.19630803

What's next

Target is 1000+ Q&As (v2.0). The areas most underrepresented right now:

Kommun-specific rules (each of Sweden's 290 municipalities has its own bygglov process quirks)
Post-2020 case law (big shifts on dolda fel doctrine)
Cross-border cases (what if your contractor is Polish, Romanian, Baltic?)

If you're Swedish and find something outdated or wrong, open a PR or an issue. I'll merge within a day.

Also releasing a 510-entry trilingual construction glossary (Swedish / English / Polish) in a sibling repo, because Polish construction workers in Sweden are a huge demographic and there's zero open terminology for them.

Built this for Zaragoza AB (Helsingborg) — a small construction firm that's using the dataset internally for their customer Q&A chatbot. Open-sourced because Swedish AI needs more domain data and there's no business reason to keep it closed.

Feedback welcome. Especially if you're working on Swedish NLP, building a Swedish legal RAG system, or just trying to renovate your kök and wondering if bygglov applies.