CKAN: structured metadata and separate indexing flows

Geospatial and other domain metadata can contain nested structures, schema-specific fields and validation rules. A catalog needs a usable editing experience and a way to discover the resulting records without flattening away their meaning.

The public extension addresses that CKAN metadata problem. The separate multi-destination event design addresses propagation to additional representations. They are related concerns, but the extension repository does not establish that it implements the external pipeline.

The public repository’s extra branch describes JSON Schema metadata types stored with CKAN extra fields, a JSON Editor interface and validation. It also documents schema registries, import/export, cloning and related metadata functions.

Solr projection fields support schema-related resource/view metadata, and the documented view search concerns public metadata. This is evidence for the extension’s CKAN/Solr feature set; it is not proof of a particular CKAN callback or database commit hook.

Separately, I implemented a custom metadata indexer with Eventarc and destinations in Elasticsearch, Solr and object storage. The integration overview shows my implementation account alongside the public extension. The public README does not establish the external publisher, authoritative record or purpose of the bucket.

Google’s Eventarc Standard documentation specifies at-least-once delivery and no FIFO ordering guarantee. Therefore duplicate and stale-event handling are requirements to examine, not capabilities to assume were already implemented in this integration.

For a retrospective design review, I would compare a stable versioned snapshot event with an event that contains only an entity reference. A snapshot improves repeatable replay but can spread stale or private data; a reference reduces payload duplication but requires source availability and a clear version policy.

Idempotent destination updates, visibility-change removal, replay and reconciliation are sensible reliability controls to evaluate. They are presented as review considerations, not as fabricated historical implementation details.

The repository documents a substantial metadata extension and Solr-based view-search behavior. My public CKAN discussion describes releasing it with ISO metadata work and import/export/clone/validation/indexing functions.

I lead the technical work on FAO’s ISO metadata catalogue, associated with data.fao.org and the agro-informatics portal and supporting a broad range of FAO projects. I also participated in ISO 19115-4 standardization work. The companion AIP catalogue case explains that institutional context alongside the separate STAC discovery lane.

The external pipeline is documented separately through my implementation account. Neither the README nor that account establishes operational volume, index freshness, an availability target or a production reliability result.

An architecture drawing becomes useful when it can say why each destination exists, who owns the canonical record and what happens when visibility changes. Adding a bucket and two search engines does not answer those questions by itself.

This case preserves the gap rather than inventing a precise event envelope or integration hook. The next step for a deeper review is to trace one real update and one delete through each destination, then test replay and stale-event behavior.