Publish a public catalog with OpenCatalogi

OpenCatalogi is the publishing layer for Conduction apps. Where OpenRegister stores your data and OpenConnector fills it from elsewhere, OpenCatalogi turns a register you own into a public, browsable, harvestable catalog: a set of API endpoints that anyone on the internet can read, and a DCAT-AP-NL feed that national portals like data.overheid.nl and data.europa.eu can harvest. It does this without a "publish" button and without copying your data anywhere — publishing is a rule on the data, enforced by OpenRegister, and a catalog is just a filter that says which data belongs in the shop window.

This tutorial takes the Pet Store register you built in the first two parts and makes it public. You scope a catalog to the register, set up the visibility rule, publish nine pets while deliberately keeping one hidden, prove the rule from a logged-out browser, and expose the whole thing as a DCAT-AP-NL feed. No code, no second server, no export.

How publishing works in OpenCatalogi

OpenCatalogi has no separate "publish" button, and that is the single most important thing to understand before you click anything. Visibility is not a flag on a page or a menu you hide — it is a rule on the data itself, enforced by OpenRegister on every request, whatever app or API the reader comes through.

Three things must all be true for an anonymous visitor to see one of your pets:

1. The pet lives in a register and schema that a catalog points at. A catalog is a filter: it names the registers and schemas whose objects belong in it. An empty catalog scope serves nothing.
2. The pet's schema grants the public group read — conditionally. This build's rule, taken straight from the live schema, is: the public group may read an object when its publicatiedatum is set and is at or before now. That condition is the publish gate. No date, or a future date, means no public read.
3. The visitor reads it through a public endpoint like /api/publications (per catalog) or /api/dcat (the harvest feed).

The next steps set up all three conditions and then prove them from a logged-out browser.

Step 1: Scope a catalog to your register

OpenCatalogi ships one catalog with the slug publications. A catalog is an OpenRegister object (it lives in OpenCatalogi's own register, under a catalog schema), and its two most important fields are registers and schemas — the scope. Point them at your Pet Store.

# Read the catalog, find its register/schema/uuid
curl -s "http://localhost:8080/index.php/apps/opencatalogi/api/catalogi"

# Scope it to the Pet Store register (2414) and the Pet schema (4318)
curl -u admin:admin -X PATCH \
  "http://localhost:8080/index.php/apps/openregister/api/objects/14/54/<CATALOG_UUID>" \
  -H "OCS-APIRequest: true" -H "Content-Type: application/json" \
  -d '{ "registers": ["2414"], "schemas": ["4318"] }'

use OCA\OpenRegister\Service\ObjectService;

$objects = \OCP\Server::get(ObjectService::class);

$objects->saveObject(
    object: [
        'registers' => ['2414'], // petstore-academy
        'schemas'   => ['4318'], // pet-academy
    ],
    register: '14', // OpenCatalogi's catalog register
    schema:   '54', // the catalog schema
    uuid:     '<CATALOG_UUID>',
);

The catalog now knows which objects belong to it. Read it back and you can see the scope on the record itself:

Verify: /api/catalogi lists the publications catalog with registers and schemas pointing at your Pet Store register and Pet schema.

Step 2: Publish the pets

Now make the pets readable by an anonymous visitor. Remember the rule: the schema must grant the public group read, gated on a publicatiedatum that is at or before now. So there are two parts — set the rule on the schema (once), then set the date on each pet you want live.

Set the visibility rule on the schema

Open the pet-academy schema in OpenRegister and go to its Security tab. This is the role-based access-control matrix: per Nextcloud group, you grant Create/Read/Update/Delete, where public represents unauthenticated access and admin always keeps full access.

The publish gate is not a simple checkbox — it is a conditional read rule. Expand Advanced: Conditional access rules and inheritance and, under Read, add a rule for the public group with one condition: property publicatiedatum, operator ≤ Less than or equal, value $now. (You add a publicatiedatum date property to the schema first, on the Properties tab, if it does not have one — this build's pet schema didn't, so we added it.)

curl -u admin:admin -X PUT \
  "http://localhost:8080/index.php/apps/openregister/api/schemas/4318" \
  -H "OCS-APIRequest: true" -H "Content-Type: application/json" \
  -d '{
        "title": "Pet",
        "slug": "pet-academy",
        "properties": {
          "name": {"type":"string"}, "species": {"type":"string"},
          "status": {"type":"string"},
          "publicatiedatum": {"type":"string","title":"publicatiedatum",
            "description":"Publication date (YYYY-MM-DD HH:MM:SS). Controls public visibility."}
        },
        "authorization": {
          "read": [
            { "group": "public", "match": { "publicatiedatum": { "$lte": "$now" } } },
            "authenticated"
          ]
        }
      }'

use OCA\OpenRegister\Db\SchemaMapper;

$schemas = \OCP\Server::get(SchemaMapper::class);
$pet     = $schemas->find(4318);

// Add the publish-date property.
$pet->setProperties(array_merge($pet->getProperties(), [
    'publicatiedatum' => ['type' => 'string', 'title' => 'publicatiedatum'],
]));

// Grant the public group read, gated on the publish date being in the past.
$pet->setAuthorization([
    'read' => [
        ['group' => 'public', 'match' => ['publicatiedatum' => ['$lte' => '$now']]],
        'authenticated',
    ],
]);

$schemas->update($pet);

Set the date on each pet

The rule is armed; now decide which pets are live. Give the pets you want public a publicatiedatum in the past, and leave one with a publicatiedatum in the future to prove the gate hides it.

# Publish a pet (date in the past → public)
curl -u admin:admin -X PATCH \
  "http://localhost:8080/index.php/apps/openregister/api/objects/2414/4318/<PET_UUID>" \
  -H "OCS-APIRequest: true" -H "Content-Type: application/json" \
  -d '{ "publicatiedatum": "2026-06-01 00:00:00" }'

# Keep one hidden (date in the future → private)
curl -u admin:admin -X PATCH \
  "http://localhost:8080/index.php/apps/openregister/api/objects/2414/4318/<SPIKE_UUID>" \
  -H "OCS-APIRequest: true" -H "Content-Type: application/json" \
  -d '{ "publicatiedatum": "2099-01-01 00:00:00" }'

use OCA\OpenRegister\Service\ObjectService;

$objects = \OCP\Server::get(ObjectService::class);

// Publish (past date).
$objects->saveObject(
    object: ['publicatiedatum' => '2026-06-01 00:00:00'],
    register: 'petstore-academy', schema: 'pet-academy', uuid: $petUuid,
);

// Keep hidden (future date).
$objects->saveObject(
    object: ['publicatiedatum' => '2099-01-01 00:00:00'],
    register: 'petstore-academy', schema: 'pet-academy', uuid: $spikeUuid,
);

OpenCatalogi's own dashboard reads this state directly. With nine pets dated in the past and one in the future, it shows 10 publications, 9 published, 1 concept — the concept being the future-dated pet that is not yet public:

Scroll the dashboard and the breakdown is by name: the published pets carry a green Published badge, while the future-dated Spike sits under Concept, exactly as the rule dictates.

Verify: in OpenRegister an admin still sees all ten pets, while the dashboard splits them into nine published and one concept. The split is your publish rule, working.

Step 3: Verify public access anonymously

The real test is not what an admin sees — it is what a stranger sees. Read the catalog as a genuinely anonymous visitor. Each catalog is served at /api/<catalogSlug>, so the publications catalog is at /api/publications. Open it with no login (log out, or use a private/incognito window):

http://localhost:8080/index.php/apps/opencatalogi/api/publications

You get only the published pets. The future-dated Spike is absent — OpenRegister filtered it in SQL via the RBAC rule, so it never reached the response at all:

