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.
Monday, October 29, 2012
Wednesday, October 24, 2012
Société Clique Space
Perhaps I illustrate the limits of my knowledge of the French language. C'est la vie...
Imagine that an individual within this world can determine which individual is responsible for every single bit of hardware and software - every device - one might come into contact with as one travels through life. Imagine an individual who can choose to ignore any device if they cannot readily determine who is responsible for a particular device. Imagine in this world, an individual who can record, in real time, the activity of any device one possesses, and can produce this device activity log as evidence of some interaction with other individuals at some future point in time.
This is Clique Space(TM). This concept uses the notion of constraints to provide a way for users to communicate mutual affinity between devices before these devices engage in a collaboration. Clique Space allows one individual to find any device possessed by an individual as easily as it will allow that individual to find an individual who possesses a device.
Technically, this mechanism exhibits many parallels with a nervous system. However, I am no authority on nervous systems, so my estimations on the similarity between Clique Space and a nervous system may be groundless, but I'd like that to be proven. My prototype is still incomplete, but I can now perhaps see what is left to be done.
Imagine that an individual within this world can determine which individual is responsible for every single bit of hardware and software - every device - one might come into contact with as one travels through life. Imagine an individual who can choose to ignore any device if they cannot readily determine who is responsible for a particular device. Imagine in this world, an individual who can record, in real time, the activity of any device one possesses, and can produce this device activity log as evidence of some interaction with other individuals at some future point in time.
This is Clique Space(TM). This concept uses the notion of constraints to provide a way for users to communicate mutual affinity between devices before these devices engage in a collaboration. Clique Space allows one individual to find any device possessed by an individual as easily as it will allow that individual to find an individual who possesses a device.
Technically, this mechanism exhibits many parallels with a nervous system. However, I am no authority on nervous systems, so my estimations on the similarity between Clique Space and a nervous system may be groundless, but I'd like that to be proven. My prototype is still incomplete, but I can now perhaps see what is left to be done.
Wednesday, October 3, 2012
An Intricate Mechanism.
Clique Space(TM) models collaborations as Cliques.
Cliques are made up of at least two Participants.
One Participant is the Clique's Owner.
Each of the Clique's Participants represents at least one device being used by an individual in the collaboration being modelled by the Clique.
The Clique has a medium which is determined by it's Owner and accepted by all other member Participants.
Each Participant has a mode which appropriately asserts how the member Participant's state conforms to that of the Owner.
The Clique's medium exposes the collaboration's characteristics to Clique Space.
A medium must be described by a flattened Media Profile hierarchy that contains a Media Profile root.
The root Media Profile describes the characteristics of the Clique Space components for a given Participant instance.
A Clique's medium is defined by a subset of the Owner's flattened Media Profile hierarchy.
All other member Participants must be able to describe the Clique's medium through flattening the Media Profile hierarchies of their constituent Connections.
A medium can be translated into a set of Enabling Constraint parameters.
A medium must be completely covered by the Participant's mode.
A mode is a set of Limiting Constraints which are primarily determined by a subset of the Owner's flattened Account Profile hierarchy.
The Clique's root Account Profile encodes the specific values that the Clique Space's data model take for a specific Participant.
Constituent Elements from a member's candidate may offer unspecified values or alternative value "compromises" to the set determined by flattening the nominated Account Profile hierarchies.
Limiting Constraints in an Account Profile flagged as not allowing compromises cannot be replaced by specific Limiting Constraints, whether from any other Element or unassigned.
All member Participants must be able to respond to changes in the Clique's mode which are made by the Owner to remain "in the Clique".
Member Participants leave their Clique.
Owner Participants disband their Clique.
A Clique will automatically disband should all member Participants leave.
The Owner can cede ownership to another member provided this other member accepts the title.
Member Participant candidates are made up of selected Connections and Affiliations, specific extra or compromise Limiting Constraints, and a selected Identity, all of which are used to determine the mode-form of a member Participant if created.
An Owner candidate specifies the same details as a member candidate, but also specifies a Clique's name.
Any Connection and Affiliation nominated in a candidate must have been "activated" against the same nominated Identity of the given candidate.
Any compromise or extra Limiting Constraint may only be specified from one of the nominated Affiliations or Connections, from the nominated Identity, from the Axle, or from one of the medium's Media Profiles.
Any number of extra Limiting Constraints unassigned to any given Element may be nominated in a candidate, and Limiting Constraints of this type are associated with the Participant they are expressed in should the Participant be created.
For any candidate, no more than one unassigned Limiting Constraint may cover an Enabling Constraint's parameter of the Clique's medium.
An unassigned Limiting Constraint must cover an Enabling Constraint's parameter of the Clique's medium.
A member candidate is asked to join an existing Clique, while an Owner candidate is asked to form a new Clique with one or more supplied member candidates.
A Clique Space knows of an indeterminate number of Element types, the first seven of which are:
Arrangements around a single Axle of instances from the remaining Elements represent a Client Device.
An instance of a node Media Profile or Connection can return a type which represents the type of device that can connect. Hence the reason why the number of Element types is indeterminate.
Limiting Constraints map to individual parameters of a Media Profile's Enabling Constraints.
One Enabling Constraint's parameter can only be covered by a single Limiting Constraint in any given Element.
A Participant's collection of Limiting Constraints express an individuals acceptance of the Clique's mode.
Zero or more Participants can be created from any Identity.
Every Participant must have an Identity, except where a Participant represents an unconnected device.
An Identity contains multiple Connections, any combination of which might be used in a Participant.
An Identity contains multiple Affiliations, any combination of which might be used in a Participant.
An Identity refers to a single Axle.
The expressed Connections and Affiliations within a single Identity instance are known as an Identity's constituents.
An Identity must contain no constituent with a Limiting Constraint that contradicts that of any other constituent.
A Connection associates an Axle with a node Media Profile.
A Connection contains the component that permits communication with the device in accordance with the associated Media Profile
A Media Profile contains the component that is used to decide whether a Participant using a medium which expresses the Media Profile has sufficient Limiting Constraint affinity to perform some action governed by the Media Profile.
An Affiliation associates an Axle with a node Account Profile.
The Axle associated in a Connection must be the Axle referred to in the Identities through which the Connection has been activated.
The Axle associated in an Affiliation must be the Axle referred to in the Identities through which the Affiliation has been activated.
The Axle represents the individual; a transcendent supervisory presence capable of possessing a device and using the device to participate in collaborations which are modelled as Cliques.
An individual, through a different, or even the same device or devices, may appear as one, two, or more Participants in the same Clique.
A device is something which can obtain a Connection to and exchange information with a Clique Space through an Agent Device.
An Agent Device is a type of device.
An administrator client is another type of device.
The administrator client renders Elements onto its View which have been projected from Agent Devices through which the administrator client has obtained Connections.
The administrator client provides a facility through which Agent Devices and Clique Spaces can be administrated.
The Agent Device is administered through its synaptic map.
A synaptic map is a type of Clique Space.
Agent Devices engage with other Agent Devices by creating synapses.
Agent Devices disengage with other Agent Devices by destroying synapses.
A synapse opens a channel through which transmitters are sent from one Agent Device to one other Agent Device.
A synapse on one Agent Device is a replication of another Agent Device's synaptic map.
A synapse is another type of Clique Space.
Agent Collaborations' Clique Spaces are Clique Spaces in which collaborative activity between external devices is recorded.
Agent Devices sharing direct membership of the Agent Collaboration are represented as Participants of the Agent Collaboration Clique Space's Clique.
There we go. A good summary. At the very least, a disclosure this detailed renders my technology prior art. I am not saying whether the summary I give is covered by my patent. I assert that this is the intent, but whether or not this is actually the case is not up to me.
Now, I appear still to have some (perhaps many) rather complicated unresolved issues. I am engineering a solution that will allow an Agent Device to transmit instructions to add and remove Elements' components to an administrator client. The administrator client must be capable of rendering "projected" Elements to its View of the Clique Space universe from the Agent Devices through which these transmissions are received. Agent Devices will also use the bulk of this mechanism to transmit components between themselves.
The thing about this whole Clique Space concept is that the data model described above is used to 1. model collaborations going on amongst Agent Devices and other external devices including the administrator client and to 2. determine which Agent Devices and which other external devices including the administrator client are recipients of changes in an Element's state. The Clique Space data model offers a simultaneous solution to the model and the controller pieces of the model-view-controller design pattern.
Point 2 of the above paragraph can be recast in this way: an Agent Device uses the data model to determine which other devices are interested in the state of Elements. This Agent Device will tell these other devices that the state of an Element has changed (an Element's component has been added or removed) if a particular device is registered as possessing an interest in this Element.
So, how is another device's interest in an Element registered in an Agent Device? Implementing the solution to this question is currently (and finally) occupying all my attention. The solution comes in two parts of its own.
In the first part, an administrator client (or any V/PM device) can receive information about the state of any Element from any Agent Device to which an external device is connected; potentially even from Clique Spaces other than the one or more Clique Spaces through which the external device's Connection's are obtained. The ability for the given external V/PM device to receive information about an Element is determined by the Limiting Constraints which are expressed in the serving Agent Device's Clique; a Clique created for any external device which also represents an instance of a Connection - an association between an Axle and a specific Media Profile type - through the given device to a Clique Space for which the Owner of the synaptic map's Clique (known by the engager Participant recorded as the Connection's originator component) transmits Element state.
The second part involves the transmission of element state information between Agent Devices through the Agent Device's Media Profile. The Agent Device's Media Profile exhibits the unique property in that the Participants in an Agent Collaboration's Clique are not transmissible between Agent Devices. An Agent Collaboration's Clique tells a particular Agent Device which other Agent Devices are interested in a particular Element. The fact that Participants in an Agent Collaboration's Clique are not transmissible avoids the possibility of infinite regress.
Participants generated from Connections which come from an Agent Device's Media Profile will appear in the serving Agent Device's Clique of the first part. The other Participant is generated from the external device's Connection. Both Participants of the serving Agent Device's Clique can be transmitted to other Agent Devices and to V/PM devices where constraints permit this transmission.
These questions make up the implementation of some very deep considerations I was entertaining when I conceived this concept. If I can actually implement the mechanisms I describe in the paragraphs above, I think I will have arrived at a proof of concept.
Cliques are made up of at least two Participants.
One Participant is the Clique's Owner.
Each of the Clique's Participants represents at least one device being used by an individual in the collaboration being modelled by the Clique.
The Clique has a medium which is determined by it's Owner and accepted by all other member Participants.
Each Participant has a mode which appropriately asserts how the member Participant's state conforms to that of the Owner.
The Clique's medium exposes the collaboration's characteristics to Clique Space.
A medium must be described by a flattened Media Profile hierarchy that contains a Media Profile root.
The root Media Profile describes the characteristics of the Clique Space components for a given Participant instance.
A Clique's medium is defined by a subset of the Owner's flattened Media Profile hierarchy.
All other member Participants must be able to describe the Clique's medium through flattening the Media Profile hierarchies of their constituent Connections.
A medium can be translated into a set of Enabling Constraint parameters.
A medium must be completely covered by the Participant's mode.
A mode is a set of Limiting Constraints which are primarily determined by a subset of the Owner's flattened Account Profile hierarchy.
The Clique's root Account Profile encodes the specific values that the Clique Space's data model take for a specific Participant.
Constituent Elements from a member's candidate may offer unspecified values or alternative value "compromises" to the set determined by flattening the nominated Account Profile hierarchies.
Limiting Constraints in an Account Profile flagged as not allowing compromises cannot be replaced by specific Limiting Constraints, whether from any other Element or unassigned.
All member Participants must be able to respond to changes in the Clique's mode which are made by the Owner to remain "in the Clique".
Member Participants leave their Clique.
Owner Participants disband their Clique.
A Clique will automatically disband should all member Participants leave.
The Owner can cede ownership to another member provided this other member accepts the title.
Member Participant candidates are made up of selected Connections and Affiliations, specific extra or compromise Limiting Constraints, and a selected Identity, all of which are used to determine the mode-form of a member Participant if created.
An Owner candidate specifies the same details as a member candidate, but also specifies a Clique's name.
Any Connection and Affiliation nominated in a candidate must have been "activated" against the same nominated Identity of the given candidate.
Any compromise or extra Limiting Constraint may only be specified from one of the nominated Affiliations or Connections, from the nominated Identity, from the Axle, or from one of the medium's Media Profiles.
Any number of extra Limiting Constraints unassigned to any given Element may be nominated in a candidate, and Limiting Constraints of this type are associated with the Participant they are expressed in should the Participant be created.
For any candidate, no more than one unassigned Limiting Constraint may cover an Enabling Constraint's parameter of the Clique's medium.
An unassigned Limiting Constraint must cover an Enabling Constraint's parameter of the Clique's medium.
A member candidate is asked to join an existing Clique, while an Owner candidate is asked to form a new Clique with one or more supplied member candidates.
A Clique Space knows of an indeterminate number of Element types, the first seven of which are:
- Axle
- Account Profile (node and root)
- Media Profile (node and root)
- Connection
- Affiliation
- Identity
- Participant
Arrangements around a single Axle of instances from the remaining Elements represent a Client Device.
An instance of a node Media Profile or Connection can return a type which represents the type of device that can connect. Hence the reason why the number of Element types is indeterminate.
Limiting Constraints map to individual parameters of a Media Profile's Enabling Constraints.
One Enabling Constraint's parameter can only be covered by a single Limiting Constraint in any given Element.
A Participant's collection of Limiting Constraints express an individuals acceptance of the Clique's mode.
Zero or more Participants can be created from any Identity.
Every Participant must have an Identity, except where a Participant represents an unconnected device.
An Identity contains multiple Connections, any combination of which might be used in a Participant.
An Identity contains multiple Affiliations, any combination of which might be used in a Participant.
An Identity refers to a single Axle.
The expressed Connections and Affiliations within a single Identity instance are known as an Identity's constituents.
An Identity must contain no constituent with a Limiting Constraint that contradicts that of any other constituent.
A Connection associates an Axle with a node Media Profile.
A Connection contains the component that permits communication with the device in accordance with the associated Media Profile
A Media Profile contains the component that is used to decide whether a Participant using a medium which expresses the Media Profile has sufficient Limiting Constraint affinity to perform some action governed by the Media Profile.
An Affiliation associates an Axle with a node Account Profile.
The Axle associated in a Connection must be the Axle referred to in the Identities through which the Connection has been activated.
The Axle associated in an Affiliation must be the Axle referred to in the Identities through which the Affiliation has been activated.
The Axle represents the individual; a transcendent supervisory presence capable of possessing a device and using the device to participate in collaborations which are modelled as Cliques.
An individual, through a different, or even the same device or devices, may appear as one, two, or more Participants in the same Clique.
A device is something which can obtain a Connection to and exchange information with a Clique Space through an Agent Device.
An Agent Device is a type of device.
An administrator client is another type of device.
The administrator client renders Elements onto its View which have been projected from Agent Devices through which the administrator client has obtained Connections.
The administrator client provides a facility through which Agent Devices and Clique Spaces can be administrated.
The Agent Device is administered through its synaptic map.
A synaptic map is a type of Clique Space.
Agent Devices engage with other Agent Devices by creating synapses.
Agent Devices disengage with other Agent Devices by destroying synapses.
A synapse opens a channel through which transmitters are sent from one Agent Device to one other Agent Device.
A synapse on one Agent Device is a replication of another Agent Device's synaptic map.
A synapse is another type of Clique Space.
Agent Collaborations' Clique Spaces are Clique Spaces in which collaborative activity between external devices is recorded.
Agent Devices sharing direct membership of the Agent Collaboration are represented as Participants of the Agent Collaboration Clique Space's Clique.
There we go. A good summary. At the very least, a disclosure this detailed renders my technology prior art. I am not saying whether the summary I give is covered by my patent. I assert that this is the intent, but whether or not this is actually the case is not up to me.
Now, I appear still to have some (perhaps many) rather complicated unresolved issues. I am engineering a solution that will allow an Agent Device to transmit instructions to add and remove Elements' components to an administrator client. The administrator client must be capable of rendering "projected" Elements to its View of the Clique Space universe from the Agent Devices through which these transmissions are received. Agent Devices will also use the bulk of this mechanism to transmit components between themselves.
The thing about this whole Clique Space concept is that the data model described above is used to 1. model collaborations going on amongst Agent Devices and other external devices including the administrator client and to 2. determine which Agent Devices and which other external devices including the administrator client are recipients of changes in an Element's state. The Clique Space data model offers a simultaneous solution to the model and the controller pieces of the model-view-controller design pattern.
Point 2 of the above paragraph can be recast in this way: an Agent Device uses the data model to determine which other devices are interested in the state of Elements. This Agent Device will tell these other devices that the state of an Element has changed (an Element's component has been added or removed) if a particular device is registered as possessing an interest in this Element.
So, how is another device's interest in an Element registered in an Agent Device? Implementing the solution to this question is currently (and finally) occupying all my attention. The solution comes in two parts of its own.
In the first part, an administrator client (or any V/PM device) can receive information about the state of any Element from any Agent Device to which an external device is connected; potentially even from Clique Spaces other than the one or more Clique Spaces through which the external device's Connection's are obtained. The ability for the given external V/PM device to receive information about an Element is determined by the Limiting Constraints which are expressed in the serving Agent Device's Clique; a Clique created for any external device which also represents an instance of a Connection - an association between an Axle and a specific Media Profile type - through the given device to a Clique Space for which the Owner of the synaptic map's Clique (known by the engager Participant recorded as the Connection's originator component) transmits Element state.
The second part involves the transmission of element state information between Agent Devices through the Agent Device's Media Profile. The Agent Device's Media Profile exhibits the unique property in that the Participants in an Agent Collaboration's Clique are not transmissible between Agent Devices. An Agent Collaboration's Clique tells a particular Agent Device which other Agent Devices are interested in a particular Element. The fact that Participants in an Agent Collaboration's Clique are not transmissible avoids the possibility of infinite regress.
Participants generated from Connections which come from an Agent Device's Media Profile will appear in the serving Agent Device's Clique of the first part. The other Participant is generated from the external device's Connection. Both Participants of the serving Agent Device's Clique can be transmitted to other Agent Devices and to V/PM devices where constraints permit this transmission.
These questions make up the implementation of some very deep considerations I was entertaining when I conceived this concept. If I can actually implement the mechanisms I describe in the paragraphs above, I think I will have arrived at a proof of concept.
Subscribe to:
Posts (Atom)