Skip to content

Surface data access in the UI: Data tab export links and RDF autodiscovery#1097

Merged
JeroenDeDauw merged 2 commits into
feature/subject-rdf-exportfrom
feature/data-access-links
Jul 19, 2026
Merged

Surface data access in the UI: Data tab export links and RDF autodiscovery#1097
JeroenDeDauw merged 2 commits into
feature/subject-rdf-exportfrom
feature/data-access-links

Conversation

@JeroenDeDauw

@JeroenDeDauw JeroenDeDauw commented Jul 19, 2026

Copy link
Copy Markdown
Member

Fixes #1095

Stacked on #1090, whose per-subject RDF endpoint these menus link to; based on
feature/subject-rdf-export so the diff is only this work. GitHub retargets to
master once #1090 merges.

The REST API served a page's RDF, its Subjects as JSON, a Subject as JSON, and
(via #1090) a Subject's RDF, in native or ontology-mapped projections — none of
it reachable from the UI. This adds three things:

  • A per-subject export menu in each expanded Data tab row, beside the ID: JSON,
    then Turtle and TriG for each readable projection.
  • A page-level export menu in the Data tab header: page-subjects JSON, then
    per-projection Turtle/TriG of the page RDF. The two menus share one labelling
    scheme so they read as one system.
  • <link rel="alternate"> autodiscovery tags (Turtle + TriG, native projection)
    in the head of pages that carry NeoWiki data.

The menus are driven by the projections the viewing user may read. SubjectsAction
exposes that list as the wgNeoWikiRdfProjections JS config var, filtered
server-side by filterReadableProjectionNames() so a restricted Mapping page title
never reaches a reader who cannot see it. A later per-wiki choice to hide a
projection then becomes a server-side filter with no UI change.

Menu item URLs carry explicit format= parameters and percent-encode the projection
name; each opens in a new tab so the Data tab state is not lost (Codex 1.14 menu-item
anchors cannot set a target, so navigation happens on selection). Autodiscovery links
are emitted only when the page has Subjects, so the advertised endpoint never 404s.

Tests: Vitest covers the URL/label derivation (ordering, native-vs-mapping labels,
projection encoding). PHP integration covers the config var and its permission
filtering, and the head tags being present on a page with Subjects and absent on one
without.

UI check: the Data tab (?action=subjects) of a page with subjects and an ontology
mapping — e.g. the demo Pablo Picasso page. Expand a subject row for the per-row
Export menu; use the header Export for the whole page.

AI-authored — Claude Code, Opus 4.8 (max); detailed spec (issue + lead decisions and recon) steered by @JeroenDeDauw, no human revisions mid-task; diff not yet human-reviewed; PHPUnit (1835) + Vitest (1048) + phpcs/phpstan green locally, all export endpoints returned 200 with the expected content-types and both head tags verified live, UI screenshotted headless and reviewed by the lead session; CI green.

JeroenDeDauw and others added 2 commits July 19, 2026 22:43
…overy

Fixes #1095

Stacked on #1090, whose per-subject RDF endpoint these menus link to; based on
feature/subject-rdf-export so the diff is only this work. GitHub retargets to
master once #1090 merges.

The REST API served a page's RDF, its Subjects as JSON, a Subject as JSON, and
(via #1090) a Subject's RDF, in native or ontology-mapped projections — none of
it reachable from the UI. This adds three things:

- A per-subject export menu in each expanded Data tab row, beside the ID: JSON,
  then Turtle and TriG for each readable projection.
- A page-level export menu in the Data tab header: page-subjects JSON, then
  per-projection Turtle/TriG of the page RDF. The two menus share one labelling
  scheme so they read as one system.
- `<link rel="alternate">` autodiscovery tags (Turtle + TriG, native projection)
  in the head of pages that carry NeoWiki data.

The menus are driven by the projections the viewing user may read. SubjectsAction
exposes that list as the `wgNeoWikiRdfProjections` JS config var, filtered
server-side by filterReadableProjectionNames() so a restricted Mapping page title
never reaches a reader who cannot see it. A later per-wiki choice to hide a
projection then becomes a server-side filter with no UI change.

Menu item URLs carry explicit `format=` parameters and percent-encode the
projection name; each opens in a new tab so the Data tab state is not lost (Codex
1.14 menu-item anchors cannot set a target, so navigation happens on selection).
Autodiscovery links are emitted only when the page has Subjects, so the advertised
endpoint never 404s.

Tests: Vitest covers the URL/label derivation (ordering, native-vs-mapping labels,
projection encoding). PHP integration covers the config var and its permission
filtering, and the head tags being present on a page with Subjects and absent on
one without.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The head-tag test matched only the path substring, so a regression dropping the
PROTO_CANONICAL expansion to a relative href would have shipped silently. Assert
the hrefs are absolute so the canonical-URL behavior is locked.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@JeroenDeDauw
JeroenDeDauw marked this pull request as ready for review July 19, 2026 22:31
@JeroenDeDauw
JeroenDeDauw merged commit f5c5edb into feature/subject-rdf-export Jul 19, 2026
9 checks passed
@JeroenDeDauw
JeroenDeDauw deleted the feature/data-access-links branch July 19, 2026 22:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant