Determination of the Clique's medium.

Right now, I feel that I can direct my attention toward some very central issues of the Clique Space(TM) purpose.

The light of my enquiry appears to shine almost squarely on the issue of determining the medium which every Participant in a specific Clique will have. This blog entry therefore is some deliberation over the considerations central to this mechanism, and some implications on other mechanisms incident by this mechanism.

Every candidate Participant supplies a collection of Connections which represent devices underlying a given Participant if it were created. Each candidate supplies a set of one or more Connections which have been activated against an Identity, also given in the candidate. The Clique's medium is determined primarily by the candidate which is nominated as the Owner Participant.

The Owner's medium is determined by iterating through the Owner candidate's given set of Connections. For each Connection, the associated Media Profile hierarchy is flattened, and returned as a set of Media Profiles. Each of these iterations progressively builds a baseline medium; each iteration is the logical union between the Media Profile name correspondence from the Connection of the given iteration with the set which has been built in previous iterations. One of the Owner candidate's Connections is nominated as the Participant's Connection: it is the Connection on the device spine which will yield the type of Participant desired; the Media Profile, the Connection, and the hypothetical Participant are collectively known as the device's spine. Each of these elements extends the respective abstract Clique Space's element class declaration.

The other member candidates describe other sets of Connections from the same or other identities through which a similar process of building a set of Media Profiles will happen. Each member contributes to determining the Clique's medium: at the end of determining the medium for each member, the Owner's medium is trimmed by finding the logical intersection between the Owner's medium and each member. This is done progressively until all members have been iterated through.

The final medium obtained in this process is the maximum degree of functionality common to all candidates which can be contained by the candidate Owner Participant. The final consideration regarding the medium is to determine whether the given medium will be accepted by the spinal Connection. The Clique cannot form if any Media Profile present in the candidate medium is not present in the spinal medium. The spinal medium is found by flattening the hierarchy of the given spine's Media Profile as it is for any of the candidates' media.

Each member Participant is assigned its own version of the Owner's medium. This is because medium equivalence is determined by the correspondence between the name of the Owner's and member's Media Profile name. Hence, the name of the Media Profile is sufficient to determine equivalence and this means that a member can specify a name-equivalent Media Profile from a different Clique Space. The use of name-equivalent, but different Media Profile instances for different candidates may become a consideration in determining the Clique's mode when determining whether a Clique can form.

In some ways, the Clique's mode is very similar to its medium, but considerations regarding the Clique's mode depend on consensus between all the Clique's members; not primarily on the Owner's functional capacity.

Calculating the mode is determined by marrying all the Limiting Constraints specified by a given candidate to the Enabling Constraints of the derived medium, and also evaluating whether all candidates share Limiting Constraint affinity; the Clique cannot form if one or more members have properties which contradict the intentions of others.

A more algorithmic explanation around determining the Clique's mode will be covered in a later blog entry. :)

Something is sitting in my head.

I've got something in my head. I've been working on it in there since last Monday, and it'll have to remain in there until I file and serve my submissions in an application IBM's legal counsel have made in my case to have it struck out. Too bad there perhaps. Perhaps not. Perhaps I'll know on 19 April.

Back to my head and to the things therein.

I'm looking at what I perceive to be a solution that revisits deliberations around the same subject matter given in this entry in such a way that draws on the inherent abstract nature of the core data model. What is in my head is promising a lot.

In order to understand what is in my head, one needs to understand how every piece of information an Agent Device knows of (everything except Cliques) must be expressible as a component (well, more correctly, a transmissible component) before it can be propagated to other Agent Devices or projected to other V/PM-enabled devices. All components except the Sovereign's Clique Space are transmissible, and all transmissible components except the "observer" Participant are observable. Identifiers are not components, but do have a method named asQuantum that accepts no parameters.

The asQuantum method is also declared in the transmissible component interface so these type of components can be represented as a serialisable quantum which can be propagated or projected or persisted. All Elements implement the transmissible component interface, and delegate to the enclosed identifier's asQuantum method in the corresponding Element's asQuantum method.

The lovely observation my head has captured about the third category of component (the observable transmissible component) described above is that components of this type are indeed "observable". That is, these type of components have an observer - an "observer" Clique composed entirely of "observer" Participants. This Clique registers all devices (whether Agent Devices or any V/PM device - collectively  known as "observer" devices) that are interested in a particular "observable transmissible" component.