{
  "results": [
    {
      "name": "Rex",
      "species": "Dog",
      "status": "available",
      "publicatiedatum": "2026-06-01 00:00:00",
      "@self": {
        "id": "65e72185-610a-4bf2-902d-4033d9b30411",
        "register": "2414",
        "schema": "4318"
      }
    }
  ],
  "total": 9,
  "page": 1,
  "pages": 1,
  "@catalog": { "slug": "publications", "registers": ["2414"], "schemas": ["4318"] }
}

Here is that exact response in a logged-out browser — note the total of nine, and no Spike:

Open the same register in OpenRegister as an admin and you see all ten pets — the difference between the two views is exactly your unpublished pet. That difference is the whole point: you did not hide a menu, you set a rule, and the rule travels with the data to every reader.

Verify: logged out, /api/publications returns nine pets and not the future-dated one. Set that pet's publicatiedatum to a past date and it appears; clear the date and it disappears again.

Step 4: Expose the catalog as a DCAT-AP-NL feed

A public API is for people and applications. Open-data harvesters speak a different language: DCAT-AP-NL, the Dutch profile of the W3C DCAT vocabulary, is the exchange format that data.overheid.nl and data.europa.eu harvest. OpenCatalogi renders your catalog as a DCAT-AP-NL document — each published object as a dcat:Dataset, each attached file as a dcat:Distribution — with no extra storage and no new schema.

Open the instance feed, anonymously:

http://localhost:8080/index.php/apps/opencatalogi/api/dcat

You get a JSON-LD document carrying the DCAT-AP-NL profile (data.overheid.nl/dcat-ap-nl/3.0) and the standard dcat/dct/foaf contexts:

A harvester points at this URL on a schedule, reads the catalog and its datasets, and lists your published pets alongside everyone else's open data. The datasets surface through the per-catalog feed at /api/catalogs/<catalogSlug>/dcat, where each published object renders as a dcat:Dataset:

{
  "@context": {
    "dcat": "http://www.w3.org/ns/dcat#",
    "dct": "http://purl.org/dc/terms/",
    "profile": "https://data.overheid.nl/dcat-ap-nl/3.0"
  },
  "@graph": [
    {
      "@type": "dcat:Dataset",
      "dct:title": "Rex",
      "dct:identifier": "65e72185-610a-4bf2-902d-4033d9b30411",
      "dcat:landingPage": { "@id": "http://localhost:8080/index.php/apps/openregister/api/objects/2414/4318/65e72185-610a-4bf2-902d-4033d9b30411" }
    }
  ]
}

The per-catalog feed honours the same visibility rule as Step 3: only objects whose publicatiedatum is at or before now appear, so a harvester never sees your drafts.

Verify: /api/dcat returns a JSON-LD document with the data.overheid.nl/dcat-ap-nl/3.0 profile in its @context. With DCAT harvesting enabled on the catalog, /api/catalogs/publications/dcat lists your published pets as dcat:Dataset nodes and excludes the drafts.

Troubleshooting

Test yourself

You have published the catalog if all of these are true:

• The publications catalog's registers and schemas point at your petstore-academy register and pet-academy schema.
• The pet-academy schema's read permission grants the public group with the condition publicatiedatum ≤ $now, and the schema has a publicatiedatum property.
• Nine pets carry a past publicatiedatum and one carries a future one; OpenCatalogi's dashboard shows nine Published and one Concept.
• Logged out, /api/publications returns exactly the nine published pets and not the future-dated draft.
• /api/dcat returns a DCAT-AP-NL JSON-LD document carrying the data.overheid.nl/dcat-ap-nl/3.0 profile.
• You can explain why publishing here is a rule on the data (RBAC + a date), not a button — and why that means an unpublished pet never leaves the database.

Where to go from here

Your Pet Store has travelled the whole pipeline: modelled in OpenRegister, filled by OpenConnector, and now public and harvestable through OpenCatalogi. The data you own is, on your terms, data the world can read.