Reviewing OKF's design — the concept/bundle/frontmatter model is clean, and
the sources field is a good instinct: provenance matters for knowledge
that agents consume and act on.
(Disclosure: I'm a member of and comment reviewer on the OASIS DPS TC, so I have a stake
in seeing it adopted — take the following with that in mind.)
Right now sources is free text, though. That works fine within a single
bundle maintained by one team, but it breaks down once multiple tools
produce and consume OKF bundles independently — which is already happening
(okf-gem, okf-skills, okf-generator, the knowledge-catalog viewer, at least
one Rust implementation). Free-text provenance isn't comparable or
verifiable across tools. Two bundles can both have a populated sources
field and still be describing completely different things — origin,
authorship, license, collection method, whatever the author happened to
write.
There's also currently nothing in OKF for rights/license/usage restrictions
at all. As bundles get exported, re-published, or fed into other agents'
context, "can this concept be redistributed / used for training / shared
externally" becomes a real question with no field to answer it in.
Worth a look: OASIS Data Provenance Standard (DPS) — a schema specifically
for this. Currently at CSD01 stage (post public-review, in comment
resolution toward the next committee draft). Covers exactly this gap:
source identification, provenance/lineage, and use/rights — as a
JSON-Schema-validatable structure, not free text.
Spec: https://docs.oasis-open.org/dps/prov-meta/v1.0/csd01/prov-meta-v1.0-csd01.html
Schema + repo: https://github.com/oasis-tcs/dps
Two integration shapes worth considering, in increasing order of commitment:
-
Lightweight — sources entries could optionally carry a dps key
pointing to a DPS-conformant record (inline or by URI), while staying
free text by default. Doesn't touch the "loose consumption" model —
consumers that don't care about DPS ignore the extra key entirely, same
as any other unknown frontmatter field.
-
Bundle-level — a reserved .okf/provenance.json (or similar)
conforming to the DPS schema, covering the whole bundle rather than
per-concept. Closer to how index.md/log.md work today as reserved,
optional files.
Either way, this doesn't need to be mandatory or break existing bundles —
DPS itself is additive by design (most fields optional beyond a small
required set). Happy to help work through what a minimal integration would
look like if there's interest. Also worth noting DPS is still in active
public comment resolution, so feedback from the OKF side would be timely —
this is a good moment to shape it rather than retrofit later.
Reviewing OKF's design — the concept/bundle/frontmatter model is clean, and
the
sourcesfield is a good instinct: provenance matters for knowledgethat agents consume and act on.
(Disclosure: I'm a member of and comment reviewer on the OASIS DPS TC, so I have a stake
in seeing it adopted — take the following with that in mind.)
Right now
sourcesis free text, though. That works fine within a singlebundle maintained by one team, but it breaks down once multiple tools
produce and consume OKF bundles independently — which is already happening
(okf-gem, okf-skills, okf-generator, the knowledge-catalog viewer, at least
one Rust implementation). Free-text provenance isn't comparable or
verifiable across tools. Two bundles can both have a populated
sourcesfield and still be describing completely different things — origin,
authorship, license, collection method, whatever the author happened to
write.
There's also currently nothing in OKF for rights/license/usage restrictions
at all. As bundles get exported, re-published, or fed into other agents'
context, "can this concept be redistributed / used for training / shared
externally" becomes a real question with no field to answer it in.
Worth a look: OASIS Data Provenance Standard (DPS) — a schema specifically
for this. Currently at CSD01 stage (post public-review, in comment
resolution toward the next committee draft). Covers exactly this gap:
source identification, provenance/lineage, and use/rights — as a
JSON-Schema-validatable structure, not free text.
Spec: https://docs.oasis-open.org/dps/prov-meta/v1.0/csd01/prov-meta-v1.0-csd01.html
Schema + repo: https://github.com/oasis-tcs/dps
Two integration shapes worth considering, in increasing order of commitment:
Lightweight —
sourcesentries could optionally carry adpskeypointing to a DPS-conformant record (inline or by URI), while staying
free text by default. Doesn't touch the "loose consumption" model —
consumers that don't care about DPS ignore the extra key entirely, same
as any other unknown frontmatter field.
Bundle-level — a reserved
.okf/provenance.json(or similar)conforming to the DPS schema, covering the whole bundle rather than
per-concept. Closer to how
index.md/log.mdwork today as reserved,optional files.
Either way, this doesn't need to be mandatory or break existing bundles —
DPS itself is additive by design (most fields optional beyond a small
required set). Happy to help work through what a minimal integration would
look like if there's interest. Also worth noting DPS is still in active
public comment resolution, so feedback from the OKF side would be timely —
this is a good moment to shape it rather than retrofit later.