Author the spec publication date as dct:issued

[jgeluk]

Fixes #253.

The bug

Every generated spec showed today's date in its header, whatever the branch — including /spec/main, the frozen DPROD 1.0 Beta approved by OMG. The date changed every morning.

respec/template.html never set publishDate, and ReSpec runs client-side, so it defaulted to the date the page was viewed rather than the date the document was published. The frozen archive had the same omission, so an immutable standard reported a new publication date on every visit.

Why not the commit date

That was my first implementation and it is wrong, for the reason @jgeluk raised: a maintenance commit would silently republish the standard. #236 retired the ekgf.github.io/dprod URLs and touched main — under a commit-date scheme, that alone would have restamped DPROD 1.0.

Issuing a version is a decision, so the artifact records it as one:

dprod:
  dct:issued "2026-06-01"^^xsd:date ;
  owl:versionIRI <https://www.omg.org/spec/DPROD/20260601/dprod/> ;

dct:issued is DCTERMS' "date of formal issuance", which is precisely this, and it sits beside owl:versionIRI so the two get bumped together.

Changes

• The triple, in dprod-ontology.ttl, with a comment saying why it is authored rather than derived.
• The generator reads it and pins publishDate. A missing triple raises rather than falling back to today — falling back is the bug being replaced, so it must not be a silent path.
• The frozen archive gets a hard-coded publishDate: "2025-01-01", matching the January 2025 date OMG records for DPROD 1.0 Beta 1. A static snapshot's date must not be derived from anything.
• tests/test_spec_publish_date.py so the config cannot quietly disappear again: the ontology must carry exactly one dct:issued, the template must pin publishDate, and the archive must pin a literal one.

Verification

Rendered in a real browser, since ReSpec only computes the date client-side and inspecting the HTML source proves nothing:

document	before	after
generated spec	today	01 June 2026
frozen 1.0 archive	today	01 January 2025

Removing the triple fails the build with a message pointing at the ontology, as intended.

Noticed, not fixed

The frozen archive still advertises Latest editor's draft: https://ekgf.github.io/dprod/ — a URL retired by #235, which updated latestVersion in that file but left edDraftURI. Left alone deliberately: you have just made the point that the published standard should not be edited casually, so that is your call rather than mine. Happy to fix it in a separate PR if you want it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VHbek1ZojYktiTaeFqChqA

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
dprod	Ready	Preview	Aug 21, 2026 12:42pm

[jgeluk]

Corrected: the 1.0 archive is now dated February 2025, not January.

My first value, 2025-01-01, took the OMG catalog's "Publication Date: January 2025" and invented a day. Researching it properly turned up a disagreement between OMG's own sources:

source	date
OMG catalog page, "Publication Date"	January 2025
Specification PDF cover, "Date:"	February 2025
OMG document number ptc/25-02-01 (YY-MM-NN)	February 2025
PDF XMP timestamp	2025-04-11 — when the file was produced, not published

The document's own cover reads:

Date: February 2025

Data Product Ontology (DPROD)
Version 1.0 – beta 1
OMG Document Number: ptc/25-02-01

Two independent signals inside the normative artifact against one catalog metadata field, so the archive follows the document: publishDate: "2025-02-01".

Two caveats, recorded in the file rather than glossed over:

• No source publishes a day. Both are month-precision, so the 01 is a convention, not a fact. ReSpec will render "01 February 2025", which is one more digit of precision than OMG actually states.
• The catalog and the document disagree, and I cannot tell from outside which OMG considers canonical — plausibly the beta was adopted in January and the document issued in February.

@jgeluk, as DPROD's initiator you may simply know which is right. If the catalog's January is the intended publication date, it is a one-line change.

[jgeluk]

Rule confirmed by @jgeluk: the OMG document number is authoritative for the date.

That settles it in favour of the value already committed — ptc/25-02-01 gives February 2025, so the frozen archive keeps publishDate: "2025-02-01", and the catalog page's "Publication Date: January 2025" is not followed.

Recorded as the rule rather than as my inference, in two places so the next version does not require re-deriving it:

• site/public/spec/archive/1.0/index.html — why this document is dated February 2025, and that the catalog disagrees and loses.
• dprod-ontology.ttl, next to dct:issued — once a version is published by OMG, date it from its ptc/YY-MM-NN document number. The working draft has no document number yet, so its dct:issued tracks owl:versionIRI.

The remaining caveat stands and is noted in the file: no OMG source states a day, so the 01 is a convention. This PR is otherwise unchanged and ready.