Thursday, April 26, 2012

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.

Sunday, April 8, 2012

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.

Saturday, April 7, 2012

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