Creating and Developing DS Popular Groups

• Groups may be public or private and system or user defined.
• Private groups require DS routing and have limited or no visibility in the wild.
• Public groups expose some content to the general internet at least in the form of their domain names if these are not in private DS.

The IRC subdomains of sameboat.network and their private subdomains are the workout use cases.

Basic Principle of Operation

The normal user members are the arbiters of Popular Groups

Like other DS domains, popular groups are defined by a natural language mechanism (NLM) in the DCP.

The definitions in English of a group domain are not derived from the implementation in backend technical infra. Rather the (Domain Controlled) English text worked by users interaction IS the definition of the domain which that infra realizes. The specific NLM is called domain controlled English (DCE). Via Grammatical Framework, other natural langs can be used, but I am only maintaining English which is normative.

For domain development purposes, the important distinction between users of a group or sameboat subdomain is not their Normal/DevOps status but their status/role as members of the group. DCP attempts to make what a DevOps user can do available to ordinary users via English channels.

DevOps Users

DCP creates common open format infra which can be maintained manually by DevOps users. In general, the focus for such developers will be the sources for this infra, databases, RDF, prolog, lisp, and haskell code associated with the DCP and conventional langs for end app refinements of DCP generated apps.

Because DCP must be evolving and dynamic an information hiding approach is taken in regards to the production of these open sources from the groups' English definition. DCP provides development hosts pre-configured with utilities such as Protege, visual code, compilers, etc for working and refinement of group domains and apps.

Common Structure of DS Groups

• A group member or set with owner or leader role. For system groups this is the system agency (𝔻CP).
• A group taxonomy. This defines terms used in group stories in terms of knowledge sources organized in conceptual frameworks called ontologies.
• The group structure, i.e. its position in the domain space ontology of groups. The system group is tx-authenticated (AKPERSON) users. DEVELOPER, and OPERATOR are subclasses of it. These are intrinsic groups in domain space and are complementary and orthogonal to User Defined Groups. Groups may have subgroups or be simple unitary groups.
• A group administrator. Group role enforcing single AKPERSON operator for the group and clarifying the distinction from the owners/leader role.

---

Subgroups inherit the taxonomy and administration of the parent group which they may extend. User Defined Groups do not start with a blank slate of just computer function but are created with points of contact with considerable real world knowledge about defined areas like People and Emotions, Geography, etc. which they use in their taxonomies and which is implicitly active with optional adaptations specific groups may choose. This active knowledge component is the principal distinguishing feature of groups in domain space.

The groups necessary for system operation are either built in or have been custom created so casual users that are not creating new kinds of groups do not have to be cognizant of group mechanics other than that they exist and have the nature described above. Because the mechanism is intended to be end-user articulated, in-context help and agent assistance is provided to make the operation as simple and easy as it can be while retaining the intended depth and flexibility.