Lazy initialisation, the undisclosed Element, and things that send shivers down my spine.

It is necessary, that in order that a Clique Space(TM) Agent Device can operate properly, it must use a form of lazy initialisation to manage Elements that it knows of.

As a side note; each Clique Space Element is identified by an identifier which carries some characteristic which identifies a particular Element from any other Element in existence, and that includes Elements from other Clique Spaces - an Element identifier is universally unique. This is because a well-defined combination of Elements from multiple Clique Spaces can be combined to yield a Participant in a particular Clique, and any given Clique can potentially contain Participants (which are Elements too) from multiple Clique Spaces.

Back to the point of this lazy initialisation post. Every Element refers to a certain set of other Elements that help describe the given Element. For instance, a Connection contains direct references to the Account of the device's operator and usually one Media Profile (the head of a m:n Media Profile hierarchy) describing the characteristics of the device. Now, for various reasons relating to Clique Space's efficacy as well as performance (I won't go into them - they're fairly obvious after some deliberation), an Agent Device should be able to receive a Connection without having to know about the Account or the Media Profile.

An Agent Device may receive the identifier of a Connection's Account from another Agent Device when it receives a transmitter that describes a Connection. Now, if the receiver doesn't need to know anything about the Account at that point, it needn't request the Account either from the Agent Device that sent the Connection or from another Agent Device. The Agent Device would have no knowledge of the Connection's Account unless some other Connection or Affiliation disclosed the same Account, and the Agent Device 'successfully' queried its neighbours for the given Account at some time in the past.

So, without the knowledge of the Account Element, if the Agent Device queried its own Clique Space container for the Account with the given Account's identifier, the container would return null, and that is exactly as things should be.

However, any Agent Device making a request of its neighbours can only receive an Element from any other Agent Device if the receiver has sufficient constraint affinity. This constraint affinity is evaluated by the given Agent Device's neighbours which, by virtue of the degree of affinity that the neighbour Agent Devices possess, know of the Account. The neighbouring Agent Devices decide whether the requester can receive the Element, and will only transmit a copy should any one or more of the neighbours determine sufficient affinity exists - whether or not all Limiting Constraints can be positively matched against all necessary Enabling Constraints, and if they can, that no contradictions are evaluated.

If sufficient Limiting Constraint affinity can be determined, the Account is sent by the one or more neighbours that are made aware of the request, and hence, multiple copies may be received by the Agent Device that made the request. A great function of a neural network is redundancy - it reduces the likelihood of misunderstanding and subversion, and a neural network contains within itself, the natural phenomenon of signal correction; an Agent Device can use the information from the transmitters it receives from its neighbours, and, if necessary, can ignore any transmitter that is not consistent with a majority opinion of other transmitters thus received. Hence, I believe that my Agent Devices function as Participants in Cliques exactly as one might reasonably envisage neurons would function.

Back to the point of this post again. The particular requesting Agent Device's neighbours might determine that the requester does not have sufficient affinity to know of the given Account. In this case, the neighbours will send something else in response to the query: a transmitter that represents the undisclosed Element. I called the objects used to package and transport information between Agent Devices "transmitters" because, for all I know about biological neural networks, they appear to be logically similar to the function of neurotransmitters sent between neurons over a synapse. And indeed, transmitters are sent over a logical structure in Clique Space which is known as a synapse; hence my assertion are that there appears to be a lot of correspondence between my Clique Space concept and biological neural networks as other research has come to know them. I don't think this correspondence is a mere coincidence. A lot of assertions here to be disproved...

So anyway, an Agent Device receives an undisclosed Element's transmitter, and decides that, for reasons unbeknownst to itself, it cannot know the content of that Account. If, say, a copy of the given Account was received (one of the given requester's neighbours was perhaps behaving contrary to the majority), the requester may (depending on its own knowledge of the Limiting and Enabling constraint context) probably also find out why it shouldn't possess a copy of the Element, and may (possibly because it was a well-behaved Agent Device) not create an Element instance in its Clique Space container.

So, with an undisclosed Element, an Agent Device can 1: determine if it has permission to know of the details of a particular Element, and has been presented with 2: the opportunity to find out what these details are so that 3: an Agent Device needn't keep querying its neighbours for an Element which it cannot know about. There are many things in Clique Space like this which just happen to come together. Way back in July to September 2004, these things came together in a way that sent shivers down my spine. I identify now as I did then that maybe those shivers are Cliques of recognition in the frontal cortex of my own nervous system.

A request (possibly a plea) firstly to my German follower, but to anyone else who might like what I'm about.

Hello my follower from Germany.

I've noticed you for some time. Get back to me; I don't bite unless bitten, although I lend myself to cathartic attacks on politicians and others who have wronged me significantly. All I can surmise from my blog stats is that you're from Germany, that I believe you are one individual, and that you tend to visit my blog soon after I publish an entry. I too, am one individual and my progress is slow. I can use help.

I have patents on my concept, my code-base is (currently) proprietary and Clique Space is a trademark; but these legalities are simply intended to protect the value of my idea. I don't want to be a paranoid miser - I just want the world to know what is mine so that if what is mine does turn out to have any value, it is recognised by this world. Surely, there's nothing wrong with that.

Additionally, about three quarters of my blog's views come from the US, and I would believe a significant proportion of these would be from individuals who have, like my German friend, become genuinely interested enough in what I'm doing to want to register themselves as a follower.

It would be great to hear directly from anyone who has a genuine interest. My email can be found on my blog profile page. Alternatively, contact details are sure to be found by putting something like "Clique Space Owen Thomas" into a search engine.

Hear from you soon perhaps.

A crucial re-factoring exercise.

The Clique Space(TM) administrator Client Device appears to function again after re-factoring is applied with some lessons learnt about Java generics. Lessons learnt in the administrator's Client Device will now be applied to the Agent Device; and perhaps several more lessons will be learnt there.

Going back under...

Media Profile spines: redundant?

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.

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.

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.

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).