Immersed in a world of morons.

I truly live in a society of idiots. A society says to a child "tell us what's on you mind", then, when a child grows up and finds that there is something in there, finds a society silenced by its own stupidity. No one wants to know what's going on.

I receive a reply by someone after I left an email list that calls itself "Personal Clouds". I left in disgust (I was actually thrown off, but these things coincided closely enough) at the fact that this list appears to be just as moronic as any gathering of morons can be. I sent the letter to ask for some feedback as to whether my revised paper on Clique Space(TM) was going to be published as part of a submission by some of these spotty morons. The letter reads as follows:

• Owen,
  
  
  I'm sorry I didn't respond around the time you sent the paper.
  
  
  I read through it a bit, and felt it would work well as a white paper for SSRN and for the Clique Space website, to explain what you are doing.
  
  
  I didn't see any clear way to integrate what you were discussing into a more general paper on personal clouds, because it is so focused on your company.
  
  
  I hope that helps,

Well, yes it does. It helps me work out that there is no one capable of grasping any idea of any merit. It makes me think that humanity is very inefficient when it actually comes to understanding the contents of any idea; I'm no one special, but still, I get nothing when I try and wave an idea in people's faces for more than five years. The society talks about "innovation" and encouraging its people to be innovative... my story is why people just say "bugger off society you fools."

Funnily enough, my ideas are focussed on my ideas. My ideas appeared to me relevant to this Personal Clouds list because that's what a Sovereign Clique Space is. More to this, Clique Space provides a perfectly good mechanism to federate the Agent Devices in the Sovereign Clique Spaces of two or more individuals to create federated Clique Spaces which facilitate organisations of indeterminate size.

I have been convinced that everyone is screwed in the head.

I replied to this letter with this:

• Thanks for the sincere reply.
  
  Evidently, the Personal Clouds list didn't catch on with my work. Perhaps I'll be remembered when what I believe will be inevitable actually happens, and people start thinking about how the self might be manifest in synthetic environments. Maybe there'll be some interest in what appears on SSRN.

  
  I'm off to sulk. I'm going to sit in my corner and surround myself with my code until I die. It's a much safer place than causing injury to my ego by trying get my point across to a society full of morons. Some of these morons will probably grow wealthy in the exploitation of Clique Space when the rest catch on. Too bad for me. Don't bother me if recognition is posthumous - I won't care. My ideas will be my property or no one's property.
  
  Go away now, and tell everyone not to bother me again.
  

