Define proper RDF predicate identity allocation for user-created table columns #79

New issue

Open

opened 2026-10-29 09:45:21 +01:00 by michielbdejong · 0 comments

michielbdejong commented

2026-10-29 09:45:21 +01:00

Owner

Adding a user-defined column in pnpm rehearse:table assigns an RDF predicate such as did:ng:z:michielness, but the code constructs this by concatenating a fixed prefix and the column name. There is no identifier allocation or namespace/identity policy behind this value. Persisting and using the predicate works; the gap is what identity that predicate actually establishes.

Reproduction

Run pnpm rehearse:table.
In Alice, open Edit schema, add a column and name it michielness.
Observe the displayed predicate did:ng:z:michielness and save the schema.
Independently add a column with the same name in another document. It receives the same predicate, even if the intended meaning or datatype differs.

Current implementation

SchemaEditor.tsx initially assigns a temporary UUID-based Property resource ID and sets mapping:predicate to 'did:ng:z:' + name. Editing the column name rewrites the predicate suffix.
useRuntimeSchema.ts calls addressSchema(next, { readdress: true }) on save. This derives a separate content-addressed atomic:prop:… Property ID; addressSchema.mjs leaves the RDF predicate mapping unchanged.
The schema definition is persisted in a NextGraph discrete revision, and populated values use the mapped RDF predicate. Neither persistence nor the separate Atomic Property ID establishes identity for the generated did:ng:z:… predicate.

Matrix discussion update — 29 October 2026

The follow-up Matrix discussion clarifies the status of the NextGraph namespace, but does not yet define an allocation policy for user-created predicates:

Laurin initially described did:ng:z: as an example namespace. Niko subsequently clarified that did:ng:z and other forms are not only examples: they are intended to remain and become part of the NextGraph specifications, and can be used. NextGraph currently uses did:ng:z (and did:ng:x) as a convention. Niko also said these identifiers will have a resolution mechanism different from document identifiers; the details and their treatment in the DID method specification are still to be sorted out.
Markus noted that this is an unusual use of DIDs because the identifiers are not really decentralized or based on cryptographic keys and control. He questioned the benefit over a conventional namespace such as https://nextgraph.eu/vocab/v1/...; this was a concern raised in the discussion, not an agreed decision to replace the DID namespace.
Michiel asked which prefix/allocation approach to use when a user adds a custom column. Niko's clarification means that did:ng:z need not be rejected as example-only, but the discussion did not specify how to allocate distinct predicate identities within that convention. In particular, it did not establish that concatenating a display name is sufficient.
Laurin suggested a future UI with a separate display name and a search field for common predicate IRIs matching that name. Michiel supported letting users find and reuse existing predicates before minting duplicates.

The remaining issue is therefore the allocation and reuse policy, including collision avoidance and identity on rename. The prefix alone is not established as the bug, and no final identifier syntax or resolution design was agreed in this discussion.

Expected outcome

Define and implement how user-created RDF predicates get their identities and namespaces, consistent with NextGraph's identifier conventions. Independently created fields should not silently assert the same global predicate solely because their display names match; intentional reuse should remain possible.

The decision should also cover whether display-name changes preserve predicate identity, how existing saved predicates/data are handled, and how the UI distinguishes a column label, its Atomic Property ID and its RDF predicate. A central registry is not necessarily required; an explicit, supported allocation policy is.

As a future UI enhancement, consider searching existing predicate IRIs by display name and allowing explicit reuse before minting a new predicate. This suggestion does not yet establish a discovery service or search mechanism.

Verify the chosen behavior with independently created same-name fields, intentional reuse, renaming and saved-schema reload/replication. Related: #24 (runtime schema editing), #42 (native table rehearsal).

