It is probably better that upon connecting, a Participant adapter (the Connection of an Agent Device or V/PM device) register itself with the Identity through which the Connection is expressed. This means that the Agent Device serving the device represented by the Participant adapter does not have to acquire the Axle's identifier in order to add a given Participant adapter to the Agent Device's set of served Participant adapters expressed in a given Axle. Perhaps this will permit the Agent Device instances to express these served Participant adapters in an Identity even when an Agent Device does not know the Identity's Axle.
It is hoped this will permit an individual to connect a device to an Agent Device operated by another individual without the first individual having to disclose their Axle to the second. I like this; it is a more flexible proposition.
Monday, September 10, 2012
Sunday, September 9, 2012
It is true. Your Axle is a private part that you may share with others, but if you give your sovereign away, your sovereignty goes with it.
How do I know who I am on Clique Space(TM)? How do I let others know who I am on Clique Space? How do others on Clique Space know who I am?
Axles serve an intimate purpose of self-identification. In Clique Space, Axles identify what is yours to yourself, and if you wish it, to others who you have nominated as being privy to your Axle's components, but especially the Axle's identifier. You can share or withhold this Element's identifier from disclosure through any Identity you have created. You know all these Identities are yours because they have been created only by you as the possessor of the Axle, and by using your Axle's sovereign - a private key which you never disclose to anyone else - to sign each Identity's identifier. You let others know each Identity you have created is yours by disclosing your Axle. If you don't want to let others know who is behind an Identity you publish, then you assign a Limiting Constraint to your Identity that prevents disclosure of your Axle to them.
I believe there is certainly a versatility - nay, even power - given to the individual in cyberspace through this Clique Space concept.
Now, to a more practical matter: the relaying of device activity to the individual Axle holder. This matter concerns, indeed, Clique Space mandates the concern of how devices having an interest in the Clique Space activity - any Agent Device or View/persistence mechanism-enabled (V/PM) device - are kept informed of the state of the one or more Clique Spaces to which the said devices are connected. In order for a device to be Clique Space aware, the device must be connected to a Clique Space. An individual - an Axle-holder - is really the thing capable of being aware of Clique Spaces just as they are aware of how hot or how hungry they may be; devices merely relay temperature or blood glucose levels to a device loosely called the brain wherein, in today's society, an individual appears manifest.
An Agent Device is a type of device which can talk to other Agent Devices. Agent Devices share information about Clique Space Elements, participating in the distribution of device activity throughout a Clique Space (a domain which is managed by a subset of the individuals who use the Clique Space) as the activity of all individuals who use the Clique Space. An individual, having both the capacity and the desire to observe or persist activity on a particular Clique Space connects one or more devices capable of doing this through their own Axle. In order to use these devices in any meaningful way, their Connections must be expressed through one or more Identities - created using the same Axle.
Any device which is not an Agent Device or a V/PM device is connected to a Clique Space using this same mechanism, but the Elements and components (really, just the components) used for and generated by the connection operation are not disclosed to the given device. This is because the device, not being an Agent Device or a V/PM device, doesn't have a facility to make sense of Clique Space Elements.
Lets now take a look at the Agent Device and the V/PM devices. These devices need a way of receiving information about the change in the state of all the connected devices. Now, any device (be it an Agent Device or a V/PM device) must be accessible from one collection within the Agent Device to which it is connected. It appears intuitive, and technically it is also a reasonable proposition, for the Axle's instance on a particular Agent Device to contain a set of all such Connection instances.
I have removed the notion of an "Adapter" interface except for the class called the Participant adapter - which is now implemented by any V/PM device. I think the adapter interface is a good candidate for massage so that the Agent Device's Connection can also implement this interface.
I predict some heavy-duty thinking over the next several weeks. For instance, if wer're going to use the adapter interface, then we must recognise that the methods on this interface must supply the same information for the Agent Device's Connection as is necessary for any other V/PM device.
This method's implementation on the Connection of the administrator client transmits a quantum from an Agent Device to a V/PM device. It has the following signature:
With both of these Connections implementing the same adapter, they can be contained within a set of adapters inside the same Axle as the one through which this Agent Device is connected. This, however, seems to hint at a complication: if each adapter of this set must name the same Axle in which this set is contained (must it?), then what happens if someone, using a different Axle, connects a V/PM device to this Agent Device? Is it possible that this ominous restriction is actually a ray of clarification?
The Agent Collaboration's Connection would surely implement the transmit method differently to the V/PM device; rather than transmitting the transmitter directly to the device (this would be the case in any instance of a V/PM device that I can currently think of), the Agent Collaboration's Connection would find its associated Participant (of which there would only be one) and transmit the information to all other members of the Clique excluding itself. This mechanism is detail around the concept exactly as I envisaged in mid-2004.
Some heavy-duty thinking to flesh out and implement this mechanism is needed indeed, but more than eight years of heavy-duty thinking has drawn me slowly to the acceptance that this overall concept will eventually be proven.
We'll see...
Axles serve an intimate purpose of self-identification. In Clique Space, Axles identify what is yours to yourself, and if you wish it, to others who you have nominated as being privy to your Axle's components, but especially the Axle's identifier. You can share or withhold this Element's identifier from disclosure through any Identity you have created. You know all these Identities are yours because they have been created only by you as the possessor of the Axle, and by using your Axle's sovereign - a private key which you never disclose to anyone else - to sign each Identity's identifier. You let others know each Identity you have created is yours by disclosing your Axle. If you don't want to let others know who is behind an Identity you publish, then you assign a Limiting Constraint to your Identity that prevents disclosure of your Axle to them.
I believe there is certainly a versatility - nay, even power - given to the individual in cyberspace through this Clique Space concept.
Now, to a more practical matter: the relaying of device activity to the individual Axle holder. This matter concerns, indeed, Clique Space mandates the concern of how devices having an interest in the Clique Space activity - any Agent Device or View/persistence mechanism-enabled (V/PM) device - are kept informed of the state of the one or more Clique Spaces to which the said devices are connected. In order for a device to be Clique Space aware, the device must be connected to a Clique Space. An individual - an Axle-holder - is really the thing capable of being aware of Clique Spaces just as they are aware of how hot or how hungry they may be; devices merely relay temperature or blood glucose levels to a device loosely called the brain wherein, in today's society, an individual appears manifest.
An Agent Device is a type of device which can talk to other Agent Devices. Agent Devices share information about Clique Space Elements, participating in the distribution of device activity throughout a Clique Space (a domain which is managed by a subset of the individuals who use the Clique Space) as the activity of all individuals who use the Clique Space. An individual, having both the capacity and the desire to observe or persist activity on a particular Clique Space connects one or more devices capable of doing this through their own Axle. In order to use these devices in any meaningful way, their Connections must be expressed through one or more Identities - created using the same Axle.
Any device which is not an Agent Device or a V/PM device is connected to a Clique Space using this same mechanism, but the Elements and components (really, just the components) used for and generated by the connection operation are not disclosed to the given device. This is because the device, not being an Agent Device or a V/PM device, doesn't have a facility to make sense of Clique Space Elements.
Lets now take a look at the Agent Device and the V/PM devices. These devices need a way of receiving information about the change in the state of all the connected devices. Now, any device (be it an Agent Device or a V/PM device) must be accessible from one collection within the Agent Device to which it is connected. It appears intuitive, and technically it is also a reasonable proposition, for the Axle's instance on a particular Agent Device to contain a set of all such Connection instances.
I have removed the notion of an "Adapter" interface except for the class called the Participant adapter - which is now implemented by any V/PM device. I think the adapter interface is a good candidate for massage so that the Agent Device's Connection can also implement this interface.
I predict some heavy-duty thinking over the next several weeks. For instance, if wer're going to use the adapter interface, then we must recognise that the methods on this interface must supply the same information for the Agent Device's Connection as is necessary for any other V/PM device.
This method's implementation on the Connection of the administrator client transmits a quantum from an Agent Device to a V/PM device. It has the following signature:
- void transmit(SourceParticipantAdapter
participantAdapter,Transmitter transmitter)
throws CliqueSpaceException;
With both of these Connections implementing the same adapter, they can be contained within a set of adapters inside the same Axle as the one through which this Agent Device is connected. This, however, seems to hint at a complication: if each adapter of this set must name the same Axle in which this set is contained (must it?), then what happens if someone, using a different Axle, connects a V/PM device to this Agent Device? Is it possible that this ominous restriction is actually a ray of clarification?
The Agent Collaboration's Connection would surely implement the transmit method differently to the V/PM device; rather than transmitting the transmitter directly to the device (this would be the case in any instance of a V/PM device that I can currently think of), the Agent Collaboration's Connection would find its associated Participant (of which there would only be one) and transmit the information to all other members of the Clique excluding itself. This mechanism is detail around the concept exactly as I envisaged in mid-2004.
Some heavy-duty thinking to flesh out and implement this mechanism is needed indeed, but more than eight years of heavy-duty thinking has drawn me slowly to the acceptance that this overall concept will eventually be proven.
We'll see...
Monday, September 3, 2012
How is information distributed through Clique Space(TM)?
This question is a bit obvious, but it is one which I had no specific answer for when I put my patent together.
When I conceived the Clique Space(TM) data model, I took as an article of some speculative faith, the premise that I could work out the technical considerations of how this model would be used to realise the mechanism that actually allows one Agent Device to exchange information with one or more others, as well as how one Agent Device exchanges Clique Space Element information for external device state information. I had hypothesised that mechanisms would emerge as a result of the deliberations necessary to get from the concept recorded in the patent, to its implementation recorded in code.
I envisaged that perhaps some degree of similarity between Clique Spaces and biological nervous systems would emerge, and indeed, this appears to have happened in at least one example: the emergence of the logical synapse necessary to open a channel for exchange between two Agent Devices. Although the synapse is reasonably stable, my current deliberations will have an impact on this mechanism because the changing form of the information exchange will also change the way Agent Devices engage and disengage, forming and disbanding bipartite Cliques which represent these synapses. Although I had thought the synapse might emerge as far back as when I put the patent together, this hypothetical mechanism lacked the implementation detail that exists currently; it is anticipated that some of this current detail will have been discarded and replaced before one can confidently say the synapse mechanism exhibits its final form.
The wider deliberation of the mechanism needed to get collections of Agent Devices, being members of a Clique, to communicate the changing state of their Elements amongst each other have brought me to yet other limits of my intellectual capacity as it was when I put the patent together. I feel that the implementation has evolved to a point where, since stabilising the implementation of the properties mechanism discussed in my last post - an act in itself which has pointed me the way to the promise of an answer - I now appear prepared to start replacing at least some of this faith with some reason.
At least at a purely logical level, I think my progression from this point may provide some interesting insight into how a biological nervous system recruits and coordinates its individual neurons in the performance of some act instigated by and for the organism as a whole. Such a mechanism would exhibit hierarchical and executive command and control structures, but would also simultaneously appear to self-assemble based on some form of consensus between neurons (Agent Devices) in accordance with the varying capacity of each neuron to participate. Hence, it would be very hard in any Clique Space (indeed, as it might be demonstrated in any neural system) to point to a single Agent Device as being ultimately responsible for the conduct of any Clique Space as a whole.
Whether synthetic or biological, any such system would definitely require some systematic form of message propagation. It is to this mechanism that my deliberations appear once more to turn. I have some general ideas which I hope to test. For instance, as I explained in a previous post, I see the necessity for Agent Devices to have two Cliques model a single collaboration between a collection of devices, whether these devices are Agent Devices being members of a Clique space, or a collection of devices participating in a collaboration defined by a Media Profile type external to the Clique Space implementation.
The first Clique primarily models what is actually going on in the collaboration; it gives Clique Space a sense of the collaboration's reason for existence, and to the characteristics of its member Participants in accordance to the ability of the Clique's medium to report the collaboration's activity. The second Clique is used to model which Agent Devices have a stake in knowing what is going on in the first Clique by virtue of the fact that any member Participants of this Agent Collaboration's Clique share a combination of the following three relationships with the first Clique: 1. that these Agent Devices are connected to the devices who's collaborative activity is being modelled as participants of the first Clique, or 2. that these Agent Devices are connected to a View or persistence mechanism-enabled devices viewing or persisting activity of the first Clique, and optionally, may be capable of controlling the first Clique, or 3. that these Agent Devices may be acting as relay devices, permitting propagation of Element state from Agent Devices of the first two types located in one physical location to those located in another, but for which the Agent Devices at the first location share no synapses with those at the second; perhaps a bit like a corpus callosum.
This dual-Clique scheme seems a reasonable way to propagate messages amongst relevant Agent Devices, but this mechanism does not include View or persistence devices, because they are not Agent Devices, and hence lack the mechanics necessary to participate in an Agent Collaboration. These type of external devices require another protocol to receive and process Element state information, even if these devices use the same message transport vehicle - the component transmitter, discussed in the previous entry - used in the Agent Collaboration.
It might be interesting at this point to consider how it is a designed intent that the Media Profile Element fits the bill for encoding the protocol for any collaboration type so an Agent Device can receive, process, and control device state. The information content generated by any device may be augmented with Clique Space information in the given device's media in accordance with the Media Profile through which a Connection has been established. The general concept of the Media Profile is used to describe the parameters that a specific protocol will accept. Specifically, the protocols which describe the operational parameters of 1. the Agent Collaboration, and 2. the administrator client, are exposed through Media Profiles like any other protocols. Hence, the Agent Collaboration's protocol is exposed inside the mechanism that implements this protocol by an Agent Collaboration Media Profile so the Agent Collaboration's activity, modelled as a Clique, can be Viewed, persisted, or controlled by an administrator client or any external device which possesses such a capability.
Hence, the Agent Devices have their Agent Collaboration Media Profile. This Media Profile provides the mechanism that realises the second Clique necessary for the dual-Clique propagation scheme. A Media Profile for the administrator client will be fashioned that facilitates the component exchange scheme between an Agent Device and a View or persistence enabled external device. Both the administrator client's component exchange and the Agent Device's dual-Clique schemes will use the common component propagation and exchange mechanism - the component transmitter.
The component transmitter mechanism currently looks like the ideal candidate for the administrator client component exchange scheme as it is for the Agent Device's dual-clique scheme. This is the intention for the design of the component transmitter mechanism; this mechanism replaces the failed Element precis mechanism for the Agent Collaboration, and a promising, but demonstrably inadequate Element projection mechanism for the administrator client. Both the failure of the Element precis and the inadequacy of the Element projection mechanisms prompted me to look to the component transmitter mechanism as a sufficient and flexible alternative candidate for a solution to the question of message propagation.
When I conceived the Clique Space(TM) data model, I took as an article of some speculative faith, the premise that I could work out the technical considerations of how this model would be used to realise the mechanism that actually allows one Agent Device to exchange information with one or more others, as well as how one Agent Device exchanges Clique Space Element information for external device state information. I had hypothesised that mechanisms would emerge as a result of the deliberations necessary to get from the concept recorded in the patent, to its implementation recorded in code.
I envisaged that perhaps some degree of similarity between Clique Spaces and biological nervous systems would emerge, and indeed, this appears to have happened in at least one example: the emergence of the logical synapse necessary to open a channel for exchange between two Agent Devices. Although the synapse is reasonably stable, my current deliberations will have an impact on this mechanism because the changing form of the information exchange will also change the way Agent Devices engage and disengage, forming and disbanding bipartite Cliques which represent these synapses. Although I had thought the synapse might emerge as far back as when I put the patent together, this hypothetical mechanism lacked the implementation detail that exists currently; it is anticipated that some of this current detail will have been discarded and replaced before one can confidently say the synapse mechanism exhibits its final form.
The wider deliberation of the mechanism needed to get collections of Agent Devices, being members of a Clique, to communicate the changing state of their Elements amongst each other have brought me to yet other limits of my intellectual capacity as it was when I put the patent together. I feel that the implementation has evolved to a point where, since stabilising the implementation of the properties mechanism discussed in my last post - an act in itself which has pointed me the way to the promise of an answer - I now appear prepared to start replacing at least some of this faith with some reason.
At least at a purely logical level, I think my progression from this point may provide some interesting insight into how a biological nervous system recruits and coordinates its individual neurons in the performance of some act instigated by and for the organism as a whole. Such a mechanism would exhibit hierarchical and executive command and control structures, but would also simultaneously appear to self-assemble based on some form of consensus between neurons (Agent Devices) in accordance with the varying capacity of each neuron to participate. Hence, it would be very hard in any Clique Space (indeed, as it might be demonstrated in any neural system) to point to a single Agent Device as being ultimately responsible for the conduct of any Clique Space as a whole.
Whether synthetic or biological, any such system would definitely require some systematic form of message propagation. It is to this mechanism that my deliberations appear once more to turn. I have some general ideas which I hope to test. For instance, as I explained in a previous post, I see the necessity for Agent Devices to have two Cliques model a single collaboration between a collection of devices, whether these devices are Agent Devices being members of a Clique space, or a collection of devices participating in a collaboration defined by a Media Profile type external to the Clique Space implementation.
The first Clique primarily models what is actually going on in the collaboration; it gives Clique Space a sense of the collaboration's reason for existence, and to the characteristics of its member Participants in accordance to the ability of the Clique's medium to report the collaboration's activity. The second Clique is used to model which Agent Devices have a stake in knowing what is going on in the first Clique by virtue of the fact that any member Participants of this Agent Collaboration's Clique share a combination of the following three relationships with the first Clique: 1. that these Agent Devices are connected to the devices who's collaborative activity is being modelled as participants of the first Clique, or 2. that these Agent Devices are connected to a View or persistence mechanism-enabled devices viewing or persisting activity of the first Clique, and optionally, may be capable of controlling the first Clique, or 3. that these Agent Devices may be acting as relay devices, permitting propagation of Element state from Agent Devices of the first two types located in one physical location to those located in another, but for which the Agent Devices at the first location share no synapses with those at the second; perhaps a bit like a corpus callosum.
This dual-Clique scheme seems a reasonable way to propagate messages amongst relevant Agent Devices, but this mechanism does not include View or persistence devices, because they are not Agent Devices, and hence lack the mechanics necessary to participate in an Agent Collaboration. These type of external devices require another protocol to receive and process Element state information, even if these devices use the same message transport vehicle - the component transmitter, discussed in the previous entry - used in the Agent Collaboration.
It might be interesting at this point to consider how it is a designed intent that the Media Profile Element fits the bill for encoding the protocol for any collaboration type so an Agent Device can receive, process, and control device state. The information content generated by any device may be augmented with Clique Space information in the given device's media in accordance with the Media Profile through which a Connection has been established. The general concept of the Media Profile is used to describe the parameters that a specific protocol will accept. Specifically, the protocols which describe the operational parameters of 1. the Agent Collaboration, and 2. the administrator client, are exposed through Media Profiles like any other protocols. Hence, the Agent Collaboration's protocol is exposed inside the mechanism that implements this protocol by an Agent Collaboration Media Profile so the Agent Collaboration's activity, modelled as a Clique, can be Viewed, persisted, or controlled by an administrator client or any external device which possesses such a capability.
Hence, the Agent Devices have their Agent Collaboration Media Profile. This Media Profile provides the mechanism that realises the second Clique necessary for the dual-Clique propagation scheme. A Media Profile for the administrator client will be fashioned that facilitates the component exchange scheme between an Agent Device and a View or persistence enabled external device. Both the administrator client's component exchange and the Agent Device's dual-Clique schemes will use the common component propagation and exchange mechanism - the component transmitter.
The component transmitter mechanism currently looks like the ideal candidate for the administrator client component exchange scheme as it is for the Agent Device's dual-clique scheme. This is the intention for the design of the component transmitter mechanism; this mechanism replaces the failed Element precis mechanism for the Agent Collaboration, and a promising, but demonstrably inadequate Element projection mechanism for the administrator client. Both the failure of the Element precis and the inadequacy of the Element projection mechanisms prompted me to look to the component transmitter mechanism as a sufficient and flexible alternative candidate for a solution to the question of message propagation.
Subscribe to:
Posts (Atom)