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.