Reflection on the Sovereign completes this picture.

My last deliberations pointed me to something structural in Clique Space(TM) which has given me some pause for further reflection.

Most of my posts in this blog rest on my attempts to explain and justify the efficacy of my core Clique Space concept. This core concept comprises ideas including Cliques, Clique Spaces and an assortment of Elements, all of which I am now implementing in a Java SE environment. While implementing this concept, I am looking at what its potential implications (other than those given in the patent) are. My previous post where I deliberated the subject of the expression of an individual in synthetic media has been echoing in my head since.

One trivial matter I have decided to address is to change the name of the Axle Element. It is now going to be known as the Sovereign. The Axle is potentially a target of cynical heckling: I can see people having a good time at my expense with labels like Axle holder. And anyway, I like the term Sovereign because one possesses sovereignty less than one is a Sovereign individual. I named this Element the Account in the patent because I simply hadn't come up with a better term at that point.

A far less trivial matter revolves around the relevance of this Sovereign. My need to reflect was born of what I have felt for some time was the lack of a mechanism linking the collaboration of individuals to the exchange of state information between Agent Devices and between Agent Devices and other external devices. I think today's reflection has finally forged this link.

The Axle, being renamed the Sovereign also ties in with the main subject of today's deliberation: the Sovereign's Clique Space. The Sovereign's Clique Space represents the individual. The Sovereign's Clique Space is a Clique Space which contains, as its Clique Space's Clique, a Clique otherwise known as the Sovereign's Clique. The Sovereign's Clique contains Participants which represent the Agent Collaboration which manifest the Sovereign's Clique Space. To underscore the formal convenience of this structure, the Sovereign's Clique Space and the Sovereign's Clique both have the same name; the value of the Sovereign's Identifier.

If a sentient individual manifest in a medium incompatible to Clique Space (a human being as we are currently manifest) might want to gain a vicarious presence in a Clique Space aware medium, then one might fashion a Sovereign's Clique Space made up of Agent Devices which are insufficiently capable of self-awareness and use this Agent Collaboration as a kind of Clique Space skin, endowing the individual with much of the ability to participate in collaborations mediated through Clique Space.

I think that the Sovereign Clique's member Participants may come to be considered sacred information knowable only to the individual manifest through the Agent Collaboration concerned. This is because the individual will want (and should have) unfettered possession of the Agent Devices which make up that individual; no one very much so in their right mind would want to unwillingly expose the mechanics responsible for their mind's functioning to the possibility of exploitation by external intentions. I believe the Sovereign's Clique Space mechanism is fit for the purposes of upholding the individual's sovereign and sacred nature.

All of this came together on today's walk. It appears to me to be a level higher than the synaptic map, but lower than an Agent Collaboration's Clique Space that might represent an entity formed of some cooperative endeavour; an Agent Collaboration's Clique Space which might otherwise be known as an organisation's Clique Space. I felt that my picture of this Clique Space strata needed some mechanism which set the manifestation of an individual through a Clique Space apart from the manifestation of an organisation through a Clique Space.

I had worried that something like this was missing from my deliberations for some years, and that what was missing was a mechanism of such profundity as would underscore an individual's sovereign (uncapitalised because I'm referring to the phenomenon rather than the component of my concept designed to capture this phenomenon), sacred and pre-eminent distinction; something which would endow the manifestation of the individual some distinguishing feature through which inalienable and inviolable rights afforded to an individual can then be assigned. The Sovereign's Clique Space is this mechanism; it uses nothing more than the core concepts given in the patent. It qualifies the Agent Collaboration's Clique Space which was given in the patent. The organisation's Clique Space is a version of the Agent Collaboration's Clique Space in which the Clique Space Clique would not have a name which is associated with a Sovereign Element identifier's value. All Agent Device members of the organisation Clique Space's Clique Space Clique would be members by consent of the individuals who claimed Sovereign possession of these members because an organisation's Clique Space Clique lacks the necessary mechanism to claim sovereign possession.

The Sovereign's Clique Space is a necessary middle level joining the potential for activity between individuals possible through an organisation's Clique Space, to the exchanging of Elements and their properties between any two Agent Devices which is the purpose of the synaptic map and the logical synapse.

So, it can be said that there are three basic layers to Clique Space, and each of these layers is denoted by a particular flavour of Clique Space. The bottom layer is concerned with the creation and transfer of Elements and their properties, is comprised of two Clique Spaces: the "synaptic map" and the "synapse". The second layer is concerned with the manifestation of or at least the interface for sentient participants, and its Clique Space is called the Sovereign's Clique Space. The third layer is the organisation's Clique Space, and this is where business and government organisations are manifest. I believe the middle layer, where notions of general sentience are situated, will complete the specification for a general medium which will become to be known by everyone who uses it, and who is manifest in it, as Clique Space.

To have come full-circle; starting with the Sovereign as the core Element of a core concept, then using the remaining core Elements and structures defined with them to bring a focus back to underscore the primacy of the Sovereign, is one of those things one does that induces pride and beauty in the aesthetic qualities of function. Something I have spent my lifetime chasing.

... of course, this has to work too.

Immortality in a Clique Space(TM) world.

Clique Space(TM); a concept permitting the existence of immortal beings?

This question is a contemplation which I have been entertaining because, as technology continues to evolve, our "selves" and the devices through which we express this strange quality are becoming more interrelated. We are getting closer to our contraptions; our contraptions are getting closer to ourselves.

We intuitively understand that an individual is expressed through a hominid form (a head, two arms, two legs, a torso, etc). But this is merely the impression we have formed over the past 3 or so million years. In Clique Space, the form, the manifestation, and hence, at least one Clique Space Identity defined by an individual, is a collection of devices, or rather a collection of Clique Space Connections, and a collection of capacities to act, or rather a collection of Clique Space Affiliations.

A Clique Space manifesting an individual is known as that individual's "sovereign" Clique Space. If each cell of our bodies is a device, then each cell can be represented as a Connection; there is nothing to prevent our current hominid form from being expressed in a sovereign Clique Space. The question of Affiliation in a sovereign Clique Space is not a concern, unless any neurons (the Agent Devices) of that individual's Clique Space form synapses with Agent Devices belonging to the sovereign Clique Space of another individual.

Perhaps something like a Vulkan mind-meld isn't too fanciful so long as both individuals have Clique Space aware nervous systems comprised of Agent Devices which can engage (form synapses) over some shared medium. In fact, this is precisely what Clique Space is designed to permit, and I'll talk some more about this a little later below.

