Indeed, similar to schema.org, though that is all a single huge ontology, designed for universal applicability and therefore often quite abstract in terminology use. Also it is why they are very conservative in adding new terms to the vocabulary. In the more domain-oriented pattern library there’s more freedom to define your own variants, but you make a choice then on how likely its widespread use will become. I envision it as a sort of NPM for micro ontologies, where you can figure out the usage metrics.
Quoting from @dansup in a related fedi thread:
Implementing new ActivityPub object types unused by other projects is fun!
I don’t have to worry about compatibility, and I get to define my own object schema
#pixeldev #activitypub
My response:
Not particular to your efforts, but in general:
There is however the person that comes after you to consider. Should they contact you? Dive into the codebase to figure out what you did?
A big challenge for fedi is how to get alignment and consensus on the interoperability constructs to use. Right now its an ‘everybody for themselves’ kinda thing.
And subsequent reaction:
I agree. I plan on adding federation documentation.
My long term goal is to adopt a machine readable ActivityPub implementation schema for FediDB with crowdsourced data for each project so one can build and test against real world objects.
Delighted to hear this, @dansup. Main keyword here is “crowdsourced”, as there will be Process involved…
How can we create said process so that an inclusive, active and open community emerges that productively creates these extensions? A community where cross-pollination occurs and we collectively drive each other onwards and upwards?
PS. Note that for @cjs Go-Fed and the GoToSocial impl. based on top of it, a discussion is ongoing how to support extensions. Ideally we should bring insights and discussion to SocialHub and related to other subjects, such as FEP process.