It looks as if the Clique Space(TM) Agent Device(TM) and administrator clients are coming together in some fundamental ways.
The delegate interface is casting away its intermediate forms, and simplifying itself so that an administrator can do the four Clique Space things upon which everything else sits: 1. forming, 2. disbanding, 3. joining and 4. leaving Cliques. Beyond these four functions, Clique Space is only limited to the functionality of the media which are exposed to it.
Thursday, July 19, 2012
Tuesday, July 17, 2012
BasicElement: Code listing.
I wanted to provide a listing of the BasicElement module in my last entry. I decided I'd turn my last entry into a bit of a prattle when I found that I couldn't get the HTML to display properly. I'm putting this entry together because I think I've worked it out.
If one looks closely at the way the BasicElement interface is declared, one should be able to understand the basic tenet of the Clique Space concept: modelling the activity of the individual. In a way, I think that the term "model" does not explain this Clique Space(TM) thing enough. Also, I think that because of the the notion that every device - even the Agent Device - is subject to being represented in the Clique Space environment, this listing might also demonstrate that the verb "to model" and the verb "to control" are the same thing in Clique Space.
Modelling an activity is intuitively distinguished from controlling an activity; modelling means observing or perhaps merely simulating an activity whereas controlling an activity implies intervening in an activity going on in the real world, while that activity is transpiring. It is important to note that the Agent Device is a device like any other device to Clique Space for the same reasons that modelling and controlling Clique Space activity correspond.
Something that hosts a running instance which implements this interface is known to the BasicElement as the 'Device'. This Device has a CliqueSpaceContainer which contains all the Clique Spaces and Elements that the device knows of. The BasicElement is a collection of 'Properties'; these properties describe everything the Element is. Limiting Constraints are a type of property which, while potentially contained in all Elements, are expressed only in Participants. There is a really elegant relationship between a BasicElement's properties and a BasicParticipant's Limiting Constraints, but a description of this relationship might best perhaps be left to another entry.
Anyway, being that this prattle might just be seen by the reader as a bit of a distraction, here is the source code listing. I hope the reader respects the little bit of inoffensive asserting that I have included. I'm hoping my blog entries might inspire my readers to get in contact with me. What can you lose?
...some imports that needn't be disclosed...
If one looks closely at the way the BasicElement interface is declared, one should be able to understand the basic tenet of the Clique Space concept: modelling the activity of the individual. In a way, I think that the term "model" does not explain this Clique Space(TM) thing enough. Also, I think that because of the the notion that every device - even the Agent Device - is subject to being represented in the Clique Space environment, this listing might also demonstrate that the verb "to model" and the verb "to control" are the same thing in Clique Space.
Modelling an activity is intuitively distinguished from controlling an activity; modelling means observing or perhaps merely simulating an activity whereas controlling an activity implies intervening in an activity going on in the real world, while that activity is transpiring. It is important to note that the Agent Device is a device like any other device to Clique Space for the same reasons that modelling and controlling Clique Space activity correspond.
Something that hosts a running instance which implements this interface is known to the BasicElement as the 'Device'. This Device has a CliqueSpaceContainer which contains all the Clique Spaces and Elements that the device knows of. The BasicElement is a collection of 'Properties'; these properties describe everything the Element is. Limiting Constraints are a type of property which, while potentially contained in all Elements, are expressed only in Participants. There is a really elegant relationship between a BasicElement's properties and a BasicParticipant's Limiting Constraints, but a description of this relationship might best perhaps be left to another entry.
Anyway, being that this prattle might just be seen by the reader as a bit of a distraction, here is the source code listing. I hope the reader respects the little bit of inoffensive asserting that I have included. I'm hoping my blog entries might inspire my readers to get in contact with me. What can you lose?
1 /* 2 * (C) Copyright Owen Thomas. All rights reserved. 3 * Express written permission must be obtained from Owen Thomas in order 4 * to reproduce all or part of this source or compiled code in a manner 5 * specified in said permission. 6 */ 7 8 package cliquespace.core.cliquespace.basic;
...some imports that needn't be disclosed...
40 /** 41 * @author Owen Thomas 45 */ 46 public interface BasicElement< 47 D extends Device, 48 CS extends BasicCliqueSpace<D,CS,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC>, 49 ID extends Identifier, 50 E extends BasicElement<D,CS,?extends Identifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>, 51 A extends BasicAxle<D,CS,?extends AxleIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>, 52 AP extends BasicAccountProfile<D,CS,?extends AccountProfileIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>, 53 APR extends BasicAccountProfileRoot<D,CS,?extends AccountProfileRootIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>, 54 APN extends BasicAccountProfileNode<D,CS,?extends AccountProfileNodeIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>, 55 MP extends BasicMediaProfile<D,CS,?extends MediaProfileIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>, 56 MPR extends BasicMediaProfileRoot<D,CS,?extends MediaProfileRootIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>, 57 MPN extends BasicMediaProfileNode<D,CS,?extends MediaProfileNodeIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>, 58 AF extends BasicAffiliation<D,CS,?extends AffiliationIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>, 59 C extends BasicConnection<D,CS,?extends ConnectionIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>, 60 I extends BasicIdentity<D,CS,?extends IdentityIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>, 61 P extends BasicParticipant<D,CS,?extends ParticipantIdentifier,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC,? extends Property>, 62 CL extends BasicClique<D,CS,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC>, 63 CSC extends CliqueSpaceContainer<D,CS,E,A,AP,APR,APN,MP,MPR,MPN,AF,C,I,P,CL,CSC>, 64 PR extends Property> 65 extends Element<CS,ID>{The interface's body has been removed because the contents are trivial and don't help illustrate the point I am trying to make in this entry.
85 }
I do think the interface declaration is quite special. It shouldn't be too hard for the observant reader to realise that through this interface declaration, the declarations of the BasicCliqueSpace, BasicClique, and all the Basic~ Elements can be derived. This is because the very high degree of coupling. All of these parts of the Clique Space concept are interwoven to serve a common design purpose: Clique Space is designed to represent an individual in cyberspace.
Monday, July 16, 2012
The BasicElement interface: an expression of the Clique Space(TM) concept in code.
Clique Space's(TM) implementation has been evolving for some time in Java SE. Many (but probably not most) of the features exhibit stability and robustness. I can cheerfully say that the basic expression of the Clique Space concept has exhibited reasonable stability for probably a year or more.
I've been looking for one code module that would conveniently show many of the conceptual features of Clique Space, and I think that one module in particular does this quite well. This module is the BasicElement interface. Primarily, the BasicElement interface encapsulates an important general phenomenon which Clique Space was conceived to capture: the self-referential nature of the individual - the self, or in Clique Space parlance, the Client Device - the purpose of which is to provide an cyberspatial skin detailing one's total capacity and authority to act within any Clique Space to which one is connected.
Yes, indeed, this is what Clique Space is basically meant to provide; an expression of the individual's own presence in cyberspace. The declaration of the BasicElement interface shows how the phenomenon of the individual is addressed. Being that I assert that nothing like this has ever been previously considered, this is quite a disclosure: a target for prior art if it is found that my patent doesn't adequately cover my concept - c'est la vie.
We all know that the nature of the individual is elusive. We all know we are aware of ourselves, and we all infer this quality "self" in others through empathy; the correspondence between what we feel when we perform some activity, and what we observe of that activity by these others in our environment. Even though, for a long time, members of one species on this planet appear to possess a highly refined sense of empathy, we have thus far had very little success in describing the individual as a universal quality; a quality which most of us believe should be a universal and transcendent... if only we had some framework through which it can be expressed and communicated. Hark! I hear another cue for Clique Space!
I have to make some assertions about what I think an individual is. These assertions include, but perhaps are not limited to, the following characteristics. Summarily, the individual appears to be:
How, then, especially considering point three, are we to design a system that expresses this elusive substance? Although the individual cannot be directly expressed through a computer language (the possibility that a computer system may provide an environment through which an individual might emerge is another topic which I will avoid in this entry), a computer language can provide a way that collections of logical absurdities can assert and accept claims of possession and abilities to act.
To do this, a computer language must surround the event horizon of the logical absurdity. Such a system can give an individual that uses it a cyberspatial skin that other individuals using this system likewise would be capable of recognising. This is Clique Space. In order for Clique Space to do this, one has to recognise that Clique Space must be able to surround the event horizon generated by the absurdity. In my patent, I envisaged that encirclement of the event horizon can be achieved with the Clique, the Clique Space, and the first seven of an unbounded number of Element types: Axle (nee Account), Account Profile, Media Profile, Connection, Affiliation, Identity (nee Active Affiliation) and Participant. Individual assertions are communicated through Enabling and Limiting Constraints contained within these Elements.
The implementation has not been far off the mark.
Extra Element types are created around different media types; I have envisaged after publishing my patent that these extra types would appear by deriving types from the set of Elements collectively known as the Client Device's Media Profile spine - the Media Profile, Connection, and Participant. The Identity was once a member of this set. However, the Identity was abstracted out when I realised that the Identity is a Collection of Connections and Affiliations assigned to a single Axle instance and used to generate a collection of Participants. I believe I will shortly drop the Participant and the Connection from this set because like the Identity, a Participant may contain more than one Connection whenever it is appropriate to express one individual's participation in a Clique as a collection of Connections, and a Connection might represent the association of one Axle through one device to multiple Media Profiles. Hence, the Media Profile might remain the only Element from which extra Element types may be derived.
The Elements and their broad behaviour have been declared on spec in the BasicElement interface, with two relatively minor modifications: the detailed relationships between the Identity and the other Elements, and a delineation between root and node Media and Account Profiles. The BasicElement Java interface is accompanied by eleven other Java interface modules describing subtypes of BasicElement for these seven Element types: BasicAxle, BasicAccountProfile, BasicAccountProfileRoot, BasicAccountProfileNode, BasicMediaProfile, BasicMediaProfileRoot, BasicMediaProfileNode, BasicConnection, BasicAffiliation, BasicIdentity, and BasicParticpant.
These interfaces are accompanied by declarations for a BasicClique so that BasicParticipant Elements have a medium of propagation amongst Agent Devices, and a BasicCliqueSpace, so that all BasicElement types have a pace to reside and the life cycles of all Element instances can be subject to some collectively agreed to degree of administration permitting the activity of individuals to be collectively organised; exactly as society has done for the past five thousand or so years. The BasicElement and all these related declarations are customised on other device types so devices other than Agent Devices may receive projections of these Elements. One instance of a BasicMediaProfile contains one Enabling Constraint which exposes device behaviour as parameters to Clique Space. One Enabling Constraint parameter can be given a value in one BasicParticipant by assigning a Limiting Constraint to the parameter.
Limiting Constraints can be contained in all BasicElements, but are expressed only in the BasicParticipant. The BasicIdentity is used to project an individual's worldly identity to others, and an instance of a class that uses this interface must contain Limiting Constraints which completely cover all, without internally contradicting any, of the BasicConnection instances expressed through the given BasicIdentity instance.
A technical wonder about these Basic~ Java modules is that each parameterises their own declaration and each other's declaration so that implementations (there are two in development at this moment; namely the Agent Device and the administrator client) can customise these Basic~ Elements to behave in accordance to the way a device functions. The BasicElement interface, all its subtypes, the BasicClique, the BasicCliqueSpace, and the Enabling and Limiting Constraints are inseparably woven into each other, providing an impervious container which forms the designed cyberspatial skin around individuals' event horizon, facilitating a virtual link between the absurd singularity of the individual and sensible and logical cyber-environment within which collections of individuals dwell.
I've been looking for one code module that would conveniently show many of the conceptual features of Clique Space, and I think that one module in particular does this quite well. This module is the BasicElement interface. Primarily, the BasicElement interface encapsulates an important general phenomenon which Clique Space was conceived to capture: the self-referential nature of the individual - the self, or in Clique Space parlance, the Client Device - the purpose of which is to provide an cyberspatial skin detailing one's total capacity and authority to act within any Clique Space to which one is connected.
Yes, indeed, this is what Clique Space is basically meant to provide; an expression of the individual's own presence in cyberspace. The declaration of the BasicElement interface shows how the phenomenon of the individual is addressed. Being that I assert that nothing like this has ever been previously considered, this is quite a disclosure: a target for prior art if it is found that my patent doesn't adequately cover my concept - c'est la vie.
We all know that the nature of the individual is elusive. We all know we are aware of ourselves, and we all infer this quality "self" in others through empathy; the correspondence between what we feel when we perform some activity, and what we observe of that activity by these others in our environment. Even though, for a long time, members of one species on this planet appear to possess a highly refined sense of empathy, we have thus far had very little success in describing the individual as a universal quality; a quality which most of us believe should be a universal and transcendent... if only we had some framework through which it can be expressed and communicated. Hark! I hear another cue for Clique Space!
I have to make some assertions about what I think an individual is. These assertions include, but perhaps are not limited to, the following characteristics. Summarily, the individual appears to be:
- capable of asserting themselves: the individual claims possession of things and abilities to act in one's environment
- capable of accepting others: the individual accepts the claims to possession and abilities to act by others in one's environment
- a logical absurdity: a conceptual singularity which, like the black hole analogue in gravity, is impervious to investigation, and opaque to ultimate knowledge within one's environment
How, then, especially considering point three, are we to design a system that expresses this elusive substance? Although the individual cannot be directly expressed through a computer language (the possibility that a computer system may provide an environment through which an individual might emerge is another topic which I will avoid in this entry), a computer language can provide a way that collections of logical absurdities can assert and accept claims of possession and abilities to act.
To do this, a computer language must surround the event horizon of the logical absurdity. Such a system can give an individual that uses it a cyberspatial skin that other individuals using this system likewise would be capable of recognising. This is Clique Space. In order for Clique Space to do this, one has to recognise that Clique Space must be able to surround the event horizon generated by the absurdity. In my patent, I envisaged that encirclement of the event horizon can be achieved with the Clique, the Clique Space, and the first seven of an unbounded number of Element types: Axle (nee Account), Account Profile, Media Profile, Connection, Affiliation, Identity (nee Active Affiliation) and Participant. Individual assertions are communicated through Enabling and Limiting Constraints contained within these Elements.
The implementation has not been far off the mark.
Extra Element types are created around different media types; I have envisaged after publishing my patent that these extra types would appear by deriving types from the set of Elements collectively known as the Client Device's Media Profile spine - the Media Profile, Connection, and Participant. The Identity was once a member of this set. However, the Identity was abstracted out when I realised that the Identity is a Collection of Connections and Affiliations assigned to a single Axle instance and used to generate a collection of Participants. I believe I will shortly drop the Participant and the Connection from this set because like the Identity, a Participant may contain more than one Connection whenever it is appropriate to express one individual's participation in a Clique as a collection of Connections, and a Connection might represent the association of one Axle through one device to multiple Media Profiles. Hence, the Media Profile might remain the only Element from which extra Element types may be derived.
The Elements and their broad behaviour have been declared on spec in the BasicElement interface, with two relatively minor modifications: the detailed relationships between the Identity and the other Elements, and a delineation between root and node Media and Account Profiles. The BasicElement Java interface is accompanied by eleven other Java interface modules describing subtypes of BasicElement for these seven Element types: BasicAxle, BasicAccountProfile, BasicAccountProfileRoot, BasicAccountProfileNode, BasicMediaProfile, BasicMediaProfileRoot, BasicMediaProfileNode, BasicConnection, BasicAffiliation, BasicIdentity, and BasicParticpant.
These interfaces are accompanied by declarations for a BasicClique so that BasicParticipant Elements have a medium of propagation amongst Agent Devices, and a BasicCliqueSpace, so that all BasicElement types have a pace to reside and the life cycles of all Element instances can be subject to some collectively agreed to degree of administration permitting the activity of individuals to be collectively organised; exactly as society has done for the past five thousand or so years. The BasicElement and all these related declarations are customised on other device types so devices other than Agent Devices may receive projections of these Elements. One instance of a BasicMediaProfile contains one Enabling Constraint which exposes device behaviour as parameters to Clique Space. One Enabling Constraint parameter can be given a value in one BasicParticipant by assigning a Limiting Constraint to the parameter.
Limiting Constraints can be contained in all BasicElements, but are expressed only in the BasicParticipant. The BasicIdentity is used to project an individual's worldly identity to others, and an instance of a class that uses this interface must contain Limiting Constraints which completely cover all, without internally contradicting any, of the BasicConnection instances expressed through the given BasicIdentity instance.
A technical wonder about these Basic~ Java modules is that each parameterises their own declaration and each other's declaration so that implementations (there are two in development at this moment; namely the Agent Device and the administrator client) can customise these Basic~ Elements to behave in accordance to the way a device functions. The BasicElement interface, all its subtypes, the BasicClique, the BasicCliqueSpace, and the Enabling and Limiting Constraints are inseparably woven into each other, providing an impervious container which forms the designed cyberspatial skin around individuals' event horizon, facilitating a virtual link between the absurd singularity of the individual and sensible and logical cyber-environment within which collections of individuals dwell.
Monday, July 9, 2012
How much structural symmetry is there between the Affiliation and the Connection?
This question has been occupying my mind for some time, and it relates to the way some Elements in Clique Space(TM) appear themselves, to exhibit precisely the properties that Clique Space was conceived to model. How far can I go with this? Can a Clique Space Agent Device use its data model to model relationships between its own Clique Space component object instances as they are created and deleted?
This question is a rather silly reductio ad absurdum. However, it might be interesting to note that discussions throughout this blog have touched on something I call the serving Agent Device's Clique.
Let's have another look at the serving Agent Device's Clique. I am in the process of removing the "three stage delegate" device Connection mechanism from the implementation, and working toward a new relationship between two of the implementation's components: both the Connection to the other device and the serving Agent Device's Clique modelling the collaborative exchange between an Agent Device and the other device must exist simultaneously. Delegate capacity (a capacity for the Element to contain and project an Agent Device's delegate server RMI stub to the other device through which commands will be sent back to the Agent Device from the other device) is removed from the Identity because a singular Identity will now be correctly implemented to represent collections of Connections and Affiliations around a single Axle. The delegate capacity will be shared between the Connection and the Participant: the Connection contains the RMI stub, but any message sent from the other device identifies the serving Agent Device's owner Participant created from this other device's Connection when instructing the Agent Device to perform some action in relation to a change in the other device's state.
So anyway, what am I getting at here? Well, put the delegates and all the mechanical minutiae for the serving Agent Device's Clique aside (I feel I had to explain it in part just to get it off my chest), and concentrate merely on what the Agent Device's Clique represents: a collaborative exchange between two users; the operator of the serving Agent Device, and the operator of the device which is connected to a particular Clique Space through this Agent Device, if these are indeed different individuals. While it should be obvious to the reader that the serving Agent Device's Clique models the collaboration between an Agent Device and another device (because I have just stated this), the same reader might also be ask themselves whether, because of the dependency between the serving Agent Device's Clique and the other device's Connection, this Clique appears also to represent the instance of the Connection to the given device.
I think such an observation is very interesting, as it appears to promise a similar symmetry in the relationship that manifests an Affiliation. More thought is definitely required before I start to head off in a specific direction here,but one question is this: who is collaborating with whom? Clearly, in the serving Agent Device's Clique, the two Participants are representing the operator or operators of the devices which are collaborating. However, consider this: where the Connection represents an association between an Identity (more accurately, the Identity's Axle through a given Identity) with a Media Profile, then who, if this association might also be seen as a collaboration, represents the component Media Profile? Likewise, if we are going to do something similar with the Affiliation, then who represents the Account Profile?
When we entertain this "structural symmetry", might we in actuality require two more new Cliques (rather than one because the symmetry in the Affiliation bares no functional relationship to the serving Agent Device's Clique) to model the structural symmetry: 1. one Clique to model the specific relationship between the Connection's Axle and Media Profile and 2. another Clique to model the specific relationship between the Affiliation's Axle and Account Profile? Would these Cliques have any natural value? I think they may...
Hmmm...
This question is a rather silly reductio ad absurdum. However, it might be interesting to note that discussions throughout this blog have touched on something I call the serving Agent Device's Clique.
Let's have another look at the serving Agent Device's Clique. I am in the process of removing the "three stage delegate" device Connection mechanism from the implementation, and working toward a new relationship between two of the implementation's components: both the Connection to the other device and the serving Agent Device's Clique modelling the collaborative exchange between an Agent Device and the other device must exist simultaneously. Delegate capacity (a capacity for the Element to contain and project an Agent Device's delegate server RMI stub to the other device through which commands will be sent back to the Agent Device from the other device) is removed from the Identity because a singular Identity will now be correctly implemented to represent collections of Connections and Affiliations around a single Axle. The delegate capacity will be shared between the Connection and the Participant: the Connection contains the RMI stub, but any message sent from the other device identifies the serving Agent Device's owner Participant created from this other device's Connection when instructing the Agent Device to perform some action in relation to a change in the other device's state.
So anyway, what am I getting at here? Well, put the delegates and all the mechanical minutiae for the serving Agent Device's Clique aside (I feel I had to explain it in part just to get it off my chest), and concentrate merely on what the Agent Device's Clique represents: a collaborative exchange between two users; the operator of the serving Agent Device, and the operator of the device which is connected to a particular Clique Space through this Agent Device, if these are indeed different individuals. While it should be obvious to the reader that the serving Agent Device's Clique models the collaboration between an Agent Device and another device (because I have just stated this), the same reader might also be ask themselves whether, because of the dependency between the serving Agent Device's Clique and the other device's Connection, this Clique appears also to represent the instance of the Connection to the given device.
I think such an observation is very interesting, as it appears to promise a similar symmetry in the relationship that manifests an Affiliation. More thought is definitely required before I start to head off in a specific direction here,but one question is this: who is collaborating with whom? Clearly, in the serving Agent Device's Clique, the two Participants are representing the operator or operators of the devices which are collaborating. However, consider this: where the Connection represents an association between an Identity (more accurately, the Identity's Axle through a given Identity) with a Media Profile, then who, if this association might also be seen as a collaboration, represents the component Media Profile? Likewise, if we are going to do something similar with the Affiliation, then who represents the Account Profile?
When we entertain this "structural symmetry", might we in actuality require two more new Cliques (rather than one because the symmetry in the Affiliation bares no functional relationship to the serving Agent Device's Clique) to model the structural symmetry: 1. one Clique to model the specific relationship between the Connection's Axle and Media Profile and 2. another Clique to model the specific relationship between the Affiliation's Axle and Account Profile? Would these Cliques have any natural value? I think they may...
Hmmm...
Friday, June 29, 2012
My Proprietary Interest in the Clique Space(TM) Technology.
One can follow this blog from when I started it in July 2009, and clearly observe that I have asserted over and over again, my claim that the Clique Space concept is mine, and that specifically, the term "Clique Space" is a descriptive trademark I am claiming proprietorship of. I have claimed trademark ownership of "Clique Space" at least since I registered the PCT: one will find the name and the TM citation in the document as it was submitted to WIPO. One can observe over the interval, that this blog has been making numerous and repetitive invitations to elicit interest for specific others' support; support which has often (as in the case of Wollongong University) been explicitly turned down.
One can follow this blog from when I started it in July 2009, and clearly observe the open invitation for enquiry by anyone who reads this blog. Hence, although I assert that Clique Space, its concept, and its developed technology is, in its current entirety, an effort wholly undertaken by me, Owen Paul Thomas, a resident of Wollongong, NSW, Australia, I have been trying for at least this same amount of time to garner help from any party anywhere in this world in my proprietary interest; an interest which I believe will pay a great general dividend to those people that respond.
I proclaim that my Clique Space concept will, in time, demonstrate itself to be indispensable in general social interaction. A complex, organised and truly global society, enjoying the fruit that Clique Space yields both in terms of the expression of society and the individuals it is composed of, will identify the degree to which Clique Space demonstrates its efficacy. I believe that the ubiquitous usage of Clique Space will, in times hence, prove that my conception of this Clique Space thing was defining epoch in the evolution of this thing we generally know as society...
These claims may sound grandiose, nay on delusional, but I have been working patiently, steadily, and solitarily on this thing for some time, and if I have delusional tendencies, my psychiatrist - a specialist whom I have known for about as long as this blog has existed - would have prescribed me medication and told me that taking it as directed is perhaps a good idea. He hasn't; he has specifically said that he doesn't think medication is required in my situation.
So, taking my cue from my psychiatrist and generally observing those with whom I share some personal relationship, I assess that I am not in need of intervention; that I am indeed sane and humble enough to create a solution, as robust as it might be elegant, that encapsulates a concept for which I also claim a patent - registered after 3.5 years deliberation in January 2008. I have been working on the implementation of this solution for more than four years since leaving my last employment due to the fact that irreconcilable differences experienced between myself and six employers previously presented themselves as similarly unnavigable in July 2008.
Although my efforts to present my idea have been ignored continually since I conceived the idea in mid-2004, I have persisted with it. I registered a provisional patent in January 2008, and started implementing it in Java SE in July 2008. I use NetBeans as my IDE, SVN for code versioning (provenance) management, on Ubuntu. I thank the fact that these products are completely free because I would not otherwise be able to implement this concept as "effortlessly" as these products allow. However, even with this effortlessness, I didn't think it would take as long as it has so far taken to get to where I am currently. Although the concept itself is very simple, the lack of foreknowledge of the detail of the implementation, and the lack of help and possibly even understanding from others of the help they might have been able to offer, I have persevered alone; I can thus far make my claim to this technology, in its entirety, as exclusively my own.
Hence, this entry is a reiteration of an appeal to interested others to offer their help. The idea is proprietary, and, I am hoping, a product which can be sold. There are certainly legal obstacles to be overcome provided others are willing to play the legal game fairly and offer their help openly. Doing so would also protect their interest should a party, in offering their help, become a stake-holder in this proprietary interest.
Here, I will assert further trademarks. Namely the following:
Primarily, I state this condition of use around all trademarks I have so asserted: I will bare no claim to the terms' usage elsewhere, except where it is evident that the usage of these terms appears to garner interest or revenue in a competing idea - if such an idea that doesn't infringe on my patent could be conceived. I would be respectful, and definitely honoured, if one used these terms in reference to one's own initiatives that would draw on my Clique Space concept as something that these technology vendors have specific intent to use. However, I would certainly anticipate that others who had formed such an intent would definitely have formalised their own business relationship with Clique Space and its technology before they made such statements.
I'm trying hard to be a fair, a good, and a proper man. I hope my efforts in making an open attempt to offer what I have to other people are recognised as being efforts that might come from such a man. I'm really hoping the reader has (you have) a similar intent. Get in contact with me directly (my email is available from clicking my name below the "About Me" details of this blog) if your intents are as sincere as mine.
My patent has evolved through a PCT and is currently in the process of examination in AU, NZ, and US jurisdictions. My code base is currently completely proprietary and closed source however I believe that in the future I would like to see the code released on some general purpose license.
I envisage that the prime business value of any organisation formed around the use of the technology to be a publicly accessible Clique Space - the "Public" Clique Space - that would offer usage to individuals operating as "themselves" free of charge. The Public Clique Space would receive revenue from a type of usage that required another organisation to "federate" its own Clique Space with the Public Clique Space. To this end, I envisage that the Public Clique Space Organisation would be an internationally recognised trading name of the entity set up to execute the administration of the Public Clique Space domain. In terms of Clique Space federations, Clique Space is a highly configurable environment which would allow a degree of fine-grained control unparalleled in any other available technology. Pricing schemes can be set up and levied against this configuration versatility to organisations willing to participate in a federation at whatever level will serve these other organisations' varied needs.
I would not run the Public Clique Space Organisation (I haven't got the required competencies), but I like to think that I'll retain an equity stake in it.
One can follow this blog from when I started it in July 2009, and clearly observe the open invitation for enquiry by anyone who reads this blog. Hence, although I assert that Clique Space, its concept, and its developed technology is, in its current entirety, an effort wholly undertaken by me, Owen Paul Thomas, a resident of Wollongong, NSW, Australia, I have been trying for at least this same amount of time to garner help from any party anywhere in this world in my proprietary interest; an interest which I believe will pay a great general dividend to those people that respond.
I proclaim that my Clique Space concept will, in time, demonstrate itself to be indispensable in general social interaction. A complex, organised and truly global society, enjoying the fruit that Clique Space yields both in terms of the expression of society and the individuals it is composed of, will identify the degree to which Clique Space demonstrates its efficacy. I believe that the ubiquitous usage of Clique Space will, in times hence, prove that my conception of this Clique Space thing was defining epoch in the evolution of this thing we generally know as society...
These claims may sound grandiose, nay on delusional, but I have been working patiently, steadily, and solitarily on this thing for some time, and if I have delusional tendencies, my psychiatrist - a specialist whom I have known for about as long as this blog has existed - would have prescribed me medication and told me that taking it as directed is perhaps a good idea. He hasn't; he has specifically said that he doesn't think medication is required in my situation.
So, taking my cue from my psychiatrist and generally observing those with whom I share some personal relationship, I assess that I am not in need of intervention; that I am indeed sane and humble enough to create a solution, as robust as it might be elegant, that encapsulates a concept for which I also claim a patent - registered after 3.5 years deliberation in January 2008. I have been working on the implementation of this solution for more than four years since leaving my last employment due to the fact that irreconcilable differences experienced between myself and six employers previously presented themselves as similarly unnavigable in July 2008.
Although my efforts to present my idea have been ignored continually since I conceived the idea in mid-2004, I have persisted with it. I registered a provisional patent in January 2008, and started implementing it in Java SE in July 2008. I use NetBeans as my IDE, SVN for code versioning (provenance) management, on Ubuntu. I thank the fact that these products are completely free because I would not otherwise be able to implement this concept as "effortlessly" as these products allow. However, even with this effortlessness, I didn't think it would take as long as it has so far taken to get to where I am currently. Although the concept itself is very simple, the lack of foreknowledge of the detail of the implementation, and the lack of help and possibly even understanding from others of the help they might have been able to offer, I have persevered alone; I can thus far make my claim to this technology, in its entirety, as exclusively my own.
Hence, this entry is a reiteration of an appeal to interested others to offer their help. The idea is proprietary, and, I am hoping, a product which can be sold. There are certainly legal obstacles to be overcome provided others are willing to play the legal game fairly and offer their help openly. Doing so would also protect their interest should a party, in offering their help, become a stake-holder in this proprietary interest.
Here, I will assert further trademarks. Namely the following:
- The Clique Space Axle or the term "Axle" as it would appear in relationship to the discussion of Clique Space or any related concept.
- The Clique Space Agent Device or the term "Agent Device" as it would appear in relationship to the discussion of Clique Space or any related concept.
- The Clique Space Client Device or "Client Device" as it would appear in relationship to the discussion of Clique Space or any related concept.
- The Clique Space Clique or "Clique" as it would appear in relationship to the discussion of Clique Space or any related concept.
- The Clique Space Account Profile or "Account Profile" as it would appear in relationship to the discussion of Clique Space or any related concept.
- The Clique Space Media Profile or "Media Profile" as it would appear in relationship to the discussion of Clique Space or any related concept.
- The Clique Space Enabling Constraint or "Enabling Constraint" and the Clique Space Limiting Constraint or "Limiting Constraint" as they would appear in relationship to the discussion of Clique Space or any related concept.
Primarily, I state this condition of use around all trademarks I have so asserted: I will bare no claim to the terms' usage elsewhere, except where it is evident that the usage of these terms appears to garner interest or revenue in a competing idea - if such an idea that doesn't infringe on my patent could be conceived. I would be respectful, and definitely honoured, if one used these terms in reference to one's own initiatives that would draw on my Clique Space concept as something that these technology vendors have specific intent to use. However, I would certainly anticipate that others who had formed such an intent would definitely have formalised their own business relationship with Clique Space and its technology before they made such statements.
I'm trying hard to be a fair, a good, and a proper man. I hope my efforts in making an open attempt to offer what I have to other people are recognised as being efforts that might come from such a man. I'm really hoping the reader has (you have) a similar intent. Get in contact with me directly (my email is available from clicking my name below the "About Me" details of this blog) if your intents are as sincere as mine.
My patent has evolved through a PCT and is currently in the process of examination in AU, NZ, and US jurisdictions. My code base is currently completely proprietary and closed source however I believe that in the future I would like to see the code released on some general purpose license.
I envisage that the prime business value of any organisation formed around the use of the technology to be a publicly accessible Clique Space - the "Public" Clique Space - that would offer usage to individuals operating as "themselves" free of charge. The Public Clique Space would receive revenue from a type of usage that required another organisation to "federate" its own Clique Space with the Public Clique Space. To this end, I envisage that the Public Clique Space Organisation would be an internationally recognised trading name of the entity set up to execute the administration of the Public Clique Space domain. In terms of Clique Space federations, Clique Space is a highly configurable environment which would allow a degree of fine-grained control unparalleled in any other available technology. Pricing schemes can be set up and levied against this configuration versatility to organisations willing to participate in a federation at whatever level will serve these other organisations' varied needs.
I would not run the Public Clique Space Organisation (I haven't got the required competencies), but I like to think that I'll retain an equity stake in it.
Sunday, June 24, 2012
State versus content: Clique Space(TM) as something which might be useful.
Cliques model collaborations. What does this mean?
First, a refresher on the general principle of Clique Space; one that perhaps does not pay respect to the subjects of federation or anonymous or unidentified (un-Identitied) Participants as they apply to Clique Space for the sake of simplicity, but never mind...
A collaboration is some cooperative activity going on between individuals. Each individual has some capacity to act, and uses a particular device capable of participating in this collaboration. The collaboration is going on within one or more particular media, and, when the collaboration is being modelled as a Clique, this collaboration can be observed by others, according to the degree to which these others have constraint affinity with the Clique and each of its member Participants.
Agent Devices are only special in that they are running instances of the Clique Space Agent Device code. Beyond this fact, there's nothing special about Agent Devices. Simply put, Agent Devices form Agent Collaborations, and Clique Spaces can exist in Agent Collaborations. An Agent Collaboration is modelled as a Clique within the Clique Space that exists as a result of an Agent Collaboration. Each Agent Device is controlled by an individual like any other device, and each Agent Device exposes functionality through the same control mechanism as any other device.
Clique Space users (individuals) connect other devices through Agent Devices which are members of a Clique Space to which they want to connect. All the devices one has connected to a Clique Space (including Agent Devices) generate activity in their own device specific way. Changes in device state are siphoned and modelled as activity in a Clique Space. Each connected device lets Clique Space know which other devices it is exchanging information with so the Clique Space can model this collaboration as a Clique. The exchange going on between the external device and the Agent Device to which it is connected is a collaboration like any other: it is modelled as a Clique - called the serving Agent Device's Clique.
For any given Clique, each Agent Device that is managing the direct link to an external device participating in the collaboration that the Clique is a model of, or any Agent Device managing a direct link to a View and/or control mechanism enabled device observing this Clique, becomes a member of an an Agent Collaboration which is modelled as a Clique of its own. The Agent Devices of this collaboration Clique coordinate, cross-reference and model the incoming external device state and interpret and disseminate outgoing device commands so that any user, not necessarily just the participants of the collaboration (Participants of the Clique that models this collaboration), can, if they have sufficient affinity, observe, and interact with the collaboration if a potential observer chose to observe a collaboration through Clique Space.
A given observer might later want to participate in the above collaboration. This given user might have connected a device which permits their participation in the specific collaboration's media as well as expressing to a Clique Space through an Identity, sufficient constraint (Limiting Constraint) affinity to participate in the Clique they are observing. In this case, they may either join this Clique with their given device, or, if possible, activate the given device remotely by sending commands through the Clique Space Agent Collaboration aether. The individual user would probably send these commands using the same Clique Space View enabled device through which they might be observing this Clique.
Necessarily, if the given user wishes to activate one device in a Clique Space mediated collaboration through another device, then this other device must 1. possess a View and/or control mechanism enabled device, and this capability must 2. be exposed through the device's Clique Space Connection, and 3. be expressed (projected) through an Identity which 4. furnishes the individual with this capacity to activate one device through another View and/or control mechanism enabled device.
While one individual may restrict remote device control only to devices expressed through Identities revolving around that individual's Axle (Account), such an individual may cede some remote control authority to other individuals in accordance with the constraint affinity these other individuals may possess with an Identity through which this device is expressed. Other individuals may only remotely control a device possessed by this individual only if, and to the extent that, this individual has permitted this activity to take place.
Now, to my point.
It's fairly straightforward: Clique Space's intended purpose is not to model or control a collaboration beyond those characteristics which determine whether a Participant can exist, or remain in existence in a Clique specific to this collaboration's media, and to the extent that the underlying Identity has sufficient Limiting Constraint affinity with the Clique, or is willing to make compromises (allow a Participant to acquire Limiting Constraints contrary to those of the underlying Identity) to achieve this affinity.
A Clique is not much more than a record of a collaboration; complicated exchange goes on in the specific collaboration's media as it would do regardless of whether any given device was connected to a Clique Space or not. Clique Space's ability to model, and perhaps to control a collaboration leaves the content of the collaborative exchange to the concern of the devices.
Mechanics that compose the various Clique Space collaboration media (the Agent Device as a Clique Space collaborator with a group of Agent Devices modelling a specific Agent Collaboration, or the Agent Device as an engager in a synapse with another Agent Device, or an Agent Device as a member of a Clique Space, or more generally, the Agent Device as a serving Agent Device interlocutor on a specific Clique Space with an another device in accordance to a medium specific to this exchange) are all modelled and controlled in the same abstract way: as a Clique composed of two or more Participants. The mechanics of these collaborations involving Agent Devices have a depth that Clique Space's abstract collaboration model does not penetrate because the relevant Media Profiles do not (cannot) expose all the functionality of the mechanics of these media through Connections generated from these Media Profiles; attempting to do so would introduce infinite regress.
Media Profile manufacturers may choose to represent some proportion of the collaboration's content exchange in Clique Space because doing so might be convenient. This might provide Clique Space users with the opportunity to model, and particularly, to get a Clique Space to automate the control of events on behalf of the devices' operators in accordance to the wishes of these users.
Hence, the value of Clique Space is in its ability to aggregate, model, and control devices in relation to the individual users which use Clique Space to assert their possession of them. Clique Space doesn't exist to provide users with an additional opportunity to participate in the totality of the content of a collaboration's exchange; external devices ordinarily (whether connected to a Clique Space or not) manifest external collaborations where the content exchange takes place in some medium specifically defined by the manufacturer of these devices, and which remains external and largely opaque to Clique Space.
First, a refresher on the general principle of Clique Space; one that perhaps does not pay respect to the subjects of federation or anonymous or unidentified (un-Identitied) Participants as they apply to Clique Space for the sake of simplicity, but never mind...
A collaboration is some cooperative activity going on between individuals. Each individual has some capacity to act, and uses a particular device capable of participating in this collaboration. The collaboration is going on within one or more particular media, and, when the collaboration is being modelled as a Clique, this collaboration can be observed by others, according to the degree to which these others have constraint affinity with the Clique and each of its member Participants.
Agent Devices are only special in that they are running instances of the Clique Space Agent Device code. Beyond this fact, there's nothing special about Agent Devices. Simply put, Agent Devices form Agent Collaborations, and Clique Spaces can exist in Agent Collaborations. An Agent Collaboration is modelled as a Clique within the Clique Space that exists as a result of an Agent Collaboration. Each Agent Device is controlled by an individual like any other device, and each Agent Device exposes functionality through the same control mechanism as any other device.
Clique Space users (individuals) connect other devices through Agent Devices which are members of a Clique Space to which they want to connect. All the devices one has connected to a Clique Space (including Agent Devices) generate activity in their own device specific way. Changes in device state are siphoned and modelled as activity in a Clique Space. Each connected device lets Clique Space know which other devices it is exchanging information with so the Clique Space can model this collaboration as a Clique. The exchange going on between the external device and the Agent Device to which it is connected is a collaboration like any other: it is modelled as a Clique - called the serving Agent Device's Clique.
For any given Clique, each Agent Device that is managing the direct link to an external device participating in the collaboration that the Clique is a model of, or any Agent Device managing a direct link to a View and/or control mechanism enabled device observing this Clique, becomes a member of an an Agent Collaboration which is modelled as a Clique of its own. The Agent Devices of this collaboration Clique coordinate, cross-reference and model the incoming external device state and interpret and disseminate outgoing device commands so that any user, not necessarily just the participants of the collaboration (Participants of the Clique that models this collaboration), can, if they have sufficient affinity, observe, and interact with the collaboration if a potential observer chose to observe a collaboration through Clique Space.
A given observer might later want to participate in the above collaboration. This given user might have connected a device which permits their participation in the specific collaboration's media as well as expressing to a Clique Space through an Identity, sufficient constraint (Limiting Constraint) affinity to participate in the Clique they are observing. In this case, they may either join this Clique with their given device, or, if possible, activate the given device remotely by sending commands through the Clique Space Agent Collaboration aether. The individual user would probably send these commands using the same Clique Space View enabled device through which they might be observing this Clique.
Necessarily, if the given user wishes to activate one device in a Clique Space mediated collaboration through another device, then this other device must 1. possess a View and/or control mechanism enabled device, and this capability must 2. be exposed through the device's Clique Space Connection, and 3. be expressed (projected) through an Identity which 4. furnishes the individual with this capacity to activate one device through another View and/or control mechanism enabled device.
While one individual may restrict remote device control only to devices expressed through Identities revolving around that individual's Axle (Account), such an individual may cede some remote control authority to other individuals in accordance with the constraint affinity these other individuals may possess with an Identity through which this device is expressed. Other individuals may only remotely control a device possessed by this individual only if, and to the extent that, this individual has permitted this activity to take place.
Now, to my point.
It's fairly straightforward: Clique Space's intended purpose is not to model or control a collaboration beyond those characteristics which determine whether a Participant can exist, or remain in existence in a Clique specific to this collaboration's media, and to the extent that the underlying Identity has sufficient Limiting Constraint affinity with the Clique, or is willing to make compromises (allow a Participant to acquire Limiting Constraints contrary to those of the underlying Identity) to achieve this affinity.
A Clique is not much more than a record of a collaboration; complicated exchange goes on in the specific collaboration's media as it would do regardless of whether any given device was connected to a Clique Space or not. Clique Space's ability to model, and perhaps to control a collaboration leaves the content of the collaborative exchange to the concern of the devices.
Mechanics that compose the various Clique Space collaboration media (the Agent Device as a Clique Space collaborator with a group of Agent Devices modelling a specific Agent Collaboration, or the Agent Device as an engager in a synapse with another Agent Device, or an Agent Device as a member of a Clique Space, or more generally, the Agent Device as a serving Agent Device interlocutor on a specific Clique Space with an another device in accordance to a medium specific to this exchange) are all modelled and controlled in the same abstract way: as a Clique composed of two or more Participants. The mechanics of these collaborations involving Agent Devices have a depth that Clique Space's abstract collaboration model does not penetrate because the relevant Media Profiles do not (cannot) expose all the functionality of the mechanics of these media through Connections generated from these Media Profiles; attempting to do so would introduce infinite regress.
Media Profile manufacturers may choose to represent some proportion of the collaboration's content exchange in Clique Space because doing so might be convenient. This might provide Clique Space users with the opportunity to model, and particularly, to get a Clique Space to automate the control of events on behalf of the devices' operators in accordance to the wishes of these users.
Hence, the value of Clique Space is in its ability to aggregate, model, and control devices in relation to the individual users which use Clique Space to assert their possession of them. Clique Space doesn't exist to provide users with an additional opportunity to participate in the totality of the content of a collaboration's exchange; external devices ordinarily (whether connected to a Clique Space or not) manifest external collaborations where the content exchange takes place in some medium specifically defined by the manufacturer of these devices, and which remains external and largely opaque to Clique Space.
Thursday, June 21, 2012
Deliberating constraints once more... and their relevance in each Element
The question of what constraints actually mean in each Element is still unresolved. Currently, the problem appears to exhibit the following solution.
Limiting Constraint "values" are assigned to any Element in accordance to Enabling Constraint "parameters" given in Media Profiles. Each Limiting Constraint appears to be uniquely identified by some concatenation of the Element which contains the Limiting Constraint, the Media Profile which contains the Enabling Constraint, and the parameter within the Enabling Constraint which the given Limiting Constraint describes. It appears that Limiting Constraints only describe a discrete parameter in an Enabling Constraint; hence, one or more Limiting Constraints will be needed to fully describe any given Enabling Constraint.
While any Element can contain Limiting Constraints, the following would appear to be a reasonable convenience for their expression.
Although Media and Account Profiles, the Axle (its still fairly appealing), the Connection and the Affiliation carry Limiting Constraints, these Limiting Constraints do not have to be consistent beyond a necessity that no more than one Limiting Constraint must refer to any Enabling Constraint parameter within any one given Element from this category of Elements.
The Identity however, identifies a coherent set of characteristics of an individual. Therefore, an Identity is a composition of Limiting Constraints set in the category of Elements defined above which is capable of generating Participants which do not internally contradict. Such a self-contradictory Participant would be a paradox not only in the given Participant, but from the Identity from which it was generated. Hence, from a moral perspective in normal discourse away from Clique Space(TM), any individual projecting an identity to others which has a self-contradictory nature would create deep concerns for the other individuals; which characteristics would be the correct reflection of the identity?
However, where necessary, and perhaps if possible (what exactly that means isn't clear enough to describe at this moment), some interactions will take place where one or more Participants may need to drop or acquire certain characteristics which contradict the expression of one's Identity. This may be so because two Identities may not be capable of generating Participants in a Clique unless some of the Participants (those who express contrary characteristics in their Identity) agree to expressing a combination of characteristics contrary to their own; a set of characteristics which would allow these one or more Identities to generate Participants in a Clique that has a contradictory mode. In order for these Participants to be generated, the one or more opposing parties will have to (as necessary) change or withhold expression of characteristics from their Identities that would cause a constraint contradiction.
In a particular example, a third party (Participant), being the Clique's Owner, sets the Clique's mode, and can accommodate adjustment in the expression of Identity characteristics of one or both of the other Participants provided the other parties have given their consent. This situation might occur where a third party is a legal officer appointed to sort out a dispute between the other two parties who otherwise can't tolerate knowledge of the other's existence.
So, in order for Clique Space to function as envisaged, I currently believe that the Identity must select for expression, those Limiting Constraints from component Elements, which collectively, do not express a contradiction. However, where such a contradiction is evident in the Identities of two or more parties, consent can be obtained from these other parties to allow contrary Limiting Constraints when requested by the Clique's Owner as a condition to the generation of a Participant for the given Clique, and therefore, membership of the collaboration being modelled by this Clique. I know of nothing else that systematically models "consensual compromise" like this.
No Participant is generated from any Identity that does not accept a compromise which will allow their participation in a Clique. This, I contend, is as it is in life: one makes compromises when one participates in any collaborative effort; one nearly always has to make some personal sacrifice for some collective coherence.
Clique Space has many points; but it could be said that one of them is to model to other individuals, the compromises one individual has made, and appears willing to make in order to participate in a collective activity.
Limiting Constraint "values" are assigned to any Element in accordance to Enabling Constraint "parameters" given in Media Profiles. Each Limiting Constraint appears to be uniquely identified by some concatenation of the Element which contains the Limiting Constraint, the Media Profile which contains the Enabling Constraint, and the parameter within the Enabling Constraint which the given Limiting Constraint describes. It appears that Limiting Constraints only describe a discrete parameter in an Enabling Constraint; hence, one or more Limiting Constraints will be needed to fully describe any given Enabling Constraint.
While any Element can contain Limiting Constraints, the following would appear to be a reasonable convenience for their expression.
Although Media and Account Profiles, the Axle (its still fairly appealing), the Connection and the Affiliation carry Limiting Constraints, these Limiting Constraints do not have to be consistent beyond a necessity that no more than one Limiting Constraint must refer to any Enabling Constraint parameter within any one given Element from this category of Elements.
The Identity however, identifies a coherent set of characteristics of an individual. Therefore, an Identity is a composition of Limiting Constraints set in the category of Elements defined above which is capable of generating Participants which do not internally contradict. Such a self-contradictory Participant would be a paradox not only in the given Participant, but from the Identity from which it was generated. Hence, from a moral perspective in normal discourse away from Clique Space(TM), any individual projecting an identity to others which has a self-contradictory nature would create deep concerns for the other individuals; which characteristics would be the correct reflection of the identity?
However, where necessary, and perhaps if possible (what exactly that means isn't clear enough to describe at this moment), some interactions will take place where one or more Participants may need to drop or acquire certain characteristics which contradict the expression of one's Identity. This may be so because two Identities may not be capable of generating Participants in a Clique unless some of the Participants (those who express contrary characteristics in their Identity) agree to expressing a combination of characteristics contrary to their own; a set of characteristics which would allow these one or more Identities to generate Participants in a Clique that has a contradictory mode. In order for these Participants to be generated, the one or more opposing parties will have to (as necessary) change or withhold expression of characteristics from their Identities that would cause a constraint contradiction.
In a particular example, a third party (Participant), being the Clique's Owner, sets the Clique's mode, and can accommodate adjustment in the expression of Identity characteristics of one or both of the other Participants provided the other parties have given their consent. This situation might occur where a third party is a legal officer appointed to sort out a dispute between the other two parties who otherwise can't tolerate knowledge of the other's existence.
So, in order for Clique Space to function as envisaged, I currently believe that the Identity must select for expression, those Limiting Constraints from component Elements, which collectively, do not express a contradiction. However, where such a contradiction is evident in the Identities of two or more parties, consent can be obtained from these other parties to allow contrary Limiting Constraints when requested by the Clique's Owner as a condition to the generation of a Participant for the given Clique, and therefore, membership of the collaboration being modelled by this Clique. I know of nothing else that systematically models "consensual compromise" like this.
No Participant is generated from any Identity that does not accept a compromise which will allow their participation in a Clique. This, I contend, is as it is in life: one makes compromises when one participates in any collaborative effort; one nearly always has to make some personal sacrifice for some collective coherence.
Clique Space has many points; but it could be said that one of them is to model to other individuals, the compromises one individual has made, and appears willing to make in order to participate in a collective activity.
Subscribe to:
Posts (Atom)