In one model of my theory, each cell of a hominid body might be genetically engineered to interface amongst themselves using a synthetically (a product of the intellect rather than merely of the random process of mutation subject to selection which describes evolution, but then, the intellect only came about because of this process, so saying anything is truly synthetic is moot) generated collaboration structure modelled specifically through the body's neurons around a sovereign Clique Space. This sovereign Clique Space would be manifest by the collective action of this body's neurons (the Clique Space's Agent Devices); this Clique Space would in turn manifest the individual and one's singular self-identity.

In this model, the Clique Space is wholly contained in a hominid form, and in this model, I contend that there won't be too much to change because I think we will discover that our nervous system is already organised into very similar notions that I have expressed in my Clique Space concept. It might indeed be that other reasonably complicated intracellular (endocrine) mechanisms may also exhibit these properties, and conclude that the biological neural synapse is a specialised endocrine mechanism evolved specifically to communicate these as yet undiscovered biological equivalents of Clique Space Elements and their properties for the purpose of supporting and maintaining the wonderfully real illusion of individual self-identity.

So, a genetically engineered human body would represent an individual as a collection of devices, all of which are probably connected to a single Clique Space which represents this individual's body. This wonderful illusion of individual reality, corralled within one's own Clique Space, is manifest in one's own body. Any 'synthetic' individual sufficiently endowed with capacities equal to or greater than those of a regular person would have every reason to defend their presence if it were challenged by anyone else who appeared prejudiced enough to conclude their synthetic presence were artificial. Maybe these roles might reverse if the endowments were in the synthetic presence's favour.

An individual, even in hominid form, manifest from a Clique Space, is manifest through a system in which their own cognitive function can be viewed or persisted in real-time, provided the individual allows a View/persistence mechanism (V/PM) device to be connected to one or more of their sovereign Agent Device instances. This opportunity provides such individuals with a most exquisite way to control the way they work both within themselves, and with others.

Clique Space affords an individual a wider scope of existential possibilities. So, what about individuals who may not exist in hominid forms?

I conceived Clique Space in 2004 primarily because I wanted to give myself and other people access to a system that communicated activity of connected devices (phones, computers, cars, email, etc.) of one individual to one or more others according to mutual affinity of preferences amongst all parties. If you were a Clique Space user interested in whether I was doing some activity that I was permitting you to know about, then you would be able to find out. I am, indeed, permitting the communication of a version of my "self" (an Identity) to you by the fact that I am a member of a Clique in which you are also a member, or at least have the ability to observe through a V/PM device..

My Identity becomes diffuse through the Clique Space neural aether. An Identity which I project to you is not bound by my hominid form. Maybe, my "self" (I think I have adequately offered the notion of the Sovereign to represent this quality) can also shed its mortal hominid coil and migrate away from my human form. The administration of my Sovereign is highly profound task of self-identification that I would not share with anyone else.

An individual's Sovereign is the most sacred Element of that individual. One may only offer their Sovereign's identifier to another only in the most intimate of relationships, because one is really offering a property of themselves that drives most closely to the notion of one's own sovereignty. The Sovereign encloses within it properties that, even in the most intimate of circumstances, one individual should never share with another, lest that individual's self-identity become subsumed by another's. Certain Agent Devices known only to the individual must be, by the fact that they contain sacred information, the absolute property of that individual.

However, the individual in Clique Space may find that their presence can migrate outside of one's sovereignty boundaries. Sovereignty boundaries can be delineated by Clique Space membership. Agent Devices which are members of a sovereign Clique Space boundary are Participants in the Clique Space's Clique; something that the individual, manifest by these Agent Devices, may wish also to keep to themselves.

The mechanics made possible through a neural network of autonomous Agent Device instances allow individuals to cohabit the aether formed through these Agent Device interconnections by projecting Clique Space Elements through Agent Device instances which are members of others' sovereign Clique Space boundaries. Clique Spaces can be formed which do not represent an individual; these Clique Spaces represent a coalition of individuals, and incorporate Agent Devices as members of the non-sovereign Clique Space's Clique from various individuals which offer their support to the existence of this Clique Space. I believe that non-sovereign Clique Spaces allow organisations and governments to represent themselves appropriately in a world where individual sovereignty is held in a society as being that which is valued most.

The individual may also consider other Elements and properties of other Elements to be sacred, and will likewise limit their disclosure amongst Agent Devices within the sovereign boundary; the Clique Space Clique and its member Participants are one such collection of properties. Yet still, the individual can project themselves through others by disclosing Identities, Connections, Affiliations, and Participants to other individuals' Agent Devices.

The definition of the self becomes far more formalised through Clique Space than it ever can be in the a world where the individual's sovereignty is limited by the physical boundaries currently imposed by one's current hominid form. These boundaries will break down in a Clique Space future, but yet again, they will become more recognisable.

Such an individual, free of existence within a human body, will exist in other media which would persist beyond a human body. An individual can acquire Agent Devices indefinitely. Provided a continuity of presence can be maintained, an individual can prolong their existence indefinitely by a process of gradual migration through a sovereign Clique Space. Agent Devices would become a very dear commodity to such individuals; more Agent Devices promise more complicated behaviour.

Hence, collections of Agent Devices, all of which are members of an individual's sovereign Clique Space boundary, would be guarded by the individual manifest by these Agent Devices. If the capability of an individual may be physically limited only by the number and synaptic configuration of the Agent Devices within their sovereign Clique Space boundary, then individuals may indeed covet the capabilities which the acquisition of these Agent Device instances would endow.

Imagine the following bizarre scenarios! While Clique Space would promise the individual release from a human form, this release might also deliver a greater urgency to guard against the possibility of insidious violations to one's own sacred self-identity. Ecosystems might form around coalitions to protect and to predate on a consistent self-identity. The breakdown of self-identity in a breach of Clique Space sovereignty would be the most subversively insidious thing that can happen to these individuals. It would be so destabilising to the victim that only the victim's friends and associates might pick out that something is amiss.

Maybe, even an economy could form where individuals allow the trade or even perhaps the "lease" of clusters of one's own sovereign Agent Device instances for gains elsewhere in their lives. In fact, Clique Space is designed for this very purpose. Even though an Agent Device can be a member of precisely one sovereign Clique Space (that Clique Space in which the Sovereign containing sacred properties belongs), an Agent Device can potentially federate with members of other Clique Spaces, even Clique Spaces that don't represent a single individual. Agent Devices do this by acquiring Elements for other Clique Spaces as the need dictates.

Clique Space is a very fluid environment. I believe that Clique Space is also a very stable environment. I believe that a Clique Space can but needn't exist to manifest individuals. However, individuals who are manifest purely as sovereign Clique Spaces have the potential to be immortal by the fact that the Agent Devices which are members of their sovereign Clique Space's Clique can be replaced indefinitely.

Individuals manifest in other forms than through a Clique Space (a human being, perhaps) would not want the cluster of Agent Devices that represent their sovereign Clique Space to acquire any great degree of autonomy from which a distinct self-awareness may emerge lest this Clique Space decides to "go it alone". It might therefore be a better idea perhaps to keep their sovereign cluster relatively small unless or until the individual can migrate one's self-identity through the physical boundary of their biological neural network into their sovereign Clique Space and too, become a sentience wholly expressed through a synthetic neural medium.

Account Profile -> Mode Profile?

Another 9k walk brings about another turning of the Clique Space(TM) soil and another chance to massage the ideas put in the patent. Perhaps, another chance to cast these ideas into the realm of prior art.

This idea development concerns the purpose of the Account Profile with regard to the generation of a Participant for a certain Clique. Now, let's be fair. The Account Profile concept appears in the patent because I felt that the Limiting Constraints a Participant could take would mostly be conditional on the role that an Active Affiliation (now an Identity) would assume. A role (an Affiliation) is associated with a role hierarchy - an Account Profile hierarchy. Now, this is exactly the idea that I retain when I change the name of the Account Profile to the Mode Profile. This blog entry is merely a product of an opportunity I have had to think more about the detail of this mechanism. One should find little to surprise ones self when given more time to deliberate an idea, my idea appears to have become more complicated. Still, I assert that I have preserved the intent as it was given in the patent.

The change of the name is both a clarification on the structural relationships between the other Elements, and an acknowledgement about how the Mode (nee Account) Profile's purpose fulfils the objectives of the Clique Space concept especially in relation to Participant creation and destruction. This clarification also promises to widen other avenues of exploration: 1. how the concept of constraint compromise is asserted and accepted, and 2. how Cliques can be used as a means of conveying all manner of information about individuals; information that these individuals want others to know by virtue of the fact that one has a Participant as a member of a Clique. The second of these ideas may be deliberated in a future entry, but the first is covered somewhat below...

The term Mode Profile conveys a better structural meaning than Account Profile: a Clique's medium is shaped by its mode. A Clique's medium is specified by the flattened Media Profile hierarchy union of all the Participant's constituent Connections. A Clique's mode is similarly specified by finding the union of the flattened a Mode Profile hierarchy - specified by the Participant's constituent Affiliations. Because a Clique's mode must cover the Clique's medium, every parameter of each Media Profile's Enabling Constraint must be specified by no more than one Limiting Constraint value of a corresponding Mode Profile, and every parameter must be specified exactly once.

Hence, every Enabling Constraints' parameter in the flattened Media Profile which the flattened Mode Profile hierarchy describes must be covered once, and once only by the flattened Mode Profile hierarchy. Doing this creates a tightly coupled relationship between a Mode Profile hierarchy and the Media Profile hierarchy the Mode Profile hierarchy provides Limiting Constraint values for. However, I believe that the exercise of care in crafting Media and Mode Profile hierarchies should prove this coupling to be extremely versatile... we'll see...

The case may certainly arise where a role provider certainly does not intend to restrict the function of a device to some tightly constrained range of operational freedom. In these cases, the Mode Profile has two tools: the "unspecified" Limiting Constraint value, and an indicator showing whether or not a Limiting Constraint will permit compromise.

The unspecified value is intended to allow a Mode Profile to explicitly say that a Clique may exist in which values freely vary in one or more parameters. This Limiting Constraint value is compatible with any Enabling Constraint parameter. Relationships might be able to be set up between parameters so that specific parameters may be set to determine how other parameters may vary. For instance, one Clique may exist where values can vary, but only if all participants vary them to the same values in unison. Alternatively, a Clique may exist where Participants may freely vary one or more parameters to whatever value each Participant desired. Additionally, a Clique may exist where one or more parameters may specify a range of values that other parameters may freely vary within. Yet other Cliques may exist where parameters may depend on some relationship between other parameters, and control of them may be encoded in a Clique control algorithm specified in the Media Profile or left to the mechanics of the external devices' collaboration to moderate.

Whether or not a Limiting Constraint will permit compromise (also used in other internal Elements than merely the Mode Profile) is intended to be a way to allow a Participant's medium to acquire Limiting Constraint values which contradict the values given from two or more internal Elements. The compromise indicator has two values: deny and permit. This indicator asserted by one source, will permit Clique Space some ability to determine whether this source or another source contradicting the first source should be expressed in the Participant. Compromise needs to be taken into account when dealing with contradicting Limiting Constraints from the following competing sources: 1. a device in terms of a Connection or its constituent Media Profiles, 2. the individual in terms of an Identity or an Axle, 3. the provider of a role in terms of an Affiliation or its constituent Mode Profiles, and 4 as a Limiting Constraint with an unspecified source provided when the Participant is to be created. This compromise indicator is used in 1. a Mode or Media Profile in relation to a specific medium or 2. unrelated to a specific medium in another internal Element within the scope of an identity or to a Limiting Constraint with an unspecified source.

As briefly stated above, a Limiting Constraint permitting compromise may also permit overriding by a value given without an internal Element source at the time a Participant is created. The Participant, if created, is indicated as the source to these type of Limiting Constraints. In any case, if two or more Limiting Constraints describing the same parameter are found, and none of these parameters deny compromise, then the Clique Space will respond first by informing the individual associated with Identity through a connected View enabled device, waiting for a time specified by the individual requesting formation. If, in any case, two or more Limiting Constraints relating to the same parameter but from different sources deny compromise, then no Participant can be created. Hence, an Identity cannot provide two or more Limiting Constraint values for a single Enabling Constraint parameter which do not allow compromise; at least one must allow compromise.

These mechanisms allow a Clique's medium and mode to be as flexible or as organised as the individual members might, by their membership of the Clique, permit. It would be interesting indeed to see a mechanism like this work.

Société Clique Space

Perhaps I illustrate the limits of my knowledge of the French language. C'est la vie...

Imagine that an individual within this world can determine which individual is responsible for every single bit of hardware and software - every device - one might come into contact with as one travels through life. Imagine an individual who can choose to ignore any device if they cannot readily determine who is responsible for a particular device. Imagine in this world, an individual who can record, in real time, the activity of any device one possesses, and can produce this device activity log as evidence of some interaction with other individuals at some future point in time.

This is Clique Space(TM). This concept uses the notion of constraints to provide a way for users to communicate mutual affinity between devices before these devices engage in a collaboration. Clique Space allows one individual to find any device possessed by an individual as easily as it will allow that individual to find an individual who possesses a device.

Technically, this mechanism exhibits many parallels with a nervous system. However, I am no authority on nervous systems, so my estimations on the similarity between Clique Space and a nervous system may be groundless, but I'd like that to be proven. My prototype is still incomplete, but I can now perhaps see what is left to be done.

An Intricate Mechanism.

Clique Space(TM) models collaborations as Cliques.

Cliques are made up of at least two Participants.

One Participant is the Clique's Owner.

Each of the Clique's Participants represents at least one device being used by an individual in the collaboration being modelled by the Clique.

The Clique has a medium which is determined by it's Owner and accepted by all other member Participants.

Each Participant has a mode which appropriately asserts how the member Participant's state conforms to that of the Owner.

The Clique's medium exposes the collaboration's characteristics to Clique Space.

A medium must be described by a flattened Media Profile hierarchy that contains a Media Profile root.

The root Media Profile describes the characteristics of the Clique Space components for a given Participant instance.

A Clique's medium is defined by a subset of the Owner's flattened Media Profile hierarchy.

All other member Participants must be able to describe the Clique's medium through flattening the Media Profile hierarchies of their constituent Connections.

A medium can be translated into a set of Enabling Constraint parameters.

A medium must be completely covered by the Participant's mode.

A mode is a set of Limiting Constraints which are primarily determined by a subset of the Owner's flattened Account Profile hierarchy.

The Clique's root Account Profile encodes the specific values that the Clique Space's data model take for a specific Participant.

Constituent Elements from a member's candidate may offer unspecified values or alternative value "compromises" to the set determined by flattening the nominated Account Profile hierarchies.

Limiting Constraints in an Account Profile flagged as not allowing compromises cannot be replaced by specific Limiting Constraints, whether from any other Element or unassigned.

All member Participants must be able to respond to changes in the Clique's mode which are made by the Owner to remain "in the Clique".

Member Participants leave their Clique.

Owner Participants disband their Clique.

A Clique will automatically disband should all member Participants leave.

The Owner can cede ownership to another member provided this other member accepts the title.

Member Participant candidates are made up of selected Connections and Affiliations, specific extra or compromise Limiting Constraints, and a selected Identity, all of which are used to determine the mode-form of a member Participant if created.

An Owner candidate specifies the same details as a member candidate, but also specifies a Clique's name.

Any Connection and Affiliation nominated in a candidate must have been "activated" against the same nominated Identity of the given candidate.

Any compromise or extra Limiting Constraint may only be specified from one of the nominated Affiliations or Connections, from the nominated Identity, from the Axle, or from one of the medium's Media Profiles.

Any number of extra Limiting Constraints unassigned to any given Element may be nominated in a candidate, and Limiting Constraints of this type are associated with the Participant they are expressed in should the Participant be created.

For any candidate, no more than one unassigned Limiting Constraint may cover an Enabling Constraint's parameter of the Clique's medium.

An unassigned Limiting Constraint must cover an Enabling Constraint's parameter of the Clique's medium.

A member candidate is asked to join an existing Clique, while an Owner candidate is asked to form a new Clique with one or more supplied member candidates.

A Clique Space knows of an indeterminate number of Element types, the first seven of which are:

1. Axle
2. Account Profile (node and root)
3. Media Profile (node and root)
4. Connection
5. Affiliation
6. Identity
7. Participant

Each Element indicates the Clique Space which is responsible for the Element's administration.

Arrangements around a single Axle of instances from the remaining Elements represent a Client Device.

An instance of a node Media Profile or Connection can return a type which represents the type of device that can connect. Hence the reason why the number of Element types is indeterminate.

Limiting Constraints map to individual parameters of a Media Profile's Enabling Constraints.

One Enabling Constraint's parameter can only be covered by a single Limiting Constraint in any given Element.

A Participant's collection of Limiting Constraints express an individuals acceptance of the Clique's mode.

Zero or more Participants can be created from any Identity.

Every Participant must have an Identity, except where a Participant represents an unconnected device.

An Identity contains multiple Connections, any combination of which might be used in a Participant.

An Identity contains multiple Affiliations, any combination of which might be used in a Participant.

An Identity refers to a single Axle.

The expressed Connections and Affiliations within a single Identity instance are known as an Identity's constituents.

An Identity must contain no constituent with a Limiting Constraint that contradicts that of any other constituent.

A Connection associates an Axle with a node Media Profile.

A Connection contains the component that permits communication with the device in accordance with the associated Media Profile

A Media Profile contains the component that is used to decide whether a Participant using a medium which expresses the Media Profile has sufficient Limiting Constraint affinity to perform some action governed by the Media Profile.

An Affiliation associates an Axle with a node Account Profile.

The Axle associated in a Connection must be the Axle referred to in the Identities through which the Connection has been activated.

The Axle associated in an Affiliation must be the Axle referred to in the Identities through which the Affiliation has been activated.

The Axle represents the individual; a transcendent supervisory presence capable of possessing a device and using the device to participate in collaborations which are modelled as Cliques.

An individual, through a different, or even the same device or devices, may appear as one, two, or more Participants in the same Clique.

A device is something which can obtain a Connection to and exchange information with a Clique Space through an Agent Device.

An Agent Device is a type of device.

An administrator client is another type of device.

The administrator client renders Elements onto its View which have been projected from Agent Devices through which the administrator client has obtained Connections.

The administrator client provides a facility through which Agent Devices and Clique Spaces can be administrated.

The Agent Device is administered through its synaptic map.

A synaptic map is a type of Clique Space. 

Agent Devices engage with other Agent Devices by creating synapses.

Agent Devices disengage with other Agent Devices by destroying synapses.

A synapse opens a channel through which transmitters are sent from one Agent Device to one other Agent Device.

A synapse on one Agent Device is a replication of another Agent Device's synaptic map.

A synapse is another type of Clique Space.

Agent Collaborations' Clique Spaces are Clique Spaces in which collaborative activity between external devices is recorded.

Agent Devices sharing direct membership of the Agent Collaboration are represented as Participants of the Agent Collaboration Clique Space's Clique.

There we go. A good summary. At the very least, a disclosure this detailed renders my technology prior art. I am not saying whether the summary I give is covered by my patent. I assert that this is the intent, but whether or not this is actually the case is not up to me.

Now, I appear still to have some (perhaps many) rather complicated unresolved issues. I am engineering a solution that will allow an Agent Device to transmit instructions to add and remove Elements' components to an administrator client. The administrator client must be capable of rendering "projected" Elements to its View of the Clique Space universe from the Agent Devices through which these transmissions are received. Agent Devices will also use the bulk of this mechanism to transmit components between themselves.

The thing about this whole Clique Space concept is that the data model described above is used to 1. model collaborations going on amongst Agent Devices and other external devices including the administrator client and to 2. determine which Agent Devices and which other external devices including the administrator client are recipients of changes in an Element's state. The Clique Space data model offers a simultaneous solution to the model and the controller pieces of the model-view-controller design pattern.

Point 2 of the above paragraph can be recast in this way: an Agent Device uses the data model to determine which other devices are interested in the state of Elements. This Agent Device will tell these other devices that the state of an Element has changed (an Element's component has been added or removed) if a particular device is registered as possessing an interest in this Element.

So, how is another device's interest in an Element registered in an Agent Device? Implementing the solution to this question is currently (and finally) occupying all my attention. The solution comes in two parts of its own.

In the first part, an administrator client (or any V/PM device) can receive information about the state of any Element from any Agent Device to which an external device is connected; potentially even from Clique Spaces other than the one or more Clique Spaces through which the external device's Connection's are obtained. The ability for the given external V/PM device to receive information about an Element is determined by the Limiting Constraints which are expressed in the serving Agent Device's Clique; a Clique created for any external device which also represents an instance of a Connection - an association between an Axle and a specific Media Profile type - through the given device to a Clique Space for which the Owner of the synaptic map's Clique (known by the engager Participant recorded as the Connection's originator component) transmits Element state.

The second part involves the transmission of element state information between Agent Devices through the Agent Device's Media Profile. The Agent Device's Media Profile exhibits the unique property in that the Participants in an Agent Collaboration's Clique are not transmissible between Agent Devices. An Agent Collaboration's Clique tells a particular Agent Device which other Agent Devices are interested in a particular Element. The fact that Participants in an Agent Collaboration's Clique are not transmissible avoids the possibility of infinite regress.

Participants generated from Connections which come from an Agent Device's Media Profile will appear in the serving Agent Device's Clique of the first part. The other Participant is generated from the external device's Connection. Both Participants of the serving Agent Device's Clique can be transmitted to other Agent Devices and to V/PM devices where constraints permit this transmission.

These questions make up the implementation of some very deep considerations I was entertaining when I conceived this concept. If I can actually implement the mechanisms I describe in the paragraphs above, I think I will have arrived at a proof of concept.

Less on the Axle.

It is probably better that upon connecting, a Participant adapter (the Connection of an Agent Device or V/PM device) register itself with the Identity through which the Connection is expressed. This means that the Agent Device serving the device represented by the Participant adapter does not have to acquire the Axle's identifier in order to add a given Participant adapter to the Agent Device's set of served Participant adapters expressed in a given Axle. Perhaps this will permit the Agent Device instances to express these served Participant adapters in an Identity even when an Agent Device does not know the Identity's Axle.

It is hoped this will permit an individual to connect a device to an Agent Device operated by another individual without the first individual having to disclose their Axle to the second. I like this; it is a more flexible proposition.

It is true. Your Axle is a private part that you may share with others, but if you give your sovereign away, your sovereignty goes with it.

How do I know who I am on Clique Space(TM)? How do I let others know who I am on Clique Space? How do others on Clique Space know who I am?

Axles serve an intimate purpose of self-identification. In Clique Space, Axles identify what is yours to yourself, and if you wish it, to others who you have nominated as being privy to your Axle's components, but especially the Axle's identifier. You can share or withhold this Element's identifier from disclosure through any Identity you have created. You know all these Identities are yours because they have been created only by you as the possessor of the Axle, and by using your Axle's sovereign - a private key which you never disclose to anyone else - to sign each Identity's identifier. You let others know each Identity you have created is yours by disclosing your Axle. If you don't want to let others know who is behind an Identity you publish, then you assign a Limiting Constraint to your Identity that prevents disclosure of your Axle to them.

I believe there is certainly a versatility - nay, even power - given to the individual in cyberspace through this Clique Space concept.

Now, to a more practical matter: the relaying of device activity to the individual Axle holder. This matter concerns, indeed, Clique Space mandates the concern of how devices having an interest in the Clique Space activity - any Agent Device or View/persistence mechanism-enabled (V/PM) device - are kept informed of the state of the one or more Clique Spaces to which the said devices are connected. In order for a device to be Clique Space aware, the device must be connected to a Clique Space. An individual - an Axle-holder - is really the thing capable of being aware of Clique Spaces just as they are aware of how hot or how hungry they may be; devices merely relay temperature or blood glucose levels to a device loosely called the brain wherein, in today's society, an individual appears manifest.

An Agent Device is a type of device which can talk to other Agent Devices. Agent Devices share information about Clique Space Elements, participating in the distribution of device activity throughout a Clique Space (a domain which is managed by a subset of the individuals who use the Clique Space) as the activity of all individuals who use the Clique Space. An individual, having both the capacity and the desire to observe or persist activity on a particular Clique Space connects one or more devices capable of doing this through their own Axle. In order to use these devices in any meaningful way, their Connections must be expressed through one or more Identities - created using the same Axle.

Any device which is not an Agent Device or a V/PM device is connected to a Clique Space using this same mechanism, but the Elements and components (really, just the components) used for and generated by the connection operation are not disclosed to the given device. This is because the device, not being an Agent Device or a V/PM device, doesn't have a facility to make sense of Clique Space Elements.

Lets now take a look at the Agent Device and the V/PM devices. These devices need a way of receiving information about the change in the state of all the connected devices. Now, any device (be it an Agent Device or a V/PM device) must be accessible from one collection within the Agent Device to which it is connected. It appears intuitive, and technically it is also a reasonable proposition, for the Axle's instance on a particular Agent Device to contain a set of all such Connection instances.

I have removed the notion of an "Adapter" interface except for the class called the Participant adapter - which is now implemented by any V/PM device. I think the adapter interface is a good candidate for massage so that the Agent Device's Connection can also implement this interface.

I predict some heavy-duty thinking over the next several weeks. For instance, if wer're going to use the adapter interface, then we must recognise that the methods on this interface must supply the same information for the Agent Device's Connection as is necessary for any other V/PM device.

This method's implementation on the Connection of the administrator client transmits a quantum from an Agent Device to a V/PM device. It has the following signature:

•  void transmit(SourceParticipantAdapter participantAdapter,Transmitter transmitter)
       throws CliqueSpaceException;

The first parameter, participantAdapter discloses the Connection to which the desired quantum, enclosed in the transmitter given as the second parameter will be transmitted. Currently, only the administrator client's Connection (AdministratorClientConnection) implements this method, but I think it would be a good thing if this method were declared in the adaptor interface; it isn't currently. The adaptor interface needs to be implemented in the Agent Collaboration's Connection (AgentCollaborationConnection), an instance of which is created in the underlying Agent Collaboration's Clique of any other client collaboration's Clique - remember - if the client collaboration's Clique involves the participation of more than one Agent Device.

With both of these Connections implementing the same adapter, they can be contained within a set of adapters inside the same Axle as the one through which this Agent Device is connected. This, however, seems to hint at a complication: if each adapter of this set must name the same Axle in which this set is contained (must it?), then what happens if someone, using a different Axle, connects a V/PM device to this Agent Device? Is it possible that this ominous restriction is actually a ray of clarification?

The Agent Collaboration's Connection would surely implement the transmit method differently to the V/PM device; rather than transmitting the transmitter directly to the device (this would be the case in any instance of a V/PM device that I can currently think of), the Agent Collaboration's Connection would find its associated Participant (of which there would only be one) and transmit the information to all other members of the Clique excluding itself. This mechanism is detail around the concept exactly as I envisaged in mid-2004.

Some heavy-duty thinking to flesh out and implement this mechanism is needed indeed, but more than eight years of heavy-duty thinking has drawn me slowly to the acceptance that this overall concept will eventually be proven.

We'll see...

How is information distributed through Clique Space(TM)?

This question is a bit obvious, but it is one which I had no specific answer for when I put my patent together.

When I conceived the Clique Space(TM) data model, I took as an article of some speculative faith, the premise that I could work out the technical considerations of how this model would be used to realise the mechanism that actually allows one Agent Device to exchange information with one or more others, as well as how one Agent Device exchanges Clique Space Element information for external device state information. I had hypothesised that mechanisms would emerge as a result of the deliberations necessary to get from the concept recorded in the patent, to its implementation recorded in code.

I envisaged that perhaps some degree of similarity between Clique Spaces and biological nervous systems would emerge, and indeed, this appears to have happened in at least one example: the emergence of the logical synapse necessary to open a channel for exchange between two Agent Devices. Although the synapse is reasonably stable, my current deliberations will have an impact on this mechanism because the changing form of the information exchange will also change the way Agent Devices engage and disengage, forming and disbanding bipartite Cliques which represent these synapses. Although I had thought the synapse might emerge as far back as when I put the patent together, this hypothetical mechanism lacked the implementation detail that exists currently; it is anticipated that some of this current detail will have been discarded and replaced before one can confidently say the synapse mechanism exhibits its final form.

The wider deliberation of the mechanism needed to get collections of Agent Devices, being members of a Clique, to communicate the changing state of their Elements amongst each other have brought me to yet other limits of my intellectual capacity as it was when I put the patent together. I feel that the implementation has evolved to a point where, since stabilising the implementation of the properties mechanism discussed in my last post - an act in itself which has pointed me the way to the promise of an answer - I now appear prepared to start replacing at least some of this faith with some reason.

At least at a purely logical level, I think my progression from this point may provide some interesting insight into how a biological nervous system recruits and coordinates its individual neurons in the performance of some act instigated by and for the organism as a whole. Such a mechanism would exhibit hierarchical and executive command and control structures, but would also simultaneously appear to self-assemble based on some form of consensus between neurons (Agent Devices) in accordance with the varying capacity of each neuron to participate. Hence, it would be very hard in any Clique Space (indeed, as it might be demonstrated in any neural system) to point to a single Agent Device as being ultimately responsible for the conduct of any Clique Space as a whole.

Whether synthetic or biological, any such system would definitely require some systematic form of message propagation. It is to this mechanism that my deliberations appear once more to turn. I have some general ideas which I hope to test. For instance, as I explained in a previous post, I see the necessity for Agent Devices to have two Cliques model a single collaboration between a collection of devices, whether these devices are Agent Devices being members of a Clique space, or a collection of devices participating in a collaboration defined by a Media Profile type external to the Clique Space implementation.

The first Clique primarily models what is actually going on in the collaboration; it gives Clique Space a sense of the collaboration's reason for existence, and to the characteristics of its member Participants in accordance to the ability of the Clique's medium to report the collaboration's activity. The second Clique is used to model which Agent Devices have a stake in knowing what is going on in the first Clique by virtue of the fact that any member Participants of this Agent Collaboration's Clique share a combination of the following three relationships with the first Clique: 1. that these Agent Devices are connected to the devices who's collaborative activity is being modelled as participants of the first Clique, or 2. that these Agent Devices are connected to a View or persistence mechanism-enabled devices viewing or persisting activity of the first Clique, and optionally, may be capable of controlling the first Clique, or 3. that these Agent Devices may be acting as relay devices, permitting propagation of Element state from Agent Devices of the first two types located in one physical location to those located in another, but for which the Agent Devices at the first location share no synapses with those at the second; perhaps a bit like a corpus callosum.

This dual-Clique scheme seems a reasonable way to propagate messages amongst relevant Agent Devices, but this mechanism does not include View or persistence devices, because they are not Agent Devices, and hence lack the mechanics necessary to participate in an Agent Collaboration. These type of external devices require another protocol to receive and process Element state information, even if these devices use the same message transport vehicle - the component transmitter, discussed in the previous entry - used in the Agent Collaboration.

It might be interesting at this point to consider how it is a designed intent that the Media Profile Element fits the bill for encoding the protocol for any collaboration type so an Agent Device can receive, process, and control device state. The information content generated by any device may be augmented with Clique Space information in the given device's media in accordance with the Media Profile through which a Connection has been established. The general concept of the Media Profile is used to describe the parameters that a specific protocol will accept. Specifically, the protocols which describe the operational parameters of 1. the Agent Collaboration, and 2. the administrator client, are exposed through Media Profiles like any other protocols. Hence, the Agent Collaboration's protocol is exposed inside the mechanism that implements this protocol by an Agent Collaboration Media Profile so the Agent Collaboration's activity, modelled as a Clique, can be Viewed, persisted, or controlled by an administrator client or any external device which possesses such a capability.

Hence, the Agent Devices have their Agent Collaboration Media Profile. This Media Profile provides the mechanism that realises the second Clique necessary for the dual-Clique propagation scheme. A Media Profile for the administrator client will be fashioned that facilitates the component exchange scheme between an Agent Device and a View or persistence enabled external device. Both the administrator client's component exchange and the Agent Device's dual-Clique schemes will use the common component propagation and exchange mechanism - the component transmitter.

The component transmitter mechanism currently looks like the ideal candidate for the administrator client component exchange scheme as it is for the Agent Device's dual-clique scheme. This is the intention for the design of the component transmitter mechanism; this mechanism replaces the failed Element precis mechanism for the Agent Collaboration, and a promising, but demonstrably inadequate Element projection mechanism for the administrator client. Both the failure of the Element precis and the inadequacy of the Element projection mechanisms prompted me to look to the component transmitter mechanism as a sufficient and flexible alternative candidate for a solution to the question of message propagation.

Elements and components; components and properties; properties and transmitters; transmitters and quanta; quanta and components; components and components; components and transmitters; transmitters and Elements; Elements and properties; properties and components... crikey

This blog entry is about Clique Space (TM) implementation progress.

It's been a while since my last post. I've been working hard on the implementation; working on replacing the precis and the projection mechanisms with a mechanism I hope will be able to be used by both Agent Devices and View enabled devices like the administrator client. Every time I feel I'm getting a handle on the implementation, I seem to stumble onto a new phenomenon which, upon closer inspection, appears to open up a set of hitherto unanticipated set of implications. I shake my head when this happens repetitively; I hope I am sufficiently sane to carry this proof-of-concept to some type of a demonstrable conclusion within the next year or two.

So, to the deliberation at hand...

The Element - component relationship is recursive, and different components can be represented to an Element as a mandatory scalar (the Element's identifier), an optional scalar (a Connection's Media Profile), or even as members of a set (an Identity's Connections). Properties promise to allow a device to manage its knowledge of Elements. The properties mechanism enables the separation of Elements from the Elements' components. This has one particular advantage: an Element, who's components can be naturally categorised into properties, can be implemented as a set of properties. The properties mechanism hence promises any device a relatively simple and reliable way to manage the device's knowledge of an Element's state and life-cycle.

Travelling along this line of rationale warranting the properties mechanism, I encountered some problems. How does one transmit an Element's components? What if Limiting Constraint affinity prevents partial transmission of a collection of components contained in a property? What type of complex logic would permit a "property changed" message to be transmitted? Can we just get away with a binary "component added" and "component removed" logic?

Additionally, I realised that I could simplify the implementation of the properties mechanism if I were to permit a general relationship between a property and its component(s): whether scalars or sets, properties can have a default collection relationship to an Element's components. This default collection aspect of properties is convenient for the requirement that Elements contain a set of properties, but it also compounds the problem of transmission.

So, an Element is a container of properties. Properties are a mechanism that categorises an Element's components. Properties may have a mandatory or optional singular (scalar) or set (or even, perhaps associative map) relationship with the components they categorise, but, to allow all properties a single way to access their components, all properties extend a base property class which contains an associative map of components. Hence, in this relationship, it appears necessary to acknowledge a pattern underlying the properties mechanism: an Element is a collection of collections of components.

This answer appears to have underscored the need to answer the question of component transmission with perhaps another mechanism. To do this, it appears convenient (if not absolutely necessary... but I think it is this too) that components, whether existing in a property as a scalar or as a member of a collection, are transmitted from one device to another, as singular pieces of atomic information, or to perhaps without warrant, steal a term from physics: quanta. The answer regarding the question of binary logic appears to be that we can get all we need simply by implementing add and remove logic; no change logic is necessary.

So, the solution to the question of property transmission...

A transmitter is an algorithmic vehicle which contains a quantum. A quantum may be a property's component if the component is a data type capable of serialisation, or it may be a serialisable copy of the component if the component cannot itself be serialised. One, and only one quantum is transmitted in a transmitter; a quantum represents the minimum amount of information representing a particular component.

So, why the transmitter? Can't a device just transmit and receive quanta? The answer is that the transmitter appears to use something akin to the visitor OO design pattern so that a device can understand why the quantum was transmitted. The transmitter mechanism is an abstract class of which there are two concrete extensions: one to deal with component addition and the other to deal with component removal.

When the agent device receives the relevant transmitter extension, it calls a method declared in the base transmitter and implemented in the relevant extension which in turn calls the add or remove component method on the quantum, doing whatever is intuitive to create or remove the corresponding component on the Agent Device which has received the transmitter. Hence, the receiving device uses the power of polymorphism given to a quantum's implementation to determine how this quantum affects the state of the corresponding component on the Agent Device.

This solution appears to be the simplest available. Exceptions can be generated for any transmitters that attempt to add a component which the receiving device currently knows of, or to remove a component which the receiving device doesn't know of, which appears to be almost all the questions of transmission answered. There lurk nearby, other phenomena which I have admired from afar; these phenomena appear to suggest other puzzles, but I'm hoping these puzzles are easier to solve.

Sensory -> Motor :: client collaboration's Clique -> Agent Collaboration's Clique

Don't get too hopeful, but this mechanism may be the final necessary functional addition to the implementation. Once implemented, the concept might be proven.

In this entry, I briefly covered what appears to be a phenomenon which emerged as a side-effect of the progress to a functional implementation: one appears to require two Cliques in order to properly model and control collaborative activity in Clique Space(TM). Again, this mechanism arises due to the necessity of Clique Space being able to construct an environment in which a self can be extended into cyberspace; an act which must necessarily be self-referential. This mechanism might appear to be analogous to sensory and motor homunculi - a feature of complex nervous systems such as our own.

The mechanism appears to operate in the following generic way.

Clique Space siphons the state of connected devices and measures this raw device state against Limiting Constraint characteristics of the corresponding Clique's Participants; this Clique is the client collaboration Clique which models the external collaboration. This Clique, its Participants, the Participants' Limiting Constraints, and other Participants' components and can be viewed or persisted as Limiting Constraint affinity permits by any individual, possessing sufficient constraint affinity, regardless of whether they are participating in the external collaboration or not. Hence, this Clique might be seen as a type of sensory homunculus because it gives an individual who can view the collaboration as a Clique, a sense of what is going on in the collaboration the Clique is modelling.

The Agent Collaboration's Clique might be likened to a motor homunculus. This Clique permits Participants' modelled state changes to be distributed throughout the Agent Devices which are siphoning the state of the devices participating in the external collaboration.  In addition to the participating devices, Agent Devices which siphon and serve devices which can view, or persist, or even control device activity are also Participants if any connected devices with these capabilities, having sufficient Limiting Constraint affinity, intend to view, persist or control activity of the client collaboration's Clique.

There appears to be one specific exception.

The Agent Collaboration's Clique is a model of itself. This model is completely trivial and unsustainable without a client collaboration's Clique; modelling one Agent Collaboration's Clique with another promotes infinite regress. Viewing or persisting the activity in an Agent Collaboration's Clique might be thought of as acts of philosophical introspection. Perhaps attempting to control the Agent Collaboration's Clique might be seen as a kind of evil, and may be prohibited in a Clique Space administered by individuals who may find attempts to directly control an Agent Collaboration's Clique ethically questionable. Taking control of an Agent Collaboration's Clique would be like someone taking control of your own limbs through stimulating various areas of the motor homunculus of your own nervous system; you may find your body behaving in strange ways, and you might be further confused as to the intentions you had when performing these actions.

The reader is not seeing things. The term "client collaboration" is not capitalised whereas the term "Agent Collaboration" is.This is because the client collaboration, although mentioned in the patent, was considered by me as more of a context (a client collaboration as the collaboration going on in the device manufacturer's media and being modelled as a Clique by virtue of the fact that each of the member devices' state, connected to Clique Space through zero or more Agent Devices, is, provided the external device is connected to at least one Agent Device, being siphoned off by these Agent Devices and replicated in the Clique) than as anything structurally relevant to Clique Space.

This perspective can be contrasted with the Agent Collaboration, which was, at the time the patent was published, thought to have structural relevance even if the Agent Collaboration is perhaps more refined now (an Agent Collaboration is any set of Agent Devices involved in both siphoning state from the devices involved in the client collaboration and serving the view/persistence/control devices interested in this same client collaboration) than it was when the patent was published (an Agent Collaboration being merely the model of the set of Agent Devices participating in a particular Clique Space - what can now be considered a client collaboration in the mechanism disclosed in this entry). Maybe in the future I'll decide to capitalise the term Client Collaboration... maybe that time will be as soon as I implement the mechanism I have disclosed here.

Things coming together.

It looks as if the Clique Space(TM) Agent Device(TM) and administrator clients are coming together in some fundamental ways.

The delegate interface is casting away its intermediate forms, and simplifying itself so that an administrator can do the four Clique Space things upon which everything else sits: 1. forming, 2. disbanding, 3. joining and 4. leaving Cliques. Beyond these four functions, Clique Space is only limited to the functionality of the media which are exposed to it.

BasicElement: Code listing.

I wanted to provide a listing of the BasicElement module in my last entry. I decided I'd turn my last entry into a bit of a prattle when I found that I couldn't get the HTML to display properly. I'm putting this entry together because I think I've worked it out.

If one looks closely at the way the BasicElement interface is declared, one should be able to understand the basic tenet of the Clique Space concept: modelling the activity of the individual. In a way, I think that the term "model" does not explain this Clique Space(TM) thing enough. Also, I think that because of the the notion that every device - even the Agent Device - is subject to being represented in the Clique Space environment, this listing might also demonstrate that the verb "to model" and the verb "to control" are the same thing in Clique Space.

Modelling an activity is intuitively distinguished from controlling an activity; modelling means observing or perhaps merely simulating an activity whereas controlling an activity implies intervening in an activity going on in the real world, while that activity is transpiring. It is important to note that the Agent Device is a device like any other device to Clique Space for the same reasons that modelling and controlling Clique Space activity correspond.

Something that hosts a running instance which implements this interface is known to the BasicElement as the 'Device'. This Device has a CliqueSpaceContainer which contains all the Clique Spaces and Elements that the device knows of. The BasicElement is a collection of 'Properties'; these properties describe everything the Element is. Limiting Constraints are a type of property which, while potentially contained in all Elements, are expressed only in Participants. There is a really elegant relationship between a BasicElement's properties and a BasicParticipant's Limiting Constraints, but a description of this relationship might best perhaps be left to another entry.

Anyway, being that this prattle might just be seen by the reader as a bit of a distraction, here is the source code listing. I hope the reader respects the little bit of inoffensive asserting that I have included. I'm hoping my blog entries might inspire my readers to get in contact with me. What can you lose?

 1 /*
 2  * (C) Copyright Owen Thomas. All rights reserved.
 3  *  Express written permission must be obtained from Owen Thomas in order
 4  *  to reproduce all or part of this source or compiled code in a manner 
 5  *  specified in said permission.
 6  */
 7 
 8 package cliquespace.core.cliquespace.basic;

...some imports that needn't be disclosed...

40 /**
41  * @author Owen Thomas
45  */
46 public interface BasicElement<
47  D extends Device,
48  CS extends BasicCliqueSpace<D,CS,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC>,
49  ID extends Identifier,
50  E extends BasicElement<D,CS,?extends Identifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>,
51  A extends BasicAxle<D,CS,?extends AxleIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>,
52  AP extends BasicAccountProfile<D,CS,?extends AccountProfileIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>,
53  APR extends BasicAccountProfileRoot<D,CS,?extends AccountProfileRootIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>,
54  APN extends BasicAccountProfileNode<D,CS,?extends AccountProfileNodeIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>,
55  MP extends BasicMediaProfile<D,CS,?extends MediaProfileIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>,
56  MPR extends BasicMediaProfileRoot<D,CS,?extends MediaProfileRootIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>,
57  MPN extends BasicMediaProfileNode<D,CS,?extends MediaProfileNodeIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>,
58  AF extends BasicAffiliation<D,CS,?extends AffiliationIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>,
59  C extends BasicConnection<D,CS,?extends ConnectionIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>,
60  I extends BasicIdentity<D,CS,?extends IdentityIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>,
61  P extends BasicParticipant<D,CS,?extends ParticipantIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>,
62  CL extends BasicClique<D,CS,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC>,
63  CSC extends CliqueSpaceContainer<D,CS,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC>,
64  PR extends Property>
65 extends Element<CS,ID>{

The interface's body has been removed because the contents are trivial and don't help illustrate the point I am trying to make in this entry.

85 }
 

I do think the interface declaration is quite special. It shouldn't be too hard for the observant reader to realise that through this interface declaration, the declarations of the BasicCliqueSpace, BasicClique, and all the Basic~ Elements can be derived. This is because the very high degree of coupling. All of these parts of the Clique Space concept are interwoven to serve a common design purpose: Clique Space is designed to represent an individual in cyberspace.

The BasicElement interface: an expression of the Clique Space(TM) concept in code.

Clique Space's(TM) implementation has been evolving for some time in Java SE. Many (but probably not most) of the features exhibit stability and robustness. I can cheerfully say that the basic expression of the Clique Space concept has exhibited reasonable stability for probably a year or more.

I've been looking for one code module that would conveniently show many of the conceptual features of Clique Space, and I think that one module in particular does this quite well. This module is the BasicElement interface. Primarily, the BasicElement interface encapsulates an important general phenomenon which Clique Space was conceived to capture: the self-referential nature of the individual - the self, or in Clique Space parlance, the Client Device - the purpose of which is to provide an cyberspatial skin detailing one's total capacity and authority to act within any Clique Space to which one is connected.

Yes, indeed, this is what Clique Space is basically meant to provide; an expression of the individual's own presence in cyberspace. The declaration of the BasicElement interface shows how the phenomenon of the individual is addressed. Being that I assert that nothing like this has ever been previously considered, this is quite a disclosure: a target for prior art if it is found that my patent doesn't adequately cover my concept - c'est la vie.

We all know that the nature of the individual is elusive. We all know we are aware of ourselves, and we all infer this quality "self" in others through empathy; the correspondence between what we feel when we perform some activity, and what we observe of that activity by these others in our environment. Even though, for a long time, members of one species on this planet appear to possess a highly refined sense of empathy, we have thus far had very little success in describing the individual as a universal quality; a quality which most of us believe should be a universal and transcendent... if only we had some framework through which it can be expressed and communicated. Hark! I hear another cue for Clique Space!

I have to make some assertions about what I think an individual is. These assertions include, but perhaps are not limited to, the following characteristics. Summarily, the individual appears to be:

1. capable of asserting themselves: the individual claims possession of things and abilities to act in one's environment
2. capable of accepting others: the individual accepts the claims to possession and abilities to act by others in one's environment
3. a logical absurdity: a conceptual singularity which, like the black hole analogue in gravity, is impervious to investigation, and opaque to ultimate knowledge within one's environment

I, an individual, make assertion 3 as a person who is not a physicist, and without consulting another individual like Stephen Hawking who is a physicist, who may make a different assertion. It is interesting to note that an individual asserts their individuality to others in the hope these others will accept the fact that at least these assertions are being made by an individual. The individual must accept that things in one's environment manifest other individuals, and that these others will understand that something in their environment represents this individual. This paragraph illustrates how obvious point 3 becomes when entertaining the relationships between the first two points. There is more in the work of Kurt Gödel about this absurdity - more than I can understand.

How, then, especially considering point three, are we to design a system that expresses this elusive substance? Although the individual cannot be directly expressed through a computer language (the possibility that a computer system may provide an environment through which an individual might emerge is another topic which I will avoid in this entry), a computer language can provide a way that collections of logical absurdities can assert and accept claims of possession and abilities to act.

To do this, a computer language must surround the event horizon of the logical absurdity. Such a system can give an individual that uses it a cyberspatial skin that other individuals using this system likewise would be capable of recognising. This is Clique Space. In order for Clique Space to do this, one has to recognise that Clique Space must be able to surround the event horizon generated by the absurdity. In my patent, I envisaged that encirclement of the event horizon can be achieved with the Clique, the Clique Space, and the first seven of an unbounded number of Element types: Axle (nee Account), Account Profile, Media Profile, Connection, Affiliation, Identity (nee Active Affiliation) and Participant. Individual assertions are communicated through Enabling and Limiting Constraints contained within these Elements.

The implementation has not been far off the mark.

Extra Element types are created around different media types; I have envisaged after publishing my patent that these extra types would appear by deriving types from the set of Elements collectively known as the Client Device's Media Profile spine - the Media Profile, Connection, and Participant. The Identity was once a member of this set. However, the Identity was abstracted out when I realised that the Identity is a Collection of Connections and Affiliations assigned to a single Axle instance and used to generate a collection of Participants. I believe I will shortly drop the Participant and the Connection from this set because like the Identity, a Participant may contain more than one Connection whenever it is appropriate to express one individual's participation in a Clique as a collection of Connections, and a Connection might represent the association of one Axle through one device to multiple Media Profiles. Hence, the Media Profile might remain the only Element from which extra Element types may be derived.

The Elements and their broad behaviour have been declared on spec in the BasicElement interface, with two relatively minor modifications: the detailed relationships between the Identity and the other Elements, and a delineation between root and node Media and Account Profiles. The BasicElement Java interface is accompanied by eleven other Java interface modules describing subtypes of BasicElement for these seven Element types: BasicAxle, BasicAccountProfile, BasicAccountProfileRoot, BasicAccountProfileNode, BasicMediaProfile, BasicMediaProfileRoot, BasicMediaProfileNode, BasicConnection, BasicAffiliation, BasicIdentity, and BasicParticpant.

These interfaces are accompanied by declarations for a BasicClique so that BasicParticipant Elements have a medium of propagation amongst Agent Devices, and a BasicCliqueSpace, so that all BasicElement types have a pace to reside and the life cycles of all Element instances can be subject to some collectively agreed to degree of administration permitting the activity of individuals to be collectively organised; exactly as society has done for the past five thousand or so years. The BasicElement and all these related declarations are customised on other device types so devices other than Agent Devices may receive projections of these Elements. One instance of a BasicMediaProfile contains one Enabling Constraint which exposes device behaviour as parameters to Clique Space. One Enabling Constraint parameter can be given a value in one BasicParticipant by assigning a Limiting Constraint to the parameter.

Limiting Constraints can be contained in all BasicElements, but are expressed only in the BasicParticipant. The BasicIdentity is used to project an individual's worldly identity to others, and an instance of a class that uses this interface must contain Limiting Constraints which completely cover all, without internally contradicting any, of the BasicConnection instances expressed through the given BasicIdentity instance.

A technical wonder about these Basic~ Java modules is that each parameterises their own declaration and each other's declaration so that implementations (there are two in development at this moment; namely the Agent Device and the administrator client) can customise these Basic~ Elements to behave in accordance to the way a device functions. The BasicElement interface, all its subtypes, the BasicClique, the BasicCliqueSpace, and the Enabling and Limiting Constraints are inseparably woven into each other, providing an impervious container which forms the designed cyberspatial skin around individuals' event horizon, facilitating a virtual link between the absurd singularity of the individual and sensible and logical cyber-environment within which collections of individuals dwell.

How much structural symmetry is there between the Affiliation and the Connection?

This question has been occupying my mind for some time, and it relates to the way some Elements in Clique Space(TM) appear themselves, to exhibit precisely the properties that Clique Space was conceived to model. How far can I go with this? Can a Clique Space Agent Device use its data model to model relationships between its own Clique Space component object instances as they are created and deleted?

This question is a rather silly reductio ad absurdum. However, it might be interesting to note that discussions throughout this blog have touched on something I call the serving Agent Device's Clique.

Let's have another look at the serving Agent Device's Clique. I am in the process of removing the "three stage delegate" device Connection mechanism from the implementation, and working toward a new relationship between two of the implementation's components: both the Connection to the other device and the serving Agent Device's Clique modelling the collaborative exchange between an Agent Device and the other device must exist simultaneously. Delegate capacity (a capacity for the Element to contain and project an Agent Device's delegate server RMI stub to the other device through which commands will be sent back to the Agent Device from the other device) is removed from the Identity because a singular Identity will now be correctly implemented to represent collections of Connections and Affiliations around a single Axle. The delegate capacity will be shared between the Connection and the Participant: the Connection contains the RMI stub, but any message sent from the other device identifies the serving Agent Device's owner Participant created from this other device's Connection when instructing the Agent Device to perform some action in relation to a change in the other device's state.

So anyway, what am I getting at here? Well, put the delegates and all the mechanical minutiae for the serving Agent Device's Clique aside (I feel I had to explain it in part just to get it off my chest), and concentrate merely on what the Agent Device's Clique represents: a collaborative exchange between two users; the operator of the serving Agent Device, and the operator of the device which is connected to a particular Clique Space through this Agent Device, if these are indeed different individuals. While it should be obvious to the reader that the serving Agent Device's Clique models the collaboration between an Agent Device and another device (because I have just stated this), the same reader might also be ask themselves whether, because of the dependency between the serving Agent Device's Clique and the other device's Connection, this Clique appears also to represent the instance of the Connection to the given device.

I think such an observation is very interesting, as it appears to promise a similar symmetry in the relationship that manifests an Affiliation. More thought is definitely required before I start to head off in a specific direction here,but one question is this: who is collaborating with whom? Clearly, in the serving Agent Device's Clique, the two Participants are representing the operator or operators of the devices which are collaborating. However, consider this: where the Connection represents an association between an Identity (more accurately, the Identity's Axle through a given Identity) with a Media Profile, then who, if this association might also be seen as a collaboration, represents the component Media Profile? Likewise, if we are going to do something similar with the Affiliation, then who represents the Account Profile?

When we entertain this "structural symmetry", might we in actuality require two more new Cliques (rather than one because the symmetry in the Affiliation bares no functional relationship to the serving Agent Device's Clique) to model the structural symmetry: 1. one Clique to model the specific relationship between the Connection's Axle and Media Profile and 2. another Clique to model the specific relationship between the Affiliation's Axle and Account Profile? Would these Cliques have any natural value? I think they may...

Hmmm...

My Proprietary Interest in the Clique Space(TM) Technology.

One can follow this blog from when I started it in July 2009, and clearly observe that I have asserted over and over again, my claim that the Clique Space concept is mine, and that specifically, the term "Clique Space" is a descriptive trademark I am claiming proprietorship of. I have claimed trademark ownership of "Clique Space" at least since I registered the PCT: one will find the name and the TM citation in the document as it was submitted to WIPO. One can observe over the interval, that this blog has been making numerous and repetitive invitations to elicit interest for specific others' support; support which has often (as in the case of Wollongong University) been explicitly turned down.

One can follow this blog from when I started it in July 2009, and clearly observe the open invitation for enquiry by anyone who reads this blog. Hence, although I assert that Clique Space, its concept, and its developed technology is, in its current entirety, an effort wholly undertaken by me, Owen Paul Thomas, a resident of Wollongong, NSW, Australia, I have been trying for at least this same amount of time to garner help from any party anywhere in this world in my proprietary interest; an interest which I believe will pay a great general dividend to those people that respond.

I proclaim that my Clique Space concept will, in time, demonstrate itself to be indispensable in general social interaction. A complex, organised and truly global society, enjoying the fruit that Clique Space yields both in terms of the expression of society and the individuals it is composed of, will identify the degree to which Clique Space demonstrates its efficacy. I believe that the ubiquitous usage of Clique Space will, in times hence, prove that my conception of this Clique Space thing was defining epoch in the evolution of this thing we generally know as society...

These claims may sound grandiose, nay on delusional, but I have been working patiently, steadily, and solitarily on this thing for some time, and if I have delusional tendencies, my psychiatrist - a specialist whom I have known for about as long as this blog has existed - would have prescribed me medication and told me that taking it as directed is perhaps a good idea. He hasn't; he has specifically said that he doesn't think medication is required in my situation.

So, taking my cue from my psychiatrist and generally observing those with whom I share some personal relationship, I assess that I am not in need of intervention; that I am indeed sane and humble enough to create a solution, as robust as it might be elegant, that encapsulates a concept for which I also claim a patent - registered after 3.5 years deliberation in January 2008. I have been working on the implementation of this solution for more than four years since leaving my last employment due to the fact that irreconcilable differences experienced between myself and six employers previously presented themselves as similarly unnavigable in July 2008.

Although my efforts to present my idea have been ignored continually since I conceived the idea in mid-2004, I have persisted with it. I registered a provisional patent in January 2008, and started implementing it in Java SE in July 2008. I use NetBeans as my IDE, SVN for code versioning (provenance) management, on Ubuntu. I thank the fact that these products are completely free because I would not otherwise be able to implement this concept as "effortlessly" as these products allow. However, even with this effortlessness, I didn't think it would take as long as it has so far taken to get to where I am currently. Although the concept itself is very simple, the lack of foreknowledge of the detail of the implementation, and the lack of help and possibly even understanding from others of the help they might have been able to offer, I have persevered alone; I can thus far make my claim to this technology, in its entirety, as exclusively my own.

Hence, this entry is a reiteration of an appeal to interested others to offer their help. The idea is proprietary, and, I am hoping, a product which can be sold. There are certainly legal obstacles to be overcome provided others are willing to play the legal game fairly and offer their help openly. Doing so would also protect their interest should a party, in offering their help, become a stake-holder in this proprietary interest.

Here, I will assert further trademarks. Namely the following:

• The Clique Space Axle or the term "Axle" as it would appear in relationship to the discussion of Clique Space or any related concept.
• The Clique Space Agent Device or the term "Agent Device" as it would appear in relationship to the discussion of Clique Space or any related concept.
• The Clique Space Client Device or "Client Device" as it would appear in relationship to the discussion of Clique Space or any related concept.
• The Clique Space Clique or "Clique" as it would appear in relationship to the discussion of Clique Space or any related concept.
• The Clique Space Account Profile or "Account Profile" as it would appear in relationship to the discussion of Clique Space or any related concept.
• The Clique Space Media Profile or "Media Profile" as it would appear in relationship to the discussion of Clique Space or any related concept. 
• The Clique Space Enabling Constraint or "Enabling Constraint" and the Clique Space Limiting Constraint or "Limiting Constraint" as they would appear in relationship to the discussion of Clique Space or any related concept.

I will assert a similar proprietary interest over the terms Connection, Affiliation, Identity, and Constraint though perhaps I doubt more the ability for this interest to be asserted with clarity because of the general use of these terms.

Primarily, I state this condition of use around all trademarks I have so asserted: I will bare no claim to the terms' usage elsewhere, except where it is evident that the usage of these terms appears to garner interest or revenue in a competing idea - if such an idea that doesn't infringe on my patent could be conceived. I would be respectful, and definitely honoured, if one used these terms in reference to one's own initiatives that would draw on my Clique Space concept as something that these technology vendors have specific intent to use. However, I would certainly anticipate that others who had formed such an intent would definitely have formalised their own business relationship with Clique Space and its technology before they made such statements.

I'm trying hard to be a fair, a good, and a proper man. I hope my efforts in making an open attempt to offer what I have to other people are recognised as being efforts that might come from such a man. I'm really hoping the reader has (you have) a similar intent. Get in contact with me directly (my email is available from clicking my name below the "About Me" details of this blog) if your intents are as sincere as mine.

My patent has evolved through a PCT and is currently in the process of examination in AU, NZ, and US jurisdictions. My code base is currently completely proprietary and closed source however I believe that in the future I would like to see the code released on some general purpose license.

I envisage that the prime business value of any organisation formed around the use of the technology to be a publicly accessible Clique Space - the "Public" Clique Space - that would offer usage to individuals operating as "themselves" free of charge. The Public Clique Space would receive revenue from a type of usage that required another organisation to "federate" its own Clique Space with the Public Clique Space. To this end, I envisage that the Public Clique Space Organisation would be an internationally recognised trading name of the entity set up to execute the administration of the Public Clique Space domain. In terms of Clique Space federations, Clique Space is a highly configurable environment which would allow a degree of fine-grained control unparalleled in any other available technology. Pricing schemes can be set up and levied against this configuration versatility to organisations willing to participate in a federation at whatever level will serve these other organisations' varied needs.

I would not run the Public Clique Space Organisation (I haven't got the required competencies), but I like to think that I'll retain an equity stake in it.

State versus content: Clique Space(TM) as something which might be useful.

Cliques model collaborations. What does this mean?

First, a refresher on the general principle of Clique Space; one that perhaps does not pay respect to the subjects of federation or anonymous or unidentified (un-Identitied) Participants as they apply to Clique Space for the sake of simplicity, but never mind...

A collaboration is some cooperative activity going on between individuals. Each individual has some capacity to act, and uses a particular device capable of participating in this collaboration. The collaboration is going on within one or more particular media, and, when the collaboration is being modelled as a Clique, this collaboration can be observed by others, according to the degree to which these others have constraint affinity with the Clique and each of its member Participants.

Agent Devices are only special in that they are running instances of the Clique Space Agent Device code. Beyond this fact, there's nothing special about Agent Devices. Simply put, Agent Devices form Agent Collaborations, and Clique Spaces can exist in Agent Collaborations. An Agent Collaboration is modelled as a Clique within the Clique Space that exists as a result of an Agent Collaboration. Each Agent Device is controlled by an individual like any other device, and each Agent Device exposes functionality through the same control mechanism as any other device.

Clique Space users (individuals) connect other devices through Agent Devices which are members of a Clique Space to which they want to connect. All the devices one has connected to a Clique Space (including Agent Devices) generate activity in their own device specific way. Changes in device state are siphoned and modelled as activity in a Clique Space. Each connected device lets Clique Space know which other devices it is exchanging information with so the Clique Space can model this collaboration as a Clique. The exchange going on between the external device and the Agent Device to which it is connected is a collaboration like any other: it is modelled as a Clique - called the serving Agent Device's Clique.

For any given Clique, each Agent Device that is managing the direct link to an external device participating in the collaboration that the Clique is a model of, or any Agent Device managing a direct link to a View and/or control mechanism enabled device observing this Clique, becomes a member of an an Agent Collaboration which is modelled as a Clique of its own. The Agent Devices of this collaboration Clique coordinate, cross-reference and model the incoming external device state and interpret and disseminate outgoing device commands so that any user, not necessarily just the participants of the collaboration (Participants of the Clique that models this collaboration), can, if they have sufficient affinity, observe, and interact with the collaboration if a potential observer chose to observe a collaboration through Clique Space.

A given observer might later want to participate in the above collaboration. This given user might have connected a device which permits their participation in the specific collaboration's media as well as expressing to a Clique Space through an Identity, sufficient constraint (Limiting Constraint) affinity to participate in the Clique they are observing. In this case, they may either join this Clique with their given device, or, if possible, activate the given device remotely by sending commands through the Clique Space Agent Collaboration aether. The individual user would probably send these commands using the same Clique Space View enabled device through which they might be observing this Clique.

Necessarily, if the given user wishes to activate one device in a Clique Space mediated collaboration through another device, then this other device must 1. possess a View and/or control mechanism enabled device, and this capability must 2. be exposed through the device's Clique Space Connection, and 3. be expressed (projected) through an Identity which 4. furnishes the individual with this capacity to activate one device through another View and/or control mechanism enabled device.

While one individual may restrict remote device control only to devices expressed through Identities revolving around that individual's Axle (Account), such an individual may cede some remote control authority to other individuals in accordance with the constraint affinity these other individuals may possess with an Identity through which this device is expressed. Other individuals may only remotely control a device possessed by this individual only if, and to the extent that, this individual has permitted this activity to take place.

Now, to my point.

It's fairly straightforward: Clique Space's intended purpose is not to model or control a collaboration beyond those characteristics which determine whether a Participant can exist, or remain in existence in a Clique specific to this collaboration's media, and to the extent that the underlying Identity has sufficient Limiting Constraint affinity with the Clique, or is willing to make compromises (allow a Participant to acquire Limiting Constraints contrary to those of the underlying Identity) to achieve this affinity.

A Clique is not much more than a record of a collaboration; complicated exchange goes on in the specific collaboration's media as it would do regardless of whether any given device was connected to a Clique Space or not. Clique Space's ability to model, and perhaps to control a collaboration leaves the content of the collaborative exchange to the concern of the devices.

Mechanics that compose the various Clique Space collaboration media (the Agent Device as a Clique Space collaborator with a group of Agent Devices modelling a specific Agent Collaboration, or the Agent Device as an engager in a synapse with another Agent Device, or an Agent Device as a member of a Clique Space, or more generally, the Agent Device as a serving Agent Device interlocutor on a specific Clique Space with an another device in accordance to a medium specific to this exchange) are all modelled and controlled in the same abstract way: as a Clique composed of two or more Participants. The mechanics of these collaborations involving Agent Devices have a depth that Clique Space's abstract collaboration model does not penetrate because the relevant Media Profiles do not (cannot) expose all the functionality of the mechanics of these media through Connections generated from these Media Profiles; attempting to do so would introduce infinite regress.

Media Profile manufacturers may choose to represent some proportion of the collaboration's content exchange in Clique Space because doing so might be convenient. This might provide Clique Space users with the opportunity to model, and particularly, to get a Clique Space to automate the control of events on behalf of the devices' operators in accordance to the wishes of these users.

Hence, the value of Clique Space is in its ability to aggregate, model, and control devices in relation to the individual users which use Clique Space to assert their possession of them. Clique Space doesn't exist to provide users with an additional opportunity to participate in the totality of the content of a collaboration's exchange; external devices ordinarily (whether connected to a Clique Space or not) manifest external collaborations where the content exchange takes place in some medium specifically defined by the manufacturer of these devices, and which remains external and largely opaque to Clique Space.