Wednesday, July 28, 2010

Clique Space(TM) progress report

I'm putting my prototype together in Java. I thought I'd quote a comment I put in the code here. I like to put preparatory comments in code wherever I feel the need to clarify to myself what it is that I need to do. I usually do this because I want to get my intentions down, and then leave them for a while to see if I'm sure that I want to do something in the way I describe in my comments.

I like these comments because they appear to be fairly accurate, and they disclose my intentions in a fairly central piece of the concept just prior implementation. However much I like to show how good I think I am at my craft, I think this is about as close to code as I'll get in this blog.

Here it is:

We have to remove the Clique if we find that the Element we are removing references for is the only member of the Clique in this Client Device. As we need the Owner for any Clique in order to get information on that Clique, the Owner will have either been previously removed in an Agent Collaboration's message that caused this method to be called, or this Element being here removed is the Owner. I.e., the Clique will have been disbanded; an Agent Collaboration message sent to the collaborating Agent Devices from (what was previously) the Clique's Owner will advise the same.

The Client Device shouldn't have to check that the Clique has disbanded; it just removes Elements as instructed by the serving Agent Device, removing its Clique if there are no more Elements in it. The Client Device will be able to cross reference the instructions it receives through it's Participant delegate server to its serving Agent Device with activity it receives through its Agent Collaboration member server (Agent Collaboration messages), and this information can be cross referenced to help diagnose a Clique Space's stability.

It appears that the only restriction that must be put on the order of Element removal is that the delegate Element (a Participant) must be the last Element asked to be removed when the Clique between the serving Agent Device and this Client Device disbands. In this case, the Client Device must get the opportunity to remove any Elements that are managed by the delegate Element, because the serving Agent Device will not advise the Client Device to remove these Elements; removal of the delegate Element implies removal of access to the managed elements.


There you go. I'm fairly sure this looks okay, but I'll have to let the comments in my code sit there for a while. Clique Space is a little like an art installation in progress.

Tuesday, July 27, 2010

Profound maxim #1: Understanding the paradox of sentience.

I have just returned from a jog along Wollongong's foreshore. It's a drab day. Sheets of rain falling between speckled intervals of grey on a cycleway devoid of all but the seagulls; a great day to run and meditate.

Maxim: Sentience defines what is sacred, and so is sacred itself. Its container must not leak.

Monday, July 26, 2010

Clique Space(TM) and a knowning self.

As I have made clear in previous posts, Clique Space can model itself. This means that Clique Space closes the circle of capability because if it couldn't "autosimulate", it wouldn't really be an environment capable of modelling anything. It would be like a balloon which had a hole in it; Clique Space would quickly deflate.

What of this capability then? How does the property of autosimulation help Clique Space in other aspects? What could be the end result of a system capable of autosimulation?

A system capable of modelling itself is easily capable of extending this model to model its environment in much the same way as the cortical homunculus models the organism (including each one of us) within which it is maintained. In this way, Clique Space is capable of modelling all the devices that are attached to it in exactly the same way as we model all our bodily functions within our own homunculus.

Functions consequent to this mapping including coordination of numerous muscles in the performance of a particular act would also be rendered possible in a Clique Space through the coordination of devices connected to it. As an extension to this coordination, higher cortical functions such as emotions, thought, and memory can be coordinated internally inside a Clique Space in exactly the same way as each of us feel, think, and lay down memories.

I think the analogy is very real, but I also think it is a portent of much potential danger. If a big brother might exist, a Clique Space system will give it the necessary "little brother" simulator. Indeed, if a Clique Space system might permit a foundation on which a mechanised consciousness might form, the definition of the self in a society might need to be reassessed to include more than just people.

Sunday, July 18, 2010

IP registration and the consequences for Clique Space(TM)

The 30 month deadline has passed without financial backing to secure further national phases. The 31 month deadline looks likely to pass with a similar vein hope of securing a foothold in jurisdictions where I have 31 months. I'm not currently sure what I should say about development progress on Clique Space.

I am still enrolled for study, but only three national phase applications is not a positive outcome, and will tax my motivation to complete my research program. The only comfort I might be able to take from the publication of my idea is the fact that it is prior art. It's no one's idea, and hence, no one will be able to register it. Still, I have three national phases (one being the United States) so should there be any competitor activity, I may yet be able to claim licensing income in these jurisdictions, but even this is not given.

No one has helped me. Wollongong University has extended to me nothing beyond the enrolment. The opportunity for a backer to gain exclusive access to a market has slipped away. Negligence has bestowed a critical wound to a business proposal for a concept that I think will, in time, prove to be an indispensable tool for many types of collaborative activity.

Friday, July 9, 2010

Clique Space(TM) progress report.

I am deliberating the implementation of a major part of the innovative essence of Clique Space: how to determine whether a Clique can form.

This can be systematically worked out by finding the intersection of Media Profiles common to all nominated Active Affiliations, and then determining if the Clique Owner's Limiting Constraints can be applied to each Active Affiliation (including the Owner) without contradiction.

If there are no contradictions, the Clique can form. If there are contradictions, the Clique cannot form, and each contradiction will be made evident. A variation to this could be that the Owner could elect (through a Limiting Constraint) that a Clique may form provided a quorum of Participants is generated, even if some of the Active Affiliations cannot participate.

So, I believe I need something like an abstract method for Active Affiliations that will be implemented in a given Media Profile customisation. It looks like this method will accept 1: a set derived of the intersection of Media Profiles common to all member Active Affiliations (this will become the Clique's medium), and 2: the Clique Owner's Active Affiliation. It looks probable that this method will return a Participant for the Active Affiliation it is called on, or a list of contradictions. The method will return both if the user will permit the variation described above.

I remain confident...