I can't wait to start work on this. I reckon this mechanism is the final key to a demonstrable prototype. The thing about this mechanism is that it (or the something that truly has to be implemented) has been in my head since mid-2004. It is only now, however, that the implementation of everything else had to be done before I was sufficiently prepared to investigate this observer mechanism.

Maybe I'm just a dickhead. Eureka!

Another quick and dirty Clique Space(TM) description.

I wrote the following in a letter to someone, and I think it does a good job at giving the reader a basic understanding of my concept. The description is very quick, and, unlike this one, perhaps forsakes a lot of detail in an attempt to keep it within reach of the reader's attention. Here it is...

********

I'll give you a run-down about what Clique Space is supposed to be. A Clique Space is a cluster of Agent Devices. Agent Devices talk to each other by opening channels - forming logical synapses - between themselves. An Agent Device can accept connections to different external devices depending on whether the Agent Device can support the medium that the external device uses. Any device at all, so long as it can exchange state information with another device, is a candidate for connecting to an Agent Device.

Every device is a device in Clique Space. This includes Agent Devices; they're nothing special in terms of what Clique Space is supposed to model. At any instant in time, any device that is collaborating with one or more other devices is modeled in Clique Space as a Participant in a Clique. A Clique can therefore have two or more member participants. One participant is the Clique's owner.

