Spaces materializer doesn't normalize hasHelper/hasMaintainer RoleInstantiations (members invisible to get-space-members)

[tkuhn]

Summary

The spaces materializer does not normalize gen:RoleInstantiations for the gen:hasHelper and gen:hasMaintainer role predicates. They are left in the raw npa:bindingSubject / npa:bindingObject / npa:rolePredicate form instead of being resolved to the npa:forSpace / npa:forAgent / npa:inverseProperty (or npa:regularProperty) shape that every other role predicate gets.

Because get-space-members matches on npa:forSpace / npa:forAgent / npa:regularProperty|inverseProperty, helper- and maintainer-role members are invisible to it. Downstream this breaks Nanodash: e.g. term-definition lookups scoped to a space's members (get-term-definitions filtered by space.getUsers() pubkeys) drop definitions signed by a helper/maintainer agent, so the affected /part pages show no defining nanopub, no label (falling back to the trusty-code tail), no classes, and no associated views.

Evidence (live spaces repo at query.knowledgepixels.com)

Two RoleInstantiations for the same space, materialized differently:

Admin RI (normalized — works):

?ri a gen:RoleInstantiation ;
    npa:forSpace        <https://w3id.org/spaces/biochementity> ;
    npa:forAgent        <https://orcid.org/…> ;
    npa:inverseProperty gen:hasAdmin ;
    npa:viaNanopub      <…> .

Helper RI (raw — broken): <space> gen:hasHelper <bot>, np RAw_rkvLWknDwsYPqJLkrUu1rqDq45OeUsmKGwPrbebWU

?ri a gen:RoleInstantiation ;
    npa:bindingSubject <https://w3id.org/spaces/biochementity> ;         # not forSpace
    npa:bindingObject  <…/biochementity-bot> ;                            # not forAgent
    npa:rolePredicate  gen:hasHelper ;                                    # not inverseProperty
    npa:viaNanopub     <…RAw_rkv…> .

No forSpace / forAgent / inverseProperty triples are emitted.

This is specific to two predicates, not custom roles in general. Grouping all materialized RIs by regularProperty/inverseProperty vs. rolePredicate across the whole store:

• Normalized (have forSpace/forAgent/inverse|regularProperty): hasAdmin, hasObserver, hasGuest, hasTeamMember, hasHost, hasProjectLead, the 3pff/* roles, several wikidata props, … — many custom roles included.
• Raw only (rolePredicate, no forSpace/forAgent): gen:hasMaintainer (3) and gen:hasHelper (2) — nothing else.

So the Helper role definition (RAV50vIbaMl1Owh5M8cfTygJvuFVL9m6JWCqHJxccxm4o/helperRole, inverse property hasHelper) is recognized by get-space-roles but its member instantiations are never normalized.

Reproduce

• Space: https://w3id.org/spaces/biochementity (ref root https://w3id.org/np/RAfldXyar-OhYePUAyA7_vFqPwIrsLbApXibMsw5J0yw4)
• get-space-members (IRI- and ref-scoped) returns empty, though the space has a helper member.
• get-space-admins returns the 3 admins.
• Membership np: RAw_rkvLWknDwsYPqJLkrUu1rqDq45OeUsmKGwPrbebWU (<space> gen:hasHelper <…/biochementity-bot>).
• Nanodash symptom: /part?…&id=https://w3id.org/peh/biochementities/RAXLultl4AU7cROMceVhTXI0z3lh2x0ySLkYgi_JekrSs&context=https://w3id.org/spaces/biochementity/r/vocabulary — no defining np / label / views. (The bot …/biochementity-bot, hash 87310ad3…, is loaded in the registry; get-term-definitions finds the definition when its pubkey is passed and drops it otherwise.)

Expected

gen:hasHelper and gen:hasMaintainer RoleInstantiations should be normalized to npa:forSpace / npa:forAgent / npa:inverseProperty (per the role definition's regular/inverse declaration) exactly like hasAdmin, hasObserver, etc., so get-space-members surfaces them.

Notes

• Likely also affects anything relying on maintainer membership via hasMaintainer.
• A full re-materialization/re-ingest will probably be needed for already-loaded helper/maintainer instantiations after the fix.
• Nanodash-side, ResourcePartPage (and AboutPartPanel, DownloadRdfPage) hard-scope get-term-definitions to member/admin pubkeys with no fallback, which turns this materializer gap into a hard failure; tracked separately on the Nanodash side.

[tkuhn]

Correction / clarification after re-checking the live spaces repo.

"Never emitted" was too strong — the normalized row is present, but in the current-space-state (validated) graph (npa:hasCurrentSpaceState ?g), which is caught up:

RAw_rkv… npa:forSpace <…/biochementity> ; npa:forAgent <…/biochementity-bot> ;
         npa:inverseProperty gen:hasHelper ; npa:hasRoleType gen:MemberRole .

But that isn't the graph get-space-members reads. The deployed get-space-members (RA2eGba0…) sources its candidate RIs from the raw npa:spacesGraph (by design, so it can show unvalidated members with a ?validated flag), and there the helper RI is still un-normalized:

RAw_rkv… npa:rolePredicate gen:hasHelper ; npa:bindingSubject <…/biochementity> ;
         npa:bindingObject <…/biochementity-bot> .   # no forSpace / forAgent / inverseProperty

Consequences, re-tested live:

• get-space-members (ref, root_np …RAfldXyar…) → 0 rows. The helper is still not surfaced.
• Store-wide in npa:spacesGraph, every role predicate is normalized except hasHelper (2) and hasMaintainer (3); e.g. hasObserver has 57 normalized RIs there. So the gap is specifically these two predicates in the extraction graph, not the state graph.

Note: the space now also has a normalized hasAdmin RI for the same bot (RAHbEghp…) — a temporary manual admin-role workaround. get-space-admins surfaces that, but get-space-members filters hasAdmin out, so it doesn't mask this. If the earlier check saw the member "surfaced," it was likely reading the state graph directly or seeing that admin row.

Ask: normalize hasHelper/hasMaintainer into npa:forSpace/npa:forAgent/npa:inverseProperty in the npa:spacesGraph extraction (as all other predicates already are), so get-space-members — and thus the Nanodash space.getUsers() term-definition lookup — sees them without the admin workaround. (Alternative — sourcing get-space-members from the state graph — would drop unvalidated members, which contradicts its current design, so extraction normalization is the right fix.)

[github-actions]

🎉 This issue has been resolved in version 1.20.0 🎉

The release is available on:

• nanopub-query-1.20.0
• GitHub release

Your semantic-release bot 📦🚀