Tuesday, December 9, 2014

CL,I,P,O,N

A nightmare of confusion.

Recent time with Clique Space(TM) has dragged me into the dependency nightmare that is Java generics; a nightmare from which I might be awakening.

Clique Space code comes in two halves. The chassis is the basic Clique Space data structure definitions and implementation of functionality in relation to the sending and receiving of transmitters while the top half is the body of the specific implementation of a Clique Space aware device.

The halves are separated by a set of parameterised types that make the cute acronym disclosed in the title of this blog entry. The specific device implementation's body "clips on" to the generic chassis. Hence, the chassis defines these generic parameters, and the body completes their implementation. The terms used in the acronym are as follows:
  • CL - The basic Clique structure and mechanisms contained therein.
  • I - The Identity structure and mechanisms contained therein.
  • P - The basic Participant structure and mechanisms contained therein.
  • O - A more specific Participant structure relating to Owner Participants of subscriber Cliques and involvements.
  • N - A more specific Participant structure relating to non-Owner Participants of subscriber Cliques and involvements.
The acronym using the first three of these parameterisations has been around for a while. The final two types needed to be added to or "clipped on" the end of the fist four because I wanted a way to discriminate between the Owner and non-Owner Participants of a synapse, a service, or a viscera. One of the prime benefits of using generics is that one can check types at compile time, thereby reducing the size of one's code (not having to guard run time type casting) and ensuring one's code has fewer bugs.

Hence, these extra two types (O and N) are used to ensure that an Owner Participant is returned where an Owner Particpant is expected and a non-Owner Participant is likewise returned when expected. This type of discrimination is important in cases where structures derived from the basic Clique (the synapse, the service, and the viscera... possibly others as yet uncontemplated) are being manipulated. These specific Clique structures have extra functionality because this extra functionality helps a Clique space do the things I intend it to do.

A thing of beauty.

Wednesday, December 3, 2014

The Viscera and the Service

I explained the function of the viscera here, so I will dispense another explanation in this entry and explain what the service is. I'll then contrast the two.

The service, like the viscera, is a Clique. Unlike the viscera, it is strictly a bipartite Clique; the owner is always an Agent Device, and the other member is an external device (which could be a View device like an administrator client which is able to view or persist Clique Space activity). External devices cannot participate in viscera because they are not Agent Devices. Agent Devices are the only type of Clique Space aware device that manifest the functionality necessary to participate in viscera; Agent Devices are the neurons of a Clique Space.

Although services are not synapses (synapses are another type of bipartite Clique) they are used where synapses connect an Agent Device with a View device. A set of synapses do not connect an Agent Device to any other type of external device other than a View device. Hence, external devices that lack a View capability are known simply as drones.

A service implements a connection between an Agent Device and some type of external device, whether that device be a View device or a drone. All external devices siphon their state into a Clique Space and accept commands from a Clique Space through one or more Agent Devices through which each device shares a service.

The basic service represents the aggregate mechanism of exchange between an Agent Device and an external device that exists beyond the synapse mechanism that Clique Space aware devices use to share information. The service may define an interface known as a service delegate which defines how external device information is exchanged between the external device and its connected Agent Device. Services are strictly bipartite because they represent the mechanism of exchange between one external device instance and the Agent Device instance that serves it.

An Agent Device can stop serving a drone by simply disbanding the associated service, while more specifically for a View device, the connected Agent Device must also disband the associated inbound and outbound synapses.

A service is not a viscera. To lightly go over that which has already been explained, a viscera is a Clique that represents all the Agent Devices that contribute to the manifestation of a Clique Space. A viscera is multipartite, and can theoretically contain an unlimited number of participants.

However, a service is a viscera in a subtle but crucial way. Just as every Agent Device obtains a non owner visceral participant to be a member of a viscera, an external device must obtain a non owner service Participant to be counted as a member of a service. This symmetry is very handy because it allows many of the mechanisms of Agent Device - Agent Device engagement to be used in Agent Device - View device engagement. The convenience of this symmetry also appears to confirm that I remain onto a real possibility with this Clique Space thing.

Friday, November 14, 2014

Viscera

Clique Space (TM). I am still doing it! It is evolving... not changing from my intentions, but growing in its ability to express my intentions.

Agent Devices and administrator clients can now engage and disengage. There are no less than three Cliques that are formed when an Agent Device engages an administrator client: two synapses and a service Clique. The two synapses are needed to represent and model the transmission channels from one device to the other and vice versa. The service represents the client/server relationship shared between the administrator client and the Agent Device.

The beautiful thing about the three Clique structure appears to be that two Agent Devices are going to use a similar three Clique engagement strategy as the Agent Device - administrator client uses, but in subtle but quite elegant way which is particularly suited to the purpose of the Agent Device - Agent Device engagement semantics. The synapses exist for the same reason: to transmit state between Agent Devices, but the service Clique is called something quite different because it has an altogether profoundly different function.