This is what I think is going on in real time in our brains (neurons form Cliques which grow, shrink and disband and move like pseudopods throughout one's whole nervous system) and my Clique Space hypothesis, if I can prove that it at least works, may go on to show how one can get devices (or, rather, clusters of devices) to behave like people [10 April 2013 edit: who are really just clusters of devices otherwise known as cells]). I think the Agent Device is a synthetic equivalent of a neuron; and will demonstrate the functional necessity of the neuron, the synapse, the neurotransmitter, and various other structural features of biological nervous systems we know exist.

********

Whatever description I could put in writing, I don't think I could cover the concept as comprehensively as I could if I disclosed the code. Yet, so far, the code I have is incomplete, and so the code does not even comprehensively cover the concept as it exists in my mind. Maybe sometime, I'll be able to present an implementation, and therefore prove the concept works.

Telework and CEO stupidity.

Clique Space(TM) came about because I wanted a system that informed others of my real-time activity over anything that can connect to and exchange information with a Clique Space. However, in this short blog entry, I will talk of my frustrations - frustrations which mothered my invention. I'm going to offer a brief opinion on how Yahoo's chief executive made a strategic decision last week that bordered on insane for its lack of forethought.

Technology created to realise of a mode of work that society has long desired, exists in a society that levels blame at the feet of this mode whenever things unrelated to it need to be fixed. The fact that an edict can come down to rescind a telework condition from employees, as though it were a light switch that is tuned on and off at the whims of a micromanager looking for something other than management philosophy to demonise, only underscores the blatant wanton stupidity of some who have been selected into executive positions.

Someday, I hope telework will become a condition that is not subject to the whims of micromanaging idiots. Maybe someday, and organisation called The Clique Space Organisation will provide a sanctuary for development teams to produce quality software without a CEO who wants to blame flagging revenues and market share on the fuzzy notion that telework isn't "what is right for [The Clique Space Organisation] right now".

Employees at Yahoo who find their telework restored can only look forward to the privilege being removed again whenever the CEO wants to be seen to be addressing another unrelated problem. Fix the real cause of your company's problem Marissa Mayer; it sure as hell isn't telework.

Michael Bloomberg, the mayor of New York city is reported to have said that telework is “one of the dumber ideas I’ve ever heard.”. I think that you, Mr Bloomberg, are an anachronism waiting for time to wash away.

Two more proprietary claims.

In addition to these claims, I make the following in relation to terms used in Clique Space(TM).

• The Clique Space Sovereign or the term "Sovereign" as it would appear in relationship to the discussion of Clique Space or any related concept.
• The Clique Space Mode Profile or the term "Mode Profile" as it would appear in relationship to the discussion of Clique Space or any related concept.

These new claims are new terms I have chosen to express the concepts labelled Axle and Account Profile of the previous post respectively.The existing claims still stand.

Agent Device assembly and analogue to a neuron.

Since I now have established a relatively stable implementation of the core data model, I have been adapting the Agent Device to it. This has actually gone through smoother than I imagined.

The core Element declarations were no big problem to implement in the Agent Device, and since the identifiers and their factory and quanta are generically closed in the core data model (inside the common Clique Space project - shared between Agent Device and administrator client), the Agent Device readily accepted the changes.

[Edit 19 March 2013: Much of the time,] I love this Clique Space (TM) adventure. I find that the architecture talks to me at least as much as I direct its form. As I walk through this journey, the concept reminds me of how similar its function is to that of a neuron.

For instance, I had to ponder a bit today about how external devices interface with a serving Agent Device. Now, a cluster of one or more Agent Devices form an Agent Collaboration. This Agent Collaboration constructs a Clique which is modelling a collaboration going on in another cluster of one or more external devices. Each external device is represented by one or more Participants in the Clique which represents this external device collaboration in one or more Clique Spaces; the Clique spans Clique Spaces when it contains Participants (a Clique must contain a minimum of two Participants) from two or more Clique Spaces.

Now, each Participant has at least one Connection which represents precisely one channel of communication between precisely one external device and precisely one Agent Device. The Agent Device from whence the Connection serving the external device originates could be of the same Agent Device as the one from whence the Participant originates; but then it may not be, and this fact might promise some rather interesting phenomena to do with the makeup of individual Participants. However, this aside, the dilema I had today was based around the question of knowing which Agent Device served which external device through which Connection.

This question is resolved nicely around the notions of generic closure of the Elements. This "generic closure" notion is one I've come to like as I have developed my idea in Java. Like the identifiers and their factories and quanta, the Elements come in a bottom and a top half. The bottom half of these structures create a "generically open" mechanism where classes and interfaces are parameterised in such a way that allows strong and circular type conveyance between almost all methods - certainly all methods that convey one Element out of another.

When implementing the top half of these open structures, one "generically closes" the bottom half with the desired implementation that the particular device requires. Neither the implemented identifiers, factory or quanta, nor the Elements require further parameterisation; hence the term. However - and this is very convenient indeed because it promises to overcome the dilemma I had pondered today - these generically closed implementations are regular Java classes, and hence can still be extended.

Now, considering the requirement that a single Agent Device must be responsible for serving a single external device, this extensibility can be applied to any given Connection as this given Connection is created on the Agent Device maintaining this service channel. This Agent Device can then transmit this Connection to other Agent Devices as necessary, and when the receiving Agent Devices reconstruct the transmitted Connection , they need only create the conventional underived version of the Connection.

This is especially good since the derived type of Connection object does not need to be conveyed in the connection identifier's quantum; this quantum is the first thing that is transmitted to an Agent Device (the receiver). This quantum lets the receiver know of the existence of a Connection Element identified by the identifier's value contained in the quantum object. As the receiver isn't the server for the Connection, it needn't create the extended Connection class. So, the receiver needn't even know of what the extended class the transmitter (or rather - because the receiver can be a link in a chain of transmissions and retransmissions - the originator) is extended as. Hence, any Agent Device can receive any type of connection object even if a given Agent Device does not have the extended version of the Connection class loaded in its JVM.

Quaint and rather good, that one. Still, a Connection, like any other Element, can contain any number and type of components it likes. One will probably have a need to deal with dynamic class loading and RMI code-base servers in time... a frustrating situation which will probably see me looking for a good library that will allow one Agent Device to load classes from another, or perhaps, to put one of these together myself.

Returning directly to the analogue with the neuron, this knowledge of the Connection type only by the Element's originator serves, I imagine, a very similar purpose to an organism which has only a subset of its interconnected neurons sending an receiving signals directly from cells of other organs. Most neurons merely relay signals from one neuron to the next, and hence, neither have, nor need, knowledge themselves of how those neurons connected to a cell of another organ actually serve these communication channels. The relay neurons, however, can, because they must, still convey information about these other cells.

Hence, the concept of a specialised Connection type appears to fit the purpose for those neurons (Agent Devices) which interface channels with cells of another organ (external Devices), while the general Connection type is what is constructed on the relay neurons.

Clique Space(TM) Progress Report

I think I now have a stable implementation of the data structure (data model) that realises the basic Clique Space capability. This basic data structure is manifest in the Clique Space project, and is built on in the Agent Device and administrator client (Client Device) projects so to specialise the basic data structure for these two devices.

The basic data structure is a marvel in its use of Java generics. To achieve type consistency between all the Elements, the Clique, the Clique Space, the Clique Space container, and the device implementations, each class is declared in almost an identical way. I think nothing has ever used Java's generic class parameterisation feature quite the same way that I have done here.