Structured Community Memory

Structured community memory is the practice of preserving source-grounded records about people, sessions, projects, needs, offers, and follow-up opportunities so a community can recover context and make useful connections later. A durable system for community memory needs provenance, review, consent, freshness, and visibility boundaries so it does not become a hidden surveillance layer, task board, or stale profile directory.

Why It Matters

Communities lose useful context when knowledge stays trapped in calls, chats, private notes, or one person's memory. A structured memory system can help a group answer practical questions months later: who has worked on a problem, what was offered, what was asked for, which conversation started the thread, and what follow-up would be useful.

The hard part is not storing more data. The hard part is turning activity into records that remain trustworthy. Community memory needs clear sources, dates, review status, and limits on what should be remembered. Without those controls, a memory system can create false authority, expose private context, or turn social contribution into unwanted profiling.

Source Provenance

Every durable memory claim should point back to its source. Provenance models such as W3C PROV-O provide a useful pattern: records should retain enough information to explain where they came from, who or what generated them, and what activity produced them. For community memory, this usually means keeping links to sessions, transcripts, summaries, posts, wiki pages, or other source artifacts alongside the derived record.

Provenance is especially important when a transcript or meeting summary is converted into a data model. The derived profile, ask, offer, or follow-up note should not stand alone as if it were manually verified truth. It should carry its source label, observed date, confidence, and review state.

Community Profiles

Community profiles can help people find collaborators, but they should be treated as living, permissioned records rather than permanent dossiers. A useful profile might include a person's stated interests, skills, recent contributions, preferred ways to help, and public links. It should avoid private contact details, inferred personality labels, sensitive attributes, or stale claims that the person has not reviewed.

Schema.org Person offers a broad public vocabulary for describing people, but community profile systems usually need additional fields for consent, visibility, freshness, source provenance, and review status. A field may be technically valid and still be inappropriate to store or display.

A strong profile model should make these questions easy to answer:

• Who provided or confirmed this information?

• When was it last observed or reviewed?

• Is it public, member-only, private, or admin-only?

• Is the field stated by the person, inferred from activity, or added by an editor?

• When should the field expire or be rechecked?

Asks, Offers, And Follow-Up Signals

Asks and offers are lightweight collaboration signals. An ask describes what someone needs: feedback, review, a collaborator, a lead, a resource, or a decision. An offer describes what someone is willing to provide: expertise, time, code review, introductions, design help, facilitation, or domain knowledge.

Schema.org Offer is useful as a reference point for representing something being offered, but community offers are not always commercial listings. Many are informal, time-bound, conditional, or relational. They need context: who made the offer, when, where, under what constraints, and whether it is still current.

A follow-up workflow should treat asks and offers as signals for human review, not automatic assignments. The goal is to surface possible next steps without turning the community memory system into a project management board.

Human-Reviewed Recommendations

Structured memory can support recommendations such as suggested collaborators, relevant past sessions, related projects, or unanswered asks. These recommendations should be explainable and reviewable. Human-centered recommender systems research emphasizes that recommender systems should support human goals, context, transparency, and control rather than optimizing only for prediction.

For a community system, that means recommendations should show why they appeared. A useful recommendation might say that a person is suggested because they publicly offered protocol review in a dated session, or because a related wiki page links them to a project. It should not imply availability, obligation, endorsement, or private knowledge that the source does not support.

Privacy, Consent, And Retention

Structured memory systems should collect less than they can. Privacy frameworks and data protection principles point toward minimization, accuracy, storage limitation, purpose limitation, and appropriate security. In practice, a community memory system should define what it stores, why it stores it, who can see it, how long it should live, and how people can correct or remove it.

Useful guardrails include:

• Store public or consented profile fields before inferred fields.

• Mark sensitive or uncertain information as non-public or leave it out.

• Expire asks, offers, and availability signals unless refreshed.

• Keep review status visible to editors and reviewers.

• Separate source artifacts from public summaries when the source contains private or messy context.

This is not legal advice. It is a design constraint: memory that cannot be corrected, traced, or forgotten will eventually become a liability.

Relation To Personal CRM And Portal Primitives

Personal CRM focuses on one person's relationship memory: who they know, what they discussed, and what to follow up on. Structured community memory is broader. It asks how a group can maintain shared context across sessions, projects, profiles, threads, and wiki pages without flattening people into contacts.

In Portal terms, structured community memory should connect existing primitives rather than replace them:

• Profiles describe people and contributor identities.

• Events anchor sessions and source artifacts.

• Activity Items record dated signals that something happened.

• Threads track ongoing lines of work or thought.

• Projects represent concrete collaboration surfaces.

• Wiki Pages preserve durable, source-backed knowledge.

The wiki layer is where the pattern becomes explainable. The operational records can change, but the wiki page should help future contributors understand how to model, review, and use those records responsibly.

Open Questions

• What profile fields should be self-asserted only, and which can be editor-curated from public sources?

• How should a person review or correct structured memory about themselves?

• When should asks, offers, and follow-up signals expire by default?

• Which recommendations should be visible to the whole community, and which should stay behind an editor review surface?

• What is the smallest useful schema for a pilot without overbuilding a social graph?

Further Reading

• W3C PROV-O: https://www.w3.org/TR/prov-o/

• W3C ActivityStreams 2.0 Core: https://www.w3.org/TR/activitystreams-core/

• Schema.org Person: https://schema.org/Person

• Schema.org Offer: https://schema.org/Offer

• NIST Privacy Framework: https://www.nist.gov/privacy-framework

• GDPR Article 5 principles: https://gdpr-info.eu/art-5-gdpr/

• Wenger-Trayner introduction to communities of practice: https://www.wenger-trayner.com/introduction-to-communities-of-practice/

• Konstan and Terveen, Human-centered recommender systems: https://doi.org/10.1609/aimag.v42i3.18142

• Related Portal wiki page, Personal CRM: https://portal.raidguild.org/wiki/personal-crm