Domain model and vocabulary document

[evanp]

aschrijver noted in w3c/activitypub#397 that we don't have a well-understood domain model and glossary for understanding social protocols, extensions, vocabularies, vocabulary extensions, etc.

This seems like a more appropriate document or conversation to have in the SWICG level than an ActivityPub-specific discussion. So I suggest we move the conversation here.

[aschrijver]

Thank you. I closed the other issue. Here's the SocialHub topic I referred to: https://socialhub.activitypub.rocks/t/fep-process-guaranteeing-an-open-and-decentralized-ecosystem/3602/23

[aschrijver]

I responded in Fediverse Developer chat on the subject and will quote below:

---

@bumblefudge: as for evan's message, i think there is something to evan's idea that domain model is use-case wide, not protocol-specific

For sure it is. I've been making that point for a long time. When someone creates federation support for their use case they must map their business and/or application domain to that provided by the AS/AP ecosystem, and modeling message formats + msg exchange according to the application domain for Social Networking that is enforced by the ActivityPub protocol.

I.e. if my use case is in ECommerce business domain I may find this in my ubiquitous language:

• Shop offers Products
• Products added_to Shopping Basket
• Shopping Basket checked_out when Payment Received

How that maps to an AP extension (if "extension" is correct terminology) entirely depends on how the developer wants to model the federation taking place. And also on whether they foresee interop with other ECommerce.

From the three bullets above, what the shop offers may be the only thing of interest to federate (though theoretically there could be a Payment Provider service in the mix). Then comes the question "How to model that in AS/AP?" .. this could use as:Offer where the product might be goodrelations:ProductOrService. But maybe as:Offer isn't a good choice, because a ton of other fedi developers already use this in another meaning (in another domain bounded context).

But I don't know, because the relation of ActivityStreams wrt the domain of AS/AP isn't very clear. Some AS activities are like universal CRUD directives, while for others their meaning is undefined.

@bumblefudge: so maybe the domain modeling and use-case refinement could work together and help us find common languages to make requests for spec clarification
Yes, I think so

---

@melvincarvalho: so whats the core model, what's the base model, what's the extension model

Yes. I feel that the discussion on CG-wide/usecase-level discussion is only relevant wrt finding and documenting guidelines for writing extensions. And in addition by finding use cases that cannot easily be modeled in AS/AP to document what the protocol isn't suitable for. Certain architecture patterns aren't a good fit.

---

@melvincarvalho: in the end i translated [messages for my music app] to schema.org (yet another system!): MusicRecording and MusicGroup

Schema.org is likely a good choice. Very popular vocabulary, created for SEO purposes. It is not the only possible choice, and also your app is likely not the only one to target Music (top-level) domain use cases. With fedi interop in mind how can we ensure that the next app, even when it is made for slightly different use cases, can eventually integrate with yours? This is another aspect where the SocialCG could provide guidance.

There were several discussions in LD realms about the open world assumption which bring so much complexity. I think the assumption is (maybe Christine mentioned that somewhere) that AS/AP is also open world. But is that feasible/manageable? Right now people integrate very narrowly (mastodon-led microblogging integrations) and the assumption is closed world, and that fits well with JSON-only approach. In an open world situation I should be able to integrate my custom:Song with your schema:MusicRecording. Not likely to happen soon. We will create app-by-app custom bridges to create integrations.

One form of guidance might be:

• If you create an app in the Music domain, then use schema:MusicRecording as the object type for your songs.

Now this might be recommended by a FEP, but most likely it will evolve best if there'd be some kind of developer hub for everyone interested in the Music domain. Such hubs exist now for Podcasting and Forge Federation. They maintain their own specs. And they should do according to best-practices handed over by the SocialCG in order to have greatest interop guarantees.