When an Agent Device is started with a new Sovereign Identity, it creates a Clique called a "viscera". I like the term; it actually encompasses the very core of the Clique Space concept: the self. Every sovereign Clique Space needs a viscera to function. The viscera discloses to every Agent Device which has joined it all members of the viscera. It allows the Sovereign to function by virtue of the fact that all member Agent Devices comprising the Sovereign are disclosed to all others through the viscera.

When two Agent Devices, being of the same Sovereign, engage one another, and the initiator engages a respondent otherwise not engaged by any other Agent Device, then both the initiator and respondent know that the respondent is joining the viscera, and the respondent (I think... this hasn't been done yet) will create and transmit the identity of a new viscera Participant back to the initiator. The initiator will advise all its co-engaged neighbours of the new member, and all these Agent Devices will do the same to their neighbours, thereby creating a wave front which will make its way through all the Agent Devices associated with the viscera.

The viscera would be comprised of very many Agent Devices (millions to billions and beyond) and would constitute the physical manifestation of an individual presence that would emerge from such a system. The term was chosen because it appears obvious to me that disbanding the viscera should be known as evisceration.

Tuesday, August 19, 2014

Quale

Here's something that has been developing for some time.

A Clique Space models the world in which it is manifest. That was always the intention, only now, I think I'm observing the mechanisms in a near final form. The Quale class was mentioned earlier in reference to the Escher interface, but recently, I managed to merge functionality from the CommunicableQuale class into Quale class so that I could remove the CommunicableQuale class.

Anyway, I wrote some comments about what qualia are to Clique Space inside the Java source module, and have decided to create a blog that quotes them. Here they are:

  • The terms "Quale" and "Qualia" appear as contentious terms in studies on the philosophy of mind. However, in Clique Space, they are used as a label for a defined structure. Because of the term's contentious history, its use here may be appropriate to some and may not be to others; I don't really care because it is ultimately just a label for a mechanism implemented in a computer language.

    An instance of a quale in Clique Space represents a particular state that one or more devices connected to the Clique Space may be expressing at a point in time. Qualia are converted into signals and transmitted between Clique Space aware (CSA) devices as context when each of these CSA devices enter and leave subscriptions. A subscription represents the association of a particular quale to a particular instance of a principle. Each principle instance is uniquely associated with a particular instance of an Element. Instances of Elements are also qualia.

    This Quale interface has similarities to the terms usage in philosophy. Because qualia exist independently of their subscriptions, one quale can appear in multiple subscriptions in circumstances where this modelling is appropriate.

    A Clique Space quale defines a state for conveying the very abstract notion of "what it is like" to have knowledge about some sensory state. For instance, a quale with a description "Colour [Red]" may be the subject in a subscription signifying that a camera pixel sensitive to red light is active, and this same quale also could also be used in another subscription to mean that some cognitive process within a (Clique Space) mind could be imagining something coloured red. Being that the quale instance lacks a context (the task of assigning context is delegated to subscriptions, and the Context class is a proxy object which is used to convey this context from one CSA device to a neighbouring CSA device), qualia represent abstract qualities which can be shared amongst phenomena to represent common phenomenological properties.
I thought about quoting some code, but at the moment, I couldn't be bothered fiddling with mark up. Maybe I will later. I hope this is interesting to someone...

Friday, May 16, 2014

The Droste Effect

Some of the drawings by M.C. Escher (notably this one) are known as Droste Effects. I have cited Escher's "Prentententoonstelling" because Escher expressly highlights the impossibility of his drawing: it's where he puts his signature.

Clique Space creates an environment which models that which is motivated to model. As such, it appears (at least to me) that Clique Space does in Java SE what Escher does in his lithographs. However, I think that my construction of this phenomenon is a necessary component to the concept, even though I did not realise this necessity was evident when I first conceived the core components that make up the Clique Space data model back in 2004.

I'll throw caution to the wind and talk about some Clique Space mechanics in this entry, because I think the phenomenon I am disclosing here is a priceless example of the power of Clique Space. In any rate, I'll be light on specifics so I might merely pique the reader's interest to the extent that they might want to get in contact with me. All contact is welcome, especially from those of us who have a lot of money.

The core data model of Clique Space includes the definition of seven Elements: the Sovereign, the Media and Mode Profiles, the Connection, the Affiliation, the Identity, and the Participant. All of these Elements are also qualia, and each Element except the Sovereign is a communicable quale.

Each Element instance is uniquely and universally identifiable: to keep to this intent, each Element class is paired with its own identifier class. Hence, all Element classes extend the "Element" class, and all identifier classes extend the "Identifier" class. Every class except the Sovereign implements the "CommunicableQuale" interface, and this interface includes an "asSignal" method which generates a specific signal (a copy of the associated identifier's value) when a given device wishes to transmit the fact that something has happened to the given communicable Element.

Creation of the identifier is delegated to the Element class's constructor. This is all good; the Element's constructor can use Java generics in some wonderful ways to call back to the subclass implementation, creating the type of identifier required. However, to do this, one observes the ejection of a nugget of impossibility inherent also in the drawings of Escher. This nugget is the self-referential nature of how the implementation of those communicable Elements effects the extension of the Element class to implement the Sovereign.

To keep a long story short (and the implementation specifics safely distant), all Elements (including the Sovereign) must extend the "Element" class. All Elements (except the Sovereign) are communicable Elements, and yet even the Sovereign, though it does not use the same call-back mechanism to create its identifier, must provide something (let's call it a mechanism that caps the naked contradiction) to insert as the thing that implements the communicable side of a communicable Element's nature.

The solution to this gordian knot is to use Java generics to create the most elegant logical relationships: all Elements except the Sovereign indicate themselves as their communicable quale. The Sovereign, possessing no ability to be communicated, specifies a dummy (unimplemented because it is never called) interface that covers the naked contradiction. I have likened this particular interface to be like the presence of Mr Escher's signature in his "Prentententoonstelling" image, and have thus called this interface the "Escher".

Et voila:
public interface Escher<
 CL extends Clique<CL,I,P>,
 I extends Identity<CL,I,P>,
 P extends Participant<CL,I,P>>
extends CommunicableQuale<CL,I,P,Escher<CL,I,P>>{/*Declare nothing.*/}


Hence, I believe that at the moment, the "Escher" interface is an effective mechanism that pays a dry reference to the universality of the phenomenon that I am attempting to address.

Monday, February 10, 2014

Clique Space(TM). "Medium. Mode. Model. Mind."(TM).

A nice catchphrase encompassing a core notion within the Clique Space concept.

The notion is that Cliques contain a medium and a mode. The medium describes what each Participant is physically capable of doing while the mode describes what the Participants are actually doing within what they're capable of doing. Clearly therefore, the mode is a collection of values which are set against a set of parameters which comprise the medium.

Just how this mechanism ultimately realises Clique Space has been the subject of the POC development. It is ongoing, however much of the mechanism has been worked through. This currently remains confidential because I intend to submit a patent for the mechanism. To summarise, Clique's are models of collaborative exchanges going on between people through a certain physical medium. Each of a Clique's Participants exhibit a certain mode, and this mode which is governed by the mode of one of the Clique's Participants known as the Owner. The devices which are actually doing the collaborating siphon their state into Agent Devices which martial, cross reference, and represent this external device state information as Cliques. The Agent Devices may send control information to the external devices depending on changes in intent of each Participant's underlying Identity.

Clique Space is all about representing robust and flexible identity (Identity) in a cyberspatial context. One or more Identities are projected by individuals to others through Clique Spaces: administrative domains which are capable of exchanging information between one another in federations. This federation mechanism is facilitated through Clique activity; Cliques are generally free to move like pseudopodia between Clique Spaces as Participants are created and destroyed because individuals from different Clique Spaces join and leave Cliques.

Hence, Identities convey autonomous individual supervisory presences. Identities produce Participants in Cliques which indicate collaborative engagements. Clique Space looks to me like a neural network, and I believe that the mechanism I have conceived is capable of providing a bridge between neural activity and cognitive function. Furthermore, I believe that Clique Space may well be the centrepiece of what is necessary to manifest an individual in a synthetic medium. Hence, mind.

Hell, I might as well assert that "Medium. Mode. Model. Mind." is a trademark also. So it is.

Monday, December 16, 2013

Response to an Unexpected Email about Clique Space(TM).

Here's a copy of everything but the first two and final paragraphs of an email response I gave to an unexpected email I received this morning:

  • Clique Space is still a concept without a proof, it is currently a Java SE subversion managed code base. I started development in about July 2008, and anticipated (guessed) that two years should be long enough to prove the ideas. So, although I didn't anticipate the proof to take as long as it has, what has kept me going is a steady increase in my confidence when I see solutions evolve around implementation details that underscore the primacy of the underlying data [model].

    I believe that at the moment, I am currently in greatest need of two things: funding for coders and intellectual property protections.

    I have absolutely no money. While that doesn't stop me proving my concept, progress is awfully slow. Alone, I can't offer any payment for the efforts of another person to help on the proof, but I might be able to offer an equity stake so that should the concept actually work, any individual who helped in the development would likewise share in any earnings. If I was offering this equity stake to an individual or a small organisation, I would anticipate this stake to be very small. While I currently own 100% of Clique Space, I would anticipate my direct stake in Clique Space to ultimately be very small if the concept attracts the right attention.

    My stake in the IP, currently at 100%, is also negotiable. I would hope that the implementation might become subject to an OSS licence, and that a self-sustaining community would form to support the subsequent evolution of a proven concept.

    You have probably come to me because you have read my blog, and noticed that while perhaps, I have a great idea, I'm not great at promoting it. I would certainly appreciate help here. As a general rule, I am not one who is given to a jet set life of international hobnobbing; I kind of like my life here in Wollongong.
 It gave me an opportunity to disclose more of my state of progress, so I have quoted it in this entry.