Distribute frozen federation corpus by concept destination
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b
This commit is contained in:
parent
3e3191549a
commit
372f671eef
81 changed files with 14146 additions and 99 deletions
|
|
@ -0,0 +1,114 @@
|
|||
# ActivityPub Actors and Followers
|
||||
|
||||
## Source Type
|
||||
|
||||
Standard. W3C ActivityPub (REC) with Activity Streams 2.0 vocabulary for
|
||||
federated social actors, inboxes, and follower relationships.
|
||||
|
||||
## Domain
|
||||
|
||||
Federated social graphs, actor identity, following/followers, and server-side
|
||||
account representation.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
ActivityPub treats users as server-side actors with inboxes and outboxes. A
|
||||
person may have several actors across servers, mapping well to contextual
|
||||
identities and personas.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Actor**: Activity Streams object (Person, Service, Group, Organization,
|
||||
Application) with `inbox`, `outbox`, `followers`, `following`, `liked`.
|
||||
- **Person actor**: human-associated actor on a federated server.
|
||||
- **Service / Application actor**: automated or app-mediated actor.
|
||||
- **Group actor**: collective actor with shared inbox/outbox.
|
||||
- **Follow activity**: actor A sends Follow to actor B; B may Accept or Reject.
|
||||
- **Followers / Following collections**: reverse-indexed social graph edges.
|
||||
- **preferredUsername**: handle local to the origin server.
|
||||
- **Actor ID (URL)**: globally unique actor URI, typically HTTPS profile URL.
|
||||
- **SharedInbox**: delivery optimization for addressing multiple actors.
|
||||
- **Public / followers-only addressing**: audience scoping for activities.
|
||||
- **WebFinger**: discovery of actor profile from `acct:user@domain`.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Actor | Server-hosted social entity with inbox/outbox; not necessarily one human. |
|
||||
| Person | Actor type for human-associated accounts. |
|
||||
| Follow | Directed activity establishing follower relationship. |
|
||||
| Follower | Actor who follows another actor. |
|
||||
| preferredUsername | Local handle on origin server. |
|
||||
| Actor ID | HTTPS URI identifying actor globally. |
|
||||
| Inbox / Outbox | Message endpoints for receiving/sending activities. |
|
||||
| Group (actor type) | Collective actor in ActivityPub sense. |
|
||||
| Service | Non-human automated actor type. |
|
||||
| acct: URI | Account identifier for WebFinger discovery. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Actor is the primary social identity unit**, hosted on an origin server.
|
||||
- **One human may operate multiple actors** across servers (implicit, not
|
||||
standardized as same-person link).
|
||||
- **Following is a social subscription**, not membership or authorization.
|
||||
- **Actor ID is globally unique** within the fediverse namespace.
|
||||
- **Server is authority** for actor existence and deletion.
|
||||
- **Groups and Organizations are actor types**, not separate provisioning models.
|
||||
- **No standardized account linking** across actors for same natural person.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- ActivityPub **Actor** maps to **Actor** (Person → Natural Person association
|
||||
via Account/Profile on origin server).
|
||||
- **Person actor** implies **Natural Person** operator but actor ≠ person.
|
||||
- **Service/Application actor** maps to **Artificial Agent**.
|
||||
- **Group actor** maps to **Community** or **Group** collective actor.
|
||||
- **Follow** maps to **Following Relationship** (directed, social).
|
||||
- **preferredUsername** + domain maps to **Identifier** in server **Scope**.
|
||||
- **Actor ID (URL)** maps to global **Identifier**.
|
||||
- Multi-server actors per person support S02, S09, S14 without mandatory
|
||||
synonymity.
|
||||
- **followers-only** audience maps to Scope/audience boundary on Profile.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Actor vs. User**: ActivityPub actor is server entity; apps say user.
|
||||
- **Person vs. Natural Person**: Person is actor type, not verified human.
|
||||
- **Group**: ActivityPub Group actor vs. LDAP/SCIM group vs. IAM group.
|
||||
- **Follow vs. Member**: following ≠ community membership unless separately defined.
|
||||
- **Account vs. Actor**: `acct:` suggests account, but actor is richer object.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| ActivityPub concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Actor (Person) | Actor + Profile + Account (on origin server) |
|
||||
| Actor (Service) | Artificial Agent + Service Account |
|
||||
| Actor (Group) | Community or Group collective actor |
|
||||
| Actor (Organization) | Organization collective actor |
|
||||
| Follow activity | Following Relationship |
|
||||
| Followers/Following collections | Relationship indexes |
|
||||
| preferredUsername | Identifier (local handle) |
|
||||
| Actor ID (URL) | Identifier (global) |
|
||||
| acct: URI | Identifier |
|
||||
| Origin server domain | Scope |
|
||||
| Inbox/Outbox | Operational endpoints (downstream) |
|
||||
| WebFinger | Discovery protocol (downstream) |
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Should cross-server actors for one Natural Person require explicit Synonymity
|
||||
Assertion, or remain unlinked by default?
|
||||
- Does ActivityPub Organization actor type map to Organization or Community
|
||||
depending on moderation model?
|
||||
- How should moved-to / moved-from actor migration (if used) map to Identifier
|
||||
Binding supersession?
|
||||
- Should followers-only audience be a Profile visibility Scope or separate
|
||||
Relationship attribute?
|
||||
|
||||
## References
|
||||
|
||||
- W3C ActivityPub — https://www.w3.org/TR/activitypub/
|
||||
- Activity Streams 2.0 — https://www.w3.org/TR/activitystreams-core/
|
||||
- WebFinger (RFC 7033) — https://datatracker.ietf.org/doc/html/rfc7033
|
||||
|
|
@ -0,0 +1,113 @@
|
|||
# FOAF Agent Person Group OnlineAccount
|
||||
|
||||
## Source Type
|
||||
|
||||
Semantic vocabulary. FOAF (Friend of a Friend) RDF vocabulary for persons,
|
||||
agents, groups, and online accounts.
|
||||
|
||||
## Domain
|
||||
|
||||
Semantic web social identity, person/agent distinction, and account
|
||||
representation.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
FOAF distinguishes persons, agents, organizations, groups, accounts, and
|
||||
membership-like properties — an early explicit separation of actor, account,
|
||||
and online presence.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **foaf:Person**: a person (human); may have name, homepage, depiction.
|
||||
- **foaf:Agent**: anything that can do things; superclass of Person, Organization,
|
||||
Group.
|
||||
- **foaf:Organization**: collective agent with members and name.
|
||||
- **foaf:Group**: collective agent with `member` property linking to agents.
|
||||
- **foaf:OnlineAccount**: account on a service; links via `accountServiceHomepage`
|
||||
and `accountName`.
|
||||
- **foaf:OnlineChatAccount / OnlineGamingAccount**: specialized account types.
|
||||
- **foaf:member**: agent belongs to group (inverse of Group membership).
|
||||
- **foaf:knows**: social acquaintance link between agents (not authorization).
|
||||
- **foaf:mbox / mbox_sha1sum**: email or hashed email identifiers.
|
||||
- **foaf:openid**: OpenID identifier for agent.
|
||||
- **foaf:Document / Image**: non-agent resources.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Person | Human being in FOAF sense. |
|
||||
| Agent | Anything capable of action; includes persons and collectives. |
|
||||
| Organization | Named collective agent. |
|
||||
| Group | Collective agent with explicit members. |
|
||||
| OnlineAccount | Presence on a service with account name. |
|
||||
| member | Membership link from group to agent. |
|
||||
| knows | Social network acquaintance between agents. |
|
||||
| accountName | Handle on a service. |
|
||||
| accountServiceHomepage | Service URL defining account namespace. |
|
||||
| mbox | Email identifier (often `mailto:` URI). |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Agent is the root actionable type**; Person is a specialization.
|
||||
- **Person is explicitly human**, separate from accounts.
|
||||
- **OnlineAccount is not the person**; it is an account on a service linked
|
||||
to an agent.
|
||||
- **Groups and Organizations are agents** with member properties.
|
||||
- **Social knows is weak affiliation**, not trust or authorization.
|
||||
- **Identifiers (mbox, openid) are properties**, not first-class scoped objects.
|
||||
- **RDF graph allows multiple incomplete assertions** about same agents.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- FOAF **Person** maps closely to **Natural Person**.
|
||||
- FOAF **Agent** maps to **Actor**.
|
||||
- FOAF **Organization** / **Group** map to **Organization** / **Group**
|
||||
collective actors.
|
||||
- FOAF **OnlineAccount** maps to **Account** with service **Scope** defined
|
||||
by `accountServiceHomepage`.
|
||||
- **accountName** maps to **Identifier**.
|
||||
- **member** maps to **Membership Relationship**.
|
||||
- **knows** maps to **Affiliation Relationship** (social, weak).
|
||||
- FOAF is strong evidence for **P1** (actor root) and **P2** (person ≠ account).
|
||||
- Supports S01, S08, S09 with explicit person/account split.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Agent vs. Artificial Agent**: FOAF Agent includes humans; canon Artificial
|
||||
Agent is non-human only.
|
||||
- **Group vs. Community**: FOAF Group is generic collective; community implies
|
||||
participation norms.
|
||||
- **OnlineAccount vs. Profile**: FOAF account is service presence; profile is
|
||||
broader presentation surface.
|
||||
- **knows vs. Following**: knows is bidirectional acquaintance; ActivityPub
|
||||
Follow is directed.
|
||||
- **mbox vs. Identifier**: mbox is contact + identifier; conflation risk.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| FOAF concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Person | Natural Person |
|
||||
| Agent | Actor |
|
||||
| Organization | Organization |
|
||||
| Group | Group |
|
||||
| OnlineAccount | Account |
|
||||
| accountName | Identifier |
|
||||
| accountServiceHomepage | Scope (service namespace) |
|
||||
| member | Membership Relationship |
|
||||
| knows | Affiliation Relationship |
|
||||
| mbox / openid | Identifier |
|
||||
| depiction / name | Profile attributes |
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Should FOAF OnlineAccount always imply Account, or sometimes Profile only?
|
||||
- How should `mbox_sha1sum` map for privacy-preserving synonymity (weak match)?
|
||||
- Does FOAF Group map to Group only, or also Community when informal?
|
||||
- Should knows remain Affiliation, or split into Following vs. acquaintance?
|
||||
|
||||
## References
|
||||
|
||||
- FOAF vocabulary specification — http://xmlns.com/foaf/spec/
|
||||
- FOAF 0.99 RDF schema — http://xmlns.com/foaf/0.1/
|
||||
|
|
@ -0,0 +1,112 @@
|
|||
# Schema.org Person Organization Membership
|
||||
|
||||
## Source Type
|
||||
|
||||
Semantic vocabulary. Schema.org types and properties for Person, Organization,
|
||||
membership, and role-like affiliations.
|
||||
|
||||
## Domain
|
||||
|
||||
Structured data about people and organizations, SEO/social graphs, and
|
||||
membership representation on the web.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
Schema.org distinguishes persons, organizations, membership, employee roles,
|
||||
and affiliation properties — widely used for web-scale person/org modeling.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **Person**: living human; properties include `name`, `email`, `identifier`,
|
||||
`sameAs`, `affiliation`, `worksFor`, `memberOf`.
|
||||
- **Organization**: business, club, or other collective; `member`, `employee`,
|
||||
`department`, `subOrganization`, `parentOrganization`.
|
||||
- **OrganizationRole**: intermediate type linking person to organization with
|
||||
`roleName`, `startDate`, `endDate`.
|
||||
- **member / memberOf**: reciprocal membership between Person and Organization.
|
||||
- **employee / worksFor**: employment relationship properties.
|
||||
- **affiliation**: organization a person is affiliated with (looser than member).
|
||||
- **sameAs**: URL of related entity — often used for weak equivalence/synonymity.
|
||||
- **identifier**: PropertyValue or Text for external IDs.
|
||||
- **SportsTeam / PerformingGroup**: specialized Organization subtypes.
|
||||
- **ProgramMembership**: membership in a program with tier/benefits.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| Person | Human being in structured data. |
|
||||
| Organization | Collective entity (company, club, NGO). |
|
||||
| memberOf | Person belongs to Organization. |
|
||||
| member | Organization has Person as member. |
|
||||
| employee | Person employed by Organization. |
|
||||
| worksFor | Inverse employment link. |
|
||||
| affiliation | Looser org association for Person. |
|
||||
| sameAs | Related/equivalent resource URL (weak linking). |
|
||||
| OrganizationRole | Named role with temporal bounds. |
|
||||
| subOrganization | Org hierarchy child. |
|
||||
| identifier | External ID for entity. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Person means human** in schema.org intent.
|
||||
- **Membership and employment are properties**, not reified relationship objects
|
||||
(except OrganizationRole).
|
||||
- **sameAs is informal equivalence** between web resources, not verified identity.
|
||||
- **Organizations can nest** via subOrganization/parentOrganization.
|
||||
- **Roles can be typed** via OrganizationRole with dates.
|
||||
- **No authentication or authorization** semantics.
|
||||
- **Properties are multi-valued**; one person can have many memberships.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- Schema.org **Person** maps to **Natural Person**.
|
||||
- **Organization** maps to **Organization** collective actor.
|
||||
- **memberOf / member** map to **Membership Relationship**.
|
||||
- **employee / worksFor** map to **Affiliation Relationship** or employment
|
||||
specialization of Membership.
|
||||
- **affiliation** maps to **Affiliation Relationship** (looser).
|
||||
- **OrganizationRole** maps to **Role** relationship with temporal bounds.
|
||||
- **subOrganization** maps to structural relationship between Organization
|
||||
actors (child/parent).
|
||||
- **sameAs** maps to **weak Synonymity Assertion** between web resources —
|
||||
high conflation risk if treated as strong link.
|
||||
- **identifier** maps to **Identifier** PropertyValue.
|
||||
- Supports S03 (sub-orgs), S07 (informal groups as Organization subtypes), S08.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **Person vs. Profile**: schema.org Person is often used for public profile page.
|
||||
- **member vs. employee**: overlapping employment semantics; not always distinct.
|
||||
- **sameAs vs. Synonymity**: sameAs is SEO linking, not identity proofing.
|
||||
- **Organization vs. Community**: SportsTeam/PerformingGroup blur social vs. org.
|
||||
- **Role vs. OrganizationRole**: roleName may be job title or permission label.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| Schema.org concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| Person | Natural Person |
|
||||
| Organization | Organization |
|
||||
| memberOf / member | Membership Relationship |
|
||||
| employee / worksFor | Affiliation or employment Membership |
|
||||
| affiliation | Affiliation Relationship |
|
||||
| OrganizationRole | Role + Membership with temporal bounds |
|
||||
| subOrganization | Organization hierarchy Relationship |
|
||||
| sameAs | Weak Synonymity Assertion (caution) |
|
||||
| identifier | Identifier |
|
||||
| ProgramMembership | Membership Relationship (program scope) |
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Should sameAs ever promote beyond weak Synonymity without additional evidence?
|
||||
- Does OrganizationRole warrant a canonical temporal Relationship subtype?
|
||||
- How should ProgramMembership map vs. Community membership?
|
||||
- Should subOrganization be a distinct Relationship type or Organization attribute?
|
||||
|
||||
## References
|
||||
|
||||
- Schema.org Person — https://schema.org/Person
|
||||
- Schema.org Organization — https://schema.org/Organization
|
||||
- Schema.org OrganizationRole — https://schema.org/OrganizationRole
|
||||
- Schema.org sameAs — https://schema.org/sameAs
|
||||
|
|
@ -0,0 +1,108 @@
|
|||
# WebID and Solid Profile
|
||||
|
||||
## Source Type
|
||||
|
||||
Standard and ecosystem specification. WebID (W3C CG) for decentralized
|
||||
identifiers; Solid Protocol for user-controlled data pods and profiles.
|
||||
|
||||
## Domain
|
||||
|
||||
Decentralized identity-style profile discovery, user-controlled storage, and
|
||||
WebID-based identification.
|
||||
|
||||
## Why This Source Matters
|
||||
|
||||
WebID/Solid support user-controlled profiles and decentralized identity-style
|
||||
profile discovery, relevant to persona, identifier, and data-sovereignty
|
||||
semantics.
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- **WebID**: HTTP(S) URI identifying an agent; dereferencing yields profile
|
||||
document (RDF).
|
||||
- **WebID profile document**: RDF description of agent with type, name,
|
||||
certificates, and links.
|
||||
- **Solid Pod**: user-controlled personal data store with access control.
|
||||
- **Solid Profile**: extended profile in pod with extended attributes and
|
||||
preferences.
|
||||
- **WebID-OIDC**: bridge binding OIDC authentication to WebID URI.
|
||||
- **Agent type in profile**: self-described person or organization.
|
||||
- **ACL (WAC / ACP)**: resource-level access control on pod resources.
|
||||
- **Type Index**: registry of resource types in a pod.
|
||||
- **Identity provider linkage**: OIDC issuer associated with WebID.
|
||||
|
||||
## Relevant Terminology
|
||||
|
||||
| Term | Source meaning |
|
||||
| --- | --- |
|
||||
| WebID | HTTP URI identifying an agent; profile at same URL. |
|
||||
| Profile document | RDF at WebID URI describing the agent. |
|
||||
| Pod | User-controlled storage space. |
|
||||
| Solid Profile | Profile data stored in pod. |
|
||||
| Agent | Entity described by WebID (person or org). |
|
||||
| WebID-OIDC | OIDC flow producing ID token with WebID claim. |
|
||||
| ACL | Access control on pod resources. |
|
||||
| Type Index | Discovery of pod resource categories. |
|
||||
| issuer | OIDC provider linked to WebID authentication. |
|
||||
|
||||
## Modeling Assumptions
|
||||
|
||||
- **Identifier (WebID URI) is primary**; profile is dereferenceable description.
|
||||
- **User controls data placement** in pod, not only profile attributes.
|
||||
- **Agent self-describes** type (person/org) in RDF profile.
|
||||
- **Authentication can bind OIDC subject to WebID** via WebID-OIDC.
|
||||
- **Access control is resource-centric** on pod, separate from identity record.
|
||||
- **No central directory**; discovery via URI dereferencing.
|
||||
- **Multiple profiles/pods per person** possible across providers.
|
||||
|
||||
## Identity-Canon Implications
|
||||
|
||||
- **WebID URI** maps to **Identifier** (globally dereferenceable).
|
||||
- **Profile document** maps to **Profile** with RDF attributes.
|
||||
- **Pod** maps to user-controlled **Scope** for data storage.
|
||||
- **Agent in profile** maps to **Actor** (Natural Person or Organization).
|
||||
- **WebID-OIDC binding** maps to **Synonymity Assertion** / **Identifier
|
||||
Binding** between OIDC `sub`+`iss` and WebID URI.
|
||||
- **ACL** maps to authorization projection on resources in pod Scope.
|
||||
- Supports S14 (pseudonymous/scoped identity), S02 (multiple profiles), user
|
||||
sovereignty goals from ResearchSeed.
|
||||
|
||||
## Terminology Conflicts
|
||||
|
||||
- **WebID vs. DID**: both decentralized identifiers; different ecosystems and
|
||||
resolution models.
|
||||
- **Profile vs. Account**: Solid profile is data surface; may not include
|
||||
login credentials on same system.
|
||||
- **Agent vs. Actor**: WebID agent is self-described entity; canon Actor is
|
||||
broader participation root.
|
||||
- **Identity vs. WebID**: developers equate WebID with whole identity.
|
||||
- **ACL vs. Authorization Principal**: pod ACL uses WebID URIs as agents.
|
||||
|
||||
## Candidate Canonical Mappings
|
||||
|
||||
| WebID/Solid concept | Candidate canonical concept |
|
||||
| --- | --- |
|
||||
| WebID URI | Identifier |
|
||||
| Profile document | Profile |
|
||||
| Solid Pod | Scope (user-controlled data) |
|
||||
| Agent (in RDF) | Actor |
|
||||
| WebID-OIDC binding | Identifier Binding / Synonymity Assertion |
|
||||
| OIDC iss + sub | Scoped Identifier |
|
||||
| ACL agent | Authorization Principal (WebID URI) |
|
||||
| Type Index | Profile/discovery metadata |
|
||||
| Pod resource | Resource (downstream) |
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Should WebID URI be a distinct Identifier subtype vs. generic HTTP URI?
|
||||
- How should WebID-OIDC binding strength compare to OIDC pairwise sub (S14)?
|
||||
- Does pod Scope warrant a canonical "Data Scope" specialization?
|
||||
- Should Solid ACL remain purely authorization projection, or inform
|
||||
Relationship types for resource sharing?
|
||||
|
||||
## References
|
||||
|
||||
- Solid Protocol — https://solidproject.org/TR/protocol
|
||||
- WebID 1.0 (community spec) — https://www.w3.org/2005/Incubator/webid/wiki/Identity_Providers
|
||||
- WebID-OIDC — https://solid.github.io/webid-oidc-spec/
|
||||
- Solid Access Control (ACP) — https://solidproject.org/TR/acl-spec
|
||||
Loading…
Add table
Add a link
Reference in a new issue