Yes. A FEP that allows definition of “Compliance Profiles” has been discussed a number of times. Explicitly disallowing extensions is new idea to me. But I imagine compliance profile to mean something like:
This endpoint or actor exposes [these] capabilities and behaviour, as defined in [these] FEP’s.
I’ve drawn a diagram to accompany my thoughts (note: names/terminology are merely examples):
So this is just brainstorm how to slice stuff into more reusable chunks, creating “Lego bricks” as FEP’s and “Lego kits” are the Compliance profiles. An endpoint/actor may support multiple compliance profiles. On top of these profiles apps can add their app-specific “magic sauce”. Core interoperability is guaranteed on the compliance profile level.
I didn’t draw the ActivityStreams vocabulary in the diagram above. It is positioned as some kind of foundational vocab, providing social primitives (the “atoms” of social apps, as it were). Now Valueflows might be just as foundational as we discussed in the toots.
OTOH it may also be more like a Compliance Profile. If I look at the Valueflows ontology model, which is quite intricate, then I’d be inclined to see it like that. There’s be multiple “lego blocks” in that model, multiple FEP’s, if you want to offer it for the broadest possible interoperability.
I don’t know how I would slice VF into building blocks, but I see “Planning”, “Process flow” (or workflows), “Roles”, etc. Blocks that have broader use than Valueflows alone… maybe. Take “Roles” for instance, and this is already part of ForgeFed. Are these concepts incompatible, or should they share the same definition?
Yes, indeed. What is interesting to observe is the distinction between a “business domain” and an “application domain”.
In the diagram above I explicitly did not refer to a concept of “Microblogging”, as it is very arbitrary what that means. It is an application domain. Specific to a type of app.
They are less valuable to achieving broad interoperability when compared to considering business domains. Business domains refer more to actual activity people do to satisfy particular needs. The concepts in these models are generally more app / technology independent.
In the “forge federation” community and to @fr33domlover I mentioned that “federation of code forges” is also indicating an application domain. A code forge is a rather arbitrary bundling of features in an online platform. It is less valuable, and even risky, to analyse models from this perspective.
What you actually want is to federate the real-world processes and activities that are involved with Software Development - the top-level business domain. This domain can be broken down into many sub-domains, still all business domains (e.g. Revision Control, Issue Tracking, Project Management, etc.)