feat(spaces): show member names instead of bare ORCIDs in space user listings - #695
Merged
Conversation
…listings The Approved Members, Self-Assigned/Observers and Pending Members tables on a space's About tab rendered most agents as bare ORCID digits. Nanodash resolves a name client-side only via UserData (get-all-user-intros), which covers just the agents who published a key introduction of their own -- for https://w3id.org/spaces/semantics/2026-eu that was 4 of 97 members. The names are in the data already, so the listing queries now return them as a member_label companion column: the canonical foaf:name mirrored into the current space state when present, otherwise the foaf:name asserted for that agent in the pubinfo of the grant nanopublication. Full label coverage on every space sampled, at no measurable query cost (330 rows in ~0.9s). Purely self-declared claims that carry no name anywhere still show their IRI. Views resolve to their latest version, but queries are pinned by exact IRI, so the three ref-scoped constants have to be bumped here for the change to take effect on space pages -- AboutSpacePanel drives these tables from the ref-scoped queries, not from the views' own gen:hasViewQuery, whenever the ref root is known. Published query supersedes: - LIST_SPACE_MEMBERS_REF RA-90ZiE (supersedes RAJ15No3) - LIST_SPACE_OBSERVERS_REF RANXPEIi (supersedes RAt8PKQ2) - LIST_SPACE_NON_APPROVED_REF RAoX3Htu (supersedes RAVsaIwA) The corresponding IRI-keyed queries (used as the no-refRoot fallback) and the three view nanopubs were superseded alongside them, so both paths agree. Verified end-to-end against a local instance: all three tables render names and keep their existing headers, with member_label hidden as a label companion. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Npfb25jWo6cLNjKbHZPtim
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The Approved Admins/Maintainers/Members, Self-Assigned/Observers and Pending Admins/Maintainers/Members tables on a space's About tab rendered most agents as bare ORCID digits.
Nanodash resolves an agent name client-side in
NanodashLink, but only viaUserData→get-all-user-intros, which covers just the agents who published a key introduction of their own. Most role holders of a space never did. Forhttps://w3id.org/spaces/semantics/2026-euthat was 4 named out of 97 members.Fix
The names are already in the data, so the listing queries now return them as a
member_labelcompanion column, resolved in two steps:foaf:nameon the agent in the current space-state graph — canonical, from the agent's own introduction;foaf:nameasserted for that agent in the pubinfo of the grant nanopublication (Nanodash writes this whenever an agent placeholder is filled).QueryResultTablehides a_labelcompanion and renders it as the link text, andFilteredQueryResultDataProvideralready sorts a column on its_label, so no rendering code changes. Default row order now follows the display name (tier first for members).Full label coverage on every space sampled, at no measurable cost (330 rows in ~0.9 s). Agents whose grant carries no name either — purely self-declared claims — still show their IRI; that name was never asserted anywhere.
Why a code change is needed
Views resolve to their latest version automatically, but queries are pinned by exact IRI. And
AboutSpacePaneldrives these three tables from the hard-coded ref-scoped queries (root_np-keyed), not from the views' owngen:hasViewQuery, whenever the ref root is known — the view query is only the fallback. So the constants have to be bumped here for the change to reach a real space page.LIST_SPACE_MEMBERS_REFRA-90ZiEE8OomcMz4np_IoQtsodQjyycUKfRPMDI67ju4RAJ15No3…LIST_SPACE_OBSERVERS_REFRANXPEIihP6m2ozdLr6KTw4Jw9fKk6BxbI3sGVOuyYUzQRAt8PKQ2…LIST_SPACE_NON_APPROVED_REFRAoX3HtuHttjxGWkdPc9tzF11hNrTiD2fm3OcQgR7WbxwRAVsaIwA…The corresponding IRI-keyed queries (the no-refRoot fallback) and the three view nanopubs were superseded alongside them, so both paths agree. All are published live and their supersede chains resolve.
Verification
Ran a local instance on the patched constants:
zonmw/antibiotica-resistentie-abr/541003005— members render as Margreet Bloemers, Tobias Kuhn, Anita C. Schürch, Ad Fluit, Herman Wunderink, JPM Coolen, Lieke B. van Alphen, Monika Anna Fliss, Rob Willems, Suzan Bongers (previously all but two were bare ORCIDs).fdo-conference-2026— members 3/3 named, observers 10/10 named on the first page, pending 10/10 named.Headers stay
member | tier | role assignments;member_labelis hidden as a companion.🤖 Generated with Claude Code
https://claude.ai/code/session_01Npfb25jWo6cLNjKbHZPtim