Tuesday, June 12, 2012

Might an Element's properties promise a significant key to cracking the Clique Space(TM) implementation riddle?

Enough about IBM bullshit. Such trivia I'll probably revisit later...

I have asserted many times in a multitude of ways that Clique Space is a simple way of conceptualising a system that allows a collection of devices, possessing state and belonging to an individual, to be assigned to any particular individual, and for any collection of devices which have been so assigned, to be projected to other individuals who themselves, possess devices that project one or more identities likewise.

The idea is perhaps devilishly simple. It's implementation has been occupying my time for almost four years, and sometimes I get the feeling that the implementation might be getting away on me.

Recently, I have had the need to introduce something called an Element's property. Properties appear to serve many of the purposes that I had glimpsed at over quite a number of earlier points over the past four years, and possibly even earlier than that.

An Element contains a collection of properties; it is a container of properties which are internal to the Clique Space implementation. Although not fully implemented at the time this was written, it appears as though a Participant's properties are the all-important Limiting Constraints; properties which dictate how a Clique Space represents and mediates an individual's participation in a collaboration being modelled and controlled inside a Clique. While Limiting Constraints can appear in any Clique Space Element, the Enabling Constraints which expose the state of a device to Clique Space are contained on a Media Profile hierarchy - an n:m acyclic graph - the "top" node representing the particular devices distinct functionality, and the "root" node representing the Clique Space which has ultimate governorship of how this device is controlled when participating in a Clique. It currently appears appropriate that a Media Profile must contain a single Enabling Constraint and from this Enabling Constraint contain a collection of Limiting Constraint labels which expose device control parameters. It also currently appears appropriate that an Element's Limiting Constraints will be contained in an Elements "Limiting Constraints property" to be used as a source of a Participant's state as it changes - changing a Limiting Constraint in any Element will change the state of a Participant in which that Limiting Constraint is expressed.

Admittedly, I couldn't quite get a grip on the relationship between Limiting Constraints and their expression in a Participant when I drafted the patent. It looks as if the implementation artefact of the properties formalises this relationship, and also allows the Clique Space system to abstract the particular internal workings of its own media away from the Enabling/Limiting Constraints mechanism which would be used to express this working when Agent Devices are represented as Participants in the Clique Space's Clique, bipartite engager's Clique (a synapse), and with administrator devices in bipartite serving Agent Device's Cliques. However, I do contend that while these relationships were still fluid at the time I put the patent together, they are considerations revolving around the details of the implementation rather than the abstract concept; the building blocks (Element, Clique Space, Agent Device, Account, Account Profile, Affiliation, Connection, Identity - nee Active Affiliation, Media Profile, Participant, Enabling Constraint, Limiting Constraint) have remained a sufficiently stable explanation of the concept.

The Client Device still exhibited some fluidity in definition; this was because the relationships between the building blocks required some clarification. But I believe the Client Device, being a collection of Affiliations, Collections, Identities and Participants concerning an individual Account has since acquired a robust definition.

All other artefacts like the administrator device (sometimes described as the Client Device because this has been the only other device which has thus far been able to connect to an Agent Device), the engager, the collaborator, the Clique Space member, the synapse, the property, the transmitter, the precis, the delegate, etc. are artefacts that have emerged through the development and implementation of the concept. Although I might have over-engineered the implementation (most early implementations are over-engineered) I assert that these artefacts emerged only as a causal necessity of getting from the concept to the implementation.

I'm hoping that in time, the Clique Space implementation will find that the introduction of the properties might be the final major artefact that fulfils the abstract intentions given in the Clique Space concept. I also do hope that the jurisdictions in which my patent is registered hold these registrations to be valid if or when they are challenged.

No comments:

Post a Comment