Standardizing on a common Community domain as AP extension?

Fediversity Fediverse Futures
,
9

Wow, what a wonderful feedback. I truly :heart: love this @lynnfoster, thank you! I will - with my still very limited expertise on vocab modeling - try to provide some useful additional observations…

  • Keep concepts as low-level as possible in order to achieve greatest versatility in the model.
  • Many / most concepts can be tailored by means of user-defined classifications.
  • ValueFlows vs. AS/AP compatibility will probably mostly be defined in terms of model equivalency.
    • (Note: In AS this requires e.g. "type": ["Person", "foaf:Person"] which most apps don’t support currently)

Group is the central idea for this extension. In terms of AS I’d say:

  • An as:Group has members, which can be any concrete class representing any Actor type (this is standards-compliant).
  • The membership of an Actor is expressed by its roles, and that may use (one or more) as:Relationship.

The above already comes a long way, but is a bit different to ValueFlows in the types of actors / agents it allows.

Note that the AS definition of Group (“Represents a formal or informal collective of Actors.”) is already a specialization of the universal concept of Group (“Any Group of Objects”) and does not take roles into account, but also doesn’t define how membership must be modeled, which is fine.

In terms of AP and this Community extension I wonder if a special as:Collection type should be defined to represent membership. If feel followers / following doesn’t cut it. Maybe as:Group has a ‘members’ collection. But it would be quite breaking with what’s out there at present. In current group modeling efforts (e.g. here), we are trying to fit everything in the existing standard specs with as:Join, as:Follow, etc. (and having no consensus how this should be done interoperatively).

Some examples

Community in software (Discourse)

Discourse considers itself community software, and I have pitched the “[discourse] community has no boundary” paradigm there. I’ll use their software (e.g. this forum) as example when looking at various actor types being part of Community (as:Group):

  • First of all one Discourse installation (currently) represents one Community (the top-level as:Group).
  • Person actors are not directly represented, but represented by one or more user accounts they create.
    • OT: Bit of a problem here. At admin level the forum knows something about this, but it might be okay to map accounts directly to Persons. Alternatively there might be an implicit Person that has Relationships representing accounts, which raises new problems. Or Account can be a separate custom Actor type. Or… [feedback welcome]
  • Group actors exist in Discourse to represent sub-groups of the top-level Community group, and cannot be nested.
    • Communities in general may have nested groups (conceptually staff → moderators → admins are implicitly nested).
  • Application actors participate in the community too. There’s @system account interaction on behalf of the application.
    • There’s also @discobot community ‘butler’ bot. This can be an Application actor (though Service fits too).
    • Many softwares with membership concepts have bots, think e.g. IRC. There might a custom Bot actor type.
  • Service actors may be provided by various Discourse plugins, where the service reports / listens to the forum.
    • Think of Github, Discourse, Mattermost, Opencollective integrations.
    • Some of these are a bit of a stretch. In general I think certain (SaaS) Services can act as full-blown members.
  • Organization actors, like Persons are not directly represented, but there can be organization accounts.

It is interesting to think of what would happen if Discourse adopted the “community has no boundaries” paradigm…

  • There would be membership relationships between Communities (instances of discourse).
  • There’d probably be truly a concept of nested groups to be supported.
  • There might be additional requirements to define community intersections/overlap (“we only share these categories”).

And currently there would be limitations in the way cross-community membership can be defined. Identities are tied to instances and we lack SSO, identity providers, roaming identity or whatever other mechanism to provide this. Solving the Identity problem on fedi would be fantastic, but goes way beyond this topic.

Real-world communities

When representing communities as they exist in the real world, things come closer to ValueFlows. In that regard I’m wondering the following:

  • If a non-incorporated Community is funded by donations (e.g. via an OpenCollective), is it an economic agent? I think it is.
  • Given a paid SaaS Service can it be considered an economic agent? Or do you fall-back to the Organization that offers it?
  • What does it mean if an Organization is community member? Probably only some representatives participate in the community.

Shouldn’t VF also generalize to having any agent possibly be an ecomic agent? (Maybe you already do so, idk)

Just to be sure: You shouldn’t consider AS/AP as particular to social-only apps. Though it is now primarily used and presented for the social space, application is much broader. I make this argument in Positioning ActivityPub: De-Emphasize "Being Part of the Fediverse" as primary USP and the #fediversity:fediverse-futures category is about exploring these broader application / business domains. E.g. #software:forgefed is an example of a non-social application to extend AS/AP.

(PS. In your REA reference the REA Ontology Paper link is dead, here’s the latest archive.org [DOC] version)

2 Likes