Adding a user-defined column in `pnpm rehearse:table` assigns an RDF predicate such as `did:ng:z:michielness`, but the code constructs this by concatenating a fixed prefix and the column name. There is no identifier allocation or namespace/identity policy behind this value. Persisting and using the predicate works; the gap is what identity that predicate actually establishes. ## Reproduction 1. Run `pnpm rehearse:table`. 2. In Alice, open **Edit schema**, add a column and name it `michielness`. 3. Observe the displayed predicate `did:ng:z:michielness` and save the schema. 4. Independently add a column with the same name in another document. It receives the same predicate, even if the intended meaning or datatype differs. ## Current implementation - [SchemaEditor.tsx](https://git.elfaconsortium.eu/ELFA/database-apps/src/commit/504154181c286c2782b1fcaaed0c939290317b50/shared/schema/SchemaEditor.tsx#L245) initially assigns a temporary UUID-based Property resource ID and sets `mapping:predicate` to `'did:ng:z:' + name`. Editing the column name rewrites the predicate suffix. - [useRuntimeSchema.ts](https://git.elfaconsortium.eu/ELFA/database-apps/src/commit/504154181c286c2782b1fcaaed0c939290317b50/shared/schema/useRuntimeSchema.ts) calls `addressSchema(next, { readdress: true })` on save. This derives a separate content-addressed `atomic:prop:…` Property ID; [addressSchema.mjs](https://git.elfaconsortium.eu/ELFA/database-apps/src/commit/504154181c286c2782b1fcaaed0c939290317b50/shared/schema/addressSchema.mjs) leaves the RDF predicate mapping unchanged. - The schema definition is persisted in a NextGraph discrete revision, and populated values use the mapped RDF predicate. Neither persistence nor the separate Atomic Property ID establishes identity for the generated `did:ng:z:…` predicate. ## Matrix discussion update — 29 October 2026 The follow-up Matrix discussion clarifies the status of the NextGraph namespace, but does not yet define an allocation policy for user-created predicates: - Laurin initially described `did:ng:z:` as an example namespace. Niko subsequently clarified that `did:ng:z` and other forms are **not only examples**: they are intended to remain and become part of the NextGraph specifications, and can be used. NextGraph currently uses `did:ng:z` (and `did:ng:x`) as a convention. Niko also said these identifiers will have a resolution mechanism different from document identifiers; the details and their treatment in the DID method specification are still to be sorted out. - Markus noted that this is an unusual use of DIDs because the identifiers are not really decentralized or based on cryptographic keys and control. He questioned the benefit over a conventional namespace such as `https://nextgraph.eu/vocab/v1/...`; this was a concern raised in the discussion, not an agreed decision to replace the DID namespace. - Michiel asked which prefix/allocation approach to use when a user adds a custom column. Niko's clarification means that `did:ng:z` need not be rejected as example-only, but the discussion did not specify how to allocate distinct predicate identities within that convention. In particular, it did not establish that concatenating a display name is sufficient. - Laurin suggested a future UI with a separate display name and a search field for common predicate IRIs matching that name. Michiel supported letting users find and reuse existing predicates before minting duplicates. The remaining issue is therefore the allocation and reuse policy, including collision avoidance and identity on rename. The prefix alone is not established as the bug, and no final identifier syntax or resolution design was agreed in this discussion. ## Expected outcome Define and implement how user-created RDF predicates get their identities and namespaces, consistent with NextGraph's identifier conventions. Independently created fields should not silently assert the same global predicate solely because their display names match; intentional reuse should remain possible. The decision should also cover whether display-name changes preserve predicate identity, how existing saved predicates/data are handled, and how the UI distinguishes a column label, its Atomic Property ID and its RDF predicate. A central registry is not necessarily required; an explicit, supported allocation policy is. As a future UI enhancement, consider searching existing predicate IRIs by display name and allowing explicit reuse before minting a new predicate. This suggestion does not yet establish a discovery service or search mechanism. Verify the chosen behavior with independently created same-name fields, intentional reuse, renaming and saved-schema reload/replication. Related: #24 (runtime schema editing), #42 (native table rehearsal).

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

ELFA/database-apps#79

No description provided.

Rows
Columns