@smallcircles@social.coop @box464@mastodon.social @ivan@bonfire.cafe While I think having domain-specific custom types is good, your answers show the problem with that approach, and why Fedi devs try to stick with the existing primitives as much as possible: there are already plenty of vocabularies available, I name schema.org, you named another 3... Which one do we want to use for maximum compatibility? Should everyone trying to make a federated e-commerce software just support vocabulary from 10 different sources because each first-party developer creates their own custom types? That breaks the inter-service compatibility... In that sense, using simpler types from the Activity Streams Vocabulary, and just extending them by adding the wanted properties, makes it a better experience for interoperability.
I think the Social Group behind AP proposals was working on an extended vocabulary spec, I don't know what the status is on that, though.

@Varpie @box464 @ivan

If you look at https://forgefed.org it chose to implement as:Offer in the context of "software development" toplevel domain (or perhaps "code forges" application domain).

Here we may say that it is alright to do so, if its use adheres the informatively specified functionality of "offering one object to another" in that general sense.

Yet I think I'd model this quite differently, and mapping to ActivityStreams is more a disadvantage than anything else. The spec has to describe the combinatorial logic of what to do when receiving as:Offer and needs a 'smart pre-processor' to determine the use case and bounded context.