@hrefna@chris@tchambers@help as the underdog, we (WordPress) have to still work on the "classic" features to keep up with the big networks, before we will be able to "do our own thing".
I was about to point to the informal practice of having a FEDERATION.md. I entered the ones I found in the wiki on #SocialHub "Guidelines for new #ActivityPub developers".
I guess this discussion boils down to having a best-practice guide on writing ActivityPub extensions.
If we use linked data, let that be describing LD best-practices. That should likely include how/when to reuse existing props/types from other ontologies.
And maybe rather *not* use those types/props, but defer to creating your own namespaced extension. Because choosing from existing ontologies would mean either standardization on that, or supporting full LD functionality/complexity.
But that would lead to horrible designs.. Receive an Offer? Go into huge if/then/else construct to determine from the props what kind of Offer we deal with.
For this we have namespacing to indicate the bounded context (consistency boundary) in which the activity lends its meaning.
For ActivityStreams the first project that manages to broadly popularize a particular activity, gets to decide its predominant meaning (in current fedi practice).
On 2) what is also interesting is to consider how suitable AS is as a generic set of social primitives, when the semantics of the activities aren't crystal clear.
For some activities things are easy, e.g. ones relating to CRUD-over-the-wire. But e.g. an as:Offer much less so.
I've seen Offer been discussed in very different (bounded) contexts, where semantics/meaning would be fundamentally different. These would have different (custom) props to distinguish them.