Those who make hay out of an idea like Clique Space will (if I'm not one of them) be fraudulent morons who are bullshitting their way through life in a society of gullible morons.

This society, when one of its number try to present an idea to others, behaves as if one's ideas won't matter. Some in this society promote themselves as being the go-to people when one has ideas that address a certain problem, but even these people can't comprehend. Even when one appeals for help in testing their ideas, this society generally regards the individual with complete contempt. Conclusion: this society is completely full of morons. Morons, morons, everywhere!

You're probably an idiot. Stay away from me.

Role Based Access Control.

Here's a UML class diagram of the general Role Based Access Control mechanism. It is put together according to the one that can be found from a Wiki page on the subject.

Fair enough.

Here's the same diagram of the mechanism adapted with classes from the Clique Space(TM) data model.

The adapted RBAC data model does not use all the classes defined in the Clique Space data model. However, it can clearly be seen by me that those Clique Space classes that do match the function of the RBAC ones do so rather well.

There are obvious omissions (incompletenesses) in RBAC.

Firstly, RBAC has only one hierarchy. RBAC does not distinguish between 1. the functional compatibility of various different devices and 2. the responsibility assigned to different individual roles. RBAC has the equivalent of point 2 only; the Affiliation does the same thing as the User/Role Constraint association of the RBAC model.

Secondly, I can't work out what the Role Activation Constraint class is meant to be. There is no equivalent to this beast in the Clique Space data model.

Thirdly, it seems that the Session class in RBAC represents some application or login session with a server-based system. Hence, the best fit for this class in the Clique Space data model appears to be the Connection Element, even if the relationship of the Agent Device to the device represented by a Connection is not quite identical. The Connection is an association between a Sovereign and a Media Profile in the same way that the Affiliation associates a Sovereign and a Mode Profile. Hence, a Connection has a single Sovereign, and so the Sovereign end of the association between it and the Connection has had its multiplicity changed to 1.

Finally, the RBAC model has no formal method of recording consent. Consent should be seen as the most important component of a system that models the interaction of individuals. Consent happens when the interacting is taking place; it cannot be given before or after. Clique Space models consent in the structure of the Clique and its Participants. An unspecified log-file mechanism laid over an RBAC database is the best that RBAC can do.

It almost appears that the person or people who designed RBAC gave up hope that their model could represent the flexibility of the multitude of personal relationships. It looks like they only saw the role side of these relationships, and were blind to the compatibility side. It appears that they decided that the incompleteness they experienced with this lack of a good mechanism could be swept under the metaphorical carpet by their Role Activation Constraint class.

I hope Clique Space will show these individuals the error of their ways. In time, I hope Clique Space will demonstrate a superior solution to the same problem domain as RBAC. Without an implementation, one can only hope. Still, hope is what drives me to this implementation.

The three spines.

This diagram provides justification for why there are seven Elements in Clique Space(TM). The first diagram of this blog.

So, what does it say?

In Clique Space, there are seven Elements. These Elements are represented in the diagram above by the blue hexagonal Chips. There are three spines. The diagram shows the Participant at the centre of the diagram; the Participant is the Element that is common to all three spines. Each spine is labelled by the Element named in the outermost Chip. Therefore, starting at the top, and going clockwise, we have: the Sovereign spine, the Mode Profile spine, and the Media Profile spine.

The diagram discloses that in order to create an Identity, one must have a Sovereign. As the only Sovereign that one has access to is one's own, the only Sovereign one can use to create Identities is one's own. In order to create an Affiliation, one must have a Mode Profile and an Identity. In order to create a Connection, one must have a Media Profile and an Identity. One does not necessarily need to use one's own Identity to create a Connection or Affiliation.

As the paragraph above establishes, the red arrows in the diagram indicate which Elements of a particular type one needs in order to create the Element to which the arrows point. There are two red arrows from the Connection to the Participant and this is meant to imply that one needs to have one or more Connections to create a Participant. One also needs an Identity to create a Participant. However, the two yellow arrows with a dashed tail indicate that one needs zero or more characteristics (properties) which may be sourced from one or more Affiliations or the given Affiliations' Media Profile hierarchies.

Properties are settings which are paired with the corresponding Enabling Constraint given in the Clique's medium (derived from a subset of the flattened Media Profile hierarchies of the given Connections) and for each Enabling Constraint:Property pair, creates a Limiting Constraint. These Limiting Constraints are stored in the Participant. Properties may also be sourced from any Element so therefore, needn't come from any of the given Identity's Affiliations or any of the Mode Profiles associated with these Affiliations.

Basically, that's the justification for why Clique Space has seven Elements. I hope this helps others understand Clique Space.

There are a few subtle things that this diagram doesn't make obvious.

For instance, because a Participant expresses a collection of Connections, only characteristics associated with those Connections may be also be candidate properties for expression in the Participant. Additionally, because a subset of the flattened Media Profile hierarchy's Enabling Constraints are selected to be expressed in the Participant, only those Media Profiles from which Enabling Constraints have been selected can supply candidate properties. I also think that those candidate properties must be related to a specific Enabling Constraint contained in that particular Media Profile, but perhaps that's taking things a little too far.

Another relationship this diagram doesn't make obvious is that one may use any Identity to create a Participant. However, this Identity and the Identity of all the Connections must be the same. If a property has been selected from an Affiliation or a Mode Profile, the Identity of any Affiliation acting as the source must match the Identity given to the Participant. Any property sourced from a Mode Profile must be sourced from a Mode Profile that has been associated to one the Affiliations of the given Identity.

In 2004, I could see the seven Elements, but couldn't fully appreciate the relationship down to the level which I have described here. Maybe much of the relationship is now prior art. But still, if those Elements were removed, there's not much left to invent with, and I think the relationship was a product of the concept's development, and not necessarily an inventive step.

Oh, and yes... how does one create the outermost Elements? There are things that are too complicated to explain even as text following the diagram. I know what they are, but it'll be good just to leave them for another blog entry. At least, I can quickly say that the same mechanism being left out is used to create all the Elements; it just isn't mentioned in this entry because it would steer the reader too far from the purpose of this entry.

A small epiphany today: the candidate as a key.

I've just resumed my 6k jogs after nearly two weeks of less than great weather. Just before I went on today's stint, I had a small epiphany that has since spread its tendrils of enlightenment over the whole concept, revealing perhaps many answers to problems that hitherto remained without an answer.

The epiphany happened like this: I was getting ready to go out for my jog, and I was just trying to capture my thoughts as comments in the AdministratorClientMediaProfile class. I'm working on the connect method of this class; a remote method call from an administrator client when someone attempts to connect one to an Agent Device member of their Sovereign's Clique Space.

It was intended that the candidate data structure be used to communicate two things: a collection of named enabling constraints and a collection of properties. These candidates would come in two subtypes: the Owner's candidate would indicate such properties as would be expressed in an Owner Participant, and the member's candidate would indicate such properties as would be expressed in a member Participant. The current placement of this candidate as a structure which can be used in a remote call has fallen out of favour. The candidate as it is currently implemented appears inappropriate.

I made some wistful half-formed remarks about declaring candidate "templates" as a property of an Identity and left for my jog. As I walked out my door, a small frisson buzzed me. I thought to myself that it would just be better to think of the candidate as a named object which contains Enabling Constraints and the location, within the Identities scope, of properties which would fit into parameters of these Enabling Constraints to yield a Participant's Limiting Constraints.

While I was jogging, I did some more thinking. When I got back, I re-edited my comments and what I put down earlier evolved into what has been re-quoted here:

• Consider moving the concept of the candidate into more of a central role as an internal property of an Identity. This may be a good way to establish connection semantics for all external devices. A candidate might then need only be referred to by its name when a connection is requested through an external device.

The candidate has taken a new, and hopefully a simpler position within the implementation. The candidate is a key that is used to instruct an external device to connect to a Clique Space. Entries in the Identity's internal candidates property can be referred to by name when a device is being used to request its connection to a Clique Space. Hence, to reference a candidate held in an Identity, all that needs to be communicated from the device is a candidate's name. Usage of a named candidate in this way appears to be precisely how a user would prefer to determine the way an external device might initiate a connection with the user's sovereign Clique Space so the device can then be engaged with other devices through Clique Space.

Structurally, the candidate completely specifies the set of Media Profiles that determine the Participant's medium. The candidate key, on the other hand, only draws specific mode entries form the Mode Profile spine, so that when the Participant is being formed, additional Properties can be taken from wherever they reside in the Connections and the Connections' Media Profiles.

At the moment, I still think that there will be times where a named candidate will not provide a flexible option when engaging a device once it is connected to a Clique Space. There will be plenty of times where it still appears necessary to be able to create a candidate for a single use; especially in a situation where an individual needs to be flexible, and admit a form of compromise so the Clique can form and some process governed by this Clique can ensue.

Currently, I still think it good to turn this paradigm shift over in my head for a little while yet to see if I can work out if any anomaly renders it unsuitable before I move to implement.

In my journey.

My journey, in the context of this blog entry, is the set of events and an interval of time that have led me to this point in my development of my Clique Space(TM) thing.

In my journey, I have been witness to a changing code base. In my journey, my code base has both grown and shrunk as realisations have born the creation and growth of new structures as well as the atrophy and destruction of structures rendered redundant. In my journey, I have seen my code base changes flow and boil in consequence to the effect of my intellectual endeavours to construct a system that is faithful to the purpose which I conceived in 2004.

In my journey, I have witnessed the following: my code base accrues the software equivalent of carbuncles and stretch marks that one would observe in any part of one's body subject to the stress of general use. My code base has accrued its own set of idiosyncrasies that one might observe of a car or a house over an extended period of time and use.

There is something else I have been witnessing about this code base over possibly the most recent six months: it has been drawing closer to my concept. I suspect this change is significant because up until about six months ago, I thought that my concept could have been the product of insufficient reflection on the problems that it tried to address: namely, how does one make a claim on the devices in one's environment as if these devices were part of one's body - visceral claims about one's own car, one's Facebook page, one's PC, one's golf ball, one's bank account etc that are as strong as the same individual's claim to one's own hands, one's feet, one's fingernails, one's eyes, one's intestines etc.

Now, up to six months ago, the evolving code base - the changing implementation of the concept - was generally saying to me that it might only work if I made certain compromises to my concept. However, since I had worked out the Sovereign's Clique Space (this happened on 17 December 2012 when I posted my first account of this phenomenon) it now appears that what I had correctly labelled as "speculative faith" up to this point, had become a testable hypothesis.

In effect, I saw the way to the goal-posts when I observed the role that the Sovereign (labelled as the Account in my patent that I published in 2008 and a part of the data structure present in my concept since 2004) and the Sovereign's Clique Space played in allowing the individual to make visceral claims about things outside of a hominid form. These deliberations in December last year concluded my philosophical deliberations on the relationship of the possessor and that which is possessed in a detail which appears to have coincided with another event: the code base began to diminished in size by a significant amount. I am unaware of just how much it has diminished so far, but I believe it would be at least 20%. Other structures like the relationship between the Identity (erstwhile Active Affiliation), and its component Connections and Affiliations have gained clarity and robustness.

My deliberations on 17 December last year also demonstrated the efficacy of the Media Profile. This development included the overlaying concept of the Media Profile spine first thought useful as a mechanism to admit a process of obtaining progressively more delegated functionality through a particular device. The notion whereby subclass adaptations of the Media Profile, the Connection, the Active Affiliation, and the Participant to a specific medium was retained on all classes but the Active Affiliation after the deliberations on this earlier blog entry pointed to the redundancy of these "delegates"; it is not considered necessary that devices using a specific medium go through a multi-stage login process to obtain their Participant in their serving Agent Device's Clique.

I hope to see the observer mechanism, as a (Media Profile) spinal adaptation will realise a component almost as profound, and no less intertwined with, the concept of the Sovereign and its Clique Space. Although the specific specification of the observer mechanism is an artefact of development which emerged subsequent to the publishing of my patent, my original inspiration in 2004 was that Clique Spaces are manifest though collections of Agent Devices, each cooperating with others forming Cliques which may grow, shrink, and disband. The observer mechanism simply draws on the data model disclosed in the patent to ultimately realise this behaviour of the Agent Device.

Another line in my email signature: "Philosophy. Atheist gap-filler."

Sometimes this Clique Space thing gets me thinking about the nature of the self. Such thoughts are often the subject of religious dogma. My family background is Anglican, but I am not an adherent to any religious philosophy, save any familial and traditional ties to customs originating from Anglicanism and Christianity in general that still roost in my secular atheist belief system.

So, I like the quip in the title of this entry. It'll be my repartee to the conundrum that theists think they're presenting with the oft heard argument that "If one doesn't have God (a god), then how can one have morals?".

I think it'll also make a handy repellent. Make it so.

Implementation of the observer mechanism.

As I write this entry, I am taking some time away from coding the observer mechanism.

This observer mechanism, like any other mechanism that models and moderates the behaviour of devices within Clique Space is a medium. Hence, the observer mechanism must exhibit the structural components necessary for the representation of any medium in Clique Space: the abstract classes for the Media Profile, the Connection, and the Participant require implementations that can be instantiated.

However, the observer's medium is a medium that models a functional subset of the behaviour of the Agent Device, and hence, there are other structures that need to be implemented.

The Clique needs a subclass on the Agent Device: the observer Clique must contain only observer Participants. This Clique is importantly distinct from a Clique that models the way other media are modelled and controlled in that the observer Clique indicates which Agent Devices have knowledge of a specific component. Every observable component has an observer Clique when an Agent Device responsible for the creation and management of an observable component transmits knowledge of this component to another Agent Device. The Agent Device that created the observable component is the observer Clique's Owner, although in an observer Clique, like any other Clique, ownership can cede to another Agent Device, and so like any other Clique, the observer Clique is not anchored to any one location.

There is at least one minor issue with this model. If an observer Participant is a component (all of Clique Space's Elements are components), and if the observer Participant, in being a component other than a Clique, is observed, then how is that observer Participant observed? One cannot create another observer Clique because the creation of another observer Clique (Cliques - including the observer Clique - are components, but they are the only type of component that is not observable) would involve the creation of more observer Participants. This is an infinite regression, and so to avoid this, any specific observer Participant's observer Clique is the Clique which contains the observer Participant. This solution not only appears to be a convenient way of avoiding the infinite regress, but it appears to have a certain (though circular) logical necessity; in this mechanism, I feel echoes of the same necessarily visceral emotional base (the ego) that I seem to observe when I observe myself.

With this mechanism, component transmission can be tracked and controlled by a collection of Agent Devices. It appears that this mechanism is crucial to the cooperative activity of Agent Devices, and I believe this mechanism will have something to say about cognitive function in biological neural systems.

Anyway, implementation awaits...