Shortly into today's long walk, I realised that the Active Affiliation implies Identity epiphany I discussed yesterday has had another implication. The Identity object, in being an aggregation of devices and roles, does not belong to any device in particular: it is, like the Account, Account Profile, and the Affiliation, an abstract Element needed only by Clique Space(TM) to manage an individual's particular identity as they may wish to express it through these Elements, Connections and Media Profiles.
I spent the remainder of today's walk debating the merits of customising the remaining Media Profile, Connection and Participant for different media, and I can't find one. I questioned myself as to why it ever occurred to me that customising Media Profiles, Connections, Active Affiliations and Participants was a good idea, and this may have been because there was a point in time where I had to deal with the fact that the administrator Client Device needed to implement these Elements in peculiar ways so I could do things like being able to reconstruct an Element from multiple projections.
Additionally, I have been trying to work out the form of the Agent Device's media Elements, and how the mechanics of the Agent Device implementation realises its media as just a small subset of media which could be modelled by Clique Space. The Agent Device needs to provide an adequate answer to this question of self-reference if Clique Space's ultimate value is to be realised. I believe considerations about the intersection between the model and the implementation were carried perhaps a little too far; apart from the server side code allowing device state to be siphoned to an Agent Device, or Enabling Constraints necessary to represent and convey this state, or perhaps code necessary to render a collaboration in a specific medium to a specific display context, the core Clique Space application model must provide everything necessary for other media unrelated to the Agent or administrator Client Device to be modelled in a Clique Space.
Client and server side code still has to be developed for regular devices and Agent Devices respectively, but I believe that discounting of the notion of the Media Profile spine and keeping the core data model abstract will be an acute simplification of the proof-of-concept. That'll make happy by a degree of acuity equal to this simplification.
Friday, March 23, 2012
Clique Space(TM) does things a bit differently.
Scanning my blog stats a couple of days ago, I happened upon a referring URL about a product called mSpy. It appears to be a mobile phone and other device monitoring software thing that can sit on a phone and silently track and log its activity. The product is sold as a way to "Remotely read SMS, Call Logs, Emails, Listen Surroundings, Track phone location and more.".
The web site discloses things Clique Space is theoretically capable of doing (at the moment, almost everything about Clique Space is theoretical) but Clique Space appears to take a very different view about device control. Clique Space logs any device activity that an Identity (nee the Active Affiliation) permits in the circumstance only if the individual using the given device has permitted this purpose. When an Identity acquires a Participant, that Participant has only been acquired because the user to whom the Identity relates has sanctioned activity that the Identity and its component Elements permit.
Clique Space operates a constraint-based model: the stability of a Clique Space depends on the accurate maintenance of Limiting Constraint affinity. So, even if, say, an employer wanted an empoyee to use a phone in a certain way, the individual having a potential to act as an employee would have to explicitly accept this way of operating a device by activating an Affiliation (thereby realising this potential) created by their employer before it could be used.
Although I am not discounting the utility of the quoted product's offering, I do find such propositions as mSpy (there are many other products) to be a less portable solution than what I'm talking about with Clique Space. If a user wants to use their phone with Clique Space, they'll install client side code for the appropriate Clique Space's Media Profile spine, and when one turns on one's phone, one will explicitly claim assent to a particular Identity to which an Affiliation supplied by their employer for this purpose has been activated.
Before one can obtain a Participant by joining or forming a Clique (before operating the Clique Space aware phone in some way), one selects which Limiting Constraints of the Identity's component Elements (Media Profiles, Account Profiles, Connections, Affiliations, and the user's Account) are appropriate for expression in this Participant against the Clique's Limiting Constraints. If there are constraint contradictions which cannot be resolved, then the Participant cannot be acquired and Clique Space will not model and control the phone's activity to make calls, send texts, etc.
Now, the individual's employer might own this phone. If this is true, the employer might tell Clique Space this when the phone obtains its Connection by setting a Limiting Constraint advising Clique Space that a Participant involving this phone can only be acquired against the employer's Affiliation, and possibly only with a certain Identity nominated by the individual. The user cannot use the phone without activating (and possibly only activating) the given Affiliation because this phone is also configured by the employer to work only when it is being used in the one or more Clique Spaces where the employer has created their specific Affiliation. Hence, the user can only use their employer's phone by activating a given Affiliation. This Affiliation may itself contain Limiting Constraints, or be associated with an Account Profile hierarchy which contains Limiting Constraints, which shape the functioning of the phone to whatever purposes the usage of the phone is governed by the employer's authority.
The Clique Space data model is a very powerful way of asserting control over a device such that all stakeholders have claimed assent to this control. The same Limiting Constraint mechanism that covers control and authority also covers access to device activity by other users. Hence, the phone's activity can only be logged by individuals who possess a pre-determined reason, and this can only be done when final assent has been given by the device's operator.
...
I mean no disrespect to the mSpy product developers. I have avoided making specific statements about how their product operates because I just had a cursory look over their web page. I lack any association with this company or its products. This product is quoted merely as an example of impressions I receive from products as I see them, and I most certainly do not intend to be an authority over anything I say in anything else but Clique Space. People who read this blog should visit mSpy themselves for any authoritative opinions.
Maybe the impressions I have given here, misinformed as they may be, are incorrect in some substantial way. If statements I have made are incorrect, let me know and I'll correct them. In any case, I wish mSpy good fortune.
The web site discloses things Clique Space is theoretically capable of doing (at the moment, almost everything about Clique Space is theoretical) but Clique Space appears to take a very different view about device control. Clique Space logs any device activity that an Identity (nee the Active Affiliation) permits in the circumstance only if the individual using the given device has permitted this purpose. When an Identity acquires a Participant, that Participant has only been acquired because the user to whom the Identity relates has sanctioned activity that the Identity and its component Elements permit.
Clique Space operates a constraint-based model: the stability of a Clique Space depends on the accurate maintenance of Limiting Constraint affinity. So, even if, say, an employer wanted an empoyee to use a phone in a certain way, the individual having a potential to act as an employee would have to explicitly accept this way of operating a device by activating an Affiliation (thereby realising this potential) created by their employer before it could be used.
Although I am not discounting the utility of the quoted product's offering, I do find such propositions as mSpy (there are many other products) to be a less portable solution than what I'm talking about with Clique Space. If a user wants to use their phone with Clique Space, they'll install client side code for the appropriate Clique Space's Media Profile spine, and when one turns on one's phone, one will explicitly claim assent to a particular Identity to which an Affiliation supplied by their employer for this purpose has been activated.
Before one can obtain a Participant by joining or forming a Clique (before operating the Clique Space aware phone in some way), one selects which Limiting Constraints of the Identity's component Elements (Media Profiles, Account Profiles, Connections, Affiliations, and the user's Account) are appropriate for expression in this Participant against the Clique's Limiting Constraints. If there are constraint contradictions which cannot be resolved, then the Participant cannot be acquired and Clique Space will not model and control the phone's activity to make calls, send texts, etc.
Now, the individual's employer might own this phone. If this is true, the employer might tell Clique Space this when the phone obtains its Connection by setting a Limiting Constraint advising Clique Space that a Participant involving this phone can only be acquired against the employer's Affiliation, and possibly only with a certain Identity nominated by the individual. The user cannot use the phone without activating (and possibly only activating) the given Affiliation because this phone is also configured by the employer to work only when it is being used in the one or more Clique Spaces where the employer has created their specific Affiliation. Hence, the user can only use their employer's phone by activating a given Affiliation. This Affiliation may itself contain Limiting Constraints, or be associated with an Account Profile hierarchy which contains Limiting Constraints, which shape the functioning of the phone to whatever purposes the usage of the phone is governed by the employer's authority.
The Clique Space data model is a very powerful way of asserting control over a device such that all stakeholders have claimed assent to this control. The same Limiting Constraint mechanism that covers control and authority also covers access to device activity by other users. Hence, the phone's activity can only be logged by individuals who possess a pre-determined reason, and this can only be done when final assent has been given by the device's operator.
...
I mean no disrespect to the mSpy product developers. I have avoided making specific statements about how their product operates because I just had a cursory look over their web page. I lack any association with this company or its products. This product is quoted merely as an example of impressions I receive from products as I see them, and I most certainly do not intend to be an authority over anything I say in anything else but Clique Space. People who read this blog should visit mSpy themselves for any authoritative opinions.
Maybe the impressions I have given here, misinformed as they may be, are incorrect in some substantial way. If statements I have made are incorrect, let me know and I'll correct them. In any case, I wish mSpy good fortune.
Thursday, March 22, 2012
Another name for the Active Affiliation
My rediscovery of the Active Affiliation's function (yes, I merely forgot the rationale I had - which was quite fluid at the time) has, I believe in the scale of things, been a profound event
If Clique Space(TM) could have a community-based label for a set of ideals on what it is, this label would be Identity Metasystem. It has always been my claim that Clique Space allows its users to make visceral statements about the things in this world one may possess. Clique Space perhaps doesn't try to make such a statement about the things one may have said or done while one isn't using it or if one cannot verify the identity of others because they aren't using it, or have prevented you access particular Elements such as their Account. However, with a system like Clique Space, I claim that individuals can certainly go about their lives fairly secure that a system like Clique Space will help every individual ascertain the identity of individuals with whom they collaborate, or at least give individuals informed discretional power to decide whether a collaboration is going to ensue.
Now, identity is the key component to Clique Space. It was a key motivator because the necessity that parented this invention was a need to find a way I could argue to my boss that I could give him or her a tool that they could use to monitor my progress in doing work for them, while preventing their prying into other areas of my life.
Identity is key. The Active Affiliation is key to a user's identity in Clique Space. It quacks like a duck. The Active Affiliation is an identity. I will here forth refer to the Active Affiliation as the Identity.
It has been so decreed. Thus it shall be.
If Clique Space(TM) could have a community-based label for a set of ideals on what it is, this label would be Identity Metasystem. It has always been my claim that Clique Space allows its users to make visceral statements about the things in this world one may possess. Clique Space perhaps doesn't try to make such a statement about the things one may have said or done while one isn't using it or if one cannot verify the identity of others because they aren't using it, or have prevented you access particular Elements such as their Account. However, with a system like Clique Space, I claim that individuals can certainly go about their lives fairly secure that a system like Clique Space will help every individual ascertain the identity of individuals with whom they collaborate, or at least give individuals informed discretional power to decide whether a collaboration is going to ensue.
Now, identity is the key component to Clique Space. It was a key motivator because the necessity that parented this invention was a need to find a way I could argue to my boss that I could give him or her a tool that they could use to monitor my progress in doing work for them, while preventing their prying into other areas of my life.
Identity is key. The Active Affiliation is key to a user's identity in Clique Space. It quacks like a duck. The Active Affiliation is an identity. I will here forth refer to the Active Affiliation as the Identity.
It has been so decreed. Thus it shall be.
Wednesday, March 21, 2012
A promising use for the Active Affiliation
In earlier blog entries, I have alluded to the possibility that the Active Affiliation might be redundant. In today's ~8.5k walk, I had two wonderfully refreshing thoughts; one of which was to demonstrate the real possibility of a hitherto hinted at purpose of the Active Affiliation. This thought came to me because I am contemplating the mechanism around how Limiting Constraint affinity is determined, which determines whether a Participant can exist.
My dilemma about the value of the Active Affiliation in the core data model had been with me since I had conceived the data model in 2004. I couldn't quite comprehend at that point whether or not it was ultimately necessary in a final implementation, so deciding it better that one can always remove redundancy in an over-engineered concept, I included the Active Affiliation in the original patent spec. However, today's thinking has prompted me to reassess my recent earlier stance on the Active Affiliation. The Active Affiliation appears to be useful as the focal point of the Client Device.
Focal point of the Client Device? What does this mean? It means that my emphasis on the concept of the Client Device might have to change slightly from what I said in an earlier posting. I am completely comfortable with saying this because nothing I have had to revisit about the Client Device changes anything from the original patent spec. In fact, the Active Affiliation seems to serve the purpose (which I had felt could turn out to be when I put it in my spec) of being the point at which Limiting Constraint affinity is determined in Clique Space(TM).
In saying this, I am admitting to backing away from my recent assertions that the Participant is where this affinity is determined. To realise the core value of the Clique Space concept, it appears that the Active Affiliation determines Limiting Constraint affinity between any two device/user/role descriptions that the respective Client Devices can take. In fact, the Client Device now acquires more of a holistic definition; an Agent Device can still be a Client Device, but the Client Device is the representation of all Clique Space Elements around an Active Affiliation associated with a single Account. Hence, in accordance with my previous blog entry, the Agent Device can still be considered separately from all other devices, only these other devices may make up a single Client Device if they are described by the same Active Affiliation as the instance or instances of the Agent Devices being excluded from consideration. This realisation really realigns my original intent of both the Active Affiliation and the Client Device.
None of what I have said breaks the original data model. In fact, it reinforces certain components of it, and clarifies others. For instance, it appears that to be consistent, any Active Affiliation will have a single Account. This fact reinforces the necessity for the Connection and Affiliation to be associations between the same Account. A similar relationship is reinforced between the Active Affiliation and any Participants that are created from it: an Active Affiliation can have zero or more Participants, but, because devices are located, viewed, and controlled on Clique Space through their Participants, an Active Affiliation must have at least one Participant to interact with other Active Affiliations.
Clarification is also seen in the association of Connections and Affiliations: one or more Connections can be associated with one or more Affiliations - so long as all these Elements associate the same single Account. This clarification points to a further clarification of the relationship between Active Affiliations and Participants: through the Active Affiliation, a Participant may actually represent multiple Connections and multiple Affiliations. This relationship is a real value proposition for Clique Space in that an individual may join or form a Clique as one Participant even though they have to use more than one "real" device, and they may also join or form a Clique as a representative of more than one role.
This realisation that the Active Affiliation element of the Client Device's structure has specific utility could be one of the most fundamental realisations to the efficacy of the original concept.
...
The other thought I had this day was about a main factor determining when the Agent Devices engage and disengage. Although it appears to be a good one, I think I'll leave this blog entry to cover only the above thought, suffice to leave this reminder to myself of the other thought: unengaged Agent Devices try to talk to each other, and engage (create synapses) only when they can maintain a conversation. When this conversation cannot be maintained, they disengage (destroy synapses).
My dilemma about the value of the Active Affiliation in the core data model had been with me since I had conceived the data model in 2004. I couldn't quite comprehend at that point whether or not it was ultimately necessary in a final implementation, so deciding it better that one can always remove redundancy in an over-engineered concept, I included the Active Affiliation in the original patent spec. However, today's thinking has prompted me to reassess my recent earlier stance on the Active Affiliation. The Active Affiliation appears to be useful as the focal point of the Client Device.
Focal point of the Client Device? What does this mean? It means that my emphasis on the concept of the Client Device might have to change slightly from what I said in an earlier posting. I am completely comfortable with saying this because nothing I have had to revisit about the Client Device changes anything from the original patent spec. In fact, the Active Affiliation seems to serve the purpose (which I had felt could turn out to be when I put it in my spec) of being the point at which Limiting Constraint affinity is determined in Clique Space(TM).
In saying this, I am admitting to backing away from my recent assertions that the Participant is where this affinity is determined. To realise the core value of the Clique Space concept, it appears that the Active Affiliation determines Limiting Constraint affinity between any two device/user/role descriptions that the respective Client Devices can take. In fact, the Client Device now acquires more of a holistic definition; an Agent Device can still be a Client Device, but the Client Device is the representation of all Clique Space Elements around an Active Affiliation associated with a single Account. Hence, in accordance with my previous blog entry, the Agent Device can still be considered separately from all other devices, only these other devices may make up a single Client Device if they are described by the same Active Affiliation as the instance or instances of the Agent Devices being excluded from consideration. This realisation really realigns my original intent of both the Active Affiliation and the Client Device.
None of what I have said breaks the original data model. In fact, it reinforces certain components of it, and clarifies others. For instance, it appears that to be consistent, any Active Affiliation will have a single Account. This fact reinforces the necessity for the Connection and Affiliation to be associations between the same Account. A similar relationship is reinforced between the Active Affiliation and any Participants that are created from it: an Active Affiliation can have zero or more Participants, but, because devices are located, viewed, and controlled on Clique Space through their Participants, an Active Affiliation must have at least one Participant to interact with other Active Affiliations.
Clarification is also seen in the association of Connections and Affiliations: one or more Connections can be associated with one or more Affiliations - so long as all these Elements associate the same single Account. This clarification points to a further clarification of the relationship between Active Affiliations and Participants: through the Active Affiliation, a Participant may actually represent multiple Connections and multiple Affiliations. This relationship is a real value proposition for Clique Space in that an individual may join or form a Clique as one Participant even though they have to use more than one "real" device, and they may also join or form a Clique as a representative of more than one role.
This realisation that the Active Affiliation element of the Client Device's structure has specific utility could be one of the most fundamental realisations to the efficacy of the original concept.
...
The other thought I had this day was about a main factor determining when the Agent Devices engage and disengage. Although it appears to be a good one, I think I'll leave this blog entry to cover only the above thought, suffice to leave this reminder to myself of the other thought: unengaged Agent Devices try to talk to each other, and engage (create synapses) only when they can maintain a conversation. When this conversation cannot be maintained, they disengage (destroy synapses).
Friday, March 16, 2012
Further considerations about the Agent Collaboration.
Many of the posts I put up on this blog are hypothetical deliberations about imminent or important complicated Clique Space(TM) implementation issues. Here's some of what I've been thinking...
The Agent Collaboration is a collaboration of one or more Agent Devices. Agent Collaborations are modelled by Cliques in the same way that a collaboration by any other set of devices are. A Clique Space Clique is a Clique that models an Agent Collaboration that is the manifestation of a Clique Space. Every Clique Space has a Clique Space Clique. Every Agent Device uses the Clique Space's Media Profile spine to generate all spinal Elements (Media Profile, Connection, Active Affiliation and Participant; or maybe in the future just the Media Profile, Connection and Participant) necessary to become Participants in a Clique Space's Clique.
Now, we can consider Agent Collaborations that represent Client Devices (of which the Agent Device is one) except the Agent Device.
First, a refresher on what Participants and Cliques are. In general, Participants represent each device/individual/role of each Client Device in the corresponding collaboration of the "real" device's medium. The device's medium is represented in Clique Space by the Clique's medium, which is decided firstly at Clique formation, and then perhaps at any appropriate time thereafter in the scope of the Clique's existence by the Clique Owner's Participant. So, for instance, a conference call of six people, three from one company, and three from another will be represented accordingly in a Clique of six participants; the Clique's Owner might also be the conference call's moderator.
Consider the Agent Collaboration underlying this Clique. For instance, all devices might actually be connected to the same Agent Device. Hence, all Client Devices, each of which correspond to a given device would be represented by a Participant (each of these Participants is the Owner of a bipartite serving Agent Device's Clique) that registers, as a spinal component, a Connection that lists the same Agent Device as the serving Agent Device. Hence, there would be no actual Agent Collaboration representing the Agent Collaboration's Clique - there would just be a Clique with two Participants representing the same Agent Device; the Owner and its twin.
Now consider a slight variation in the make-up of the Agent Device's Clique: perhaps four of the Participants from the conference call Clique are connected to one Agent Device, and the remaining two are each connected to other Agent Devices. There are a total of three Agent Devices siphoning and controlling the state of all devices of the conference call collaboration, and hence the Agent Collaboration's Clique has four Participants; three representing each connected Agent Device, and one representing the Agent Collaboration Clique Owner's twin.
But what if some device not involved in the conference call was controlled by someone who wanted to observe this conference call Clique? As they're not a Participant, they cannot get information about the Clique. If (which is most probably the case) they were a Participant in the conference call, but their phone does not possess a View, there would be no value in using Clique Space to record or control activity in this Clique.
To be valuable, Clique Space must allow a user the ability to view and persist the activity of any Clique to which they have sufficient Limiting Constraint affinity. To understand how this information is made available, one must remind one's self about the underlying Agent Collaboration, and how this collaboration, like any other device collaboration, can be modelled as a Clique.
The underlying Agent Collaboration can be modelled in a Clique that includes the participating Agent Devices as well as other non-participating Agent Devices. These extra "non-participating" Agent Devices would acquire Participants to the Agent Collaboration Clique when a connected Client Device had a View mechanism, and was connected by a user who may have had to activate an Affiliation with sufficient Limiting Constraint affinity to view a Clique in which they are not a member, and wants to observe and/or interact with this Clique in some way.
I have already developed an ideal candidate Media Profile spine for modelling this underlying Agent Collaboration's Clique: the Agent Device's Media Profile. Currently, this Media Profile generates Participants that appear in the serving Agent Device's Clique; a bipartite Clique. The other Participant in this serving Agent Device's Clique is the Client Device; it is the owner. I envisage every Client Device will create a serving Agent Device's Clique with the Agent Device to which it is connected. However only the administrator's Client Device creates these Cliques - because the administrator's Client Device is the only Client Device developed for Clique Space so far.
Agent Devices will collaborate in relation to a specific Clique. These multipartite Cliques might be best labelled after what they represent: Agent Collaboration Cliques. These Agent Collaboration Cliques contain Participants representing the Agent Devices to which are connected at least one View or persistence mechanism enabled Client Device which has expressed an interest in at least one View of the given Clique - either to observe, persist, or perhaps even to control the activity of the devices modelled as Participants within the given Clique. Hence, it appears that the Agent Device's Media Profile spine can generate Participants for a multipartite Clique function in which these Agent Device's Participants might be these Cliques' Owners.
I have earlier referred to Clique Spaces as a form of Agent Collaboration Clique. Usage of this term to only describe Clique Spaces appears too restrictive; a Clique Space is an Agent Collaboration which is centrally managed by a group of one or more users possessing an Affiliation to the Clique Space's administrator Account Profile. Clique Spaces themselves provide domains for Element and Clique life-cycle management, Clique ownership as well as user security and privacy etc. Other Agent Collaborations are more fluid; they form grow, shrink and disband in accordance with the capacity by which users can form and disband, join and leave, or cede ownership of Cliques. Hence, a Clique's Participants may reside on the same Clique Space, or different Clique Spaces where the given Clique Spaces allow - through mutual agreement which can be modelled by a Clique - other Cliques to span theses Clique Spaces.
Something else that becomes apparent with these Agent Collaboration Cliques. They appear to be recursive; maybe even, and perhaps nonsensically, circular. They may be recursive if one has a need to observe people who are observing people who are ... observing a Clique of a conference call: beautiful big bro. They may be circular if I'm watching you watching me (ah huh..), but I think this has about as much utility as a similarly named Abba song suggests.
We'll see...
The Agent Collaboration is a collaboration of one or more Agent Devices. Agent Collaborations are modelled by Cliques in the same way that a collaboration by any other set of devices are. A Clique Space Clique is a Clique that models an Agent Collaboration that is the manifestation of a Clique Space. Every Clique Space has a Clique Space Clique. Every Agent Device uses the Clique Space's Media Profile spine to generate all spinal Elements (Media Profile, Connection, Active Affiliation and Participant; or maybe in the future just the Media Profile, Connection and Participant) necessary to become Participants in a Clique Space's Clique.
Now, we can consider Agent Collaborations that represent Client Devices (of which the Agent Device is one) except the Agent Device.
First, a refresher on what Participants and Cliques are. In general, Participants represent each device/individual/role of each Client Device in the corresponding collaboration of the "real" device's medium. The device's medium is represented in Clique Space by the Clique's medium, which is decided firstly at Clique formation, and then perhaps at any appropriate time thereafter in the scope of the Clique's existence by the Clique Owner's Participant. So, for instance, a conference call of six people, three from one company, and three from another will be represented accordingly in a Clique of six participants; the Clique's Owner might also be the conference call's moderator.
Consider the Agent Collaboration underlying this Clique. For instance, all devices might actually be connected to the same Agent Device. Hence, all Client Devices, each of which correspond to a given device would be represented by a Participant (each of these Participants is the Owner of a bipartite serving Agent Device's Clique) that registers, as a spinal component, a Connection that lists the same Agent Device as the serving Agent Device. Hence, there would be no actual Agent Collaboration representing the Agent Collaboration's Clique - there would just be a Clique with two Participants representing the same Agent Device; the Owner and its twin.
Now consider a slight variation in the make-up of the Agent Device's Clique: perhaps four of the Participants from the conference call Clique are connected to one Agent Device, and the remaining two are each connected to other Agent Devices. There are a total of three Agent Devices siphoning and controlling the state of all devices of the conference call collaboration, and hence the Agent Collaboration's Clique has four Participants; three representing each connected Agent Device, and one representing the Agent Collaboration Clique Owner's twin.
But what if some device not involved in the conference call was controlled by someone who wanted to observe this conference call Clique? As they're not a Participant, they cannot get information about the Clique. If (which is most probably the case) they were a Participant in the conference call, but their phone does not possess a View, there would be no value in using Clique Space to record or control activity in this Clique.
To be valuable, Clique Space must allow a user the ability to view and persist the activity of any Clique to which they have sufficient Limiting Constraint affinity. To understand how this information is made available, one must remind one's self about the underlying Agent Collaboration, and how this collaboration, like any other device collaboration, can be modelled as a Clique.
The underlying Agent Collaboration can be modelled in a Clique that includes the participating Agent Devices as well as other non-participating Agent Devices. These extra "non-participating" Agent Devices would acquire Participants to the Agent Collaboration Clique when a connected Client Device had a View mechanism, and was connected by a user who may have had to activate an Affiliation with sufficient Limiting Constraint affinity to view a Clique in which they are not a member, and wants to observe and/or interact with this Clique in some way.
I have already developed an ideal candidate Media Profile spine for modelling this underlying Agent Collaboration's Clique: the Agent Device's Media Profile. Currently, this Media Profile generates Participants that appear in the serving Agent Device's Clique; a bipartite Clique. The other Participant in this serving Agent Device's Clique is the Client Device; it is the owner. I envisage every Client Device will create a serving Agent Device's Clique with the Agent Device to which it is connected. However only the administrator's Client Device creates these Cliques - because the administrator's Client Device is the only Client Device developed for Clique Space so far.
Agent Devices will collaborate in relation to a specific Clique. These multipartite Cliques might be best labelled after what they represent: Agent Collaboration Cliques. These Agent Collaboration Cliques contain Participants representing the Agent Devices to which are connected at least one View or persistence mechanism enabled Client Device which has expressed an interest in at least one View of the given Clique - either to observe, persist, or perhaps even to control the activity of the devices modelled as Participants within the given Clique. Hence, it appears that the Agent Device's Media Profile spine can generate Participants for a multipartite Clique function in which these Agent Device's Participants might be these Cliques' Owners.
I have earlier referred to Clique Spaces as a form of Agent Collaboration Clique. Usage of this term to only describe Clique Spaces appears too restrictive; a Clique Space is an Agent Collaboration which is centrally managed by a group of one or more users possessing an Affiliation to the Clique Space's administrator Account Profile. Clique Spaces themselves provide domains for Element and Clique life-cycle management, Clique ownership as well as user security and privacy etc. Other Agent Collaborations are more fluid; they form grow, shrink and disband in accordance with the capacity by which users can form and disband, join and leave, or cede ownership of Cliques. Hence, a Clique's Participants may reside on the same Clique Space, or different Clique Spaces where the given Clique Spaces allow - through mutual agreement which can be modelled by a Clique - other Cliques to span theses Clique Spaces.
Something else that becomes apparent with these Agent Collaboration Cliques. They appear to be recursive; maybe even, and perhaps nonsensically, circular. They may be recursive if one has a need to observe people who are observing people who are ... observing a Clique of a conference call: beautiful big bro. They may be circular if I'm watching you watching me (ah huh..), but I think this has about as much utility as a similarly named Abba song suggests.
We'll see...
Wednesday, March 14, 2012
The Clique Space(TM) Media Profile and consideration of the mechanics of the Agent Collaboration
I've lost my head of steam on development for the moment. This loss of momentum has been due to considerations which have appeared in respect of implementing the final core Clique Space's Media Profile: the aptly named Clique Space Media Profile. This was previously known as the collaborator Media Profile, but that was when I though implementation of it and another Media Profile would be necessary. However, this necessity appeared to have evaporated, and shortly after that realisation, I decided that the name I was reserving for this other (Clique Space) Media Profile was more appropriate for the collaborator Media Profile; hence, I dropped the name "collaborator" for the collaborator Media Profile in favour of "Clique Space".
So, to the mechanics of an Agent Collaboration I now find necessary to entertain.
Each Agent Device uses its Clique Space Media Profile to represent itself as a Participant in the Clique Space Clique - the Clique that models the the Agent Collaboration in which each Participant represents each Agent Device's membership of a given Clique Space. Pretty simple: the Clique Space Clique is a model of a given Agent Collaboration much in the way any other Clique is a model of any other media collaboration - reflected in another Agent Collaboration which represents all the Agent Device's which possess a connection to the devices which have Participants in the other media Clique. So, in the specific case of the Clique Space Agent Collaboration, the medium being modelled is Clique Space.
That's all great, and it is exactly what I envisaged in July (or August, or perhaps September) 2004. However, now that I have arrived at this stage of implementation, I have to do a bit of thinking about the mechanics of the Agent Collaboration, and how the Clique Space Media Profile's 1: Enabling and 2: Limiting Constraints will map to 1: Agent Device functionality and 2: functional limitations imposed by the administrator(s) of a particular Clique Space.
Putting the media mapping to one side for now, I have to consider how the Agent Devices are actually going to collaborate. Each Agent Device is merely a node in a neural network, and messages are merely propagated across an Agent Collaboration to all Agent Devices which are members of a Clique. In the case of the Clique Space Clique, the given Agent Collaboration represents all Agent Devices that are members of the given Clique Space.
Another side point that is very interesting about this concept. Clique Spaces can be "federated" in a way by allowing a particular Clique to contain Participants from different Clique Spaces. Coupled with the flexibility of the Media Profile hierarchy and the flexible way Enabling Constraints can be expressed, and in the way Limiting Constraints (properties of any Element, but especially Account Profiles and their associated hierarchy) can be expressed in a Participant, this provides a level of administrative control that I believe is capable of "infinite phenomenological flexibility" (uh... okay...) in that any one individual can have full control of who else can see an interact with any collection of one or more devices one may possess within the phenomenon of what it is to be an individual.
Anyway, back to the technical details of the Agent Collaboration. Messages (I've settled on the term "pulses") shall propagate through the Clique Space's Agent Collaboration (the Clique Space's medium) like ripples through a pond. Any Agent Device with sufficient Limiting Constraint affinity can create a pulse. There are a whole slew of details that need to be figured out: what if an Agent Device goes off-line? What happens when an Agent Collaboration representing another medium contains Participants from multiple Clique Spaces? How are decisions made in situations when one pulse contradicts another?
All these considerations may be to a greater or lesser degree, different to the media being modelled. However, the Clique Space's Agent Collaboration - the Clique Space's medium (modelled by the Clique Space's Media Profile) being the medium that regulates all other media which Clique Space will model, will set an ultimate baseline to the ability of a Clique Space's implementation to realise this idea of infinite phenomenological flexibility. It is the Agent Collaboration's pulse that remains the largest unknown to this reality; and after working out how Agent Devices engage each other to create synapses, and how administrator Client Devices connect to and receive projections of various Elements so they can be viewed and persisted as necessary by the individual users of Clique Space, the pulse message is now the subject of my full attention.
Another six months perhaps...
So, to the mechanics of an Agent Collaboration I now find necessary to entertain.
Each Agent Device uses its Clique Space Media Profile to represent itself as a Participant in the Clique Space Clique - the Clique that models the the Agent Collaboration in which each Participant represents each Agent Device's membership of a given Clique Space. Pretty simple: the Clique Space Clique is a model of a given Agent Collaboration much in the way any other Clique is a model of any other media collaboration - reflected in another Agent Collaboration which represents all the Agent Device's which possess a connection to the devices which have Participants in the other media Clique. So, in the specific case of the Clique Space Agent Collaboration, the medium being modelled is Clique Space.
That's all great, and it is exactly what I envisaged in July (or August, or perhaps September) 2004. However, now that I have arrived at this stage of implementation, I have to do a bit of thinking about the mechanics of the Agent Collaboration, and how the Clique Space Media Profile's 1: Enabling and 2: Limiting Constraints will map to 1: Agent Device functionality and 2: functional limitations imposed by the administrator(s) of a particular Clique Space.
Putting the media mapping to one side for now, I have to consider how the Agent Devices are actually going to collaborate. Each Agent Device is merely a node in a neural network, and messages are merely propagated across an Agent Collaboration to all Agent Devices which are members of a Clique. In the case of the Clique Space Clique, the given Agent Collaboration represents all Agent Devices that are members of the given Clique Space.
Another side point that is very interesting about this concept. Clique Spaces can be "federated" in a way by allowing a particular Clique to contain Participants from different Clique Spaces. Coupled with the flexibility of the Media Profile hierarchy and the flexible way Enabling Constraints can be expressed, and in the way Limiting Constraints (properties of any Element, but especially Account Profiles and their associated hierarchy) can be expressed in a Participant, this provides a level of administrative control that I believe is capable of "infinite phenomenological flexibility" (uh... okay...) in that any one individual can have full control of who else can see an interact with any collection of one or more devices one may possess within the phenomenon of what it is to be an individual.
Anyway, back to the technical details of the Agent Collaboration. Messages (I've settled on the term "pulses") shall propagate through the Clique Space's Agent Collaboration (the Clique Space's medium) like ripples through a pond. Any Agent Device with sufficient Limiting Constraint affinity can create a pulse. There are a whole slew of details that need to be figured out: what if an Agent Device goes off-line? What happens when an Agent Collaboration representing another medium contains Participants from multiple Clique Spaces? How are decisions made in situations when one pulse contradicts another?
All these considerations may be to a greater or lesser degree, different to the media being modelled. However, the Clique Space's Agent Collaboration - the Clique Space's medium (modelled by the Clique Space's Media Profile) being the medium that regulates all other media which Clique Space will model, will set an ultimate baseline to the ability of a Clique Space's implementation to realise this idea of infinite phenomenological flexibility. It is the Agent Collaboration's pulse that remains the largest unknown to this reality; and after working out how Agent Devices engage each other to create synapses, and how administrator Client Devices connect to and receive projections of various Elements so they can be viewed and persisted as necessary by the individual users of Clique Space, the pulse message is now the subject of my full attention.
Another six months perhaps...
Thursday, March 8, 2012
All in good time.
Something I put in a couple of weeks ago is now talking back to me:
I've got news for it: you will be coded when I'm ready. No sooner than that!
java.lang.UnsupportedOperationException: [AgentTwo] Code me now!
at cliquespace.core.agentdevice.cliquespace.source.SourceClique.(SourceClique.java:244)
at cliquespace.core.agentdevice.cliquespace.source.clique.AgentCollaborationClique.(AgentCollaborationClique.java:28)
at cliquespace.core.agentdevice.pulse.ParticipantJoined.performAction(ParticipantJoined.java:83)
at cliquespace.core.agentdevice.AgentDevice.acceptPulse(AgentDevice.java:563)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:553)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
I've got news for it: you will be coded when I'm ready. No sooner than that!
Thursday, March 1, 2012
The first pulse.
At about 1:00pm today, I set up a Clique Space(TM) containing two Agent Devices. The first one (the Owner) sent a pulse to the second one containing a Clique Space's Participant (the fourth vertebral Element of the Clique Space's Media Profile spine) indicating the second Agent Device's membership of the given Clique Space through the synapse that resulted as a part of this exchange from the engagement process between the two Agent Devices. Very nice indeed.
I've still to get the second to set up its own instance of the Clique Space, but I currently believe this is a straightforward task. It has taken me close to four years to get this far - resolving many technical questions along the way.
I've still to get the second to set up its own instance of the Clique Space, but I currently believe this is a straightforward task. It has taken me close to four years to get this far - resolving many technical questions along the way.
Subscribe to:
Posts (Atom)