DPROD artifacts fail to resolve at their OMG NS URLs. Return 404

[adplincinst]

When processing json-ld document, the context object url returns 404

curl https://www.omg.org/spec/DPROD/dprod-context.jsonld
{"timestamp":"2026-08-11T23:13:59.588+00:00","status":404,"error":"Not Found","path":"/spec/DPROD/dprod-context.jsonld"}(.venv)

[adplincinst]

for additional context, the url https://www.omg.org/spec/DPROD/dprod-context.jsonld is referenced here in the @context

https://github.com/EKGF/dprod/blob/develop/examples/dprod-example.json

[jgeluk]

@adplincinst — confirmed, and thank you for the follow-up pinpointing examples/dprod-example.json as the referrer.

This 404 is one of two independent defects standing between that example and a working expansion. Even once the URL resolves, the artifact it will serve is currently a bare prefix map: no id/type aliases, no term definitions for DataProduct, outputPort, title, conformsTo and the rest, and no "@type": "@id" coercions. Expanding the example against it would yield essentially the empty graph rather than an error, which is arguably a worse failure mode than the 404 you are seeing now.

That second defect is filed as #246. This issue remains the publication half and is a blocker for it — fixing the context contents without deploying it to the OMG URL leaves you exactly where you are.

For local work in the meantime, the context is generated into dist/dprod-context.jsonld by bash build.sh, though with the caveat above about its contents.

[jgeluk]

Still reproducing, and it is broader than the context file. Three DPROD artifacts fail to resolve at their OMG URLs today:

https://www.omg.org/spec/DPROD/dprod-context.jsonld   404
https://www.omg.org/spec/DPROD/dprod/                 404   <- the vocabulary namespace IRI
https://www.omg.org/spec/DPROD/dprod.ttl              404

The second is the most serious: https://www.omg.org/spec/DPROD/dprod/ is the namespace IRI for every DPROD term. A namespace that does not dereference is a defect in a linked-data standard independent of any tooling, and it is what rdfs:isDefinedBy points at throughout the ontology.

Nothing merged recently closes this, and none of it could have. This is a hosting gap — the artifacts are not published at those URLs — while the recent work concerned what the artifacts contain and which URLs the specification links to:

• Examples cannot be expanded: adopt prefixed terms and add value coercion to dprod-context.jsonld #246 / PR Make DPROD JSON-LD examples expand into RDF #248 fixed the contents of the context. It had been a bare prefix map that defined no terms, so even once this 404 is resolved the old file would not have expanded the examples. That is now correct and is generated into dist/dprod-context.jsonld.
• Spec header advertises URLs that 404, including in the frozen 1.0 archive #255 / PR Stop the spec header advertising URLs that 404 #256 stopped the specification linking to URLs that 404, including .../DPROD/dprod.ttl and the namespace IRI. It routes around the problem; it cannot fix it.

So the examples in this repository still carry "@context": "https://www.omg.org/spec/DPROD/dprod-context.jsonld" and still fail for any external consumer, exactly as reported. The content is ready; the publication is not.

What resolving this requires

The generated artifacts need to be published at their OMG URLs, ideally with content negotiation on the namespace IRI. They are produced by bash build.sh into dist/ and are already served from our own site, which is a useful check that the files themselves are fine:

https://ekgf.org/dprod/spec/develop/dprod-context.jsonld   200
https://ekgf.org/dprod/spec/develop/dprod.ttl              200

This is an OMG-side action rather than a code change, so it needs to be raised with OMG directly.

Retitling would be reasonable — the issue now covers three artifacts, not just the context.

[adplincinst]

Thanks @jgeluk for following up. Looking forward to dereferenceable URLs referenced in examples/docs.