Account Profile -> Mode Profile?

Another 9k walk brings about another turning of the Clique Space(TM) soil and another chance to massage the ideas put in the patent. Perhaps, another chance to cast these ideas into the realm of prior art.

This idea development concerns the purpose of the Account Profile with regard to the generation of a Participant for a certain Clique. Now, let's be fair. The Account Profile concept appears in the patent because I felt that the Limiting Constraints a Participant could take would mostly be conditional on the role that an Active Affiliation (now an Identity) would assume. A role (an Affiliation) is associated with a role hierarchy - an Account Profile hierarchy. Now, this is exactly the idea that I retain when I change the name of the Account Profile to the Mode Profile. This blog entry is merely a product of an opportunity I have had to think more about the detail of this mechanism. One should find little to surprise ones self when given more time to deliberate an idea, my idea appears to have become more complicated. Still, I assert that I have preserved the intent as it was given in the patent.

The change of the name is both a clarification on the structural relationships between the other Elements, and an acknowledgement about how the Mode (nee Account) Profile's purpose fulfils the objectives of the Clique Space concept especially in relation to Participant creation and destruction. This clarification also promises to widen other avenues of exploration: 1. how the concept of constraint compromise is asserted and accepted, and 2. how Cliques can be used as a means of conveying all manner of information about individuals; information that these individuals want others to know by virtue of the fact that one has a Participant as a member of a Clique. The second of these ideas may be deliberated in a future entry, but the first is covered somewhat below...

The term Mode Profile conveys a better structural meaning than Account Profile: a Clique's medium is shaped by its mode. A Clique's medium is specified by the flattened Media Profile hierarchy union of all the Participant's constituent Connections. A Clique's mode is similarly specified by finding the union of the flattened a Mode Profile hierarchy - specified by the Participant's constituent Affiliations. Because a Clique's mode must cover the Clique's medium, every parameter of each Media Profile's Enabling Constraint must be specified by no more than one Limiting Constraint value of a corresponding Mode Profile, and every parameter must be specified exactly once.

Hence, every Enabling Constraints' parameter in the flattened Media Profile which the flattened Mode Profile hierarchy describes must be covered once, and once only by the flattened Mode Profile hierarchy. Doing this creates a tightly coupled relationship between a Mode Profile hierarchy and the Media Profile hierarchy the Mode Profile hierarchy provides Limiting Constraint values for. However, I believe that the exercise of care in crafting Media and Mode Profile hierarchies should prove this coupling to be extremely versatile... we'll see...

The case may certainly arise where a role provider certainly does not intend to restrict the function of a device to some tightly constrained range of operational freedom. In these cases, the Mode Profile has two tools: the "unspecified" Limiting Constraint value, and an indicator showing whether or not a Limiting Constraint will permit compromise.

The unspecified value is intended to allow a Mode Profile to explicitly say that a Clique may exist in which values freely vary in one or more parameters. This Limiting Constraint value is compatible with any Enabling Constraint parameter. Relationships might be able to be set up between parameters so that specific parameters may be set to determine how other parameters may vary. For instance, one Clique may exist where values can vary, but only if all participants vary them to the same values in unison. Alternatively, a Clique may exist where Participants may freely vary one or more parameters to whatever value each Participant desired. Additionally, a Clique may exist where one or more parameters may specify a range of values that other parameters may freely vary within. Yet other Cliques may exist where parameters may depend on some relationship between other parameters, and control of them may be encoded in a Clique control algorithm specified in the Media Profile or left to the mechanics of the external devices' collaboration to moderate.

Whether or not a Limiting Constraint will permit compromise (also used in other internal Elements than merely the Mode Profile) is intended to be a way to allow a Participant's medium to acquire Limiting Constraint values which contradict the values given from two or more internal Elements. The compromise indicator has two values: deny and permit. This indicator asserted by one source, will permit Clique Space some ability to determine whether this source or another source contradicting the first source should be expressed in the Participant. Compromise needs to be taken into account when dealing with contradicting Limiting Constraints from the following competing sources: 1. a device in terms of a Connection or its constituent Media Profiles, 2. the individual in terms of an Identity or an Axle, 3. the provider of a role in terms of an Affiliation or its constituent Mode Profiles, and 4 as a Limiting Constraint with an unspecified source provided when the Participant is to be created. This compromise indicator is used in 1. a Mode or Media Profile in relation to a specific medium or 2. unrelated to a specific medium in another internal Element within the scope of an identity or to a Limiting Constraint with an unspecified source.

As briefly stated above, a Limiting Constraint permitting compromise may also permit overriding by a value given without an internal Element source at the time a Participant is created. The Participant, if created, is indicated as the source to these type of Limiting Constraints. In any case, if two or more Limiting Constraints describing the same parameter are found, and none of these parameters deny compromise, then the Clique Space will respond first by informing the individual associated with Identity through a connected View enabled device, waiting for a time specified by the individual requesting formation. If, in any case, two or more Limiting Constraints relating to the same parameter but from different sources deny compromise, then no Participant can be created. Hence, an Identity cannot provide two or more Limiting Constraint values for a single Enabling Constraint parameter which do not allow compromise; at least one must allow compromise.

These mechanisms allow a Clique's medium and mode to be as flexible or as organised as the individual members might, by their membership of the Clique, permit. It would be interesting indeed to see a mechanism like this work.